Re: [mkgmap-dev] looking for set-typ.pl script
Steve Ratcliffe (st...@parabola.me.uk) wrote: Hi I already looked into the archive and I can't find this script. The links are dead, or the attachment was removed from the mails. So could somebody provide me this script? This would be great. The links are downloadable from the on-line archive of the emails at least, not tried the downloaded archive: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007067.html Attachment link is: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20100207/b6f54347/attachment.bin Also available here: http://www.cferrero.net/maps/map_downloads.html -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] crash. Too many tiles?
Hi list, This should have been a bit of an experimental map, with as much tiles as possible, by having splitter do --max-nodes=15 In the end, however, I don't get a map at all: java -enableassertions -Xmx1700m -jar ../mkgmap/dist/mkgmap.jar --make-opposite-cycleways --mapname=3168 --latin1 --remove-short-arcs=2.8 --reduce-point-density=5.4 --lower-case --route --preserve-element-order --max-jobs --location-autofill=1 --link-pois-to-ways --description=Nederland --style=1430 --family-name=Openstreetmap 29 jan 11 --series-name=OSM-Valentijn --gmapsupp --tdbfile --net -c template.args Exception in thread main java.lang.IllegalArgumentException at java.nio.ByteBuffer.allocate(ByteBuffer.java:311) at uk.me.parabola.imgfmt.sys.Directory.sync(Directory.java:176) at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:230) at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:240) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:119) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:127) This is in the Netherlands, so nodes all over the place, and in fact, I'm getting lots and lots of Area (51.8994140625,6.6357421875) to (52.0751953125,6.8994140625) contains 209.578 nodes but can't be split further messages. The resulting cut has 265 tiles. A few weeks ago, I remember having made such a map - but that could just be because there were a bit fewer nodes somewhere and the number of tiles was below 256 - could just be, I don't know. (The reason for this many tiles was the idea that a Nüvi might get better bike performance on long distances if the number of data to unpack (i.e. individual tiles) would be smaller - because of the smaller tiles. Might be just a stupid idea, I don't know, I was going to check but we might never know now... ;) So I'm just passing this on, for the sake of it, don't look too long at it because it's probably not worth it; but if there's an easy fix, it is welcome ;-) Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] crash. Too many tiles?
Hi Valentjin, IIRC then there are some limitiations in the format, which don't allow more than 256 tiles in one img file. There should be no exception but a clear error message, but I think it would not work anyway. Regards, Johann Valentijn Sessink schrieb: Hi list, This should have been a bit of an experimental map, with as much tiles as possible, by having splitter do --max-nodes=15 In the end, however, I don't get a map at all: java -enableassertions -Xmx1700m -jar ../mkgmap/dist/mkgmap.jar --make-opposite-cycleways --mapname=3168 --latin1 --remove-short-arcs=2.8 --reduce-point-density=5.4 --lower-case --route --preserve-element-order --max-jobs --location-autofill=1 --link-pois-to-ways --description=Nederland --style=1430 --family-name=Openstreetmap 29 jan 11 --series-name=OSM-Valentijn --gmapsupp --tdbfile --net -c template.args Exception in thread main java.lang.IllegalArgumentException at java.nio.ByteBuffer.allocate(ByteBuffer.java:311) at uk.me.parabola.imgfmt.sys.Directory.sync(Directory.java:176) at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:230) at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:240) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:119) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:127) This is in the Netherlands, so nodes all over the place, and in fact, I'm getting lots and lots of Area (51.8994140625,6.6357421875) to (52.0751953125,6.8994140625) contains 209.578 nodes but can't be split further messages. The resulting cut has 265 tiles. A few weeks ago, I remember having made such a map - but that could just be because there were a bit fewer nodes somewhere and the number of tiles was below 256 - could just be, I don't know. (The reason for this many tiles was the idea that a Nüvi might get better bike performance on long distances if the number of data to unpack (i.e. individual tiles) would be smaller - because of the smaller tiles. Might be just a stupid idea, I don't know, I was going to check but we might never know now... ;) So I'm just passing this on, for the sake of it, don't look too long at it because it's probably not worth it; but if there's an easy fix, it is welcome ;-) Best regards, Valentijn ___ 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] issues with overlapping maps
Hi, There are some issues with two maps that I'd like to display on a Dakota GPS: Openfietsmap Benelux (OFM_NL) and Germany (OFM_DE): http://img209.imageshack.us/img209/3628/ofmh.jpg -The German map is built from a Geofabrik Germany abstract, -the Dutch map is built with the Geofabrik europe.osm.pbf. -Both maps have a different FID but the same draw order. The problem lies in the empty background of the Germany tiles. If I send some selected tiles to my GPS, sometimes the 'German' Northsea floods the Dutch areas (depending on the zoom level). When I zoom in, the sea disappears but the pointer doesn't show the streetnames etc. It seems only to see the background map. If I point it to an area where both maps don't overlap, it shows the name or type of the osm features. The odd thing is that this only shows up in a Dakota/Oregon. On a nüvi I don't have those issues at all. If I change the draw priority of one of the maps, cities and towns on the other map are not searchable anymore. Also a gap appears between the two maps if the draw orders are not equal. It doesn't make any difference if the maps are selected or not. (This weird behaviour only shows up on the Dakota and Oregon types, on a Nüvi deselecting the map DOES make a difference). The mkgmap args file is listed here: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/osm_bnl.args Maybe this option has to do with the background problems? generate-sea: extend-sea-sectors,close-gaps=6000,floodblocker,land-tag=natural=background The maps can be downloaded here: http://sites.google.com/site/openfietsmap/downloads Regards, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Area splitting
In the last days there have been two questions around the mkgmap message Area (xxx,yyy) to (zzz,qqq) contains ... but can't be split further. The message is printed during the subdivision creation process which means a tile is splitted into several subdivisions which do not exceed a special dimension and does not exceed a maximum size (which means a max number of nodes, lines and/or shapes). I have started to look how this works because I think there is some work to do. Such errors will occurr more often with increasing density of map information. The split process does not seem to be optimal. I want to start with a list of questions and observations and hope someone of you is able to answer/comment them or is willing to dive into the source code to get an idea of what's going on there. 1. Class Area definition An area is defined with minLat, minLong, maxLat, maxLong. It is not possible to define an area with minLat==maxLat or minLong==maxLong. Is there any reason for this? 2. Class Area split The split method divides the area into a given number of (rather) equal sized subareas. An area [(0,0) to (100,100)] would be split (xsplit==2, ysplit==1) into [(0,0) to (50,100)] [(50,0) to (100,100)] I think this is wrong, because the two areas are overlapping at x==50. Does anyone know why the split method does not split into distinct areas? 3. Class MapSplitter As far as I understand lines and shapes are put to the subdivision that contain their center points. Assuming the situation (I describe a line example but the same applies to shapes) E --- + | | + | x | + --- + + S+ S = start point of a line E = end point of a line + = line x = center point -| = borders of the subdivision The line is defined in the subdivision although it does not intersect the subdivision. But its center point is located in the subdivision. Is that correct? The coordinates of the line points are stored as diffs to the center of the subdivision as a kind of compression. The diffs have a higher and lower limit. If a line is quite long and one point is far away from the center of the subdivision it could not be stored. What happens in such a case? I think a warning message is printed in the constructor of the Subdivision class but what happens to the line point? Would it be better to split a line in such a case? Or would it be better to split a line so that the complete line fits into a subdivision? 4. Subdivision splitting In case a subdivision is too full it is splitted into equal sized areas. Would it be a good first approach to improve the splitting so that the algorithm tries to split the subdivision into rather equal filled subdivisions (e.g. each splitted subdivision should contain the same number of points plus center points of lines/shapes? Have fun! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Area splitting
Hi It would be good if we had a tool to visualise the strategies used to allocate elements to the subdivisions. Something that displays the subdivision boundaries and highlights the elements that belong to a subdivision in some way. I really have no idea of the best way to do this. 1. Class Area definition An area is defined with minLat, minLong, maxLat, maxLong. It is not possible to define an area with minLat==maxLat or minLong==maxLong. Is there any reason for this? Perhaps it is but then it would not be able to contain anything except perhaps a vertical or horizontal line. Why do you think it is important that it should be possible. 2. Class Area split The split method divides the area into a given number of (rather) equal sized subareas. An area [(0,0) to (100,100)] would be split (xsplit==2, ysplit==1) into [(0,0) to (50,100)] [(50,0) to (100,100)] I think this is wrong, because the two areas are overlapping at x==50. Does anyone know why the split method does not split into distinct areas? This is just a grid used to allocate elements to subdivision. In reality the subdivision is expanded to contain its elements. So they always overlap by quite a bit. When a division is split, then each element is allocated in one of the two new divisions. When the splitting is finished the real subdivision bounds are calculated based on the actual contents. The only important thing is that each element can be allocated into exactly one of the new divisions. 3. Class MapSplitter As far as I understand lines and shapes are put to the subdivision that contain their center points. I can't remember the whole history here, I think at one time I used the first point in the line, but it didn't produce particularly uniform results. Assuming the situation (I describe a line example but the same applies to shapes) E --- + | | + | x | + --- + + S+ S = start point of a line E = end point of a line + = line x = center point -| = borders of the subdivision The line is defined in the subdivision although it does not intersect the subdivision. But its center point is located in the subdivision. Is that correct? Because the grid is only used to allocate elements to subdivisions, it doesn't matter that no point is actually in the grid section. The subdivision will always be sized to contain its contents. I'm not saying that its a good thing though. Possible room for improvement there if it happens often. The coordinates of the line points are stored as diffs to the center of the subdivision as a kind of compression. The diffs have a higher and lower limit. If a line is quite long and one point is far away from the center of the subdivision it could not be stored. What happens in such a case? I think a warning message is printed in the constructor of the Subdivision class but what happens to the line point? Would it be better to split a line in such a case? Or would it be better to split a line so that the complete line fits into a subdivision? Well this is the main problem. We split lines earlier on. Originally I split lines so that in the worst case they would never be too big to fit into a subdivision. Perhaps we should split them after we know roughly where the subdivision boundaries are going to be. 4. Subdivision splitting In case a subdivision is too full it is splitted into equal sized areas. Would it be a good first approach to improve the splitting so that the algorithm tries to split the subdivision into rather equal filled subdivisions (e.g. each splitted subdivision should contain the same number of points plus center points of lines/shapes? Probably yes! I think our existing approach gives sub-divisions that overlap a lot more than Garmin or cgpsmapper produced maps. It is certainly something that needs looking at again and I encourage you to do so. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
