Re: [mkgmap-dev] Commit: r2050: Add option pois-to-area-placement to configure the placement of POIs created from areas
Hi, I tested this (r2052) and found that pois-to-area-placement (in the arguments file) does not work like pois-to-area-placement=building=entrance;building=entrance;entrance=yes So the default does not work. I tested with entrance=yes nodes. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Defer relations does not work with PBF
Hi WanMil, Sorry, I have been a little busy due to a business trip last week. I still have not fully recovered from the jet lag. you have commited the defer relation lookup feature (r1466). It is not implemented for the PBF loader. Do you still use this feature? Can you give an example where this feature is useful? I tested it on this ferry route relation a long time ago: http://www.openstreetmap.org/browse/relation/155054 The relation contains two stops that are type=site relations, containing the highway=bus_stop node in role=passengers and a node on the route way http://www.openstreetmap.org/browse/way/123403659 in role=vehicle. I saw a suggestion in the wiki that bus route relations should be mapped in this way. I guess that the idea is to enable better routing, or to better resolve the bus stops when a bus goes through some 270° ramps below and above a bridge. I just checked, and the two highway=bus_stop endpoints of this ferry route do not inherit any ref or name information from the ferry route relation. So, it is indeed broken for PBF input. How hard would it be to implement the deferred relation lookup in PBF? I feel that it is needed for anything that uses subrelations. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2050: Add option pois-to-area-placement to configure the placement of POIs created from areas
Hi Chris, Am Freitag 21 Oktober 2011, 08:59:04 schrieb Chris66: Hi, I tested this (r2052) and found that pois-to-area-placement (in the arguments file) does not work like pois-to-area-placement=building=entrance;building=entrance;entrance=yes So the default does not work. I tested with entrance=yes nodes. Chris For lines within the argument file If you give : add-pois-to-areas pois-to-areas-placement or add-pois-to-areas pois-to-areas-placement= an empty tag list is used, so the pois are placed at the center. If you do not give the option pois-to-area-placement at al the default taglist is assumed, so (again in the argfile): add-pois-to-areas # no option here or add-pois-to-areas pois-to-areas-placement: entrance=main;entrance=yes;building=entrance or add-pois-to-areas pois-to-areas-placement=entrance=main;entrance=yes;building=entrance is the same or in your case: add-pois-to-areas pois-to-areas-placement: entrance=yes All given examples tested and work like expected. Did you add quotes from the command line (which prevent shell interpretation) to the argument file, or was the help text confusing? hope this helps Hasemann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2050: Add option pois-to-area-placement to configure the placement of POIs created from areas
Am 21.10.2011 12:01, schrieb Olaf Hasemann: Did you add quotes from the command line (which prevent shell interpretation) to the argument file, or was the help text confusing? Yes, maybe I misunderstood the help text: --pois-to-areas-placement[=taglist] A semicolon separated list of tag=value definitions. A POI is placed at the first node of the polygon tagged with the first tag/value pair. If none of the nodes are tagged with the first tag-value pair the first node tagged with the second tag-value pair is used and so on. If none of the tag-value pairs matches or the taglist is empty the center of the polygon is used. It is possible to define wildcards for tag values like entrance=*. Default: entrance=main;entrance=yes;building=entrance Which I interpreted in this (obviously wrong) sense : If the option is missing, POI is placed in the middle of the polygon If the option is set, POI is placed at a node which can be defined by the tag-list. If tag-list is missing, use default tag list So, as I learned now: The default is used if the pois-to-areas-placement option is completely missing. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Perculiar index search concerning bus_stops
Just for clarification: All bus_stops have the point number 0x2f08. That means that they also must be available as categorized POIs. But what I see in the category is the same result as above - peculiar. Regards Klaus -- View this message in context: http://gis.638310.n2.nabble.com/Perculiar-index-search-concerning-bus-stops-tp6892353p6916873.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Defer relations does not work with PBF
Hi WanMil, Sorry, I have been a little busy due to a business trip last week. I still have not fully recovered from the jet lag. you have commited the defer relation lookup feature (r1466). It is not implemented for the PBF loader. Do you still use this feature? Can you give an example where this feature is useful? I tested it on this ferry route relation a long time ago: http://www.openstreetmap.org/browse/relation/155054 The relation contains two stops that are type=site relations, containing the highway=bus_stop node in role=passengers and a node on the route way http://www.openstreetmap.org/browse/way/123403659 in role=vehicle. I saw a suggestion in the wiki that bus route relations should be mapped in this way. I guess that the idea is to enable better routing, or to better resolve the bus stops when a bus goes through some 270° ramps below and above a bridge. I just checked, and the two highway=bus_stop endpoints of this ferry route do not inherit any ref or name information from the ferry route relation. So, it is indeed broken for PBF input. How hard would it be to implement the deferred relation lookup in PBF? I feel that it is needed for anything that uses subrelations. Hi Marko, I think it's quite easy. I just wondered if it does anything because nobody complained. And of course I need a testcase to implement the feature. Can you send me the style files where it has an effect? I will try to fix that within the next days. Have fun! WanMil Best regards, 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
[mkgmap-dev] gmapsupp visible in Basecamp
Just found out that you can make a gmapsupp.img on micro SD card or in your GPS unit visible in Basecamp. This becomes the common procedure by map sellers, they only deliver a gmapsupp on microSD card so you don't have to install the map on the pc anymore. By default the Ms (Mapsource) flag is set to 1 but you can set it to 0 with Gmaptool: Reading file G:/garmin/gmapsupp.img. File: G:/garmin/gmapsupp.img, length 46495744 Header: 21.10.2011 18:36:39, DSKIMG, XOR 00, V 0.00, Ms 1 Set version in header - advanced option, GMapTool writes map version into img file header. First two input fields are for map version, field Ms is for Mapsource flag. Value 0 for flag makes img in GPS visible to BaseCamp. I have tried it with my Openfietsmap and it worked. However I discovered that my map is transparent. Underneath it appeared the Basecamp basemap, a very rough map with highways that used my custom typ file (with the wrong lines of course). Any ideas how to make this basemap invisible? I think it has something to do with not using the 0x4b background; I dont use it because this causes ghost shading in Mapsource (zooming in produces a lot of noise, like this example: http://dl.dropbox.com/u/8541959/mapsource%20lines.jpg). If I edit my map with gpsmapedit, I can see this background polygon 4b is still there, but I simply dont have defined it in the typ file because of those unwanted effects in Mapsource. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Defer relations does not work with PBF
On Fri, Oct 21, 2011 at 06:22:29PM +0200, WanMil wrote: I think it's quite easy. I just wondered if it does anything because nobody complained. And of course I need a testcase to implement the feature. Can you send me the style files where it has an effect? It should work with the default style. Let me try now. josm * hit ctrl-shift-o * download relation 155054 * download the bounding box minlat='60.1469084' minlon='24.9462708' maxlat='60.16963579995' maxlon='24.9937026' * or just download the above bounding box straight away * save to file test.osm java -jar mkgmap.jar --gmapsupp --latin1 test.osm strings gmapsupp.img |grep 009 KAUPPATORI 0099(SUOMENLINNAN LAUTTA) SUOMENLINNA 0098(SUOMENLINNAN LAUTTA)+ The same thing with osm.pbf should omit the name of the ferry route relation from the bus stop labels: strings gmapsupp.img |grep 009 KAUPPATORI 0099 SUOMENLINNA 0098+ Strangely, I failed to convert the test.osm to test.osm.pbf: osmosis --rx test.osm --wb test.osm.pbf osmosis --rx test.osm --wb omitmetadata=true test.osm.pbf java -jar mkgmap.jar --gmapsupp --latin1 test.osm.pbf This would produce an empty gmapsupp.img for me (10k or 8k instead of the 92K). I have no idea what goes wrong. Maybe my Osmosis 0.39 is too old? This is the first time I have asked it to write osm.pbf. XML output and PBF and XML input have worked. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitted ways
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. Thanks ___ 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. there is an option --merge-lines but it is expected to break routing. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
On http://forum.gps.nl/viewtopic.php?f=109t=36229 there are some screenshots about the transparency problem of the gmapsupp.img files in Basecamp. I have tried to put a background polygon 0x4b in my typ files (draw priority 1, sea at 2 and the rest higher numbers) but it didn't help. Other mkgmap OSM maps shows the same effects. Here is a screenshot from the gmapsupp on sd card: http://forum.gps.nl/download/file.php?id=410 This is the pc installed version: http://forum.gps.nl/download/file.php?id=411 ___ 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] splitted ways
Why should we use -merge-line ? Why should we dont use -merge-lines ? Will the img-Files be smaler with merge-line ? Will search be faster ? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
