[mkgmap-dev] Last level not empty, why not anymore?
How comes that the newest mkgmap versions write in information into the last level, instead of leaving it empty? I do think that this prohibits using layers in Mapsource as maps without empty level seem to show up allways on top, instead according to their mapname/mapid. 3 weeks ago this behaviour still was fine. There could be several other problems related to not leaving the last level empty, though I have not found any except the draw priority issues in Mapsource I'm not sure since when the problem came up exactly - because I currently got problems accessing my main pc remotely, From around 25 weeks ago to 10 days ago I did not update my mkgmap version because some of my own patches were not compatible with the continue patch and mkgmap would not build anymore. 10 days ago I switched to newest mkgmap version and put in the continue patch - otherwise my mkgmap version is equal to svn. So sometime in between 10 days ago and 25 days ago this behaviour was changed. (so in between rev 1080 and 1124). Felix ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Last level not empty, why not anymore?
Hi On 12/08/09 08:52, Felix Hartmann wrote: > How comes that the newest mkgmap versions write in information into the > last level, instead of leaving it empty? What tool is showing you that it is not empty? I have run a quick test on the latest and it looks empty: RgnDisplay output: - Level 5, Subdiv 1 -- || | final at 1d, (end 0) - Level 4, Subdiv 1 -- ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Last level not empty, why not anymore?
Steve Ratcliffe wrote: Hi On 12/08/09 08:52, Felix Hartmann wrote: How comes that the newest mkgmap versions write in information into the last level, instead of leaving it empty? What tool is showing you that it is not empty? I have run a quick test on the latest and it looks empty: RgnDisplay output: - Level 5, Subdiv 1 -- || | final at 1d, (end 0) - Level 4, Subdiv 1 -- ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Mapsource. I have maps with level 0-4 while level 5 should be empty, set via "resolution xx" in the style-file (24,22,20,18,16). the overview map contains points only, no lines (verified with gpsmapedit and mp text). Nevertheless can I see motorways and coastlines in Mapsource (detail medium) from 50-120km, while it should be empty as the lowest resolution I have set in the style-file is 16. 50-120km is however resolution 15 (zoom=5 for mapsource). Opening the .img in gpsmapedit shows me that level 5 is the last level at resolution 15. Now having an empty overview map and seeing motorways and coastline in level 15 in Mapsource I have to assume that the last level is not empty (otherwise I could not see it in Mapsource). I got notice of the problem when I wanted to show srtm contourlines with my maps in Mapsource. As usual I connected all *.img (my mkgmap produced maps and the contourline maps) by tdb/overview image. The contourlines have higher map-id and higher name. Usually therefore you would expect contourlines to show above any polygon of the map *.img. Due to the last level not empty bug I assume (can't find any other problem) the contourlines are drawn below the polygons, and therefore invisible if I set background polygon 0x4b in typfile. If no typfile is used they are still behind all polygons (so invisible in forests, cities, ). You can try if you find any other error: maps are here: http://openmtbmap.x-nation.de/maps/mtbaustria.7z.zip contourlines here: http://openmtbmap.x-nation.de/maps/contourlines/srtm_austria.zip ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] patch (how to submit?)
Hi Steve, hello list, Here's a patch that documents the naming options better. It mainly describes the --family-name option (previously only a TODO). Is this the best way to submit them? (I noticed that a rather trivial patch that I sent to the list, about Splitter reading hex numbers from areas.list, was not checked in so I'm wondering if there's a better way to send patches?) Best regards, Valentijn --- options.orig 2009-08-12 11:05:57.0 +0200 +++ options 2009-08-12 11:09:48.0 +0200 @@ -123,7 +123,13 @@ This is an integer that identifies a family of products. --family-name - TODO: describe this + If you build several maps, this option describes the + family name of all of your maps. Garmin will display this + in the map selection screen. + Example: --family-name="OpenStreetmap mkgmap XL 2019" + TODO: at least the "-" character seems to have a strange + effect on the family name; latin-alphabet and digits seem + safe, but other characters should be checked. --product-id This is an integer that identifies a product within a family. @@ -134,8 +140,11 @@ --overview-mapname=name If --tdbfile is enabled, this gives the name of the overview - .img and .tdb files. - The default map name is OSM_map. + .img and .tdb files. The default map name is OSM_map. + On Garmin maps, this option describes the area of your + map, for example "Germany_and_Belgium". + TODO: underscores seem to render as spaces, not sure if this + is mandatory. --overview-mapnumber=8 digit number If --tdbfile is enabled, this gives the internal 8 digit ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Option --remove-short-arcs
Hi Is there any problem with this option, such that you might not want to use it? As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m. If that is so, then we should just set the required behaviour whenever the route option is given. I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hello Steve, Steve Ratcliffe schreef: > As I understand it, if you do not give it then routing will not work, > as we know (or believe) that all routing arcs have to be more than > 5.4m. Your 5.4m confuses me a bit. the help file says: "If MinLength is specified (in metres), arcs shorter than that length will be removed. If a length is not specified, only zero-length arcs will be removed." Also, Mark Burton noted "As you know, the resolution is just over 2m so any (connected) nodes that are less than approx 2.5m apart will need to be merged to avoid having short arcs.". That's why I (manually) set my short-arcs option to 4 meters; but now I understand that that's too small? > but if removing them is our current best approach, lets make it the > default. I agree. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Steve, > Is there any problem with this option, such that you might not want > to use it? I am not aware of any problem. > As I understand it, if you do not give it then routing will not work, > as we know (or believe) that all routing arcs have to be more than 5.4m. I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24) > If that is so, then we should just set the required behaviour whenever > the route option is given. Why don't we do that but still provide an option to turn off the short arc removal (which should never need to be used but may be useful when tracking down problems). > I realize that there might be other approaches, eg we could stretch arcs > instead of removing them, but if removing them is our current best > approach, lets make it the default. It seems to be working well enough at the moment. Shall I change the code to remove the --remove-short-arcs option and, instead, enable that function if --route is specified and (the new) --keep-short-arcs option is not specified? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Mark Burton wrote: Hi Steve, Is there any problem with this option, such that you might not want to use it? I am not aware of any problem. As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m. I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24) If that is so, then we should just set the required behaviour whenever the route option is given. Why don't we do that but still provide an option to turn off the short arc removal (which should never need to be used but may be useful when tracking down problems). I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default. It seems to be working well enough at the moment. Shall I change the code to remove the --remove-short-arcs option and, instead, enable that function if --route is specified and (the new) --keep-short-arcs option is not specified? Cheers, Mark Yes, but we should be clear about the distance needed. I used =3 because without specifying it, I had some route calculation working, that without specifying did not work. If there is really 5.4m then the default should go for 5.4 -- or just leave the option as it is right now but use it by default except if say --remove-short-arcs=no is given... ___ 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] [PATCH v1] Better rounding in mkgmap
On Tue, Aug 11, 2009 at 5:37 PM, Elrond wrote: > "incorrect" is probably too hard (except for the very > special case, where I needed the better rounding). > "suboptimal" would be a better term. Hi Elrond, I tested your patch, and could see differences in the map. However, I could not really determine which would be more 'optimal'. I'll just take your word for that. ;-) (I tested on Roadtrip for the Mac, so behaviour may differ in Mapsource or in a GPS unit.) I have noted no additional difficulties with the patch. Everything seems to work fine so far, both in Roadtrip and on my eTrex. Thanks. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Felix, > Mark Burton wrote: > > Hi Steve, > > > > > >> Is there any problem with this option, such that you might not want > >> to use it? > >> > > > > I am not aware of any problem. > > > > > >> As I understand it, if you do not give it then routing will not work, > >> as we know (or believe) that all routing arcs have to be more than 5.4m. > >> > > > > I believe that the mimimum distance will depend on lat/lon because the > > real constraint is that the source and target nodes must not have the > > same coordinates (resolution being 360 deg / 2^24) > > > > > >> If that is so, then we should just set the required behaviour whenever > >> the route option is given. > >> > > > > Why don't we do that but still provide an option to turn off the > > short arc removal (which should never need to be used but may be useful > > when tracking down problems). > > > > > >> I realize that there might be other approaches, eg we could stretch arcs > >> instead of removing them, but if removing them is our current best > >> approach, lets make it the default. > >> > > > > It seems to be working well enough at the moment. > > > > Shall I change the code to remove the --remove-short-arcs option and, > > instead, enable that function if --route is specified and > > (the new) --keep-short-arcs option is not specified? > > > > Cheers, > > > > Mark > > > Yes, but we should be clear about the distance needed. I used =3 because > without specifying it, I had some route calculation working, that > without specifying did not work. If there is really 5.4m then the > default should go for 5.4 -- or just leave the option as it is right now > but use it by default except if say --remove-short-arcs=no is given... Ahh, I forgot about that aspect. At this time, if you don't specify a length with the --remove-short-arcs option, it only removes zero-length arcs. I think that is the most sensible behaviour because we know that zero-length arcs are bad for routing. The fact that some maps require a minimum arc length to be specified should be investigated some more to see what the issue is. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Mark Burton wrote: Hi Felix, Mark Burton wrote: Hi Steve, Is there any problem with this option, such that you might not want to use it? I am not aware of any problem. As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m. I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24) If that is so, then we should just set the required behaviour whenever the route option is given. Why don't we do that but still provide an option to turn off the short arc removal (which should never need to be used but may be useful when tracking down problems). I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default. It seems to be working well enough at the moment. Shall I change the code to remove the --remove-short-arcs option and, instead, enable that function if --route is specified and (the new) --keep-short-arcs option is not specified? Cheers, Mark Yes, but we should be clear about the distance needed. I used =3 because without specifying it, I had some route calculation working, that without specifying did not work. If there is really 5.4m then the default should go for 5.4 -- or just leave the option as it is right now but use it by default except if say --remove-short-arcs=no is given... Ahh, I forgot about that aspect. At this time, if you don't specify a length with the --remove-short-arcs option, it only removes zero-length arcs. I think that is the most sensible behaviour because we know that zero-length arcs are bad for routing. The fact that some maps require a minimum arc length to be specified should be investigated some more to see what the issue is. Cheers, Mark I think actually the reason for routing to work better with 3 instead of simply no argument might be, that garmin would not crash on very short arcs, but simply avoids to change roads often, so by setting 3 or higher one could actually reduce some unneccessary street changes, hence sometimes (very rare) better routing over long distances. Probabely this issue that was a bit controlled by the patch, should be addressed by other patches however Until we have those patches, I am a bit sceptical about dropping the support to specify the arc length. ___ 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] [PATCH v1] - Add support for marine (aka extended) types
On Tue, Aug 4, 2009 at 10:40 PM, Mark Burton wrote: > > Ahoy there shipmates, > > This patch is a first stab at providing support for the 3-byte extended > types that are used on marine maps. I tested this, and found that it works fine, both on my eTrex and in Roadtrip for Mac OS X. FYI, I did not have to switch to marine mode or anything else to get the symbols to display. (Although some of the symbols didn't look that nice, but I assume they're there for utility and not aesthetics.) So far, I have just tried this with a few types: a lateral buoy symbol and a pier line type. It would probably be nice to get this committed, so more people can experiment with the additional possibilities this can offer. > At this time, the various extra attributes that can be assigned to the > marine entities (depth, colour, light colour/flash, etc.) are not > handled but I have made some progress in understanding their encoding > so at least some of these could be supported in the future. Obviously, > the OSM data would need to be enriched to specify the required > attributes. There appears to be significant progress in adding this type of data to OSM. Since the proposed tags attempt to conform to international standards, it should be fairly easy to match these to Garmin types: http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Better rounding in mkgmap
Hi Elrond, hello list, ... I did *not* yet test the patch, but, while biking around with a Garmin this morning, I realised that getting the rounding correct is an improvement, because your position is more precise. This could help in cases where a subtle rounding error will just put you on another road. You won't notice the difference as an end user, because there's many places where the choice of two parallel roads is difficult and any GPS unit will make some mistakes. My guess is that you could only see the difference when you would try to gather data on how many times you are on the right track and how many times you're 0.5 off... So if you ask me, "better rounding is better" and we should use anything that rounds better :) V. Clinton Gladstone schreef: > Elrond wrote: >> "incorrect" is probably too hard (except for the very >> special case, where I needed the better rounding). >> "suboptimal" would be a better term. > I tested your patch, and could see differences in the map. However, I > could not really determine which would be more 'optimal'. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Felix, > Until we have those patches, I am a bit sceptical about dropping the > support to specify the arc length. I am not suggesting that we drop the ability to specify the min arc length but I do think it's reasonable for it to default to zero rather than some length like 3 or 5 (at least until we really understand what's going on). I propose: If --route is specified but --remove-short-arcs is not, we enable the short arc removal for zero length arcs. If --remove-short-arcs=num is specified then we remove arcs <= num. If --remove-short-arcs=no is specified, we don't do any short arc removal even if --route is specified. How's that sound? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - Add support for marine (aka extended) types
Clinton Gladstone writes: > On Tue, Aug 4, 2009 at 10:40 PM, Mark Burton wrote: >> >> This patch is a first stab at providing support for the 3-byte extended >> types that are used on marine maps. > > I tested this, and found that it works fine, both on my eTrex and in > Roadtrip for Mac OS X. > > FYI, I did not have to switch to marine mode or anything else to get > the symbols to display. (Although some of the symbols didn't look > that nice, but I assume they're there for utility and not aesthetics.) > So far, I have just tried this with a few types: a lateral buoy symbol > and a pier line type. I wonder about using the marine types for inland surveying features, in the glorious struggle trading off rendered accuracy and ability to convey as much information as possible. Probably that's something I'll do privately only, as I can see a lot of objections. >> At this time, the various extra attributes that can be assigned to the >> marine entities (depth, colour, light colour/flash, etc.) are not >> handled but I have made some progress in understanding their encoding >> so at least some of these could be supported in the future. Obviously, >> the OSM data would need to be enriched to specify the required >> attributes. Are we still maintaining garmin-features.csv? Perhaps all the used features are already there, but it would be nice to keep it updated to at least all the features we use. I managed to look at a test map and have a pending diff to add a few things. > There appears to be significant progress in adding this type of data > to OSM. Since the proposed tags attempt to conform to international > standards, it should be fairly easy to match these to Garmin types: > > http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging Wow, following established standards - what a novel concept, but I'm very glad to see it. pgpoVHxCzLcwX.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Mark Burton wrote: Hi Felix, Until we have those patches, I am a bit sceptical about dropping the support to specify the arc length. I am not suggesting that we drop the ability to specify the min arc length but I do think it's reasonable for it to default to zero rather than some length like 3 or 5 (at least until we really understand what's going on). I propose: If --route is specified but --remove-short-arcs is not, we enable the short arc removal for zero length arcs. If --remove-short-arcs=num is specified then we remove arcs <= num. If --remove-short-arcs=no is specified, we don't do any short arc removal even if --route is specified. How's that sound? to me that sounds good. Cheers, Mark ___ 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] [PATCH v1] - Add support for marine (aka extended) types
Hi Clinton, > On Tue, Aug 4, 2009 at 10:40 PM, Mark Burton wrote: > > > > Ahoy there shipmates, > > > > This patch is a first stab at providing support for the 3-byte extended > > types that are used on marine maps. > > I tested this, and found that it works fine, both on my eTrex and in > Roadtrip for Mac OS X. Excellent. > FYI, I did not have to switch to marine mode or anything else to get > the symbols to display. (Although some of the symbols didn't look > that nice, but I assume they're there for utility and not aesthetics.) > So far, I have just tried this with a few types: a lateral buoy symbol > and a pier line type. On my eTrex, you can choose between various marine icon sets (Garmin, NOAA, International) and there is also an option to have "marine colors". > It would probably be nice to get this committed, so more people can > experiment with the additional possibilities this can offer. As it's fairly unlikely to break maps that don't use any extended types it's probably safe to commit. > > At this time, the various extra attributes that can be assigned to the > > marine entities (depth, colour, light colour/flash, etc.) are not > > handled but I have made some progress in understanding their encoding > > so at least some of these could be supported in the future. Obviously, > > the OSM data would need to be enriched to specify the required > > attributes. > > There appears to be significant progress in adding this type of data > to OSM. Since the proposed tags attempt to conform to international > standards, it should be fairly easy to match these to Garmin types: > > http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging The author of the OpenSeaMap effort says that there are now two proposed schemes for tagging marine entities. As far as mkgmap is concerned it doesn't really make much difference what the tags are but it would be nice if there was just one tag set to transform rather than 2. However, I do intend to continue work on this soon. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Mark Burton writes: > I am not suggesting that we drop the ability to specify the min arc > length but I do think it's reasonable for it to default to zero rather > than some length like 3 or 5 (at least until we really understand > what's going on). > > I propose: > > If --route is specified but --remove-short-arcs is not, we enable the > short arc removal for zero length arcs. > > If --remove-short-arcs=num is specified then we remove arcs <= num. > > If --remove-short-arcs=no is specified, we don't do any short arc > removal even if --route is specified. That sounds fine, but I don't see why --remove-short-arcs should not be the default even when routing is not enabled. I can see the point that it is not strictly needed, but aren't repeated points in a way non-sensical anyway? pgpKMD820AOTg.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] observation regarding "board ferry"
Hello list, An observation I made regarding the "board ferry" message. I made a short route that involves a ferry in simulation (non-GPS) mode, so the Garmin will travel on the map all by itself. - both OSM and native Garmin will stop at the beginning of a ferry route, probably waiting for the virtual boat to leave. - however, the Garmin shows an icon of a boat, while the OSM map just shows an arrow (turn right/turn left). Could "board ferry" be a sort of turn restriction? I'm happy to test random values, but don't know where to look or what to look for. Anyone? 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] Option --remove-short-arcs
Hi Greg, > That sounds fine, but I don't see why --remove-short-arcs should not be > the default even when routing is not enabled. I can see the point that > it is not strictly needed, but aren't repeated points in a way > non-sensical anyway? I prefer not to mess with the map data unless absolutely necessary or explicitly called for by the user. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Mark, On 12/08/09 11:23, Mark Burton wrote: > I believe that the mimimum distance will depend on lat/lon because the > real constraint is that the source and target nodes must not have the > same coordinates (resolution being 360 deg / 2^24) Are you sure that is the real constraint? The 5.4m value is widely known and used by everyone else in the Garmin map making communities, so it sees unwise to ignore it. So OK, we do not know where this number comes from. The best speculation was from Alex who notes that it is close (within 10%) of the minimum length that can be encoded into RouteArc.lenth Since the conversion factor from meters/feet is empirically determined, it could be incorrect by a few percent anyway. Cheers, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Steve, Still more confused: Steve Ratcliffe schreef: > The 5.4m value is widely known and used by everyone else ... does this mean that, to be on the safe side, I should use --remove-short-arcs=5.5 when I want a routable map? V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Sea Area not showing on Nuvi 860T
Just thought I would let you know that while I can see the sea area on my Vista HCx, I cannot on the Nuvi 860T. You may remember that I had some issue with the address not displaying properly on the latter unit too. I wonder if there are going to be issues with maps displaying properly on new units like the 860T. Perhaps Garmin have started changing their format. -- Regards, Cliff. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1131: Add/improve help text.
Version 1131 was commited by steve on 2009-08-12 15:01:38 +0100 (Wed, 12 Aug 2009) Add/improve help text. - Valentijn Sessink ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] ... and a success report
A nice success report: I built a map of Germany for my Garmin Nuvi 205 BeNeLux & France. And guess what? Even inter-map-routing works! I can route from Amsterdam to an obscure place somewhere half way in Germany, without any problems. :-) V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Steve, > On 12/08/09 11:23, Mark Burton wrote: > > I believe that the mimimum distance will depend on lat/lon because the > > real constraint is that the source and target nodes must not have the > > same coordinates (resolution being 360 deg / 2^24) > > Are you sure that is the real constraint? Nope. > The 5.4m value is widely known and used by everyone else in > the Garmin map making communities, so it sees unwise to ignore > it. > > So OK, we do not know where this number comes from. The best > speculation was from Alex who notes that it is close (within 10%) > of the minimum length that can be encoded into RouteArc.lenth > Since the conversion factor from meters/feet is empirically > determined, it could be incorrect by a few percent anyway. Well, I don't mind. Would you like the default min arc length be 5.4m rather than 0? Easily done. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ... and a success report
On 12/08/09 15:12, Valentijn Sessink wrote: > A nice success report: I built a map of Germany for my Garmin Nuvi 205 > BeNeLux& France. And guess what? Even inter-map-routing works! I can > route from Amsterdam to an obscure place somewhere half way in Germany, > without any problems. :-) So was that with --remove-short-arcs=5.4 (or 5) in the end then? And have you done previous maps of the same area that didn't work without that option? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ... and a success report
Steve Ratcliffe schreef: > So was that with --remove-short-arcs=5.4 (or 5) in the end then? And > have you done previous maps of the same area that didn't work without > that option? No, this is a completely unrelated success report (hence the new message), and I did not try any other maps. It "just" seems to work, magically. That's how we want it, isn't it? (And it was done with ...rt-arcs=4) (And it was not thoroughly tested anyway). V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Last level not empty, why not anymore?
Hallo Felix, war jetzt gerade am einfachsten mal so zu antworten. Ich habe gerade mal dein Austria map und die SRTM-Austria mit gmaptool in ein mapset zusammengefasst. Die Höhenlinien sind nicht bzw. nur manchmal "aufblitzend" an ein paar Stellen zu sehen. Dann habe ich mapname+ID für eine Kachel der SRTM-Karte der T3= 62240042.img auf 64240042.img gesetzt, welche somit höher als die der MTBAustria ist und die Kachel neu kompiliert und eingebunden (respektive die alte Kachel natürlich rausgeschmissen). Soweit ich das sehe funktioniert es bei mir dann im Bereich dieser Kachel. MS Detail=mittel ab 3km abwärts Höhenlinien sichtbar MS Detail=am höchsten ab 10km abwärts Höhenlinien sichtbar. Gruss Gert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
It could be like this: --remove-short-arcs (a) --remove-short-arcs=MinLength (b) --remove-short-arcs=no(c) If routing is enabled, arcs shorter than 5.4m will be removed to avoid routing problems. This behaviour can be modified with this option. It has three variants: (a) turn on short arc removal even if routing is not enabled. (b) explicitly specify the minimum arc length (no 'm' suffix). (c) completely disable short arc removal. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Inter tile routing broken
Yesterday I realized I can no longer calculate routes involving more than one tile in Mapsource using my Spain map. I compile it daily using latest svn and I don't know when the problem was introduced (it worked fine last time I checked it). I have tried splitting the map with latest splitter from svn and also with version downloaded from mkgmap.org. Resulting areas.list files are: svn-splitter: # List of areas # Generated Wed Aug 12 14:24:42 CEST 2009 # 63240001: 1677312,-446464 to 1941504,-137216 # : 35.991211,-9.580078 to 41.660156,-2.944336 63240002: 1941504,-446464 to 2048000,-137216 # : 41.660156,-9.580078 to 43.945313,-2.944336 63240003: 1677312,-137216 to 1894400,215040 # : 35.991211,-2.944336 to 40.649414,4.614258 63240004: 1894400,-137216 to 2048000,215040 # : 40.649414,-2.944336 to 43.945313,4.614258 web-splitter: # List of areas # Generated Wed Aug 12 16:08:13 CEST 2009 # 63240001: 1677312,-448512 to 1941504,-137216 # : 35.991211,-9.624023 to 41.660156,-2.944336 63240002: 1941504,-448512 to 2048000,-137216 # : 41.660156,-9.624023 to 43.945313,-2.944336 63240003: 1677312,-137216 to 1894400,215040 # : 35.991211,-2.944336 to 40.649414,4.614258 63240004: 1894400,-137216 to 2048000,215040 # : 40.649414,-2.944336 to 43.945313,4.614258 I also tried other osm files, with the same result. Does anyone know what is going wrong here? Regards Carlos ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Inter tile routing broken
I bet you used --ignore-osm-bounds option on compiling! Carlos Dávila wrote: > Yesterday I realized I can no longer calculate routes involving more > than one tile in Mapsource using my Spain map. I compile it daily using > latest svn and I don't know when the problem was introduced (it worked > fine last time I checked it). I have tried splitting the map with latest > splitter from svn and also with version downloaded from mkgmap.org. > Resulting areas.list files are: > svn-splitter: > # List of areas > # Generated Wed Aug 12 14:24:42 CEST 2009 > # > 63240001: 1677312,-446464 to 1941504,-137216 > # : 35.991211,-9.580078 to 41.660156,-2.944336 > > 63240002: 1941504,-446464 to 2048000,-137216 > # : 41.660156,-9.580078 to 43.945313,-2.944336 > > 63240003: 1677312,-137216 to 1894400,215040 > # : 35.991211,-2.944336 to 40.649414,4.614258 > > 63240004: 1894400,-137216 to 2048000,215040 > # : 40.649414,-2.944336 to 43.945313,4.614258 > > web-splitter: > # List of areas > # Generated Wed Aug 12 16:08:13 CEST 2009 > # > 63240001: 1677312,-448512 to 1941504,-137216 > # : 35.991211,-9.624023 to 41.660156,-2.944336 > > 63240002: 1941504,-448512 to 2048000,-137216 > # : 41.660156,-9.624023 to 43.945313,-2.944336 > > 63240003: 1677312,-137216 to 1894400,215040 > # : 35.991211,-2.944336 to 40.649414,4.614258 > > 63240004: 1894400,-137216 to 2048000,215040 > # : 40.649414,-2.944336 to 43.945313,4.614258 > > I also tried other osm files, with the same result. > Does anyone know what is going wrong here? > Regards > Carlos > ___ > 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] Putting the DP code under the microscope (simplifyWays patch V8)
On Sat, Jul 25, 2009 at 3:55 PM, Johann Gail wrote: > > Find attached an patch of my working copy. It is based mainly on my old > simplifyWays patch. Its diffed against the current R1102. > > The main idea is to merge the lines directly before input them to the > filters. > It improves drawing speed on my etrex considerably on very low zooms. I'm > not sure, if it is the optimal place to do the merging, but it seems to > work. I tested this patch, and it seems to work well. I have not yet thoroughly tested it, and I have not done a speed comparison, but I think the patch is quite worthwhile. Are you considering further work on it, or getting it committed? Cheers and Thanks. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Inter tile routing broken
Felix Hartmann escribió: > I bet you used --ignore-osm-bounds option on compiling! > You win. That was the origin of the problem. I remember having read something about --ignore-osm-bounds affecting routing in the list or somewhere else some time ago, but I didn't take care of it :-[ . Cheers Carlos > Carlos Dávila wrote: > >> Yesterday I realized I can no longer calculate routes involving more >> than one tile in Mapsource using my Spain map. I compile it daily using >> latest svn and I don't know when the problem was introduced (it worked >> fine last time I checked it). I have tried splitting the map with latest >> splitter from svn and also with version downloaded from mkgmap.org. >> Resulting areas.list files are: >> svn-splitter: >> # List of areas >> # Generated Wed Aug 12 14:24:42 CEST 2009 >> # >> 63240001: 1677312,-446464 to 1941504,-137216 >> # : 35.991211,-9.580078 to 41.660156,-2.944336 >> >> 63240002: 1941504,-446464 to 2048000,-137216 >> # : 41.660156,-9.580078 to 43.945313,-2.944336 >> >> 63240003: 1677312,-137216 to 1894400,215040 >> # : 35.991211,-2.944336 to 40.649414,4.614258 >> >> 63240004: 1894400,-137216 to 2048000,215040 >> # : 40.649414,-2.944336 to 43.945313,4.614258 >> >> web-splitter: >> # List of areas >> # Generated Wed Aug 12 16:08:13 CEST 2009 >> # >> 63240001: 1677312,-448512 to 1941504,-137216 >> # : 35.991211,-9.624023 to 41.660156,-2.944336 >> >> 63240002: 1941504,-448512 to 2048000,-137216 >> # : 41.660156,-9.624023 to 43.945313,-2.944336 >> >> 63240003: 1677312,-137216 to 1894400,215040 >> # : 35.991211,-2.944336 to 40.649414,4.614258 >> >> 63240004: 1894400,-137216 to 2048000,215040 >> # : 40.649414,-2.944336 to 43.945313,4.614258 >> >> I also tried other osm files, with the same result. >> Does anyone know what is going wrong here? >> Regards >> Carlos >> ___ >> 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 > > -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Rounding bug in splitter?
> If you do that, does that mean that those of us who manually calculate > our areas.list files as input to splitter will then need to ensure the > bounding coordinates are divisible by 4096 rather than 2048? No, the generation of areas.list is a completely separate step from the actual splitting that uses it. However... > I guess it will only really matter when working on tiny test areas > that could previously have been bounded in a 2048x2048 box and would > now need to be bounded in a 4096x4096 box. ...it seems you need to have the area borders aligned to 2048 map units(*) AND the area centre points must also be aligned to a 2048 map unit boundary. In practice this means that the area widths and heights must be multiples of 4096 even though the tile borders are only 2048 aligned. If you don't do this, you'll likely see some of the area-boundary problems that Valentijn descibed in the other thread. I have a fix for the splitter in the works, hopefully it will be checked in later tonight. If you're producing areas.list files by hand then I'd suggest you follow the same rules. (*) this number is dependent on the zoom level values in your style file. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Mark > Well, I don't mind. Would you like the default min arc length be 5.4m > rather than 0? Easily done. Yes I would like the default to be 5.4m as that is the best information we have. I also see no need to remove short arcs when not routing as that case is handled fine by the existing code. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs [PATCH v1]
What we want is that the result of RouteArc.convertMeters() is
not less than 1. So with the values it has at the moment that requires
a min arc length of 4.878 metres. If we set the default to 5m, we
should be chuckling.
It could look like the attached patch.
diff --git a/resources/help/en/options b/resources/help/en/options
index 9bbfad7..ceb1921 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -182,11 +182,15 @@ Miscellaneous options:
in which they appear in the OSM input. Without this option,
the order in which the elements are processed is not defined.
---remove-short-arcs[=MinLength]
- Merge nodes to remove short arcs that can cause routing
- problems. If MinLength is specified (in metres), arcs shorter
- than that length will be removed. If a length is not
- specified, only zero-length arcs will be removed.
+--remove-short-arcs (a)
+--remove-short-arcs=MinLength (b)
+--remove-short-arcs=no(c)
+ If routing is enabled, arcs shorter than 5m will be removed
+ to avoid routing problems. This behaviour can be modified with
+ this option. It has three variants:
+ (a) turn on short arc removal even if routing is not enabled.
+ (b) explicitly specify the minimum arc length (no 'm' suffix).
+ (c) completely disable short arc removal.
--road-name-pois[=GarminCode]
Generate a POI for each named road. By default, the POIs'
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
index 1a0968d..b268b17 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
@@ -184,7 +184,7 @@ public class RouteArc {
return b;
}
- private static int convertMeters(double l) {
+ public static int convertMeters(double l) {
// XXX: really a constant factor?
// this factor derived by looking at a variety
// of arcs in an IMG of Berlin; 1/4 of
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 0c45d68..82f7488 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -105,7 +105,7 @@ public class RoadNetwork {
log.error("Road " + road.getRoadDef().getName() + " (OSM id " + road.getRoadDef().getId() + ") contains consecutive identical nodes - routing will be broken");
log.error(" " + co.toOSMURL());
}
-else if(arcLength == 0) {
+else if(RouteArc.convertMeters(arcLength) == 0) {
log.error("Road " + road.getRoadDef().getName() + " (OSM id " + road.getRoadDef().getId() + ") contains zero length arc");
log.error(" " + co.toOSMURL());
}
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index e350483..025573c 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -107,8 +107,13 @@ class Osm5XmlHandler extends DefaultHandler {
ignoreBounds = props.getProperty("ignore-osm-bounds", false);
routing = props.containsKey("route");
String rsa = props.getProperty("remove-short-arcs", null);
- if(rsa != null)
- minimumArcLength = (rsa.length() > 0)? Double.parseDouble(rsa) : 0.0;
+ final double DEFAULT_MIN_ARC_LENGTH = 5;
+ if("no".equals(rsa))
+ minimumArcLength = null;
+ else if(rsa != null)
+ minimumArcLength = (rsa.length() > 0)? Double.parseDouble(rsa) : DEFAULT_MIN_ARC_LENGTH;
+ else if(routing)
+ minimumArcLength = DEFAULT_MIN_ARC_LENGTH;
else
minimumArcLength = null;
frigRoundabouts = props.getProperty("frig-roundabouts");
@@ -500,6 +505,7 @@ class Osm5XmlHandler extends DefaultHandler {
Map arcCounts = new IdentityHashMap();
int numWaysDeleted = 0;
int numNodesMerged = 0;
+ log.info("Removing short arcs (min arc length = " + minArcLength + "m)");
log.info("Removing short arcs - counting arcs");
for(Way w : wayMap.values()) {
List points = w.getPoints();
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs [PATCH v1]
On 12/08/09 17:13, Mark Burton wrote: > What we want is that the result of RouteArc.convertMeters() is > not less than 1. So with the values it has at the moment that requires > a min arc length of 4.878 metres. If we set the default to 5m, we > should be chuckling. > > It could look like the attached patch. > > > > > > ___ > 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] Option --remove-short-arcs [PATCH v1]
Sorry about previous blank email... On 12/08/09 17:13, Mark Burton wrote: > What we want is that the result of RouteArc.convertMeters() is > not less than 1. So with the values it has at the moment that requires > a min arc length of 4.878 metres. If we set the default to 5m, we > should be chuckling. OK and how about we take the opportunity to check out convertToMeters() Could anyone that has a route that they know or can measure the exact length of and compare to the length given by mapsource with an mkgmap generated map post their results to the list or to me. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs [PATCH v1]
Hi Steve, > OK and how about we take the opportunity to check out convertToMeters() The numbers it uses at the moment suggest that the Garmin wants the arc length in unit of 16 feet. > Could anyone that has a route that they know or can measure the exact > length of and compare to the length given by mapsource with an mkgmap > generated map post their results to the list or to me. I did a very quick check and the results were plausible but further checks would certainly be a good idea. Cheers, mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Putting the DP code under the microscope (simplifyWays patch V8)
I'm currently working on it. Have you tried the patch together with routing? In my trials the routing was completely broken after applying the patch. That is because the merging is done *after* all the routing info is generated. So if two ways are merged into one, the references in the routing part of the map point nowhere. Also the turn restrictions break, because they also refer to the unmerged ways. I'm trying to apply the merging *before* the routing info and the turn restrictions are generated, but up to now I run into all kinds of trouble doing that. I hope I get it working soon, but if you like to work on it as well I can post my current diffs. Regards Thilo Am 12.08.2009 um 17:10 schrieb Clinton Gladstone: > On Sat, Jul 25, 2009 at 3:55 PM, Johann Gail > wrote: >> >> Find attached an patch of my working copy. It is based mainly on my >> old >> simplifyWays patch. Its diffed against the current R1102. >> >> The main idea is to merge the lines directly before input them to the >> filters. >> It improves drawing speed on my etrex considerably on very low >> zooms. I'm >> not sure, if it is the optimal place to do the merging, but it >> seems to >> work. > > I tested this patch, and it seems to work well. I have not yet > thoroughly tested it, and I have not done a speed comparison, but I > think the patch is quite worthwhile. Are you considering further work > on it, or getting it committed? > > Cheers and Thanks. > ___ > 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] [PATCH v2] - min arc length fixes
v2 of this patch not only enables remove-short-arcs by default when
routing is in use (as previously discussed on ML) but it also fixes some
problems in the way splitting code.
I would be grateful if people could test this patch because it could
possibly cure some routing failures.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 9bbfad7..ceb1921 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -182,11 +182,15 @@ Miscellaneous options:
in which they appear in the OSM input. Without this option,
the order in which the elements are processed is not defined.
---remove-short-arcs[=MinLength]
- Merge nodes to remove short arcs that can cause routing
- problems. If MinLength is specified (in metres), arcs shorter
- than that length will be removed. If a length is not
- specified, only zero-length arcs will be removed.
+--remove-short-arcs (a)
+--remove-short-arcs=MinLength (b)
+--remove-short-arcs=no(c)
+ If routing is enabled, arcs shorter than 5m will be removed
+ to avoid routing problems. This behaviour can be modified with
+ this option. It has three variants:
+ (a) turn on short arc removal even if routing is not enabled.
+ (b) explicitly specify the minimum arc length (no 'm' suffix).
+ (c) completely disable short arc removal.
--road-name-pois[=GarminCode]
Generate a POI for each named road. By default, the POIs'
diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java
index 5462602..3e47df7 100644
--- a/src/uk/me/parabola/imgfmt/app/Coord.java
+++ b/src/uk/me/parabola/imgfmt/app/Coord.java
@@ -20,6 +20,7 @@ import java.util.Formatter;
import java.util.Locale;
import uk.me.parabola.imgfmt.Utils;
+import uk.me.parabola.imgfmt.app.net.RouteArc;
/**
* A point coordinate in unshifted map-units.
@@ -101,6 +102,11 @@ public class Coord implements Comparable {
return latitude == other.latitude && longitude == other.longitude;
}
+ public boolean tooCloseTo(Coord other) {
+ return ((latitude == other.latitude && longitude == other.longitude) ||
+!RouteArc.goodArcLength(quickDistance(other)));
+ }
+
/**
* Distance to other point in meters.
*/
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
index 1a0968d..ae2bf8b 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
@@ -193,6 +193,12 @@ public class RouteArc {
return (int) (l * factor);
}
+
+ public static boolean goodArcLength(double len) {
+ int l = convertMeters(len);
+ return l > 0 && l < (1 << 14);
+ }
+
public void write(ImgFileWriter writer) {
offset = writer.position();
if(log.isDebugEnabled())
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 0c45d68..f76b4b1 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -105,8 +105,8 @@ public class RoadNetwork {
log.error("Road " + road.getRoadDef().getName() + " (OSM id " + road.getRoadDef().getId() + ") contains consecutive identical nodes - routing will be broken");
log.error(" " + co.toOSMURL());
}
-else if(arcLength == 0) {
- log.error("Road " + road.getRoadDef().getName() + " (OSM id " + road.getRoadDef().getId() + ") contains zero length arc");
+else if(!RouteArc.goodArcLength(arcLength)) {
+ log.error("Road " + road.getRoadDef().getName() + " (OSM id " + road.getRoadDef().getId() + ") contains a bad arc of length " + String.format("%.2f", arcLength) + "m");
log.error(" " + co.toOSMURL());
}
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 2a549f8..19beb66 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -468,9 +468,9 @@ public class StyledConverter implements OsmConverter {
// now split the way at the next point to
// limit the region that has restricted
// access
- if(!p.equals(p1) &&
+ if(!p.tooCloseTo(p1) &&
((i + 2) == points.size() ||
-!p1.equals(points.get(i + 2 {
+!p1.tooCloseTo(points.get(i + 2 {
Way tail = splitWayAt(way, i + 1);
// recursively process tail of way
addRoad(tail, gt);
@@ -531,8 +531,8 @@ public class StyledConverter implements OsmConverter {
// first point in the way
if(p1 instanceof CoordPOI &&
i > 0 &&
- !p.equals(points.get(i - 1)) &&
- !p.equals(p1)) {
+ !p.tooCloseTo(points.get(i - 1)) &&
+ !p.tooCloseTo(p1)) {
Way tail = splitWayAt(way, i);
// recursively process tail of road
addRoad(tail, gt);
@@ -622,7 +622,7 @@ public class
[mkgmap-dev] Garmin Device Routing Options
Hi, In the Garmin GPSR (mine is a Etrex Legend HCX) there are several options for routing. How are they mapped to mkgmap/OSM features? Here my guesses: Calculate Routes for: Car -> motorcar Truck -> hgv (?) Bus -> psv (?) Emergency (???) Taxi -> taxi Delivery -> psv (?) Pedestrian -> foot Bicycle -> bicycle Avoid: Toll Roads -> toll=yes Highways -> (road classes 3&4 ??) Unpaved Roads -> (??) Carpool Lanes -> (??) Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin Device Routing Options
Hi Chris, > In the Garmin GPSR (mine is a Etrex Legend HCX) there are several > options for routing. How are they mapped to mkgmap/OSM features? > > Here my guesses: > > Calculate Routes for: > > Car -> motorcar or motorcycle > Truck -> hgv (?) yes > Bus -> psv (?) yes > Emergency (???) emergency > Taxi -> taxi yes > Delivery -> psv (?) yes > Pedestrian -> foot yes > Bicycle -> bicycle yes > > Avoid: > > Toll Roads -> toll=yes not sure if this works > Highways -> (road classes 3&4 ??) has some effect > Unpaved Roads -> (??) > Carpool Lanes -> (??) these don't work Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Hi Mark, Mark Burton schreef: > v2 of this patch not only enables remove-short-arcs by default when > routing is in use (as previously discussed on ML) but it also fixes some > problems in the way splitting code. > > I would be grateful if people could test this patch because it could > possibly cure some routing failures. Fast check with the 29-07-09 14:32 "a routing problem" problem, with r1127 the problem is still there. Updated to revision 1131, used your patch which (unfortunately) doesn't solve the problem *and* now there's loads (well, 28 entries) of SEVERE (RoadNetwork): Road Kasteeltuin (OSM id 7003822) contains a bad arc of length 2,94m SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=52.02526&lon=5.18550&zoom=17 SEVERE (RoadNetwork): Road E 30 (OSM id 7004900) contains a bad arc of length 2,94m SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=52.09266&lon=5.18550&zoom=17 A couple of these are on the edge of a map, but this one for example does not: Road Franciscusdreef (OSM id 7066146) contains a bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.11912&lon=5.08551&zoom=17 I did not check other routes. Please remember that the strange a,b,c routing problem showed up in Mapsource but did not in my Garmin. I didn't check my Garmin Nuvi here. Oh, and I don't know (so I can't test) any other routing problems now but I wouldn't call that a problem :-) :-) List follows below. Best regards, Valentijn Here is the list, abbreviated so it fits in a mail: Kasteeltuin (OSM id 7003822) bad arc of length 2,94m http://www.openstreetmap.org/?lat=52.02526&lon=5.18550&zoom=17 E 30 (OSM id 7004900) bad arc of length 2,94m http://www.openstreetmap.org/?lat=52.09266&lon=5.18550&zoom=17 Einsteindreef (OSM id 7059335) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.11912&lon=5.11283&zoom=17 Franciscusdreef (OSM id 7066146) bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.11914&lon=5.08564&zoom=17 Franciscusdreef (OSM id 7066570) bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.11912&lon=5.08551&zoom=17 Schonauwenseweg (OSM id 7096292) bad arc of length 1,47m http://www.openstreetmap.org/?lat=52.01011&lon=5.18553&zoom=17 Kanaaldijk Zuid (OSM id 7096366) bad arc of length 1,47m http://www.openstreetmap.org/?lat=52.00514&lon=5.18555&zoom=17 Schalkwijkseweg (OSM id 7096378) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.01011&lon=5.18553&zoom=17 null (OSM id 23086095) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.11914&lon=5.04436&zoom=17 null (OSM id 23086101) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11914&lon=5.04442&zoom=17 N203 Provincialeweg (OSM id 6605992) bad arc of length 4,78m http://www.openstreetmap.org/?lat=52.47066&lon=4.80536&zoom=17 Staalhavenweg (OSM id 6632824) bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.47070&lon=4.62602&zoom=17 Zwarte Pad (OSM id 7495148) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11916&lon=4.29286&zoom=17 null (OSM id 30611242) bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.11916&lon=4.30825&zoom=17 Vlotgrasweg (OSM id 6544034) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.47070&lon=5.54116&zoom=17 Lisdoddeweg (OSM id 6544035) bad arc of length 3,76m http://www.openstreetmap.org/?lat=52.47070&lon=5.54123&zoom=17 null (OSM id 6589537) bad arc of length 1,46m http://www.openstreetmap.org/?lat=52.43262&lon=5.00979&zoom=17 Prinsenweg (OSM id 6958461) bad arc of length 1,46m http://www.openstreetmap.org/?lat=52.20274&lon=5.62500&zoom=17 Hogeweg (OSM id 6965686) bad arc of length 1,46m http://www.openstreetmap.org/?lat=52.34878&lon=5.62498&zoom=17 Drieseweg (OSM id 6967746) bad arc of length 2,92m http://www.openstreetmap.org/?lat=52.25984&lon=5.62500&zoom=17 null (OSM id 7059063) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.11916&lon=5.11821&zoom=17 Neckardreef (OSM id 7059064) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11916&lon=5.11821&zoom=17 Einsteindreef (OSM id 7059335) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.11914&lon=5.11285&zoom=17 Colombiadreef (OSM id 7059453) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11916&lon=5.09669&zoom=17 Japuradreef (OSM id 7059454) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11916&lon=5.09669&zoom=17 Valkenkamp (OSM id 7070206) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.14041&lon=5.00977&zoom=17 Valkenkamp (OSM id 7070266) bad arc of length 1,47m http://www.openstreetmap.org/?lat=52.14038&lon=5.00979&zoom=17 null (OSM id 29894188) bad arc of length 4,78m http://www.openstreetmap.org/?lat=52.47066&lon=5.02457&zoom=17 -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Hi Valentijn, Thanks for the feedback. I can see where the problem is occuring. Wherever you have a node that is within the minimum arc length from a tile boundary you will get an error message. The question is: Is the routing actually broken at those locations? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Hi Mark, At Wed, Aug 12, 2009 at 09:19:36PM +0100, Mark Burton wrote: > I can see where the problem is occuring. Wherever you have a node that > is within the minimum arc length from a tile boundary you will get an > error message. Your mail now sounds much less SEVERE than the error message :-) > The question is: Is the routing actually broken at those locations? Will check. Tomorrow. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Fixed Sea on Nuvi 860T
I manually set the colour for sea polygons in my style file and now they are showing up the same way as they do in Roadtrip / Mapsource. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
At Wed, Aug 12, 2009 at 10:37:14PM +0200, Valentijn Sessink wrote: > > The question is: Is the routing actually broken at those locations? > Will check. Tomorrow. Actually, while thinking about it: I'm not sure what to test. Should I check one of the sites that has a SEVERE message? Does your patch specifically target these locations? Do you expect routing not to work at these locations without your patch? And does "not work" mean that there's a road, but you won't get a route over it? Like the infamous tunnel you couldn't get through, even if it were an 80 meters journey? That sort of problem? 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] [PATCH v2] - min arc length fixes
> At Wed, Aug 12, 2009 at 10:37:14PM +0200, Valentijn Sessink wrote: > > > The question is: Is the routing actually broken at those locations? > > Will check. Tomorrow. > > Actually, while thinking about it: I'm not sure what to test. Should I check > one of the sites that has a SEVERE message? Does your patch specifically > target these locations? Do you expect routing not to work at these locations > without your patch? And does "not work" mean that there's a road, but you > won't get a route over it? Like the infamous tunnel you couldn't get > through, even if it were an 80 meters journey? That sort of problem? The patch should actually reduce the number of short arcs. The remaining arcs that it is now complaining about were there already, the new patch hasn't created them, it's just now detecting them! So, I would like to know if those ways it is griping about are routable or not. If possible, please test a few to see if you can route over them. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin Device Routing Options
On Wed, Aug 12, 2009 at 09:00:14PM +0100, Mark Burton wrote: > > Unpaved Roads -> (??) > > Carpool Lanes -> (??) > > these don't work I tried yesterday and i was under the impression that unpaved worked. Or better - i turned off "Avoid unpaved" in my GPSMap 60Csx and i was immediatly send through a "surface=gravel" "highway=unclassified" which i have never sent through before. Flo -- Florian Lohoff f...@rfc822.org "Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen." - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Improving mkgmap's Unicode transliteration
I'm going to Greece tomorrow and I noticed to my dismay that mkgmap's
transliteration tables for the Greek alphabet were totally missing.
So I hacked up a small Perl script which uses the Unicode::UCD and the
Text::Unidecode modules to fillin the blanks:
a...@aoeu:~/src/mkgmap/resources/chars/ascii$ perl
re-transliterate.pl < row03.trans > row03.trans.tmp && mv
row03.trans.tmp row03.trans
The script and a patch to row03.trans which Works For Me are attached.
But of course the tool can also be run on the rest of the files to
fill in more blanks.
And my script can of course be modified a bit further to spit out
transliterations for files not yet in mkgmap row* files.
I don't know what the row* files were originally based on but there's
a lot of prior art for transliterating Unicode and there's no need to
redo all this work for mkgmap. The Unicode Consortium has published
transliteration tables (which Text::Unidecode is largely based on),
it's much easier to use stuff like that rather than doing all the work
yourselves.
Anyway, off to pack for my flight.
#!/usr/bin/env perl
use feature ':5.10';
use strict;
use warnings;
use Unicode::UCD 'charinfo';
use Text::Unidecode;
use Data::Dump 'dump';
sub new_trans
{
my $char_name = shift;
if (my $info = charinfo($char_name)) {
my $chr = chr hex $info->{code};
my $t;
if ($t = unidecode($chr) and $t ne '[?]') {
return $t;
}
}
return;
}
while (<>)
{
chomp;
if (/^U\+/) {
my ($char_name, $trans, $annotate) = $_ =~ m[^(U\+\S+)\s+(\S+)\s+(.*)];
my $new_trans;
if ($trans eq '?' and ($new_trans = new_trans($char_name))) {
say "$char_name $new_trans" . (" " x (10 - length($new_trans))) . "$annotate";
} else {
say;
}
} else {
say;
}
}
Index: row03.trans
===
--- row03.trans (revision 1131)
+++ row03.trans (working copy)
@@ -127,8 +127,8 @@
U+0371 ?# character ͱ
U+0372 ?# character Ͳ
U+0373 ?# character ͳ
-U+0374 ?# character ʹ
-U+0375 ?# character ͵
+U+0374 ' # character ʹ
+U+0375 , # character ͵
U+0376 ?# character Ͷ
U+0377 ?# character ͷ
U+0378 ?# character
@@ -137,7 +137,7 @@
U+037b ?# character ͻ
U+037c ?# character ͼ
U+037d ?# character ͽ
-U+037e ?# character ;
+U+037e ? # character ;
U+037f ?# character Ϳ
U+0380 ?# character
U+0381 ?# character
@@ -145,116 +145,116 @@
U+0383 ?# character
U+0384 ?# character ΄
U+0385 ?# character ΅
-U+0386 ?# character Ά
-U+0387 ?# character ·
-U+0388 ?# character Έ
-U+0389 ?# character Ή
-U+038a ?# character Ί
+U+0386 A # character Ά
+U+0387 ; # character ·
+U+0388 E # character Έ
+U+0389 E # character Ή
+U+038a I # character Ί
U+038b ?# character
-U+038c ?# character Ό
+U+038c O # character Ό
U+038d ?# character
-U+038e ?# character Ύ
-U+038f ?# character Ώ
-U+0390 ?# character ΐ
-U+0391 ?# character Α
-U+0392 ?# character Β
-U+0393 ?# character Γ
-U+0394 ?# character Δ
-U+0395 ?# character Ε
-U+0396 ?# character Ζ
-U+0397 ?# character Η
-U+0398 ?# character Θ
-U+0399 ?# character Ι
-U+039a ?# character Κ
-U+039b ?# character Λ
-U+039c ?# character Μ
-U+039d ?# character Ν
-U+039e ?# character Ξ
-U+039f ?# character Ο
-U+03a0 ?# character Π
-U+03a1 ?# character Ρ
+U+038e U # character Ύ
+U+038f O # character Ώ
+U+0390 I # character ΐ
+U+0391 A # character Α
+U+0392 B # character Β
+U+0393 G # character Γ
+U+0394 D # character Δ
+U+0395 E # character Ε
+U+0396 Z # character Ζ
+U+0397 E # character Η
+U+0398 Th# character Θ
+U+0399 I # character Ι
+U+039a K # character Κ
+U+039b L # character Λ
+U+039c M # character Μ
+U+039d N # character Ν
+U+039e Ks# character Ξ
+U+039f O # character Ο
+U+03a0 P # character Π
+U+03a1 R # character Ρ
U+03a2 ?# character
-U+03a3 ?# character Σ
-U+03a4 ?# character Τ
-U+03a5 ?# character Υ
-U+03a6 ?# character Φ
-U+03a7 ?# character Χ
-U+03a8 ?# character Ψ
-U+03a9 ?# character Ω
-U+03aa ?# character Ϊ
-U+03ab ?# character Ϋ
-U+03ac ?# character ά
-U+03ad ?# character έ
-U+03ae ?# character ή
-U+03af ?# cha
Re: [mkgmap-dev] Rounding bug in splitter?
Hi Valentijn, > Chris Miller schreef: > >> but my impression is that the conclusion was that the splitter should >> be rounding areas off to boundaries in multiples of 4096 rather than >> 2048? >> > As far as I've seen - thanks to Steve Ratcliffe's findings - divisible > by 2048 is enough, if you make sure that the difference is a multiple > of 4096. (i.e. if your bounds are 0x123800 and 0x456800, that is OK; > but 0x123800 and 0x456000 is not OK). > > Anyway, dividing by 4096 is a good method of achieving this. I've checked in what is hopefully a fix for this to the splitter. There's a new parameter called --resolution, which represents the lowest zoom level specified in your style file and dictates what boundaries to align the split tiles on. By default it's 13 which equates to tiles on boundaries of 2048 map units, and tiles with width/height in multiples of 4096 units. I've tested this with the netherlands.osm map and can't see any obvious problems (including around the tile borders and when routing across tiles), but as this is the first time I've used mkgmap to load osm files into MapSource I'm not 100% sure what I'm supposed to be looking for and your testing and comments would be appreciated. Have a play and let me know if you think it's an improvement. Cheers, Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Rounding bug in splitter?
Chris Miller wrote: Hi Valentijn, Chris Miller schreef: but my impression is that the conclusion was that the splitter should be rounding areas off to boundaries in multiples of 4096 rather than 2048? As far as I've seen - thanks to Steve Ratcliffe's findings - divisible by 2048 is enough, if you make sure that the difference is a multiple of 4096. (i.e. if your bounds are 0x123800 and 0x456800, that is OK; but 0x123800 and 0x456000 is not OK). Anyway, dividing by 4096 is a good method of achieving this. I've checked in what is hopefully a fix for this to the splitter. There's a new parameter called --resolution, which represents the lowest zoom level specified in your style file and dictates what boundaries to align the split tiles on. By default it's 13 which equates to tiles on boundaries of 2048 map units, and tiles with width/height in multiples of 4096 units. the resolution option seems to be not working... I set resolution=15 but it defaults to 13. Actually if my lowest object is in resolution 16, meaning an empty level will be created at resolution 15, do I have to tell resolution=16 or resolution=15? - I assume 16, but to be on the safe side just went for 15. Also since sometime the maxnodes seems to be disrepted, I noticed it this morning after updating from svn D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar -Xmx1200M splitter.jar --mapid=6320 --maxnodes=100 --resoultion=15 switzerland.osm /D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar -Xmx1200M splitter.jar --mapid=6320 /-/-maxnodes=100 --resoultion=15 switzerland.osm / /Time started: Thu Aug 13 01:03:10 CEST 2009 mapid = 6320 maxnodes = 100 *resoultion = 15* Map is being split for *resolution 13:* - area boundaries are aligned to 0x800 map units - areas are multiples of 0x1000 map units wide and high Processing switzerland.osm 2.500.000 nodes processed... A total of 2595381 nodes were processed in 1 file Min node ID = 172204 Max node ID = 461905799 Time: Thu Aug 13 01:03:38 CEST 2009 Exact map coverage is (45.821378231048584,5.957551002502441) to (47.80904531478882,10.491621494293213) Rounded map coverage is (45.791015625,5.9326171875) to (47.8125,10.5029296875) Splitting nodes into areas containing a maximum of 1.600.000 nodes each... 2 areas generated: Area 6320 contains *1.277.171 nodes *(45.791015625,5.9326171875) to (47.8125,8.1298828125) Area 6321 contains *1.318.210 nodes* (45.791015625,8.1298828125) to (47.8125,10.5029296875) Writing out split osm files Thu Aug 13 01:03:38 CEST 2009 Processing 2 areas in a single pass Starting pass 1, processing 2 areas (6320 to 6321) 2.500.000 nodes processed... Writing ways Thu Aug 13 01:04:24 CEST 2009 Writing relations Thu Aug 13 01:04:44 CEST 2009 Wrote 2.595.381 nodes, 269.182 ways, 2.463 relations Time finished: Thu Aug 13 01:04:44 CEST 2009/ I've tested this with the netherlands.osm map and can't see any obvious problems (including around the tile borders and when routing across tiles), but as this is the first time I've used mkgmap to load osm files into MapSource I'm not 100% sure what I'm supposed to be looking for and your testing and comments would be appreciated. Have a play and let me know if you think it's an improvement. Cheers, 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
Re: [mkgmap-dev] Rounding bug in splitter?
Felix Hartmann writes: > D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar > -Xmx1200M splitter.jar --mapid=6320 --maxnodes=100 > --resoultion=15 switzerland.osm > > /D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar > -Xmx1200M splitter.jar --mapid=6320 /-/-maxnodes=100 > --resoultion=15 switzerland.osm / You have spelled resolution incorrectly. Perhaps the splitter (and mkgmap) should error out when given an unknown option. pgpX0AtXyBfIY.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] best practice in adding address info for enhancing POI address search in Garmin units
Hi, Perhaps not entirely appropriate here, but just the same here goes. I am planning to finally incorporate address search in my Philippine garmin map. Currently, I always use --no-poi-address switch because we lack address info in our data for the Phil. There are several ways to add this for mkgmap, Karlsruche schema and the is_in tag. What would be the best and more efficient way to enable address info in the POIs? My previous attempts to use the is_in tag as a proxy to address info yield showed inaccurate results. My guess would be the full Karlsruche schema in liue of the is_in tags. -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Mark, Again, a quick check, but I can't seem to route on the Fransiscusdreef: F'dreef to Vechtdijk sends me on a 1.2km odyssee :) Here's the data: 63240003: 0x24d000,0x34000 to 0x251000,0x3b000 63240008: 0x251000,0x25000 to 0x255000,0x39000 63240009: 0x251000,0x39000 to 0x255000,0x4 java -Xmx1600m -enableassertions -jar ~/garmintest/splitter/dist/splitter.jar --split-file=areas.list netherlands.osm I used: java -enableassertions -Xmx1800m -jar ~/garmintest/mkgmap/dist/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --lower-case --preserve-element-order --location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args See attached gdb-file. For now, I'll stop testing, but if you want me to test anything else, please tell me so. Best regards, Valentijn Mark Burton schreef: > So, I would like to know if those ways it is griping about are routable > or not. If possible, please test a few to see if you can route over > them. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 Fransicusdreef.gdb Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Rounding bug in splitter?
> --=-=-= > > Felix Hartmann writes: > >> D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar >> -Xmx1200M splitter.jar --mapid=6320 --maxnodes=100 >> --resoultion=15 switzerland.osm >> >> /D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar >> -Xmx1200M splitter.jar --mapid=6320 /-/-maxnodes=100 >> --resoultion=15 switzerland.osm / >> > You have spelled resolution incorrectly. Perhaps the splitter (and > mkgmap) should error out when given an unknown option. --maxnodes too should in fact be --max-nodes. Improving the command-line handling has been on my todo list, though performance, key features and bugfixes have been higher priorities so far. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Mark, Sorry for the misunderstanding. Without looking, I assumed the SEVERE error had been introduced by your patch, while it was probably somewhere between r1127 and r1131 (not sure, did not look again). Without your patch, the same errors show up. However, experimenting a bit with the Fransiscusdreef I sent, I think I have a small, simple, reproducable (in MapSource that is, so no guarantees) routing problem where A to C goes wrong, while A to B, B to C and A to B via C go right. I thought you might be interested, the MapSource file is attached. This goes wrong both with and without your patch (but both of them were compiled *without* any remove-short-arcs options, so I guess there is a chance that the unpatched version *with* remove-short-arcs behaves totally different from the new version without any remove-short-arcs (as r-s-arcs is default now), right? Best regards, Valentijn Mark Burton schreef: > The patch should actually reduce the number of short arcs. The > remaining arcs that it is now complaining about were there already, the > new patch hasn't created them, it's just now detecting them! -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 Fransicusdreef version 2.gdb Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
