Re: [mkgmap-dev] error splitting binary files
Hi It was discussed on osmosis-dev ML. There was just a differenc in some bytes in the beginning of a working file and the not working file of Geofabrik. The part which includes the data was exactly the same. No one knew why one file doesn't work on windows. Regards, aighes -Ursprüngliche Nachricht- Von: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev- boun...@lists.mkgmap.org.uk] Im Auftrag von Minko Gesendet: Montag, 20. Dezember 2010 18:49 An: Development list for mkgmap Cc: frederik Betreff: Re: [mkgmap-dev] error splitting binary files Hi, Any news about this problem (which still exists)? aighes wrote: It seems to be an error in extract-file. Osmosis has also problems Frederik is informed about it (talk-de) and will take a closer look to it. aighes -- View this message in context: http://gis.638310.n2.nabble.com/error- splitting-binary-files-tp5758967p5811383.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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error splitting binary files
Yes, the file generated under windows was working well. 4GB problem can't be, because of using 64bit java and also in the past I processed files larger then 4 GB and the windows-generated pbf-file is also larger than 4GB. Regards aighes -Ursprüngliche Nachricht- Von: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev- boun...@lists.mkgmap.org.uk] Im Auftrag von Chris66 Gesendet: Freitag, 24. Dezember 2010 20:44 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] error splitting binary files Am 24.12.2010 11:37, schrieb Henning Scholland: It was discussed on osmosis-dev ML. There was just a differenc in some bytes in the beginning of a working file and the not working file of Geofabrik. The part which includes the data was exactly the same. You are sure that one of the two files was working on windows ? My guess was that it's some kind of 4 GB problem (only on windows) with pbf input files. Is splitter using the same pbf-code like osmosis ? Chris ___ 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] elevation contours, wrong values
Hi I have an problem with the values of my elevation contours. They where created by srtm2osm. After processing them with mkgmap, I opened the resulting map with MapSource, but the values are to little by factor ~3.3. The ele-values were retagged to name. I think MapSource or mkgmap take my metric values as foot-values and transfer them to metric system. After splitter the values where correct in metric system. Is this a mkgmap-bug or is it a Garmin-thing and I have to input foot-values? Greets, Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] elevation contours, wrong values
Hi, in the resulting osm-file are all values correct. Eg. the elevationline for 20m is tagged with ele=20. Also this line is displayed there elevation is 20m. But this line is named as 6m. srtm2osm-call should be correct. It creates metric values unless you set -foot, what I haven't done. MapSource use also metric system. Henning Am 18.01.2011 21:36, schrieb Felix Hartmann: You have to give proper commands to srtm2osm. This has nothing to do with mkgmap. On 18.01.2011 21:17, Henning Scholland wrote: Hi I have an problem with the values of my elevation contours. They where created by srtm2osm. After processing them with mkgmap, I opened the resulting map with MapSource, but the values are to little by factor ~3.3. The ele-values were retagged to name. I think MapSource or mkgmap take my metric values as foot-values and transfer them to metric system. After splitter the values where correct in metric system. Is this a mkgmap-bug or is it a Garmin-thing and I have to input foot-values? Greets, Henning ___ 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
Re: [mkgmap-dev] elevation contours, wrong values
Thanks a lot, this was the hint I needed. Works now very well. Henning Am 19.01.2011 13:28, schrieb garvanmaew: On Tue, 2011-01-18 at 21:46 +0100, Henning Scholland wrote: Hi, in the resulting osm-file are all values correct. Eg. the elevationline for 20m is tagged with ele=20. Also this line is displayed there elevation is 20m. But this line is named as 6m. srtm2osm-call should be correct. It creates metric values unless you set -foot, what I haven't done. MapSource use also metric system. Henning Assuming there is no bug in mkgmap, you should check your style file. GARMIN store elevation heights internally in feet, so the meters must be converted to feet by mkgmap, following settings in the style file. Form your post it would appear that this is not happening. I have only used contours with polish format input. With polish format you need to add elevation=M in the header portion of the mp file to tell mkgmap you are using meters. From what I can see this is handled by the style file for OSM input. Garvan ___ 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
Re: [mkgmap-dev] New splitter build for pbf format
Am 26.01.2011 13:54, schrieb WanMil: Hi Steve, hi Scott, I tried the new splitter build but it's not working for me. I splitted the 4.6GB europe.osm.pbf using the default splitter arguments. The output was 64 osm.gz files with a total size of 881M which seems to contain nodes only. WanMil Hi Scott announced that he has made an important fix to the osmpbf library which fixes a bug only seen on Windows with large files. So I have rebuilt the pbf capable version of splitter with this newly released version of osmpbf.jar. There are no other differences so if you were not affected by the bug you do not need to re-download. The new download is at: URL: http://files.mkgmap.org.uk/download/7/splitter-r161-2.zip ..Steve ___ 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 Maybe Geofabrik must create the files also with new version. So it will take some days, til they do so. Cheers Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New splitter build for pbf format
Am 28.01.2011 19:24, schrieb dom Team OiD: Is also the big file problem fixed? I think about the europe file splitting. Is this problem solved? Hi, yes this bug is fixed. Todays snapshot of osmosis includes the new version too. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
Am 31.01.2011 21:20, schrieb Marko Mäkelä: On Mon, Jan 31, 2011 at 08:31:09PM +0100, Henning Scholland wrote: Am 31.01.2011 20:16, schrieb Marko Mäkelä: On a related note, I believe that an alternative to add-pois-to-areas should be implemented, by introducing an add_poi action in the polygons style file. In that way, one could flexibly choose which polygons deserve a POI. I found an easy way to fix this issue. I set one Garmin-polygon-ID with a transparent image. In polygons-style-file I created as example the following rule: shop=supermarket building!=* [0x0D resolution 23] For building=yes I've an extra rule. 0x0D is my transparent Garmin-ID. It works fine. Only default name should be set in the rule and not in TYP-file. Oh, you seem to have a different use case for the add_poi feature. I was thinking that I do not necessarily want to have a POI for certain areas, say, amenity=school name!=* or amenity=parking access=private. You seem to not want a polygon for features for which POIs are to be generated. The add_poi action would help also there: just tell mkgmap to create the POI but not the polygon. For instance, do not create a polygon for amenity=recycling or tourism=lean_to, but just the POI. Marko Yes of cause a better implementation would help both of us. But if you want to search for a POI, it must be a node and so I need to have for some areas a node. If there is no rule for a area-tag in points-file, there wont be an node from --add-pois-to-area. Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wondering about mkgmap usage.
Am 01.02.2011 09:44, schrieb dom: Hi, I'm using mkgmap since a while and it works great. Good work and thanks to all of the developer. I know how many time you are investing into it and how many time such a OS project needs to care about. So my question is. I already have seen that some of the map compilers are calling the mkgmap with the typ file at the end. For example: java .. -jar mkgmap.jar [option] typfile.typ I also tried it and I found no advantage or difference to a call without the typ file? What is the reason for this? I also didn't find any doc for this. Thanks, Marco If you let mkgmap also create the gmapsupp.img, than you have to call mkgmap with a TYP-file. Otherwise mkgmap will use default TYP-file. For normal creation of maps it is not necessary to have a TYP-file in mkgmap-call. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wondering about mkgmap usage.
Am 01.02.2011 10:14, schrieb dom: Ah I just need it when I will create a gmapsupp.img and when I want to use my typ file with the gmapsupp.img. When I'm just creating mapsets and no gmapsupp.img there is no need to add it to the mkgmap command, right? Marco Yes Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
Am 03.02.2011 12:51, schrieb Ben Konrath: On Tue, Feb 1, 2011 at 4:20 PM, Torsten Leistikowde_m...@gmx.de wrote: Moin, Henning Scholland schrieb am 31.01.2011 21:41: Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon? In OSM some objets can be mapped in OSM as a node or as an area, depending on the availability of the source data. If they are mapped as a node, I want them to be displayed as a symbol in my map. If they are mapped as an area, I want them to be displayed as a polygon. With the pois-to-area function the latter ones are displayed in a map twice, as a polygon AND as a symbol. That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out No, this is a error in osm-data. One object should only taged once. So if you tag this information to a node, you shouldn't tag same info to the polygon. If add-pois-to-area creates an POI, there shouldn't be any node in OSM-data. If there is already a node and so there are two symbols in the map, it's not an mkgmap-bug. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
Am 03.02.2011 22:36, schrieb Marko Mäkelä: On Thu, Feb 03, 2011 at 05:02:43PM +0100, Torsten Leistikow wrote: For some types this might be ok, but for some types I do not want the symbol in addition to the polygon. For some minor map features, I would want only the symbol, not the polygon. For example, mappers could start drawing bus stop shelters from Bing aerial images. The shelters would be smaller than the Garmin map resolution, and thus the POI would be enough. Did you try my hack with a transparent polygon? All in all I think the best would be an action in polygon-style for creating a POI. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter and long way-segments
Hi everyone I've a problem with ways with long segments (e.g. boarders or ferry-lines) and splitter. These ways gets broken, because the nodes are to far away from splitoffset. I've made a screenshot [1] for explanation. Increasing the splitter-offset wont be a good idea, because tiles will become to big. Also I wont add additional nodes in osm-data, because this only will solve the problem only for one map. Are there any other opportunities for fixing this problem and keep routing on ferry-lines alife? Henning [1] http://www.aighes.de/data/example.png ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and long way-segments
Am 07.02.2011 23:45, schrieb Minko: Henning, Did you try a higher overlap setting? Maybe --overlap=6000 ? --overlap Nodes/ways/rels that fall outside an area will still be included if they are within this many map units. Default is 2000 Sorry for late answer, but I tried this already. In some cases it works. But ferries at north sea or baltic sea (eg. Rostock-Helsinki) or other ocean-ferries (Norway-GB) have waysegments with length of more than 100km. These lines gets broken an I think its impossible to increase tiles so much. One solution would be, that splitter detect long segments and add two nodes next to the boarder of the tiles. But I don't know, if this is an easy think to detect these long segments. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - success!
Am 12.02.2011 14:56, schrieb Chris66: Am 12.02.2011 13:24, schrieb Steve Ratcliffe: Now in Basecamp the Mapinstall crashes when the progress bar of the index generating process is at 16%. I had this problem while upload a complete UK. I've since found that if I just upload a few tiles it doesn't happen. OK, when only sending *one* tile it works. Now when I find for addresses on my Legend HCX, I can choose between region Deutschland and region Germany. Region Deutschland seems to show the basemap entries: Ahsen, DEU Alstätte, DEU Altenrheine, DEU ... while region Germany shows the OSM entries: Ahaus, Kreis Borken Albachten, Münster ... I used location-autofill=1 and --country-name=germany --country-abbr=DE --area-name=DE For region Deutschland I have to enter LÜ to find cities starting with Lü but for Region Germany I have to enter LU to find cities starting with Lü. Greetings Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-de Hi, did you use --code-page//=1252? This should fix the problem with umlauts. Germany instead of Deutschland seems to to a bug in OSM is_in-tag, which contains the english name ;) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - success!
Sorry, I was wrong... is_in contains Deutschland Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search and index.
Hi Am 13.02.2011 23:52, schrieb Steve Ratcliffe: There is a big problem with address search with poor and inconsistent map data. With my map of England I get the choice of four different variations on the name of the country to choose from. One must be chosen and doing so means that you can only find streets that have that particular country name. Now there is no way for me to know since after all everything is really in the same country. So to make address search really useful the country names have to be cleaned up, (other countries may be in a better state). Does anyone have any good ideas about this? ..Steve Do you think, it's an osm-data-problem? Then it would be very helpful, to explain, which tags are involved and causes the faults. Is it is_in, addr:country or which tags did mkgmap use therefor? If there are faults in the data, they should be fixed. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address city country name assignment.
Am 16.02.2011 11:32, schrieb Christian Steins: On Wed, 16 Feb 2011 08:00:48 +0200, Du Plessis, Bennie wrote: I don't understand which tags are used to find the country (and other address data) for a street, or city to use in address search. I think we should have a wiki page describing all this. -how do the different location-autofill options work? -what is the algorithm for getting the region for a place? -how are streets assigned to cities? -what is the purpose of the LocatorConfig.xml file? Don't forget the importanrs point: How to use it. :-) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-cycleways labels invisible
Am 17.02.2011 00:01, schrieb Minko: It's still a bit confusing to me. Does ?? in [0x?? road_speed=? road_class=? continue] mean that you can use wildcards? Or is it just an example and you need to fill it in for every road type, like Felix already mentioned? And I suppose you need to add cycleway=opposite_lane as well. And maybe bicycle:oneway=no or oneway:bicycle=no since some will use these tags instead of cycleway=opposite You have to use a routable Garmin-way-ID instead of ?? and for ? you have to insert a numeric value (as normal). If you need several pairs of these rules depends on your generel style. If you want to distinguish eg. a tertiary oneway from a track oneway you need for each highway a pair of rules. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Weird behavior and problem with splitter r161
You have to use an osmosis-build, builded after 28.1.2011. Also it is faster to use splitter with an existing areas.list-file and europe.osm.pbf-file. This will be as fast as splitting your area with osmosis. So you save the time for splitting your myBenelux.osm.pbf Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygones and tags in outer line
Am 22.02.2011 00:03, schrieb Thorsten Kukuk: On Mon, Feb 21, Henning Scholland wrote: Am 21.02.2011 23:13, schrieb Thorsten Kukuk: Hi, I found now several buildings/areas, which where constructed with multipolygons, but where only the inner polygons where ignored for rendering Hi Thorsten It seems to be an error in osm-data. If you have a MP, all taggs on outer way describes the hole polygon. All taggs on MP-relation describes the area between outer and inner polygon. I was already afraid of that. Looks like at least in Nuernberg, somebody did this consistently wrong :( But I only wonder that the renderer used for the maps on openstreetmap.org is doing it correct. So it's hard to argue that it is a osm-data bug ... Thorsten You can take a look into our wiki ( http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon ) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap and values with semicolon in it
Am 24.02.2011 21:55, schrieb WanMil: what would you expect? - Two POIs at the same location? - One POI at the same location? - Two POIs at the same location if the two tags will be assigned with different garmin ids and one POI if will be assigned with same garmin id? But be careful...there are also tags like surface=grass;asphalt at some streets or other tags with opposed meaning. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Include the following patches into trunk -- Patch1 - Drop small Polygons
Am 01.03.2011 19:47, schrieb Felix Hartmann: On 01.03.2011 19:44, Henning Scholland wrote: Am 01.03.2011 19:38, schrieb Felix Hartmann: On 01.03.2011 19:33, Felix Hartmann wrote: The following patches are in my eyes really worthwhile and should be added to trunk. They all work fine without glitches. 1. Drop small Polygons I am not sure who wrote this patch, but I have been using it longtime and it certainly does improve map performance especially on higher resolutions. It removes all polygons which consist of less than 8 pixels. If you deem that this is too extreme (though 8 pixels is really nothing, and polygons of less than 8 pixel size are barely noticeable anyhow - and only slow down map drawing) the following line could be reduced to maybe 6 or 4 pixels: +private static final int MIN_SIZE_POLYGON = 8; Ups forgot to say, I'm actually using it with a value of 15 and it seems to work pretty well with 15. Wont it cause routing errors, if little highway-areas will be removed? Henning What do you mean by highway areas? I removes lines consisting of 1 point but but not on the routing nodes, but only on visual display. A 1point line cannot exist in resolution 24 but only in resolutions 23 down. Neither in Mapsource nor on GPS I can see a difference of removing 1 point lines (yes there is a visual difference if removing polygons smaller than 15 pixels, but that usually makes the map better readable, 15 pixels is still tiny and causes rather a better readable map because small non identifiable crap gets removed). I thought about small polygons with highway-tag. If these polygons gets removed, there will be a gap. Or did I misunderstood your mail and these polygons will only be removed from drawing but not from routing part of the map? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Inundated tile with no coastline
Am 01.03.2011 21:38, schrieb Nakor: Hello, I have a tile with no coastline that shows up inundated. How can this be? How can I fix it? The tile is split us_midwest from geofabrick with: 4162: 2183168,239616 to 2215936,280576 # : 46.845703,5.141602 to 47.548828,6.020508 Are you sure, that there is no natural=coastline inside the tile. Sometimes someone taggs a lake or somthing like that as natural=coastline, which may cause your error. If possible, you could unzip your 41662.osm.gz and open osm-file in josm, and filter every object without natural=coastline. Then you can search the fault. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Compiling from source on Mac OS - Warning: Could not find resource file /opt/jars/protobuf-2.3.0/protobuf.jar to copy.
Am 08.03.2011 02:00, schrieb garvanmaew: On Tue, 2011-03-08 at 07:57 +0700, garvanmaew wrote: On Tue, 2011-03-01 at 20:14 +, Steve Ratcliffe wrote: Hello BUILD FAILED /Users/railrun/Downloads/osm/mkgmap/build.xml:212: Warning: Could not find resource file /opt/jars/protobuf-2.3.0/protobuf.jar to copy. I don't have a Mac, but that filename does not occur in the latest version of the splitter. So the best solution would be to fetch the latest version. Also make sure that no old file is still around for example a local.properties file that may be supplying that name. Best wishes ..Steve ___ Is installing splitter now a requirement for mkgmap? I get the same error as above on a fresh download (no old files) from svn trunk. I have never used splitter, I do not need it for my maps. Garvan PS. I should have said I am using Ubuntu, not a Mac. Garvan No splitter is required, but mkgmap also needs protobuf.jar Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Compiling from source on Mac OS - Warning: Could not find resource file /opt/jars/protobuf-2.3.0/protobuf.jar to copy.
Am 08.03.2011 12:16, schrieb Marko Mäkelä: On Tue, Mar 08, 2011 at 10:00:22AM +, Steve Ratcliffe wrote: pbf files are: - smaller - faster to read (and write?) - already understood by mkgmap - readable by Osmosis (the 0.5 XML produced by splitter is not) You can read 0.5 XML with osmosis 0.35 and older and with josm ;) But pbf-output would be very nice... Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] broken charset in latest mkgmap
You should try --code-page=1250 aighes ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New locator branch
Am 18.03.2011 14:45, schrieb WanMil: Yes, we provide the same option for coastlines. So it's possible although there is the size restriction. Boundaries take around 3% of the complete OSM data (3% as osm.gz compared to osm.pbf). So think about creating a europe map from the 4.5 GB dump. The boundary data file would be around 3%*4.5GB(osm.pbf) = 135MB(osm.gz). So in the end your computer additionally needs as much main memory as you need to compile a 135MB big tile. The calculation is quite rough but the result is clear: the memory requirements grow quite much compared to the overall size of your map Maybe it would be a good solution to change splitter. If one member of a relation with information about boundaries or other polygons is inside a tile, the whole relation should be in that tile. This will also fix problems with huge multipolygons. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] broken charset in latest mkgmap
Am 18.03.2011 16:28, schrieb Maks Vasilev: Hi! r1894 mkgmap parametrs: http://code.google.com/p/velo100mapper/source/browse/trunk/makemap.basic All text in map have broken charset. As written above: You should use --code-page=1250 instead of --charset=cp1250. As I remember also --lower-case shouldn't be used. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Options overhaul
Hi I think it would be better for the user of mkgmap, that they get with the same used parameter the same result. Opt-in is better then opt-out. If I set --route, map should contain routing information and if I don't set --route, there shouldn't be any routing information in the map. I think this is important, because not every user of mkgmap reads mkgmap-dev and knows, why the new map behave different with same parameters. If I set an old parameter or a parameter, which isn't necessary, mkgmap should print out a warning and a short explanation. E.g. Don't use --charset=cp1250, use --code-page=1250 instead. To keep all users up to date, I think it would be the best way, to have a wiki-page or direct at mkgmap-wiki-page a mkgmap-call which should be used to create a good map. Or maybe in the help-printout of mkgmap a hint, which parameter should be used in typical usecase. E.g. which layer should be used to get a well performing map. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter and .pbf
You also could use r170 and also all other version 161 Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Idea: map layers (multiple output tiles per input tile)
Am 10.04.2011 13:45, schrieb Felix Hartmann: I'ld actually rather have the opposite. Get mkgmap to accept multiple input files and merge them into the same layer. That way one could take 2 osm files, or one 1polish map, one osm, or one .img and one .osm (say one contourlines, one normal map) and join them into one map. It's already possible to combine *.img and osm-files in one step. I use this for processing a new map (input osm-tilesfrom splitter) with the old contour-tiles. Works fine. Result is a working map for MapSource and a working gmapsupp.img. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] junction=roundabout
Hi Minko Might it be an fault in OSM-data? In Germany junction=roundabout imply oneway=yes. I don't know exactly how this is handled in other countries, but I won't be surprised, if this is globally implied. So if there is an roundabout, which isn't an oneway, you should add an oneway=no. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
Hi I think it would be great, to have a wiki page, with some explanations, what to do for creating addressindex with locator-branch. Which parameters should I use? What to write in style-file? etc. I would do it myself, but I don't know, what have to be done. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
You need to - infront of tf. --tf instead of -tf ;) Henning Am 27.04.2011 12:01, schrieb Minko: How do I run osmosis in a windows batch file? If I put this line in the osmosis.bat file: set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways boundary=administrative -tf accept-relations boundary=administrative --used-node -wx europe-boundaries.osm I get this error: only one default (un-named) argument can exist per task. Arguments 3 and 2 have no name ___ 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
Re: [mkgmap-dev] [locator] Osmosis parameters required
Try: osmosis --read-pbf europe.osm.pbf --tf accept-ways boundary=administrative --used-node --tf accept-relations boundary=administrative --used-way --write-xml boundary.osm I have't tried it, because I haven't now access to my desktop , but I think, this should catch all needed data. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Osmosis parameters required
Am 30.04.2011 12:58, schrieb Henning Scholland: osmosis --read-pbf europe.osm.pbf --tf accept-ways boundary=administrative --used-node --tf accept-relations boundary=administrative --used-way --write-xml boundary.osm Sorry, I've forgotten an --used-node osmosis --read-pbf europe.osm.pbf --tf accept-ways boundary=administrative --used-node --tf accept-relations boundary=administrative --used-way --used-node --write-xml boundary.osm Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Osmosis parameters required
Am 01.05.2011 00:41, schrieb Carlos Dávila: osmosis --rb spain.osm.pbf --tf accept-ways boundary=administrative --used-node --tf reject-relations outPipe.0=ways --rb spain.osm.pbf --tf accept-relations boundary=administrative --used-node --used-way outPipe.0=relations --merge inPipe.0=ways inPipe.1=relations --write-xml file=spain-boundaries.osm Hi, I would suggest, that you have to reject in you first part also the nodes and in the second part nodes and ways. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
Am 03.05.2011 23:37, schrieb Felix Hartmann: On 03.05.2011 23:27, Minko wrote: Yes, that is also a good alternative, 0x01 as a transparent line and on top either 0x10f01 or 0x10f02 you cannot make a line transparent by omitting it from the typfile, but go ahead and do your tries. Yes, but you can use a transparent png-file ;) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Talk-de] continue statement and order of drawn ways?
Am 04.05.2011 00:08, schrieb Felix Hartmann: On 04.05.2011 00:05, Henning Scholland wrote: Am 03.05.2011 23:37, schrieb Felix Hartmann: On 03.05.2011 23:27, Minko wrote: Yes, that is also a good alternative, 0x01 as a transparent line and on top either 0x10f01 or 0x10f02 you cannot make a line transparent by omitting it from the typfile, but go ahead and do your tries. Yes, but you can use a transparent png-file ;) Henning And then you have streetnames shown, but no street If you remove the streetnames on 0x01, you remove streetnames on the broken Oregon, edge 800, gpsmaps 62 series, for all maps (until hard reset) The streetnames should be at 0x01, because this is rendered on top. 0x10f01 or 2 were rendered below and will be visible because of 0x01 is transparent. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
Am 04.05.2011 20:32, schrieb Martin:
In Germany we have the same mess...
Actually I'm using this rules:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* mkgmap:admin_level5=* { set
mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative
there are 2 options for the admin-boundaries:
10 and 11 admin levels :(
So actually I still playing with this setting, maybe somebody has
better rules for Germany.
I would use:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
Am 04.05.2011 19:02, schrieb WanMil:
I want to start to collect and commit your country specific rules. I
know some of you have already posted them on the list but I have lost
track of it.
So please post your country specific rules as an answer in this thread.
WanMil
I took these out of wiki-definition of admin_level:
#address-search
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:country=AUT mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=BEL mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=CZE mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=CZE mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=DNK mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DNK mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=FIN mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=FIN mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=FRA mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=FRA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
mkgmap:country=ISL mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=ITA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=LUX mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=NLD mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=NOR mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=POL mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=POL mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=PRT mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=PRT mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=SVN mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=ESP mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=SWE mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=SWE mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=CHE mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [locator] bug, if streets were split
Hi, all streets, which were split in OSM-data get shown in search as often as parts exist in data. It would be great, if these separated streets would be shown only once, if parts have at least one common node. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with rendering of long riverbank (multipolygons)
Am 19.05.2011 16:43, schrieb Minko: How do I configure this split radius? I have examined the nodes close to the tile borders, they are within 500 m outside of the tile borders. I have splitted my maps with an overlap=3000. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Hi --overlap is the parameter, which influence the split radius. But this wont help you solving your problem. I also think, that this problem have to be fixed in the splitter. E.g. process MP and other huge polygons in splitter and not in mkgmap. splitter should have all needed information. Another solution would be to keep all nodes and ways inside one tile, which belong to an objekte which has at least one node in the area. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter PBF support patch
Am 20.05.2011 07:37, schrieb Marko Mäkelä: I could try to make the selection of XML or PBF output based on the input instead of the current default of XML. That is a good idea. I think this is a bad idea, because it will confuse the users. I would name the parameter --output=pbf or --output=xml. If no parameter --output is specified, splitter should write xml. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter PBF support patch
Am 20.05.2011 16:45, schrieb Francisco Moraes: I also noticed that the splitter outputs XML at version 0.5. That probably should be fixed. Finally, I don't know if this is an issue, but my PBF patch doesn't output any metadata as I didn't see that in the data structure used in the splitter. Metadata is not needed at all, because mkgmap doesn't need them. Thats why xml is used in version 0.5. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] What's next?
Hi WanMil, just a question: How does bnd-file creation work? Does it process everything inside the osm or pbf-file or just relations and ways containing boundary=administrative? If not, this would be a great improvement, because no osmosis is needed. osmosis isn't a very fast tool for filtering data. Another thing would be the generation of a working gmapsupp.img directly with mkgmap. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] What's next?
Hi, there are tools like o5mfilter or osmfilter. They should be faster, but they can't write pbf, just o5m or osm-xml. The Format o5m is much better for filtering data, but there isn't any tool, which converts o5m to pbf. So maybe the the hole process wont be faster. Also o5m is faster then pbf, if you would update your local file with change-sets. I know that this isn't the task of locator-branch, but maybe reading o5m would be one of the next things for bnd-generation and splitter. :-) I will ask in german forum, how to use osmfilter for our filtering and compare it to osmosis. Henning Am 06.06.2011 20:33, schrieb WanMil: bnd-file creation processes the whole input file. It does not filter for boundary=administrative. The reason for this is that postal_codes are also accepted. The osmosis step is required because otherwise you probably will have memory problems. If you use unfiltered data for the bnd-creation mkgmap must first read *all* points and *all* ways from the input file. And if you don't have a machine with tons of GB this will exhaust your memory. Maybe someone can do some research if there is a better tool for filtering the boundary data. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] What's next?
Hi, I used osmconvert, o5mfilter and todays germany.osm.pbf from geofabrik (gwdg-mirror). osmconvert.exe germany.osm.pbf --out-o5m germany.o5m o5mfilter.exe germany.o5m --keep-nodes= --keep-ways-relations=boundary=administrative =postal_code grenzen.osm This took just 2 minutes and the result seems to be ok, but I just took a look into data with josm. The size of germany.o5m is about 1.4 GB. Am 06.06.2011 21:12, schrieb WanMil: Anyhow it would be interesting if you can post the parameters one has to use to filter the boundaries and postal_codes using o5mfilter (or osmfilter). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] unused polygons hexes
Hi, if you just want to have a poi-Node and no special backgroundpolygon, just define one Polygon-Type with an transparent png. This polygon you can use for each area which should be handled by add-pois-to-areas. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problem with splitter
Hi, I discovered a problem with splitter.jar when using a areas.list with more then 255 tiles. If there are e.g. 256 tiles in one areas.list then splitter processes only half of the tiles e.g. 128. If there are 255 or less tiles inside, all tiles were processed. Is this a bug or a feature? It would be great, if there were no tilelimit because it is more effective to run splitter once with all tiles for all my maps and not run splitter two times. Without limit I would save 50% splittingtime. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] suggested use of add-pois-to-areas
If you use --add-pois-to-areas and one rule in polygon file is used for an object, then mkgmap goes through points style and creates an POI for the first matching rule. If you just want to have an POI and no area shown, then you can create an transparent bitmap in TYP-File and use this ID for all areas, which should be only converted to a POI. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and o5m
Am 26.08.2011 22:00, schrieb WanMil: No But it would be a very nice feature...:-) Btw. is there a reason for the limit of 255 tiles in splitter? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and o5m
Am 27.08.2011 13:03, schrieb WanMil: Splitter is generating more than 255 tiles. But there is (or was?) a limit of 255 tiles per pass. I am not sure if this limit is still valid. The webpage (http://www.mkgmap.org.uk/page/tile-splitter) is a bit out of date, e.g. does not tell about support for pbf files. Hi WanMil Current behaviour is, that max. 255 tiles are generated out of an existing areas.list-file. If there are 256 tiles listed, just the first 128 tiles were generated. Maybe there is a bug in reading aeras.list-file with more than 255 entries? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and o5m
Am 28.08.2011 17:15, schrieb WanMil: Splitter is generating more than 255 tiles. But there is (or was?) a limit of 255 tiles per pass. I am not sure if this limit is still valid. The webpage (http://www.mkgmap.org.uk/page/tile-splitter) is a bit out of date, e.g. does not tell about support for pbf files. Hi WanMil Current behaviour is, that max. 255 tiles are generated out of an existing areas.list-file. If there are 256 tiles listed, just the first 128 tiles were generated. Maybe there is a bug in reading aeras.list-file with more than 255 entries? Henning Yes, sounds like a bug. WanMil Henning, I have tried to reproduce the problem but everything was ok. I used an areas.list with 256 tiles. Splitter uses two passes with each 128 tiles. After the first 128 tiles there are some messages that some worker threads have finished and it takes some time between finishing the first 128 tiles and starting the other 128 tiles. Can you please recheck if you really have the problem? WanMil Hi WanMil and a big sorry. I never thought about a second run of splitter. I just noticed that splitter just processes half of the tiles. It works fine in two runs and seems to be faster than two separate runs. Do you have a guess why splitter needs a second run? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and o5m
Hi Chris, do you have set --max-areas. I found out, that it is set by default to 255, so that's why splitter uses a second run. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Error while generating the index
Hi, while generating index with 2023 I got with some maps this error. Has someone an idea what went wrong? It happens with my map of Germany and Denmark, all other maps were ok. Processing of the tiles was fine for all maps. Henning Exception in thread main java.lang.NegativeArraySizeException at uk.me.parabola.imgfmt.app.BufferedImgFileReader.get(BufferedImgFileReader.java:165) at uk.me.parabola.imgfmt.app.net.NETFileReader.fetchZipCity(NETFileReader.java:151) at uk.me.parabola.imgfmt.app.net.NETFileReader.getRoads(NETFileReader.java:115) at uk.me.parabola.imgfmt.app.map.MapReader.getRoads(MapReader.java:180) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addStreets(MdrBuilder.java:300) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:171) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:431) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error while generating the index
Nobody any guesses or hints? My mkgmaps-call: mkgmap.jar --max-jobs=1 --style-file=data\style --draw-priority=24 --tdbfile --code-page=%codepage% --route --remove-short-arcs --location-autofill=bounds,is_in,nearest --index --bounds=data\bounds --ignore-maxspeeds --add-pois-to-areas --mapname=%id%00 --overview-mapname=%id%00 --family-name=RRK %name% --series-name=RRK %name% %heute% --description=RadReiseKarte --family-id=%id%00 --product-id=1 --levels=0:24,1:22,2:21,3:20,4:19,5:18,6:16 --reduce-point-density=2.6 --reduce-point-density-polygon=8 --merge-lines --generate-sea=extend-sea-sectors,close-gaps=6000 --output-dir=maps\%name% --gmapsupp TYP\%id%00.typ %id%*.pbf In all style-files I put the mkgmap:...-rules WanMil told with r2020. It works fine now for all maps beside Germany. If I remove --location-autofil nothing changes. If I remove --index, there is no error anymore but also no index ;-) . Am 07.09.2011 09:36, schrieb Henning Scholland: Hi, while generating index with 2023 I got with some maps this error. Has someone an idea what went wrong? It happens with my map of Germany and Denmark, all other maps were ok. Processing of the tiles was fine for all maps. Henning Exception in thread main java.lang.NegativeArraySizeException at uk.me.parabola.imgfmt.app.BufferedImgFileReader.get(BufferedImgFileReader.java:165) at uk.me.parabola.imgfmt.app.net.NETFileReader.fetchZipCity(NETFileReader.java:151) at uk.me.parabola.imgfmt.app.net.NETFileReader.getRoads(NETFileReader.java:115) at uk.me.parabola.imgfmt.app.map.MapReader.getRoads(MapReader.java:180) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addStreets(MdrBuilder.java:300) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:171) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:431) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132) ___ 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
Re: [mkgmap-dev] Error while generating the index
Hi again If I let mkgmap only create index, I got the following exception: Exception in thread main java.lang.IndexOutOfBoundsException: Index: 44120, Size: 361 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.imgfmt.app.net.NETFileReader.fetchZipCity(NETFileReader.java:145) at uk.me.parabola.imgfmt.app.net.NETFileReader.getRoads(NETFileReader.java:115) at uk.me.parabola.imgfmt.app.map.MapReader.getRoads(MapReader.java:180) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addStreets(MdrBuilder.java:300) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:171) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:431) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132) parameters: mkgmap.jar --max-jobs=1 --tdbfile --code-page=%codepage% --index --mapname=%id%00 --overview-mapname=%id%00 --family-name=RRK %name% --series-name=RRK %name% %heute% --description=RadReiseKarte --family-id=%id%00 --product-id=1 --output-dir=maps\%name% --gmapsupp TYP\%id%00.typ maps\Germany\%id%*.img Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error while generating the index
Am 08.09.2011 10:18, schrieb Carsten Schwede: Hi Henning, do you have got a completely fresh version of mkgmap? Once I had also similiar errors, they were gone with a really fresh version of the sources. I had removed my local sources completely and had downloaded the mkgmap sources again. I use always the compiled version from mkgmap-download-page. Also other maps were fine. The Map of Germany is the biggest one with 106 tiles and about 1.37gb. Last week with 2018 (I think) everything was ok. Has someone an older versions of mkgmap before addr-Tags integration was added and could e-mail it to me? Then I could find the last working version. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error while generating the index
No guesses what could cause the following error? Would it help to upload the img-files? Am 08.09.2011 10:14, schrieb Henning Scholland: Exception in thread main java.lang.IndexOutOfBoundsException: Index: 44120, Size: 361 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.imgfmt.app.net.NETFileReader.fetchZipCity(NETFileReader.java:145) at uk.me.parabola.imgfmt.app.net.NETFileReader.getRoads(NETFileReader.java:115) at uk.me.parabola.imgfmt.app.map.MapReader.getRoads(MapReader.java:180) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addStreets(MdrBuilder.java:300) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:171) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:431) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error while generating the index
Am 12.09.2011 23:31, schrieb Steve Ratcliffe: On 12/09/11 13:01, Henning Scholland wrote: No guesses what could cause the following error? Would it help to upload the img-files? Am 08.09.2011 10:14, schrieb Henning Scholland: Exception in thread main java.lang.IndexOutOfBoundsException: Index: 44120, Size: 361 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.imgfmt.app.net.NETFileReader.fetchZipCity(NETFileReader.java:145) That error means that mkgmap cannot understand the format of the input .img file. So probably it was written incorrectly, assuming it was created by mkgmap itself. So it would probably help to identify the particular file that causes the error and upload it and if possible, the .osm file it was created from. ..Steve Hi Steve, Thanks for your hint. I figured out that tile number 26 causes the error (from Lübeck to north end of Sylt). If you would like to take a deeper look in the data you can find the splitted pbf and the resulting img here: http://www.aighes.de/data/tile_with_problem.7z If I generate the index without tile 26 everything is as fine as normal. Source of the data is a planet-file updated 2011-09-12T20\:00\:00Z. If you need further information let me know. Henning Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error while generating the index
Hi, I don't know why but I tried it again with 2028 an new data and there isn't any error any more. I tried it with default-style and my own style. Both where fine. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS 64bit installer
No Problems with normal mkgmap-nsis-installer with Win 7 64bit. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS 64bit installer
Hi I've just the Wow6432Node key in my registry. In the nsi-file generated by mkgmap there is only the 32bit-reg-key, so I think Windows changes it automatic. Also I never heard about problems while installing my maps with a 64bit Windows. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Reimplementation of add-pois-to-areas option
Maybe it would be a good solution, to look at first, if one node of the polygon is tagged as building=entrance. If there is one, use this node as POI-node, else create an node in the centre of the polygon. @WanMil: Do you see a more or less easy way to control the creation of POI out of areas with a style-file? So that it is possible to have POI out of polygons, which should not be rendered as a polygon. Now this is only possible with a transparent polygon. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Reimplementation of add-pois-to-areas option
Hi Wanmil, I tried to test your uploaded version, but it seems not to work with pbf. Is it just a compiler-thing or is this an error caused by your patch? Henning Error at line 1, col 1 Bad file format: 1701.osm.pbf Error parsing file ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Reimplementation of add-pois-to-areas option
Works well WanMil! Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Am 13.10.2011 11:19, schrieb Chris66: Am 10.10.2011 20:37, schrieb svn commit: Reimplementation of the add-pois-to-area option The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file. Didn't follow all the postings. Main question: Existing styles have to be adjusted, right? Or is it downward compatible to existing styles? If you haven't made any hacks in your Style-File to show more POI's, there shouldn't be a problem. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Using name-tag-list for country names
Am 14.10.2011 22:15, schrieb WanMil: Is there anyone who likes to fix the south african boundaries? They look awfull because there are several mixed multipolygons for the boundary. I took a look at the boundaries. There are two boundaries with admin_level=2. One containing coastline and the other one containing 12-mile-zone (I guess). If this is causing problems, this should be discussed with local community. In my opinion each country should have just one boundary with admin_level=2. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Using name-tag-list for country names
Am 14.10.2011 22:15, schrieb WanMil: Is there anyone who likes to fix the south african boundaries? They look awfull because there are several mixed multipolygons for the boundary. Sorry, forget about my first mail. The MP of the boundary contained an error. Should be fixed now. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] add-pois-to-areas entrance as option
You should only tagg the hole polygon as restaurant etc. if the hole polygon contains only this restaurant. Else you should tagg each restaurant etc. as a node inside the building-polygon. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] uisng wildcards in names
I'm not sure if this is always a good thing. If these faults wont cause a different look in the map, no one will fix these faults. I think it will be better to repair osm-data e.g. with taginfo. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Further reduction of the builtin-tag-list
Hi WanMil, could you explain, what mkgmap do with maxspeed-tagg? I haven't care about this and removed maxspeed from all ways in my style-file. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitted ways
Am 21.10.2011 22:08, schrieb Chris66: Am 21.10.2011 22:03, schrieb Werner Horsch: Is there a way to join ways which were splitted in OSM? They appear in a Garmin Nüvi as so many ways as splits were done making searches more difficult I was thinking in write some code ro re-join ways before running mkgmap, but I prefer to ask first. there is an option --merge-lines but it is expected to break routing. In newer versions of mkgmap it wont break routing, but it is difficult to set an routing-waypoint in low zoomlevel. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitted ways
Am 21.10.2011 22:03, schrieb Werner Horsch: Is there a way to join ways which were splitted in OSM? They appear in a Garmin Nüvi as so many ways as splits were done making searches more difficult I was thinking in write some code ro re-join ways before running mkgmap, but I prefer to ask first. I think, it's better to re-join the ways in mkgmap. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] add-pois-to-lines ?
Of course you're right. There should be more Nodes in a fix distance to each other like MapComposer did it. My intention was, that the user should be able to control for which ways these nodes were created. E.g. if I just want to display maxspeed-signs, these nodes should only be created if the way has a maxspeed-tagg. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] possible bug? mkgmap freezes with lines only routing style
Am 29.10.2011 15:57, schrieb Steve Ratcliffe:
Hi
I would like some opinions please from those that make maps.
If you have a style that say sets the name of every path to 'Path'
eg: highway=path | highway=footway | highway=track {name 'Path' }
or anything similar that results in thousands of roads with the same
name, then mkgmap appears to freeze.
The code that is slow is creating a list of roads that will be used
when you search for an address in MapSource or on the device.
I can fix this in various ways, but I want to ask how useful it is to
have thousands of roads with the same name appear as a result of a
search?
For a start in mapsource, you only see a few of the results anyway.
Should I drop the name completely from the index when there are more
than say 500 roads with the same name in the same city?
There is a branch called simplify-sorted-roads where I am trying out
different approaches to the problem, if anyone else wants to try it out
or look at it.
I think it would be better to control it via style-file. Eg. you should
add a tagg like mkgmap:nomerge=yes for such ways.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP compiler
Hi, I'm back from a longer holiday and haven't read every mail. So maybe my comments could already be discussed. First: It works nearly perfect! My problem is, that the generated typ-file will not written to the given output dictionary. That would be a very useful thing. The other thing is the name of the typ-file. Would it be possible to use the name of the txt-file? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] exclude words from city / state
No, I think in Germany we are using for Stadt Erfurt name=Erfurt name:prefix=Stadt. Henning Am 10.12.2011 12:55, schrieb Marko Mäkelä: On Sat, Dec 10, 2011 at 11:05:32AM +0100, Henning Scholland wrote: I don't think so because the searchstring is Stadt . But I'm not sure if there are other false positives so I think it would be better to fix these things in osm-data with name:prefix. You hopefully mean short_name and short_name:*. Marko ___ 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
Re: [mkgmap-dev] splitter
Hi, you should remove --max-areas=1. This isn't useful, if you want to split your inputdata into several smaller parts ;) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2140: - Compiled typ file should be placed in output-dir
Am 09.12.2011 22:00, schrieb svn commit: Version 2140 was commited by steve on 2011-12-09 21:00:51 + (Fri, 09 Dec 2011) - Compiled typ file should be placed in output-dir Hi Steve, just another problem now ;) If you use --output-dir and TYP-file and --gmapsupp, then I got a Could not open rrk_typ.typ-exception while mkgmap generates the gmapsupp. I think mkgmap looks only to default directory. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] LocationHook speedup
Am 31.12.2011 14:58, schrieb Gerd Petermann:
I used another way to optimize that part. On my machine, the list()
method is much faster than listFiles():
String [] boundaryFileNames = boundaryDir.list();
boolean foundBndFile = false;
for (String s: boundaryFileNames){
if (s.endsWith(.bnd)) {
foundBndFile = true;
break;
}
}
if (!foundBndFile) {
log.error(Disable LocationHook because boundary
directory contains files. Dir:
+ boundaryDir);
return false;
}
Gerd
Hi, you missed a no in the errormessage ;)
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feedback about speedup patches
Hi, great job!!! I'm saving now about 13 minutes (-17%) of mkgmap-runtime. In detail: Germany: 19:17 (2154: 24:52) -22% Turkey: 00:58 (2154: 01:04) -09% Scandinavia: 08:58 (2154: 10:33) -15% BeNeLux: 09:27 (2154: 11:00) -14% Alps: 15:03 (2154: 18:30) -19% GreatBritain: 06:23 (2154: 07:03) -09% Denmark: 01:57 (2154: 02:10) -10% mkgmap-call (example): C:\Programme\Java\jre7\bin\java.exe -Xmx7000M -jar bin\mkgmap-r2159.jar --max-jobs=5 --style-file=data\style_rrk --draw-priority=24 --tdbfile --latin1 --code-page=1252 --route --remove-short-arcs --link-pois-to-ways --location-autofill=bounds,is_in,nearest --index --bounds=data\bounds --ignore-maxspeeds --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance --mapname=1400 --overview-mapname=1400 --family-name=RRK BeNeLux --series-name=RRK BeNeLux 04.01.2012 --description=RadReiseKarte --family-id=1400 --product-id=1 --levels=0:24,1:22,2:21,3:20,4:19,5:18,6:16 --reduce-point-density=2.6 --reduce-point-density-polygon=8 --merge-lines --generate-sea=extend-sea-sectors,close-gaps=6000 --output-dir=maps\BeNeLux --gmapsupp data\rrk_typ.txt 14*.pbf Runs on PC with AMD Phenom II X6 1090T, 8gb RAM and a SSD (OCZ Vertex 2). Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing issue with split road
Hi The fault is in osm-data. There is no turn restriction tagged. I've added such an restriction. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] feature-request - variable copyright information
Hi, sorry, echo was a fault in my email. Doesn't work on windows for me. But I can handle the version manually. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problems searching for California addresses
Hi, I think you should have something like this in your mkgmap-call: --location-autofill=bounds,is_in,nearest --index --bounds=data\bounds Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] White tiles in the sea
Hi, are you sure, that it is a real tile, which stays empty or is it just a region, which isn't covered with real tiles. This could happen, if you split your osm-files without --no-trim. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Feature request: Layer control
Hi, I think you have to change the DrawOrder in your TYP-file. This tells the Garmin-device in which order the polygons should be rendered. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Hi Gerd, is it possible to use a normal splitter r200 with o5m input-data? What about mkgmap? Henning Am 17.10.2012 16:36, schrieb GerdP: Hi, here is a first try to fix this issue. splitter_problem_list.patch http://gis.19327.n5.nabble.com/file/n5731258/splitter_problem_list.patch A sample list of problem polygons: problem_polygons.txt http://gis.19327.n5.nabble.com/file/n5731258/problem_polygons.txt Specify it in the new parameter problem-file, e.g. --problem-file=./problem_polygons.txt It is recommended to use o5m format as input. To convert an existing osm.pbf file to o5m use e.g. osmconvert --drop-version --out-o5m europe.osm.pbf europe.o5m Sorry, the new code is not well commented yet, but I think it works quite well now. Any feedback is welcome. Ciao, GerdP ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Am 18.10.2012 11:44, schrieb Minko: If this patch will be implemented, will there be a list somewhere (wiki?) where we can add problematic multipolygons? I started a list here: http://wiki.openstreetmap.org/wiki/Mkgmap/help/problematic_polygons ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Hi Gerd, before adding severals boundarys and many ferry-ways in baltic sea just a question. Would it be possible to add wildcards like all ways and relation with ferry=* or all ways and relations with admin_level=2 ? How do others thing about it? Are there more ways which have typical a larger distance between nodes? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR_TRIM_ADDR.CXX error
Am 22.10.2012 13:34, schrieb Minko: Any idea what the warning message point number too big means? It is displayed when generating an index file on this img: http://mijndev.openstreetmap.nl/~ligfietser/test/OFM_Lite/63440791.zip The map looks ok without any crashes, just wondering what this message means. I have this massage with some tiles too. It comes mainly in combination with area to small to split. Maybe this helps. SEVERE (MapSplitter): 1706.osm.pbf: Area too small to split at http://www.openstreetmap.org/?mlat=56.27725mlon=9.11998zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapBuilder): 1706.osm.pbf: FIXME - too many POIs in group ...~150... SEVERE (MapBuilder): 1706.osm.pbf: FIXME - too many POIs in group Tile 1706 is in Denmark areas.list: 1706: 2603008,323584 to 2631680,446464 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR_TRIM_ADDR.CXX error
Am 22.10.2012 13:58, schrieb Minko: In Denmark all(?) addresses have been imported, something we are considering in the NLD's too since the National Address database is public domain. Maybe this causes those warnings? I checked this. Every problematic tile belongs to Denmark. So address-nodes could be the problem. They are rendered with point-ID 0x9000. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problematic_polygons file
Am 23.10.2012 09:59, schrieb Gerd Petermann: Hi Carlos, I've seen problematic_polygons file in growing quite fast in the wiki. May it affect splitter performance? If so, would it make sense to split the file by continents or countries? regarding performance: a) if you specify the --problem-file parm, splitter has to do a lot more work, so that affects performance, no matter how many ids you put ino your list. b) I don't expect a measurable performance impact for any id that does NOT occur in your input OSM file(s) as long as this list doesn't contain millions of ids. The information is stored in HashMaps, so the only negative impact is a higher possibility of hash collisions and a slightly higher memory usage for these HashMaps. Most of the additional time that is required to handle the list is caused by the fact that splitter has to read the input file more often (3 times). With o5m and pbf format, only parts of the file(s) are read, with XML input the complete file is processed. Of course, those ids that occor in your input data will require more heap and probably produce more output data, so that will affect performance. OK? The bigger problem that I see is this: The list now contains some relations like rel:52822 # Border Sweden rel:1059668 # Border Norway If you use the complete list to split e.g. finland.osm.pbf, the input file will only contain parts of the needed data for these polygons. I wonder what splitter should do in these cases? Currently it might print a few messages regarding missing nodes or ways, but it will use the incomplete data and it might write the incomplete relation to more tiles than r202, thus mgkmap might produce even more error messages. I think it would be better to change this so that splitter returns to the default handling for every relation or way that is not complete, with a corresponding message. Would that be better? I think splitter should write everything he could find in input-data to each tile. The intention is a complete boundary. Of course if you only create a map of Finland, border of Sweden would only partly in the map, but these lines shouldn't be broken. But is this a new problem? I think the relation of eg. Sweden would be written to a tile containing a part of Swedish boundary and there are also missing ways and nodes. @Carlos: Maybe it would be better to separate the wiki-list in several parts like ferry, boundary, lakes, forrest. So it is easier to find out, if the ID is already in the list. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problematic_polygons file
Hi I separated now ferry ways and boundary-relations and everything else and ordered each group by ID. I think the rest depends on the length of the list. Boundaries and ferries are separated, because they are just a side effect and are dominating actual. Also maybe they could be removed if a general rule for them is possible. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Hi Gerd, I found another problem. If a long way has no nodes in a tile but is crossing the tile, then this long way isn't copied into the crossing tile. Is it possible to fix this? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Hi Gerd, I'm using v2 of your patch. areas.list: 1605: 2320384,-153600 to 2369536,-55296 1645: 2320384,-55296 to 2381824,26624 problematic way:67416703 This way has only nodes in 1645 and is crossing 1605. He isn't displayed with josm, if split the both tiles out of a planet.pbf but it is in the file (opened with texteditor). Also mkgmap doesn't render it. Similar problem: way:29911983 and way:150505423 have one node in 1645 and are in the file but aren't shown in josm and mkgmap-generated map. Bu there are not all nodes of the ways in the tiles. Maybe this is problematic? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
