Lambertus, Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file. Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ? So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard. Thanks for having a look at this. Cheers Patrik
Am Freitag, 31. Januar 2014, 15:37:50 schrieb Patrik Brunner:
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
I think is better to use a link, named bounds.zip, to the latest file, with my python script i check for the date in latest/ if config.get('navmap', 'sea') == "latest": target = http.client.HTTPConnection("osm2.pleiades.uni-wuppertal.de") target.request("GET", "/sea/latest/") htmlcontent = target.getresponse() data = htmlcontent.read() data = data.decode('utf8') pattern = re.compile('sea_201\d{5}.zip') sea_rev_pre = sorted(pattern.findall(data), reverse=True)[1] sea_rev = os.path.splitext(os.path.basename(sea_rev_pre))[0] target.close() config.set('navmap', 'sea_rev', (sea_rev)) m2c Bernd -- amarok2 now playing:
link, redirect, file.... whatever... ... just something wget is able to fetch without bigger troubles and not much code around it. ;-) I'll use the version.txt file inside the zip file for version checking lateron. Cheers Patrik On 31.01.2014 16:29, Bernd Weigelt wrote:
Am Freitag, 31. Januar 2014, 15:37:50 schrieb Patrik Brunner:
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard. I think is better to use a link, named bounds.zip, to the latest file, with my python script i check for the date in latest/
if config.get('navmap', 'sea') == "latest": target = http.client.HTTPConnection("osm2.pleiades.uni-wuppertal.de") target.request("GET", "/sea/latest/") htmlcontent = target.getresponse() data = htmlcontent.read() data = data.decode('utf8') pattern = re.compile('sea_201\d{5}.zip') sea_rev_pre = sorted(pattern.findall(data), reverse=True)[1] sea_rev = os.path.splitext(os.path.basename(sea_rev_pre))[0] target.close()
config.set('navmap', 'sea_rev', (sea_rev))
m2c Bernd
This is not hard to achieve and I'll add an easier link with the next update. On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Good news.... many thanks, Lambertus. Anything fixed (not changing with different releases) will do it. Regards Patrik On 31.01.2014 19:18, Lambertus wrote:
This is not hard to achieve and I'll add an easier link with the next update.
On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Lambertus, I've seen that the 'bounds' is already handled with the new concept: http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip But the sea boundaries are not yet done the same way even though there is a new version of that file in the date specific directory: http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea_20140127.zip Will this be done later or did something go 'wrong' with the new build process of the sea boundaries ? ... don't want to be stressing you, it's just a question. Thanks Patrik On 31.01.2014 19:18, Lambertus wrote:
This is not hard to achieve and I'll add an easier link with the next update.
On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Yes something went wrong ... I tried to optimize my build chain by parallelizing things, but I managed to schedule two processes that want all available RAM at the same time. That didn't go well. :p So I killed the sea generator and will run that one later. On 04-02-14 18:42, Patrik Brunner wrote:
Lambertus,
I've seen that the 'bounds' is already handled with the new concept:
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip
But the sea boundaries are not yet done the same way even though there is a new version of that file in the date specific directory:
http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea_20140127.zip
Will this be done later or did something go 'wrong' with the new build process of the sea boundaries ? ... don't want to be stressing you, it's just a question.
Thanks Patrik
On 31.01.2014 19:18, Lambertus wrote:
This is not hard to achieve and I'll add an easier link with the next update.
On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ok, thanks.... sorry to be a pain... ;-) On 04.02.2014 18:52, Lambertus wrote:
Yes something went wrong ... I tried to optimize my build chain by parallelizing things, but I managed to schedule two processes that want all available RAM at the same time. That didn't go well. :p
So I killed the sea generator and will run that one later.
On 04-02-14 18:42, Patrik Brunner wrote:
Lambertus,
I've seen that the 'bounds' is already handled with the new concept:
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip
But the sea boundaries are not yet done the same way even though there is a new version of that file in the date specific directory:
http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea_20140127.zip
Will this be done later or did something go 'wrong' with the new build process of the sea boundaries ? ... don't want to be stressing you, it's just a question.
Thanks Patrik
On 31.01.2014 19:18, Lambertus wrote:
This is not hard to achieve and I'll add an easier link with the next update.
On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
No worries! :) On 04-02-14 18:55, Patrik Brunner wrote:
ok, thanks.... sorry to be a pain... ;-)
On 04.02.2014 18:52, Lambertus wrote:
Yes something went wrong ... I tried to optimize my build chain by parallelizing things, but I managed to schedule two processes that want all available RAM at the same time. That didn't go well. :p
So I killed the sea generator and will run that one later.
On 04-02-14 18:42, Patrik Brunner wrote:
Lambertus,
I've seen that the 'bounds' is already handled with the new concept:
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip
But the sea boundaries are not yet done the same way even though there is a new version of that file in the date specific directory:
http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea_20140127.zip
Will this be done later or did something go 'wrong' with the new build process of the sea boundaries ? ... don't want to be stressing you, it's just a question.
Thanks Patrik
On 31.01.2014 19:18, Lambertus wrote:
This is not hard to achieve and I'll add an easier link with the next update.
On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Lambertus, Is the latest bounds file correct? It is much smaller (72 Mb) than the previous ones (412 Mb)
On 04-02-14 18:55, Patrik Brunner wrote:
ok, thanks.... sorry to be a pain... ;-)
On 04.02.2014 18:52, Lambertus wrote:
Yes something went wrong ... I tried to optimize my build chain by parallelizing things, but I managed to schedule two processes that want all available RAM at the same time. That didn't go well. :p
So I killed the sea generator and will run that one later.
On 04-02-14 18:42, Patrik Brunner wrote:
Lambertus,
I've seen that the 'bounds' is already handled with the new concept:
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip But the sea boundaries are not yet done the same way even though there is a new version of that file in the date specific directory:
http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea_20140127.zip Will this be done later or did something go 'wrong' with the new build process of the sea boundaries ? ... don't want to be stressing you, it's just a question.
Thanks Patrik
On 31.01.2014 19:18, Lambertus wrote:
This is not hard to achieve and I'll add an easier link with the next update.
On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ligfietser wrote
Lambertus, Is the latest bounds file correct? It is much smaller (72 Mb) than the previous ones (412 Mb)
I would like to second this question and therefore "push it up" again. -- View this message in context: http://gis.19327.n5.nabble.com/bounds-and-sea-on-pleiades-tp5794898p5796043.... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Tue, Feb 11, UliBaer wrote:
ligfietser wrote
Lambertus, Is the latest bounds file correct? It is much smaller (72 Mb) than the previous ones (412 Mb)
I would like to second this question and therefore "push it up" again.
My ones (http://osm.thkukuk.de/data/) are still about 430 MB. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Sorry for the late response. Looking at the logging it appears that the process crashed. I've added some checks to (hopefully) prevent uploading such files in the future. The current map update has to finish before I can start another attempt. In the meantime the latest is replaced by a previous version. On 09-02-14 16:09, Minko wrote:
Lambertus, Is the latest bounds file correct? It is much smaller (72 Mb) than the previous ones (412 Mb)
On 04-02-14 18:55, Patrik Brunner wrote:
ok, thanks.... sorry to be a pain... ;-)
On 04.02.2014 18:52, Lambertus wrote:
Yes something went wrong ... I tried to optimize my build chain by parallelizing things, but I managed to schedule two processes that want all available RAM at the same time. That didn't go well. :p
So I killed the sea generator and will run that one later.
On 04-02-14 18:42, Patrik Brunner wrote:
Lambertus,
I've seen that the 'bounds' is already handled with the new concept:
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip But the sea boundaries are not yet done the same way even though there is a new version of that file in the date specific directory:
http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea_20140127.zip Will this be done later or did something go 'wrong' with the new build process of the sea boundaries ? ... don't want to be stressing you, it's just a question.
Thanks Patrik
On 31.01.2014 19:18, Lambertus wrote:
This is not hard to achieve and I'll add an easier link with the next update.
On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ok, found it. To my casual reading acutal and actual is the same, though bash things otherwise.... New versions for sea and bounds are available. On 11/02/2014 19:58, Lambertus wrote:
Sorry for the late response.
Looking at the logging it appears that the process crashed. I've added some checks to (hopefully) prevent uploading such files in the future. The current map update has to finish before I can start another attempt. In the meantime the latest is replaced by a previous version.
On 09-02-14 16:09, Minko wrote:
Lambertus, Is the latest bounds file correct? It is much smaller (72 Mb) than the previous ones (412 Mb)
On 04-02-14 18:55, Patrik Brunner wrote:
ok, thanks.... sorry to be a pain... ;-)
On 04.02.2014 18:52, Lambertus wrote:
Yes something went wrong ... I tried to optimize my build chain by parallelizing things, but I managed to schedule two processes that want all available RAM at the same time. That didn't go well. :p
So I killed the sea generator and will run that one later.
On 04-02-14 18:42, Patrik Brunner wrote:
Lambertus,
I've seen that the 'bounds' is already handled with the new concept:
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip But the sea boundaries are not yet done the same way even though there is a new version of that file in the date specific directory:
http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea_20140127.zip Will this be done later or did something go 'wrong' with the new build process of the sea boundaries ? ... don't want to be stressing you, it's just a question.
Thanks Patrik
On 31.01.2014 19:18, Lambertus wrote:
This is not hard to achieve and I'll add an easier link with the next update.
On 31-01-14 15:37, Patrik Brunner wrote:
Lambertus,
Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file.
Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries quite hard..... there's no need to change these files, but wouldn't it be possible to have a file just called 'bounds.zip' and 'sea.zip' (and respective for bz2 files) being a link to the actually latest file ?
So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience it shouldn't be that hard.
Thanks for having a look at this. Cheers Patrik _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (6)
-
Bernd Weigelt -
Lambertus -
Minko -
Patrik Brunner -
Thorsten Kukuk -
UliBaer