Re: [mkgmap-dev] FW: AW: RE: computing power mdx/mdr
Hi Steve, okay, in that case I think you should commit this patch with the corrected method name. I've tested the performance with a set of files created with Arndts style, and peak memory decreased from 208 MB to 175 MB. Gerd Date: Fri, 27 Feb 2015 23:57:35 + From: st...@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] FW: AW: RE: computing power mdx/mdr Hi Gerd I think in the old algo the bytes of the suffix were compared at last, with the patch they are compared before the prefix. Ah, right. I think that in both cases all streets could be found and it is just the order that they are presented to the user that will differ. Since we currently don't use suffixes, then I am not sure what will work the best. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev sort-save-mem-v2.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Complex ocean polygon hiding the islands
Hi Alexandre, yes, simplification happens in various places. The reasons are limits in the Garmin format as well as optimization of the img file size. 1) The Garmin img format uses a raster with ~2.3 m distance at resolution 24. I think of it as a bed of nails, you can draw straigt lines between any of the nails. Details below this resolution are removed. We use two different algos for lines and shapes here, so expect slightly different results for outlines. 2) The Garmin format doesn't allow a single polygon with more than 255 points, so mkgmap has to split a complex polygon into smaller pieces. 3) For lower resolutions, the raster is less precise, means, for 23 points are ~4.6m, 22 - ~9.6m and so on. 4) For lower resolutions, a variant of the Douglas-Peucker-Algo is used to reduce the img size. You can change the effect of this by using the Optimization options: http://www.mkgmap.org.uk/doc/options See also http://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm Gerd Date: Sat, 28 Feb 2015 01:33:18 -0300 From: alexandre.l...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Complex ocean polygon hiding the islands Hi guys, Please see if any of you can help me ... I have an ocean polygon with multiple edges and in the middle of these there are several islands that are in fact holes in the polygon.Here's an example: Showing only the contour lines, the polygon is drawn as follows: Zooming... When I compile the map, the islands/holes are overlapped by the sea.I noticed that when the polygon is less complex, this overlapping phenomena doesn't happens. Its looks like mkgmap simplifies complex polygons. Is there any option that I can use in mkgmap to respect the layout of complex ocean polygons? By the way, if this isn't the right list to ask this kind of question, please let me know cause I'm new here. Thanks. Alexandre ___ 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] Complex ocean polygon hiding the islands
Hi guys, Please see if any of you can help me ... I have an ocean polygon with multiple edges and in the middle of these there are several islands that are in fact holes in the polygon. Here's an example: [image: Imagem inline 1] Showing only the contour lines, the polygon is drawn as follows: [image: Imagem inline 2] Zooming... [image: Imagem inline 3] When I compile the map, the islands/holes are overlapped by the sea. I noticed that when the polygon is less complex, this overlapping phenomena doesn't happens. Its looks like mkgmap simplifies complex polygons. Is there any option that I can use in mkgmap to respect the layout of complex ocean polygons? By the way, if this isn't the right list to ask this kind of question, please let me know cause I'm new here. Thanks. Alexandre ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
Am Freitag, 27. Februar 2015, 23:24:21 schrieb Bernd Weigelt: Hi Gerd You can really use every town in germany, made a test with Munich Landshuter Allee 126 results in a list of parts like using trunk Minerviusstrasse 12 , 100 metres away is found on the exact position here are my files from today http://files.mkgmap.org.uk/download/255/cologne.zip included the O5M and as example two screenshot of Munich MapSource is not really good thing for me, at the moment i'm trying to find out how works ;-) using Win 8.1 in VirtualBox. Basecamp works OOTB Bernd Am Freitag, 27. Februar 2015, 14:59:50 schrieb GerdP: Hi Gerd do you get better results with the trunk version? I have created my maps with trunk over a long time with no problems, the address search works. If not, I think it is a problem with the indexes, not with the housenumber code. To verify that, please try to search in MapSource without a city name. MapSource, hmmh, didn't use that since years, but i install it tomorrow Maybe you can upload the input file for 65001032.img, so that I can do some tests on my own. 6532.o5m? this file is deleted, but tomorrow i can use the same region from my DACH build this evening for an upload. Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] weired housenumbers in Canada
Hi all, in Canada, a lot of OSM data comes from imports, e.g. source=NRCan-CanVec-8.0 or NRCan-CanVec-10.0 I think the house number data provided by these imports is more or less garbage. I see many ways like this: http://www.openstreetmap.org/way/18396 It is an addr:interpolation way connecting two different points which both have addr:housenumber=5 addr:street=20th Sideroad In many cases I see two of these meaningless objects, one with source=NRCan-CanVec-8.0, one with source=NRCan-CanVec-10.0. I think the only way to handle this data is to ignore it, if mkgmap finds an addr:interpolation way connecting two equal numbers, we should ignore the numbers. Right? Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
Hi Bernd, okay, so 65001032.img contains the img file and the corresponding log lines contain 6532. I see Bergisch Gladbacher Straße only as B506 Bergisch Gladbacher Straße. Did you search for that? Similar L361 Aachener Straße. Luxemburger doesn't appear in this log. Gerd Bernd Weigelt wrote Am Freitag, 27. Februar 2015, 13:05:37 schrieb GerdP: the file mkgmap.log.2 doesn't contain any line regarding file 65001032, but 6532. Is there a trick ? There is no trick ;-) the '1' is part of my map id, because i build different layers Splitter tile 6500'0'xyz Bonn Basemap 6500'1'xyz Bonn Bikemap 6500'2'xyz or splitter tile 65020xyz DACH Basemap 6502'1'xyz ... so i can use more then one image per region and layer, some devices are problematic Bernd ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/log-messages-for-housenumbers-tp5834339p5835247.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
Hi Bernd, the file mkgmap.log.2 doesn't contain any line regarding file 65001032, but 6532. Is there a trick ? Gerd Bernd Weigelt wrote Am Freitag, 20. Februar 2015, 01:39:50 schrieb GerdP: Hi i'm testing the housenumbers at the moment in Cologne, Germany. I have some problems with different addresses like at Bergisch Gladbacher Strasse, competly not found with housenumbers, same on every housenumber at the Aachener Strasse and Luxemburger Straße, all are really long ;-) Housenumbers on some shorter streets like Brühler Strasse or Deutz-Mülheimer Strasse are found really near by. Tested in Basecamp and on my Oregon 650. The logs are here http://files.mkgmap.org.uk/download/254/basemap.zip I hope they are useful Bernd Hi all, I wonder what info mkgmap should report regarding housenumbers. The current log messages printed with uk.me.parabola.mkgmap.osmstyle.housenumber.level=INFO are probably not very useful. I think mkgmap should try to report those OSM elements which should be reviewed. The messages containing the string looks wrong are candidates. I also think that mkgmap should report OSM elements which cause problems in the algos used to calculate the img data. These elements might be 100% correct, but the messages may show problems in the algos. Any ideas? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/log-messages-for-housenumbers-tp5834339.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- amarok2 now playing: artist: Ann West title: Missed It Again album: Confidante ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/log-messages-for-housenumbers-tp5834339p5835243.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
Am Freitag, 27. Februar 2015, 13:05:37 schrieb GerdP: the file mkgmap.log.2 doesn't contain any line regarding file 65001032, but 6532. Is there a trick ? There is no trick ;-) the '1' is part of my map id, because i build different layers Splitter tile 6500'0'xyz Bonn Basemap 6500'1'xyz Bonn Bikemap 6500'2'xyz or splitter tile 65020xyz DACH Basemap 6502'1'xyz ... so i can use more then one image per region and layer, some devices are problematic Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
Am Freitag, 27. Februar 2015, 13:49:28 schrieb GerdP: I see Bergisch Gladbacher Straße only as B506 Bergisch Gladbacher Straße. Did you search for that? Similar L361 Aachener Straße. I searched by enter city, streetname and a existing housenumber Bergisch Gladbacher Straße 795 https://www.openstreetmap.org/#map=19/50.97521/7.06026 or Aachener Straße 399, https://www.openstreetmap.org/#map=19/50.93686/6.91106 In both cases i got only the old list of street parts Searching for Brühler Straße 255 https://www.openstreetmap.org/#map=19/50.89835/6.95261 results in a checkered flag in front of the building. First i thought it is a problem with the spaces in the streetname, triggered from a rule in my style, but now i think it is related to the length of the street. Luxemburger doesn't appear in this log. i didn't search for the Luxemburger in the logs, but i stored the complete log files, compressed 44 MB, i can upload them, if wanted, a map image, too. BTW, it happened on every long street, tested in Bonn with the Königswinterer Straße Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
Hi Bernd, do you get better results with the trunk version? If not, I think it is a problem with the indexes, not with the housenumber code. To verify that, please try to search in MapSource without a city name. Maybe you can upload the input file for 65001032.img, so that I can do some tests on my own. Gerd Bernd Weigelt wrote Am Freitag, 27. Februar 2015, 13:49:28 schrieb GerdP: I see Bergisch Gladbacher Straße only as B506 Bergisch Gladbacher Straße. Did you search for that? Similar L361 Aachener Straße. I searched by enter city, streetname and a existing housenumber Bergisch Gladbacher Straße 795 https://www.openstreetmap.org/#map=19/50.97521/7.06026 or Aachener Straße 399, https://www.openstreetmap.org/#map=19/50.93686/6.91106 In both cases i got only the old list of street parts Searching for Brühler Straße 255 https://www.openstreetmap.org/#map=19/50.89835/6.95261 results in a checkered flag in front of the building. First i thought it is a problem with the spaces in the streetname, triggered from a rule in my style, but now i think it is related to the length of the street. Luxemburger doesn't appear in this log. i didn't search for the Luxemburger in the logs, but i stored the complete log files, compressed 44 MB, i can upload them, if wanted, a map image, too. BTW, it happened on every long street, tested in Bonn with the Königswinterer Straße Bernd ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/log-messages-for-housenumbers-tp5834339p5835255.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: AW: RE: computing power mdx/mdr
Hi Gerd I think in the old algo the bytes of the suffix were compared at last, with the patch they are compared before the prefix. Ah, right. I think that in both cases all streets could be found and it is just the order that they are presented to the user that will differ. Since we currently don't use suffixes, then I am not sure what will work the best. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: AW: RE: computing power mdx/mdr
On 27/02/15 12:11, Marko Mäkelä wrote: Right. For Japanese, MeCab has a different approach for fulltext search, applying morphological analysis. Ahh, that would be something that I was not at all aware of :) I was only referring to the cp932 code page and the index. I doubt that it works at all even for whole name matches. But I haven't tried it so maybe it does! ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
Am Freitag, 27. Februar 2015, 14:59:50 schrieb GerdP: Hi Gerd do you get better results with the trunk version? I have created my maps with trunk over a long time with no problems, the address search works. If not, I think it is a problem with the indexes, not with the housenumber code. To verify that, please try to search in MapSource without a city name. MapSource, hmmh, didn't use that since years, but i install it tomorrow Maybe you can upload the input file for 65001032.img, so that I can do some tests on my own. 6532.o5m? this file is deleted, but tomorrow i can use the same region from my DACH build this evening for an upload. Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: AW: RE: computing power mdx/mdr
On Thu, Feb 26, 2015 at 10:47:42PM +, Steve Ratcliffe wrote: Japanese almost certainly doesn't work with the global index anyway. Right. For Japanese, MeCab has a different approach for fulltext search, applying morphological analysis. I wonder if Garmin supports anything like that on its devices, or if this type of indexing makes sense for the street naming schemes that are used in Japan. If not, there is not much that a map generator can do. BTW, in the patch there was a typo in a method name: getInitalPart() should be getInitialPart(). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
