<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hi Ticker,</p>
<p><br>
</p>
<p>A quick look shows that the problem is the mapping and not Mkgmap, there are no relationships in play there, the lakes should be inners of the scrub etc etc. I have done quite a bit of mapping on OSM, and I am still not up to speed on relationships ( inners
outers and how to specify correctly ) I do see the problem, but that is quite a complex area to set about sorting out.</p>
<p><br>
</p>
<p>Gary<br>
</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>From:</b> mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on behalf of Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
<b>Sent:</b> 01 August 2016 13:47<br>
<b>To:</b> mkgmap-dev@lists.mkgmap.org.uk<br>
<b>Subject:</b> Re: [mkgmap-dev] Option to output polygons in size order</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Gary<br>
<br>
I'm looking at the scrub area (osm 405465966) at N51.06838 W001.30381<br>
In this area are 3 lakes: Peewit (sorry - didn't note the OSM ref),<br>
Kingham (osm 45437710) and Judges (osm 45437709).<br>
<br>
Before Gerd's patch to sort by size, none of the lakes showed at high<br>
resolution - they were overwritten by the scrub. After the patch my<br>
device shows Peewit and Kingham, but Judges is still overwritten.<br>
I can't see any reason why 2 of the lakes would now show (be rendered<br>
last) and 1 is rendered before the scrub. <br>
<br>
I don't think any of them<br>
were part of a multi-polygon relationship - It occurred to me that if<br>
the scrub was having to be cut-up to expose holes because it as an<br>
outer in some other relationship, and the sorting by size was based on<br>
the pieces rather than the original area, the lake could be larger than<br>
(some of) these pieces of the background scrub and hence they would<br>
show instead.<br>
<br>
With the patch, I am seeing a lot more area features. eg there is a<br>
college nearby (N51.06971 W001.32724) that encompasses playing fields<br>
and woods - I now see both.<br>
<br>
Ticker<br>
<br>
On Sun, 2016-07-31 at 13:51 +0000, Gary Bamford wrote:<br>
> Hi Ticker,<br>
> <br>
> Garmins approach to maps is layered, OSM is built on relationships,<br>
> both have their flaws, and converting from relationships to layers is<br>
> problematic at best.<br>
> <br>
> Point me to an area you are having problems with and i will check it<br>
> out to see what my set up shows,<br>
> <br>
> Regards<br>
> <br>
> Gary<br>
> <br>
> <br>
> From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on behalf<br>
> of Ticker Berkin <ticker@jagIT.co.uk><br>
> Sent: 28 July 2016 16:41<br>
> To: mkgmap-dev@lists.mkgmap.org.uk<br>
> Subject: Re: [mkgmap-dev] Option to output polygons in size order<br>
> <br>
> Hi Gary<br>
> <br>
> For my problem areas I'll look at the OSM relationships in exact<br>
> detail<br>
> - I'm only just working out how to do this.<br>
> <br>
> Judging by how OpenStreetMap.org displays an area with overlapping<br>
> polygons not in a relationship, it is making a consistent choice<br>
> about<br>
> how to show them. I haven't been able to find anything in the OSM<br>
> data<br>
> structures that defines what hides what, but, since Gerd's patch to<br>
> sort by size, I'm seeing a lot more that matches OpenStreetMap, but<br>
> not<br>
> completely.<br>
> <br>
> The type of scenario you describe could be specified with nested<br>
> multi-polygon relationships (ie the hole/inner of one relationship is<br>
> the outer of another relationship) but this would be complicated and<br>
> error-prone and, when taken to its conclusion (eg every building<br>
> punching a hole in its area, etc etc) would be totally unwieldy.<br>
> <br>
> Ticker<br>
> <br>
> On Thu, 2016-07-28 at 13:11 +0000, Gary Bamford wrote:<br>
> > Hi Ticker.<br>
> > <br>
> > When i see any errors they are consistent, by consistent I mean,<br>
> the<br>
> > final result is always the same, whatever the visible error is. <br>
> > <br>
> > when I see them, I check them out on OSM, to see how things are<br>
> > related on there.<br>
> > <br>
> > There are some tricky ones, and I am not sure what the "best<br>
> > practice" approach should be,.<br>
> > <br>
> > Imagine a residential area, within that area is a golf course, on<br>
> the<br>
> > golf course there are bunkers, also a lake and in the middle of the<br>
> > lake is an island which has a wood on it, and a pond and also more<br>
> > sand( bunkers ), I am not sure what the relationships on OSM are<br>
> > meant to be, but from what I have seen that is where most of the<br>
> > problems lie, it is a lack of that consistent approach that causes<br>
> > the problems,<br>
> > <br>
> > Regards<br>
> > <br>
> > Gary<br>
> > <br>
> > <br>
> > From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on behalf<br>
> > of Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
> > Sent: 24 July 2016 17:59<br>
> > To: mkgmap-dev@lists.mkgmap.org.uk<br>
> > Subject: Re: [mkgmap-dev] Option to output polygons in size order<br>
> > <br>
> > Hi Gary<br>
> > <br>
> > I wasn't proposing to change priority of anything or make rendering<br>
> > priority lists, just to change the order of polygons in the output<br>
> > file. I don't see that this would make any difference to the map<br>
> > size.<br>
> > <br>
> > You mention the "existing system" and the occasional problems you<br>
> > find<br>
> > when you have to correct the OSM data. How does this system work<br>
> > correctly most of the time, showing, say, lakes in marshland<br>
> > correctly,<br>
> > except, just occasionally, the rendering of the lake flashes<br>
> briefly<br>
> > before being hidden by the rendering of the marshland.<br>
> > <br>
> > Ticker<br>
> > <br>
> > On Sun, 2016-07-24 at 05:44 +0000, Gary Bamford wrote:<br>
> > > Hi Ticker.<br>
> > > <br>
> > > I have been think about this, and changing the priority to be<br>
> based<br>
> > > on polygon size would not only slowdown the gps rendering it<br>
> would<br>
> > > also increase the memory size of the final map. I am also not<br>
> sure<br>
> > it<br>
> > > would work correctly.<br>
> > > <br>
> > > Imagine a scenario whereby you have a series of partially<br>
> > overlapping<br>
> > > polygons, with some polygons fully inside another polygon, some<br>
> of<br>
> > > the overlapping polygons could be the same size, but given they<br>
> > > aren't using size as a guide you would end up having to reference<br>
> > > each polygon individually in a rendering priority list, this<br>
> could<br>
> > > easily end up being a massive list, taking a huge amount of time<br>
> to<br>
> > > process.<br>
> > > <br>
> > > I do think the existing system works, but I also know that some<br>
> of<br>
> > > the existing base data on OSM needs to be corrected. so that<br>
> multi<br>
> > > polygons have been set up correctly.<br>
> > > <br>
> > > All my maps are of the UK, and I have no real problems with<br>
> > polygons,<br>
> > > except for where I find the base data to be incorrect, and to<br>
> find<br>
> > > these errors, you have to go them them individually. I am sure<br>
> Gerd<br>
> > > will correct me on this, but if you don't specify a typ/style<br>
> file<br>
> > > then it will use the default typ/style. <br>
> > > <br>
> > > A very useful change in mkgmap would be to indicate a a<br>
> > multipolygon<br>
> > > that would never be visible due to draw order and or bad<br>
> > multipolygon<br>
> > > data, but this is more about data integrity than it is about<br>
> > > rendering a map. So I am not sure if it fits within the mkgmap<br>
> > remit.<br>
> > > <br>
> > > Regards<br>
> > > <br>
> > > Gary<br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on<br>
> behalf<br>
> > > of Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
> > > Sent: 23 July 2016 19:44<br>
> > > To: mkgmap-dev@lists.mkgmap.org.uk<br>
> > > Subject: Re: [mkgmap-dev] Option to output polygons in size order<br>
> > > <br>
> > > Hi Gary<br>
> > > <br>
> > > Experimenting with my device, using the in-build area<br>
> > representations<br>
> > > (ie no TYP section in my map) it seems as if different areas<br>
> don't<br>
> > > have<br>
> > > a particular priority; it just draws things as they arrive,<br>
> > > overwriting<br>
> > > as it goes along.<br>
> > > <br>
> > > What I'm hoping for, as a new option, is that (individual)<br>
> polygons<br>
> > > are<br>
> > > output in size order, big to small. Then all your examples work<br>
> > > perfectly, regardless of any order that OSM generates.<br>
> > > <br>
> > > I'm just guessing that splitter effects the order of polygons<br>
> that<br>
> > > cross tile boundaries, because the big islands in the input map<br>
> > that<br>
> > > are getting split mask all the land features, but for other<br>
> islands<br>
> > I<br>
> > > am getting greenery, lakes...<br>
> > > <br>
> > > Ticker<br>
> > > <br>
> > > On Sat, 2016-07-23 at 18:52 +0000, Gary Bamford wrote:<br>
> > > > Hi Ticker,<br>
> > > > <br>
> > > > The draw order dies have an effect, the Legend is a pretty slow<br>
> > > > device ( I can see mine drawing and then overwriting ), but<br>
> this<br>
> > > can<br>
> > > > only work correctly if the data on OSM is correct, the Multi<br>
> > > polygons<br>
> > > > is the base effect, if this is wrong, then it doesn't matter<br>
> what<br>
> > > the<br>
> > > > Garmin device tries to do,.<br>
> > > > <br>
> > > > let's assume the multi polygons are not correct, and they don't<br>
> > > refer<br>
> > > > to each other.<br>
> > > > <br>
> > > > Think about it, imagine a big wood and within it a lake, lets<br>
> say<br>
> > > the<br>
> > > > wood is defined by an area, and so is the lake, in this case<br>
> you<br>
> > > > would want the lake to have a higher draw order than the<br>
> forest,.<br>
> > > > <br>
> > > > now imagine a lake with a forest in the middle of it, in this<br>
> > case<br>
> > > > you would want the forest to have a higher draw order than the<br>
> > > lake.<br>
> > > > <br>
> > > > Basically you can't have both, the multiploygon has to be<br>
> correct<br>
> > > > with it's relationships,.<br>
> > > > <br>
> > > > if the OSM information is correct draw order works fine.<br>
> > > > <br>
> > > > Not sure what you mean by splitter delaying things.<br>
> > > > <br>
> > > > Gary<br>
> > > > <br>
> > > > From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on<br>
> > behalf<br>
> > > > of Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
> > > > Sent: 23 July 2016 18:42<br>
> > > > To: mkgmap-dev@lists.mkgmap.org.uk<br>
> > > > Subject: Re: [mkgmap-dev] Option to output polygons in size<br>
> order<br>
> > > > <br>
> > > > Hi<br>
> > > > <br>
> > > > I'm sure that the order in the map has some effect on the<br>
> Legend;<br>
> > > as<br>
> > > > I<br>
> > > > zoom in or scroll across areas with greenery they appear<br>
> briefly<br>
> > > and<br>
> > > > are then cleared, by the island polygon that covers everything,<br>
> > as<br>
> > > it<br>
> > > > starts drawing the ways...<br>
> > > > <br>
> > > > Generally, the openStreetMap data order is OK, but I have found<br>
> > > > examples where there are lakes, within the same meadow, that<br>
> > occur<br>
> > > > both<br>
> > > > before and after it. Not sure if this is related to multi<br>
> > -polygons,<br>
> > > > but<br>
> > > > if sorting was performed on the individual polygons there<br>
> > wouldn't<br>
> > > be<br>
> > > > any problem.<br>
> > > > <br>
> > > > Also it looks like splitter is delaying the British Isles (and<br>
> > > other<br>
> > > > large) polygons because they occurs on multiple tiles.<br>
> > > > <br>
> > > > Typ _drawOrder cannot solve the problem when there are nested<br>
> > > > polygons<br>
> > > > with more that one instance of the same type, whereas drawing<br>
> > outer<br>
> > > > ones first solves it completely.<br>
> > > > <br>
> > > > I have seen mention somewhere that areas with the same<br>
> _draworder<br>
> > > are<br>
> > > > rendered in file order<br>
> > > > <br>
> > > > Ticker<br>
> > > > <br>
> > > > On Sat, 2016-07-23 at 17:17 +0000, Gary Bamford wrote:<br>
> > > > > Hi Ticker/Gerd<br>
> > > > > <br>
> > > > > The draw order does work for the Legend ( it is the device I<br>
> > have<br>
> > > > ).<br>
> > > > > I also came across problems with multiple polygons, the<br>
> problem<br>
> > > can<br>
> > > > > be one of several things, not all multi polygons are correct<br>
> on<br>
> > > > > openstreetmap, I cam across one today "fairhaven lake" golf<br>
> > > > course,<br>
> > > > > was hiding, due to draw order, but the problem was, it is<br>
> > > contained<br>
> > > > > within a polygon for a residential area, so I had to change<br>
> the<br>
> > > > data<br>
> > > > > on openstreetmap, to make it an inner polygon. when i<br>
> download<br>
> > > the<br>
> > > > > new OSM data I expect it to work correctly.<br>
> > > > > <br>
> > > > > if the polygons are set correctly on openstreetmap, then draw<br>
> > > order<br>
> > > > > will will as you expect. <br>
> > > > > <br>
> > > > > Gary<br>
> > > > > <br>
> > > > > From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on<br>
> > > behalf<br>
> > > > > of Gerd Petermann <GPetermann_muenchen@hotmail.com><br>
> > > > > Sent: 23 July 2016 17:05<br>
> > > > > To: Development list for mkgmap<br>
> > > > > Subject: Re: [mkgmap-dev] Option to output polygons in size<br>
> > order<br>
> > > > > <br>
> > > > > Hi Ticker,<br>
> > > > > <br>
> > > > > are you sure that the order matters? I've never heard that<br>
> > theory<br>
> > > > > and I would be surprised when that is true.<br>
> > > > > The normal way to handle the draw order is to use a typ file,<br>
> > not<br>
> > > > > sure<br>
> > > > > if this works on your device, but it seems to work well for<br>
> > > others.<br>
> > > > > <br>
> > > > > Gerd<br>
> > > > > Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im<br>
> > > Auftrag<br>
> > > > > von Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
> > > > > Gesendet: Samstag, 23. Juli 2016 18:45:59<br>
> > > > > An: mkgmap development<br>
> > > > > Betreff: [mkgmap-dev] Option to output polygons in size order<br>
> > > > > <br>
> > > > > Hi<br>
> > > > > <br>
> > > > > I'm using splitter-r437/mkgmap-r3676 to make a map for Etrex<br>
> > > Legend<br>
> > > > > from british-isles-latest.osm.pbf from geofabric.de.<br>
> > > > > <br>
> > > > > Using "default" style and not using a TYP file, no land<br>
> > features<br>
> > > > > (woods,marsh,green) show because an island polygon for<br>
> "British<br>
> > > > > Isles"<br>
> > > > > is rendered near the end, on top of everything else. I guess<br>
> > that<br>
> > > > the<br>
> > > > > Etrex has all area types as the same draworder and renders<br>
> them<br>
> > > in<br>
> > > > > file<br>
> > > > > order.<br>
> > > > > <br>
> > > > > I presume I could use TYP / _DrawOrder to change this<br>
> behaviour<br>
> > > > > slightly but I keep finding examples of woods in islands in<br>
> > lakes<br>
> > > > in<br>
> > > > > marsh in islands etc etc, so _DrawOrder can't solve the<br>
> > problem.<br>
> > > > > <br>
> > > > > What would make everything show correctly would be to output<br>
> > > > polygons<br>
> > > > > in size order, largest to smallest. Could this be done<br>
> easily?<br>
> > > > either<br>
> > > > > in splitter then --preserve-element-order, or in mkgmap,<br>
> > possibly<br>
> > > > > after<br>
> > > > > style processing because there will be a lot fewer polygons<br>
> at<br>
> > > this<br>
> > > > > point.<br>
> > > > > <br>
> > > > > Regards<br>
> > > > > Ticker Berkin<br>
> > > > > <br>
> > > > > _______________________________________________<br>
> > > > > mkgmap-dev mailing list<br>
> > > > > mkgmap-dev@lists.mkgmap.org.uk<br>
> > > > > <a id="LPlnk222228" href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
<div style="margin-bottom: 20px; overflow: auto; width: 100%; text-indent: 0px;" id="LPBorder_GT_14700601961990.2511269014480514">
<table style="width: 90%; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top: 1px dotted rgb(200, 200, 200); border-bottom: 1px dotted rgb(200, 200, 200);" id="LPContainer_14700601961850.10571197104428032" cellspacing="0">
<tbody>
<tr style="border-spacing: 0px;" valign="top">
<td colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;" id="TextCell_14700601961950.980174060337157">
<div id="LPRemovePreviewContainer_14700601961950.6489996941114557"></div>
<div style="top: 0px; color: rgb(0, 75, 139); font-weight: 400; font-size: 21px; font-family: "wf_segoe-ui_light","Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; line-height: 21px;" id="LPTitle_14700601961950.6982237258525709">
<a target="_blank" href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" style="text-decoration: none;" id="LPUrlAnchor_14700601961970.025391245356047643">mkgmap-dev Info Page</a></div>
<div style="margin: 10px 0px 16px; color: rgb(102, 102, 102); font-weight: 400; font-family: "wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; font-size: 14px; line-height: 14px;" id="LPMetadata_14700601961970.2059294036742385">
www.mkgmap.org.uk</div>
<div style="display: block; color: rgb(102, 102, 102); font-weight: 400; font-family: "wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hidden;" id="LPDescription_14700601961980.5025966714976328">
This is a general development list for mkgmap. To see the collection of prior postings to the list, visit the mkgmap-dev Archives.</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
> mkgmap-dev Info Page <a href="http://www.mkgmap.org.uk">www.mkgmap.org.uk</a><br>
> This is a general development list for mkgmap. To see the collection<br>
> of prior postings to the list, visit the mkgmap-dev Archives.<br>
> <br>
> > mkgmap-dev Info Page <a href="http://www.mkgmap.org.uk">www.mkgmap.org.uk</a><br>
> > This is a general development list for mkgmap. To see the<br>
> collection<br>
> > of prior postings to the list, visit the mkgmap-dev Archives.<br>
> > <br>
> > > mkgmap-dev Info Page <a href="http://www.mkgmap.org.uk">www.mkgmap.org.uk</a><br>
> > > This is a general development list for mkgmap. To see the<br>
> > collection<br>
> > > of prior postings to the list, visit the mkgmap-dev Archives.<br>
> > > <br>
> > > > mkgmap-dev Info Page <a href="http://www.mkgmap.org.uk">www.mkgmap.org.uk</a><br>
> > > > This is a general development list for mkgmap. To see the<br>
> > > collection<br>
> > > > of prior postings to the list, visit the mkgmap-dev Archives.<br>
> > > > <br>
> > > > > mkgmap-dev Info Page <a href="http://www.mkgmap.org.uk">www.mkgmap.org.uk</a><br>
> > > > > This is a general development list for mkgmap. To see the<br>
> > > > collection<br>
> > > > > of prior postings to the list, visit the mkgmap-dev Archives.<br>
> > > > > <br>
> > > > > _______________________________________________<br>
> > > > > mkgmap-dev mailing list<br>
> > > > > mkgmap-dev@lists.mkgmap.org.uk<br>
> > > > > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> > > > _______________________________________________<br>
> > > > mkgmap-dev mailing list<br>
> > > > mkgmap-dev@lists.mkgmap.org.uk<br>
> > > > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> > > > _______________________________________________<br>
> > > > mkgmap-dev mailing list<br>
> > > > mkgmap-dev@lists.mkgmap.org.uk<br>
> > > > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> > > _______________________________________________<br>
> > > mkgmap-dev mailing list<br>
> > > mkgmap-dev@lists.mkgmap.org.uk<br>
> > > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> > > _______________________________________________<br>
> > > mkgmap-dev mailing list<br>
> > > mkgmap-dev@lists.mkgmap.org.uk<br>
> > > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> > _______________________________________________<br>
> > mkgmap-dev mailing list<br>
> > mkgmap-dev@lists.mkgmap.org.uk<br>
> > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> > _______________________________________________<br>
> > mkgmap-dev mailing list<br>
> > mkgmap-dev@lists.mkgmap.org.uk<br>
> > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> _______________________________________________<br>
> mkgmap-dev mailing list<br>
> mkgmap-dev@lists.mkgmap.org.uk<br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> _______________________________________________<br>
> mkgmap-dev mailing list<br>
> mkgmap-dev@lists.mkgmap.org.uk<br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
_______________________________________________<br>
mkgmap-dev mailing list<br>
mkgmap-dev@lists.mkgmap.org.uk<br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
</div>
</span></font></div>
</div>
</body>
</html>