Re: [mkgmap-dev] [PATCH v10] make maps in parallel
Hi Marko, Has anyone written a lint program for *.img files that would validate all the cross-references? Or a program to pretty-print the data structures in sorted format? The sorted pretty-print should be identical across runs. There are various programs around for printing out the stuff in IMG files. I have a hacked version of imgdecode that is somewhat more useful than the original and there is always the display code written by Steve. I am simply using cmp -l to do a byte-for-byte comparison of the files generated by various runs of mkgmap and then using imgdecode and display to locate where the differences reside. 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 v10] make maps in parallel
Hi Paul, Thanks for the figures. real4m13.508s user4m39.725s sys 0m16.205s Time duration: 254 secs. real3m25.462s user5m21.408s sys 0m15.697s Time duration: 205 secs. The first is without --max-jobs and the second is with and both are a considerable improvement than before the quick-distance patch Yes, it's a good time saver and when it's combined with the multicore patch I'm seeing around 350% speedup! 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 v10] make maps in parallel
Hi Clinton, I have also tested this patch on my Windows machine: the error which I previously reported regarding missing files no longer occurs. Sorry for not responding earlier, but I was away. No problem, glad it has fixed the issue. A superficial examination of the map revealed no noticeable differences or problems compared to maps compiled without the parallel code. I'll also test later on with Mac OS. OK. Thanks! The patch looks good so far. Excellent, we now have several reports that the missing file problem has been fixed (methinks that there is either a bug in the Java Futures stuff or it works somewhat differently than the documentation suggests). 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] quick distance calculation
Hi Robert, Many thanks for the feedback. how much difference is tolerable...? enabling your diagnostic code, i've observed differences typically in the range of .25% to .4%, with some exceptions like... quickDistance() = 1.4536911305450404 slowDistance() = 1.446011378093334 (0.5310990333860841% difference) quickDistance() = 1.4535945914221295 slowDistance() = 1.446011378093334 (0.5244227980276771% difference) ... and a number of lines where the relative difference doesn't really compute: quickDistance() = 0.0 slowDistance() = 0.09493529796600342 (100.0% difference) Well, that's a good question. As distance() mostly gets called to determine which of a bunch of points is nearest, it probably doesn't matter at all that the result is slightly wrong. I don't believe that the quality of the values returned by distance() will affect the accuracy of the map. Perhaps it will make some difference to the routing but, at this time, I am not convinced that distance() needs to be super^2 accurate. If anyone knows otherwise, please say. b - performance increase/decrease i compiled my village four times with and without the patch: with: make basemap1 56.00s user 0.99s system 143% cpu 39.621 total without: make basemap1 65.33s user 1.02s system 132% cpu 49.988 total without: make basemap1 70.27s user 1.19s system 137% cpu 52.111 total with: make basemap1 58.36s user 1.07s system 144% cpu 41.124 total with: make basemap1 55.84s user 1.20s system 134% cpu 42.394 total without: make basemap1 66.21s user 0.90s system 131% cpu 51.153 total with: make basemap1 51.98s user 1.14s system 142% cpu 37.339 total without: make basemap1 69.27s user 1.03s system 137% cpu 51.306 total - with avg: 55.54s user - without avg: 67.77s user - the compile with the patch takes only some 81% of the time. (in case the type of CPU matters, /proc/cpuinfo on this laptop says AMD Turion(tm) 64 X2 Mobile Technology TL-52.) Well, that's not as good a speedup as I have been seeing. Without using the parallelism patch, i.e. just using 1 core, I get around x2 performance on a very quick machine when using the quick-distance patch. Anyway, thanks again for taking the time to give it a go. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [PATCH v1] Re: [mkgmap-dev] maxspeed tag vs road_speed preset
Hi Thilo, So if you like to integrate the switch for the maxspeed handling into the trunk I will be happy, but I also understand that you might not want mkgmap to be cluttered with lots of special options. Well, I don't have a problem with lots of options so I am happy to commit that patch if people are agreed that it's useful. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bicycle routing, cycleway=opposite
Hi Marko, What would it take to duplicate the way in mkgmap, as highway=cycleway, oneway=-1? This could of course be done relatively easily by preprocessing the OSM data before feeding it to mkgmap, but I would consider it an ugly workaround. This has been discussed before but I don't think anyone implemented anything. I would be happy to give it a go. Of course, such a map would not be useful for routing vehicles. Nitpicking: I thought that bicycles are human powered vehicles. :-) Agreed, but you know what I was trying to say! Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (almost) duplicated node issue
Hi Marco, I want to say: duplicated nodes and almost duplicated nodes are map errors (expecially if they describe an highway). We do not know wich was the right intention of the mapper (make routing possible/impossible). I think that the best we can do when mkgmap finds 2 nodes that encode in the same IMG point (so in both cases: duplicated nodes or almost-duplicated nodes) is to collapse the 2 nodes in one node exacly as JOSM validator would do if they were duplicated. Does it sound good? Just my proposal... I should think that it would be reasonably easy to merge close nodes using a first pass before any ways are processed. However, tricky issues remain. Like, how do you cope with the situation of a node being generated by the clipping process and that node is within the critical distance of an existing node on the same way? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v1] - merge nodes to remove evil short arcs
Hi Marco, Mark, I'd like to help but I've no way to build mkgmap. Could you please send me a compiled mkgmap.jar to test the patch? Wilco. But why can't you build mkgmap? I believe it can even be done on Windows boxes so it can't be that difficult. Please, don't give up in searching for the BUG. I'm reading the code and I suspect the error is in the NET/NOD info calculations. In fact the issue appears when the 2 collapsing nodes has = 3 arcs. Nodes with = 3 arcs are route nodes (nodes were routing decision has to be taken) and a NOD record is to be calculated for each one. All NOD records are connected each other with pointers to build the routing network. If two connected routing nodes with 3 arcs each collapses into one with 4 arcs, I guess that all pointers structure shall be recalculated to take care of the missing routing node, and the fact the new node has now 4 arcs instead of 3 implies the NOD record is different and has to be updated. Of course my are just assumptions. Actually, I am not searching for the bug because it doesn't have to be our code that's causing the problem. It could be a bug in the garminware. Do you know who wrote the parts of the code that calculate the routing structures (src\uk\me\parabola\imgfmt\app\net\...) and how to contact them? In some file I read Robert Vollmert, Steve Ratcliffe,... No, I don't know who wrote that stuff but, surely, Steve will know. 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] quick distance calculation
Hi Clinton, I have had this patch applied for some time, and have used it for car and bicycle routing: I have not noticed any difference in routing behaviour. It is probably safe to commit. Excellent. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v3] - merge nodes to remove evil short arcs
Hi Marko, Many thanks for your suggestion about avoiding adding an arc from a node to itself. Your detective work/thinking has paid off. Actually, the real problem is much earlier in the processing and I have now committed a fix. The problem is that you can't use Coord objects as keys in HashMaps because two Coords with the same coordinates map to the same object rather than distinct objects. The bug is mine, I introduced it when I wrote the OSM support for routing. The fix is trivial, use IdentityHashMaps instead. I had already come across this issue when working on the node merging patch yesterday but it didn't occur to me to look at the rest of the code to see if the problem happened elsewhere. However, although that fixes a real bug that was causing routing crashes, it doesn't make maps that contain short segments work right. Even with that fix, the sample map I have been trying still doesn't route OK through the short segment unless I also use the merging nodes patch I have posted today. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v12] make maps in parallel
v12 Great stuff, I found out why I was getting occasional differences in the output files. It was another occurrence of a non-deterministic iteration order of a HashMap but this one was real hard to understand because it only had an effect if the OSM map data had a badly formed restriction relation in it. So now that I understand what was going on, it's cool. And yes, the re-ordering was completely harmless given that the OSM data wasn't valid anyway (restriction with multiple to ways). I intend to commit this stuff to trunk by the end of this week unless any -ve reports come in. -- v11 Patch applies to r1052. This seems to me to be well behaved. However, I am still detecting some changes in the NOD data between runs but, at this time, have no evidence that the resulting maps are broken in any way. Before committing this patch to trunk, I would like to find the cause of the reordering but it's proving elusive. I have checked all the obvious stuff like non-deterministic iteration order and shared (static) data and I believe that's all good. Anyway, in the meantime, please use this patch if you have a multi-core machine (especially if 2 cores), specify --max-jobs and report any notable findings. - Changed default number of threads to be 1. If you specify --max-jobs without a value, you get one thread per core. --max-jobs=N means use N threads. With regard to comparing the output with known good maps to see if the parallel processing is corrupting anything, one problem is that the files contain timestamps. I have test code that zeros the time stamps and have been able to compare the output from different runs. What I have seen is that sometimes there are differences that appear to be due to the order in which the labels are written to the output file. If only the order is changing that is harmless but it would be nice to understand how it's happening (I have a theory about this, yet to be proven). - Now preserves order in which files are combined (thanks Steve for the tweak). - Now serialises reading of style files and map source to avoid reentrancy issue in GType. Reworked top-level loop that waits for the parallel jobs to complete. Appears to use a lot less CPU and could possibly influence the weird problems some were reporting on Windows/Mac - please retest with this version. Steve, I haven't incorporated your changed options handling stuff yet but will do in the future if (a) you don't commit it separately and (b) we can fix the reliability issues with this parallelisation code. - Now respects --num-jobs again (broken in last patch). - Now reports exceptions in the worker threads. - Here's a better fix than last night's effort for the problem where the mapname and description for each job were getting clobbered due to the way that the command args are processed. Each job now gets a snapshot of the command args so it doesn't matter if they subsequently get changed. - Whoops! fixed a bad bug whereby each map was being output to the same file. Not sure if the fix is very elegant but at least it's not being silly any more. Now limits the default value of max-jobs to 4 no matter how many cores you have as further testing shows that having more threads just burns CPU cycles but doesn't actually finish any quicker. I guess the memory system is limiting the performance and the CPUs are spinning waiting for access. Now showing a real speedup of around 240% (my earlier higher claim was based on CPU usage and I now realise that was erroneous, sorry). Now defaults to creating a thread per core so without doing anything you should see a speedup on a SMP box when processing multiple maps. You can use --max-jobs=N to limit the concurrency - you may want to specify that if you can't increase the VM size to what is required. However, it occurs to me that if you can afford a box with more than 2 cores, then you can probably afford a reasonable amount of memory (otherwise, what's the point in having more cores?) Added help blurb. OK, let it not be said that I don't listen to others! The attached patch provides support for making maps in parallel. By default, the behaviour is the same as before but if you specify --num-threads=N where N is greater than 1, it will process N maps at the same time and then combine the results (if required). Don't forget to increase the heap size appropriately. A quick test on the big box shows good speedup - specifying --num-threads=4 and 2GB VM size. I was seeing better than 380% utilisation with 8 cores in use. I suspect the performance limitation here will be VM size and memory system bandwidth. BTW - I don't think num-threads is actually the best name for the option, so please suggest alternatives. Cheers, Mark diff --git a/resources/help/en/options b/resources/help/en/options index c236850..6358704 100644 --- a/resources/help/en/options +++ b/resources/help/en/options
Re: [mkgmap-dev] Problem with --road-name-pois
Hi Felix, I think this has not yet been mentioned on the mailing-list: There seems to be some code missing in the road-name-pois. I changed the ID to several values that if used inside the Points file, would be findable with the search function. If however I use the same ID for the -road-name-pois option, then I can only find the roadname via the all points of interstest, via the category, but not via the subcategory. For Mapsource this makes no great difference, but on my Vista HCx it means that if I can't search via subcategory, the maximum distance in cities is around 10km to find a streetname by using category/find nearest containing. If I could go via category/select subcategory/find nearest containing, the actual distance could be bigger, so the function would be more useful. On my vista hcx, using Find/geographic points/all categories I can search the RNP using nearest containing and locate roads more than 50km away. (Well a real search index which supports searching for name and city and not just name would be much much better, so I don't know if anyone of you is interested in bugcoding this). The road name search (find/addresses) found the same road ( 50 Km away) as well. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
Hi Felix, Thilo, Is it possible to produce a small example OSM file that shows this problem? If so, please zip it up and send it to me or put it on a website I can access. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
Hi Robert, http://page.mi.fu-berlin.de/vollmert/tmp/neud.osm.gz Yes, that file contains lot's of duplicate ways/nodes sitting on top of each other so it will never be able to be sub-divided (hence mkgmap blows up). Personally, I don't think we need to fix mkgmap to handle this because the data is obviously crap. What I can do is put in some code to detect this situation and issue a more useful error message before it bombs out. BTW if you download the same area, all the crap has gone away. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error with austria.osm.bz2
Hi Felix, Well it does not look so bad that mkgmap should crash. There are about 40-50 nodes that have no tags attached to them at all (except if someone cleaned up before me looking at it). In my eyes this should not lead mkgmap to crash. Ideally, yes, it shouldn't crash on any data but, at this time, mkgmap can't cope with a small area that contains more nodes/arcs than are allowed in a subdivision. I am not saying this issue cannot be fixed but, to me, it's a low priority because no sensible map should contain such a cluster of nodes. At least now it tells you where the problem area 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] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
I fired up JOSM and deleted the myriad duplicate ways as no one else had bothered to do it. With luck, the austria map will build now. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1054: When subdivision fails to reduce number of nodes, report bbox and croak.
Hi Clinton, You know, I'm not too crazy about the croak part. For example, yesterday I attempted to compile a map of a large portion of Europe from Geofabrik.de, which provides daily extracts. The entire procedure took many hours (osmosis - split - mkgmap) on my antiquated (2 years old) hardware. Sometime in the middle of the night, I ended up with the croak and a polite apology that the map could not be compiled due to an invalid bbox somewhere. Now to correct this, I would have to figure out where the invalid data came from, try to correct it, upload it, and wait another day until the Geofabrik extract is available, and then start again. This may be a considerable incentive to correct the bad data ;-), but it is inconvenient, to say the least, when attempting to compile large areas. :-( Er... would it be possible to warn and continue with the compilation, knowing that parts of the map would be corrupt? (a --force option, or something?) It's a tricky situation because by the time the problem is detected lots of half built data structures are around some of which will refer to the nodes/ways that are going to have to be thrown away to be able to carry on without croaking. I will have a go a trying to find a means of continuing in this situation but it's likely that the resulting map will be broken as far as routing is concerned. Let's see what can be 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] Commit: r1059: New approach to the too many nodes in region problem - carry on regardless.
Let's see how this does - I have tried it out on 63660006.osm and the resulting map loads into mapsource OK and is generally fine. Trying to route through the broken region does cause mapsource to either draw a straight line or pop up the your map's broken dialog. A real gps would probably hang or crash if it tried to route through the region. The fix is not very pleasing but if it allows the map to build with minimal damage to the routing then I guess it will do for now as an interim solution. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Re: Again Picture of broken road, in case it got blocked by mailing list too
I downloaded again, made a map and this is what it looks like in mapsource. I can't explain why your image is broken. Cheers, Mark attachment: modling-2.png___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem routing over very short roads
Just discovered a weirdness in that map. The short segment at the northern end of the bridge is actually two ways (one on top of the other). Using the middle mouse button in josm you can see that. Perhaps, this is the cause of your problems. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem routing over very short roads
Hi Felix, I have just uploaded my source data, try your calculation on it, I think it will fail too for you as well. http://openmtbmap.x-nation.de/maps/Debug/63660008.osm.gz That's more like it. With that map, the little segment at the N of the bridge weirds out. If you check the diagnostic output, you will see that mkgmap is not deleting that way so the end points have not resolved to the same coordinates (to make it zero length) but maybe mapsource doesn't like ways that short and is barfing on it. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem routing over very short roads
Hi Felix, Do you see any solution to this problem? Sorry, I don't have a plan at this time. I think if a way is shorter than 3.4m we get the problem. I don't think it is because of the duplicate ways. It's more subtle than that because I could make a small map (just a few 100ms height and width) that included that way and mapsource was quite happy with it but when I processed your big file, it didn't like it - so either the problem is related to the density of stuff around or the size of the area being processed or something... Could we maybe have a filter that joins such tiny roads to the ones it is connected too? Well, if it becomes zero length that will happen anyway because that's what the new remove-short-arcs option does. What I could do is extend that code to allow the min distance to be specified so you could say --remove-short-arcs=3.5 and it would zap all arcs under than length but without the distance, i.e. just --remove-short-arcs would only zap zero length arcs. I will produce a patch to do that, should be quick to do. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mkgmap-dev IRC channel
Hi, I have created IRC channel #mkgmap-dev on irc.oftc.net for discussion related to mkgmap development. 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] - extend --replace-short-arcs option to take min arc length
Hi Marco, I've experienced the same problem: a short arc disappered in Rome (I'm still looking for it...). And the routing gets broken. Did you understand why those short arcs (with no collapsing end nodes) get deleted? Sorry, no I don't. When you discover where it is, please let me know so I can take a look at it. 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] - extend --replace-short-arcs option to take min arc length
Hi Marco, 41°52.367' N 12°30.477' E I attach a small zipped osm file that compiles with that problem (it is between two tracks at a cross in the center of the osm). I'm looking at that but can't identify the problem - do you have the OSM ids for nodes/ways where it is failing? 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] - extend --replace-short-arcs option to take min arc length
Hi Dermot, If you want to have a routable map for bicycles why not just remove all the oneway tags? Because cyclists are required to obey oneway restrictions. Silly me, I was forgetting that. So how about zap the oneway tags for roads that have the opposite cycleway tags? 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] - extend --replace-short-arcs option to take min arc length
Hi Felix,
Sorry, just wanted to say that I had misinterpreted tortoiseSVN diff
files. I though those lines were deleted, but it only showed differences
to my version. I just wondered why (which was falsely assumed by me) the
lines were deleted.
OK, I was thinking that you were asking about why not delete those
lines! Sorry, my head is elsewhere this afternoon and I didn't
interpret your question right.
I do change the maps by using the following command in my style-file:
( oneway=yes | oneway=1 | oneway=-1 | oneway=true | oneway=reverse |
oneway=false ) ( cycleway=opposite | cycleway=opposite_lane |
cyclway=opposite_track) {set oneway=no}
OK.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Parsing of : and .
Hi Felix,
Sorry Mark for probably bugging you again
First the probably easier question, why is it not possible to use a line
like
1.
highway=* source=plan.at [0x07 resolution 24] in my style file? The
point in plan.at throws an exception.
2.
highway:plan.at=* .
Same problem.
In Austria due to the import many ways can be identified like this, and
one could decrease the road_class and/or road_speed because the quality
of the data is very bad.
Sorry, I know nothing about the style stuff but I guess Steve must have
not allowed . within a value string. Can you quote it? .e.g
source=plan.at
Now the harder part, would it be possible to enable in the
osm5xmlhandler.java the parsing of : ?
String mtb:scaleTag = currentWay.getTag(mtb:scale);
if ( (0.equals(mtb:scaleTag)) ||
(1.equals(mtb:scaleTag) ) || (true.equals(mtb:scaleTag) )) {
// Add additional mtb:scale over old highway
long mtb:scaleId = currentWay.getId() +
MTB_ID_OFFSET;
Way mtb:scaleWay = new Way(mtb:scaleId);
wayMap.put(mtb:scaleId, mtb:scaleWay);
ListCoord points = currentWay.getPoints();
for(int i = 0; i points.size(); ++i)
mtb:scaleWay.addPoint(points.get(i));
mtb:scaleWay.addTag(mtb:scale, 11);
log.info(Making additional mtb:scale ' +
mtb:scaleWay.getTag(name) + ');
}
If I have these lines added, mkgmap.jar does not compile.
Err, I don't think that is valid Java syntax. How about using an _
instead? i.e. mtb_scaleWay
Cheers,
Mark
BTW - in case you missed it, there's now an IRC channel for mkgmap-dev
#mkgmap-dev at irc.oftc.net - so if you have a quick question you may
find me there (as burto).
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - allow RNP type to be set on a road-per-road basis
v2 - split out the non-related changes (they have now been committed so
this patch is based on r1064).
--
OK Felix, here's something to play with. This patch allows you to
specify the garmin type of a road's RNP using a mkgmap:rnptype tag. You
can then set that tag in a style file when you match some other tag
values.
Like this (silly) example that makes the RNP generated for a footway to
be a zoo:
highway=footway {add mkgmap:rnptype=0x2c07; add access = no; add foot =
yes} [0x16 road_class=0 road_speed=0 resolution 23]
Alternatively, you could add that tag directly into the OSM XML or
even pre-process the OSM XML to add the tag conditionally.
The patch also contains a couple of other un-related changes that will
be committed separately if they are OK.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/general/MapRoad.java b/src/uk/me/parabola/mkgmap/general/MapRoad.java
index 2b0a96a..4c19696 100644
--- a/src/uk/me/parabola/mkgmap/general/MapRoad.java
+++ b/src/uk/me/parabola/mkgmap/general/MapRoad.java
@@ -16,6 +16,9 @@
*/
package uk.me.parabola.mkgmap.general;
+import java.util.HashMap;
+import java.util.Map;
+
import uk.me.parabola.imgfmt.app.lbl.City;
import uk.me.parabola.imgfmt.app.lbl.Zip;
import uk.me.parabola.imgfmt.app.net.RoadDef;
@@ -36,6 +39,7 @@ import uk.me.parabola.imgfmt.app.net.RoadDef;
public class MapRoad extends MapLine {
private final RoadDef roadDef;
+ private MapString, String attributes;
public MapRoad(long id, MapLine line) {
super(line);
@@ -108,4 +112,14 @@ public class MapRoad extends MapLine {
public void setRoadZip(Zip z) {
this.roadDef.setZip(z);
}
+
+ public void setAttribute(String tag, String val) {
+ if(attributes == null)
+ attributes = new HashMapString, String();
+ attributes.put(tag, val);
+ }
+
+ public String getAttribute(String tag) {
+ return (attributes == null)? null : attributes.get(tag);
+ }
}
diff --git a/src/uk/me/parabola/mkgmap/main/MapMaker.java b/src/uk/me/parabola/mkgmap/main/MapMaker.java
index cd36079..49c4a7d 100644
--- a/src/uk/me/parabola/mkgmap/main/MapMaker.java
+++ b/src/uk/me/parabola/mkgmap/main/MapMaker.java
@@ -236,8 +236,11 @@ public class MapMaker implements MapProcessor {
rnpRoads.add(new SortableString, MapRoad(key, r));
}
Collections.sort(rnpRoads);
- for(SortableString, MapRoad sr : rnpRoads)
-src.getPoints().add(makeRoadNamePOI(sr.getValue(), rnpt));
+ for(SortableString, MapRoad sr : rnpRoads) {
+MapRoad r = sr.getValue();
+String rnptype = r.getAttribute(rnptype);
+src.getPoints().add(makeRoadNamePOI(r, (rnptype != null)? Integer.decode(rnptype) : rnpt));
+ }
}
}
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 9197bc0..ae06175 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -625,6 +625,10 @@ public class StyledConverter implements OsmConverter {
MapRoad road = new MapRoad(way.getId(), line);
+ String rnptype = way.getTag(mkgmap:rnptype);
+ if(rnptype != null)
+ road.setAttribute(rnptype, rnptype);
+
// set road parameters.
road.setRoadClass(gt.getRoadClass());
if (way.isBoolTag(oneway)) {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] route recalculation senstivity bug found
Hi Felix, I found out the problem associated to route recalculation not working (well working but only far too late). We currently set the TRE header at 1,3,17 IF we change this over to 1,4,23 route recalculation kicks in at around 25-30m instead of 300-400 (as it happens with 1,3,17 we currently use) on my Vista HCx. I don't know how this is set because the value introduced with the patch about this seems to be organized differently. I changed this with gmaptool and now it works very well. Would be great if these values could be set directly by mkgmap. With my vista hcx and using the current value of 0x110301, the route recalculates if I go off course by no more than about 25m. I believe other people are also getting similar results. Perhaps people could confirm that? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] route recalculation senstivity bug found
Hi Felix, Let's hear them. I got many many complaints that my maps don't recalculate... Speak up chaps, how's the recalculating working out? How can I change 0x110301 so that it sets 1,4,23 instead of 1,3,17? Change line 170 of src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java to output 0x170401 instead of 0x110301. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] route recalculation senstivity bug found
Hi Felix, BTW - thanks to those who have responded re performance of the current value. Strange that it's working for you. I'm allways on SVN latest wit hVista HCx, I even think that before the updates it worked better. Anyhow I now use the different value and am happy. Could it be that it's only not working when going slow, maybe it works at carspeeds? I'd love to say that I cycle at car speeds but that, sadly, isn't true. It works at my normal cycling speed of around 26kph. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] route recalculation senstivity bug found
Felix, O.k. so there must be another reason. Maybe its as well related to road_speed or road_class? (Garmin may think that the lower the road_speed the higher the chance that there are buildings that obstruct GPS reception, or the lower the accuracy of the maps, cause minor roads are not that well mapped as major roads??). The road_speed of my maps is only 0,1 and 2 -could that be the culprit? For sure, there's lot's we don't know. For example, that 3 byte field. We don't really know what the various bits are used for. Someone a while back posted an analysis (and their theory) on what the values meant but nothing more has come from that yet. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] route recalculation senstivity bug found
Hi Marco, Mark, do you have some advice about OSM tagging for address search? If a road has a name or reference it will have an entry in the address search data structure. It needs also to have a city associated with it which can either be the nearest city (town, village, etc.) or the road can be tagged explicitly using an is_in tag. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map: tiny patch/review series
Hi Thilo,
The DP code contains another distance calculation. What you must
calculate there is the distance of one point to a line. The
Coord.distance() is used in that formula, but I do not understand the
formula itself. Maybe it's some genius trick to simplify the
calculation, but I do not get it. The only thing I see is that when I
reduce the error distance the simplified ways look nicer. But the
preset error distance of one half of the resolution should be small
enough already. So my assumption is that the actual error distance is
much larger than expected, which may be due to a bug in the code.
At the distances we're (mostly) interested in, the curvature of the
earth's surface has a tiny effect (much less than the effect of hills
valleys) so I guess (hope) that leaving out that factor is OK.
I know that this isn't your code but it's as good a place as any
to comment about it: looking at the DP code (for the first time), I
immediately see that the loop that finds the max distance is
(potentially) doing many more sqrts and divisions than it needs to. So
even if the code is correct, it could be somewhat faster which would be
worthwhile given that it gets called for every line. Eg, it could be
changed to look like this:
// Find point with highest distance.
// Loop runs downwards, as the list length gets modified while
running
for(int i = endIndex-1; i startIndex; i--) {
Coord p = points.get(i);
double ap = p.distance(a);
double bp = p.distance(b);
double abpa = (ab+ap+bp)/2;
double dd = abpa * (abpa-ab) * (abpa-ap) * (abpa-bp);
if (dd maxDistance) {
maxDistance = dd;
maxIndex = i;
}
}
maxDistance = 2 * Math.sqrt(maxDistance) / ab;
Also - you get a division by zero if ab is 0, perhaps adding a test
for that before the loop would be advisable.
Another minor nit - the comment is inaccurate as the list length doesn't change
in this loop.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map: tiny patch/review series
Hi Thilo,
At the distances we're (mostly) interested in, the curvature of the
earth's surface has a tiny effect (much less than the effect of
hills
valleys) so I guess (hope) that leaving out that factor is OK.
The curvature may have a tiny effect, but nonetheless you should
consider the coordinate system you are using. Interpreting lat and lon
as cartesian coordinates (don't know whether you are really doing
that) will give large errors at high latitudes.
I have to admit that I'm not much of a mathematician so I am quite
happy to take advice as to the soundness of the current algorithm. I
did test it against what we were using before and for the latitudes I
was using, it appeared to work OK.
I know that this isn't your code but it's as good a place as any
to comment about it: looking at the DP code (for the first time), I
immediately see that the loop that finds the max distance is
(potentially) doing many more sqrts and divisions than it needs to. So
even if the code is correct, it could be somewhat faster which would
be
worthwhile given that it gets called for every line. Eg, it could be
changed to look like this:
// Find point with highest distance.
// Loop runs downwards, as the list length gets modified while
running
for(int i = endIndex-1; i startIndex; i--) {
Coord p = points.get(i);
double ap = p.distance(a);
double bp = p.distance(b);
double abpa = (ab+ap+bp)/2;
double dd = abpa * (abpa-ab) * (abpa-ap) * (abpa-bp);
if (dd maxDistance) {
maxDistance = dd;
maxIndex = i;
}
}
maxDistance = 2 * Math.sqrt(maxDistance) / ab;
Also - you get a division by zero if ab is 0, perhaps adding a test
for that before the loop would be advisable.
Do you understand that formula for the distance calculation? If so
could you explain it for me? I don't get it.
Sorry, no.
Another minor nit - the comment is inaccurate as the list length
doesn't change in this loop.
It is accurate, because the list length does get changed by the way
the recursion works. It is not obvious, therefore this comment is
really needed!
The loop I mention does not contain any recursion. The loop in
doFilter() does (it is adorned with a similar comment).
Another question, just out of curiosity: Does it really mattern in
Java how many sqrts or sin or cos I do? Doesn't that kind of
difference get swamped by all that interpretation and memory
allocation things etc. going on? With modern FPUs that kind of
operation isn't that expensive (if it is done native).
You're quite possibly right but some maths ops are hideously slow (i.e.
acos which is used in the original distance() method). In the example
above, I would argue that taking the sqrt and division outside of the
loop doesn't make the code harder to understand and may yield some
speedup.
I would start working on the DP code if it makes sense. If somebody
understands that distance formula and could explain it it would be
very much appreciated. Otherwise I will have to make up my own formula
(sigh...)
Well, I think Johann wrote the code so maybe he will enlighten you!
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map: tiny patch/review series
On Tue, 16 Jun 2009 17:19:21 +0100 Mark Burton ma...@ordern.com wrote: In the example above, I would argue that taking the sqrt and division outside of the loop doesn't make the code harder to understand and may yield some speedup. Well, a quick test showed a barely perceptible gain so may as well leave the code as it 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] Putting the DP code under the microscope
Hi Johann, But you are right. If point 4 is a CoordNode then the endpoint should not be zapped. So it is a small bug, but will probably not help at the overview map. Well watched. Please commit that change. OK, I will remove the --i and commit that change. What are your thoughts on the patch (I think it was by Thilo) that replaces the lost last point in each polygon? Seems like a good idea to me. 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
Hi Johann,
What are your thoughts on the patch (I think it was by Thilo) that
replaces the lost last point in each polygon? Seems like a good idea to
me.
I have looked at the patch only one minute. Seems correct.
May thoughts was that the last segment ist not needed, if it is a
polygon which gets filled. But with only contours there will arise
problems. Right.
In my private working copy I have tested another solution in the meanwhile.
Do not remove the first point. Instead divide the line in two parts and
simplify both of them. Could not say if it works better or not.
I think I like this idea better. Perhaps folks can test both fixes and
decide which is best.
Sorry, I'm in a hurry, no more time left to create a patch.
No problem, I'm sure the team can do that.
Cheers,
Mark
// Create a new list to rewrite the points into. Don't alter the
original one
ListCoord coords = new ArrayListCoord(n);
coords.addAll(points);
//Handle Polygons different
+if (element instanceof MapShape) {
+ int middle = n/2;
+ douglasPeucker(coords, middle, n, maxErrorDistance);
+douglasPeucker(coords, 0, middle, maxErrorDistance);
+
+}
+else
{
// For now simplify all points, which are not nodes
// and no start and no end point
// Loop runs downwards, as the list length gets modified
while running
int endIndex = coords.size()-1;
for(int i = endIndex-1; i 0; i--) {
Regards,
Johann
___
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] Commit: r1073: Add highway shields and other ways of modifying values in the style files.
A side effect of this commit is to make address search even less usable than it was before (surely not possible, I hear you say) because it redefines a road's name to include its reference and the highway shield thingy (if appropriate). So, for example, a road called Letsbe Avenue (where all the police live) that has a reference A123 will now get assigned the name A123 Letsbe Avenue (plus the shield code if the road type warrants it) and so it will show up in the address search in the A section rather than the L section (not sure what the shield code does for search). As roads can have up to 4 labels we could set one of the labels to be the original road name and then the searching would work as before. The problem now is that by altering the name in the style file we lose the original name. Something to ponder. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - beware of the bollards!
Fed up of being routed in your car down city streets only to find the
way is blocked by a bollard? Well, if so, this is the patch for you.
If a way has a bollard on a point, the segments of the way that
connect to the bollard have access restrictions placed on them. By
default, a bollard implies: access=no, foot=yes, bicycle=yes.
Testing using mapsource shows that it generally works as expected
although if the destination cannot be reached by any other route, it
routes straight through the bollard rather than failing! If the
destination can be reached by some other route, even if the route is
really long, it will avoid the bollard.
I have chosen Garmin code 0x660f (pillar) for the bollard. On my etrex
it appears as a small dot in the way.
As usual, all feedback is welcome.
Cheers,
Mark
diff --git a/resources/styles/default/points b/resources/styles/default/points
index 1c3ae8f..28d1fc2 100644
--- a/resources/styles/default/points
+++ b/resources/styles/default/points
@@ -166,3 +166,5 @@ tourism=theme_park [0x2c01 resolution 20]
tourism=viewpoint [0x2c04 resolution 20]
tourism=wine_cellar [0x2c0a resolution 20]
tourism=zoo [0x2c07 resolution 20]
+
+barrier=bollard [0x660f resolution 20]
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index aa5bab1..05f60ac 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -42,6 +42,7 @@ import uk.me.parabola.mkgmap.general.MapPoint;
import uk.me.parabola.mkgmap.general.MapRoad;
import uk.me.parabola.mkgmap.general.MapShape;
import uk.me.parabola.mkgmap.general.RoadNetwork;
+import uk.me.parabola.mkgmap.reader.osm.CoordPOI;
import uk.me.parabola.mkgmap.reader.osm.Element;
import uk.me.parabola.mkgmap.reader.osm.GType;
import uk.me.parabola.mkgmap.reader.osm.Node;
@@ -426,6 +427,88 @@ public class StyledConverter implements OsmConverter {
}
}
+ // process any Coords that have a POI associated with them
+ if(true.equals(way.getTag(mkgmap:way-has-pois))) {
+ ListCoord points = way.getPoints();
+ for(int i = 0; i points.size(); ++i) {
+Coord p = points.get(i);
+// check if this point is a barrier and if so,
+// transfer any access restrictions to the way
+if(p instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p;
+ Node node = cp.getNode();
+ String barrier = node.getTag(barrier);
+ if(barrier != null) {
+
+ // split the way at a point after the barrier
+ // to limit the region that has restricted
+ // access (taking care not to produce a short
+ // arc)
+ if((i + 1) points.size()
+ !p.equals(points.get(i + 1))
+ ((i + 2) == points.size() ||
+ !points.get(i + 1).equals(points.get(i + 2 {
+ //log.warn(Splitting way + way.getName() + at point + (i + 1) + after + barrier);
+ Way tail = splitWayAt(way, i + 1);
+ // recursively process tail of road
+ addRoad(tail, gt);
+ }
+
+ String access = node.getTag(access);
+ String foot = node.getTag(foot);
+ String bicycle = node.getTag(bicycle);
+ if(bollard.equals(barrier)) {
+ if(access == null)
+access = no;
+ if(foot == null)
+foot = yes;
+ if(bicycle == null)
+bicycle = yes;
+ }
+ else if(cycle_barrier.equals(barrier)) {
+ if(access == null)
+access = no;
+ if(foot == null)
+foot = yes;
+ }
+
+ if(access != null)
+ way.addTag(access, access);
+ if(foot != null)
+ way.addTag(foot, foot);
+ if(bicycle != null)
+ way.addTag(bicycle, bicycle);
+
+ log.info(Way + way.getName() + has + barrier);
+ }
+}
+
+// if this is not the first point in the way, see if
+// the next point is a barrier and if so, split the
+// way here
+if(i 0 (i + 1) points.size()) {
+ Coord p1 = points.get(i + 1);
+ if(p1 instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p1;
+ Node node = cp.getNode();
+ String barrier = node.getTag(barrier);
+ if(barrier != null) {
+ // split the way at a point before the
+ // barrier to limit the region that has
+ // restricted access (taking care not to
+ // produce a short arc)
+ if(!p.equals(p1)) {
+//log.warn(Splitting way + way.getName() + at point + i + before + barrier);
+Way tail = splitWayAt(way, i);
+// recursively process tail of road
+addRoad(tail, gt);
+ }
+ }
+ }
+}
+ }
+ }
+
// if there is a bounding box, clip the way with it
ListWay clippedWays = null;
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/CoordPOI.java b/src/uk/me/parabola/mkgmap/reader/osm/CoordPOI.java
new file mode 100644
index 000..409965b
--- /dev/null
+++ b/src/uk/me/parabola/mkgmap/reader/osm/CoordPOI.java
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C)
Re: R: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Hi Marco, I read on wiki that cycle_barrier has no default access rule. I think you should be more conservative and, in absence of explicit tags, let bicycles passing through (wiki says that cycle_barrier should only imply motor_vehicle=no) You're right, will fix for v2. 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] - beware of the bollards!
Hi Dermot, I like what you're doing here, but won't that have negative impact if the adjoining way segments are fairly long? Might it prevent you from being routed to within, say, 200m of the bollard? Or will an only-viable-route logic kick in here? My testing indicates the later. If there is no other route, mapsource at least, ignores the restriction. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
Hi Marco, Mark, the wiki page about restrictions http://wiki.openstreetmap.org/wiki/Relation:restriction says I can put a key except with the following values/meaning: except - psv/bicycle/hgv/motorcar - The restriction does not apply to these vehicle types (more than one: except=bicycle;psv) So do you mean that mkgmap does not actually support/handle the except key in a relation restriction? Err, no - sorry. Almost certainly, there is some Garmin magic to express such an exception but we don't know about it! 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] - beware of the bollards!
Hi Martin, But what about using turn restrictions instead of manipulating the nearest segments of the ways? See recent posts. The reason is: if my destination is on side A of the bollard on the restricted segment, garmin would still send me via the bollard whe it's shorter because it ignores all restrictions if the destination is within a restricted zone, right? My testing with mapsource did not do that. It took the long way around even though the destination was close to the other side of the bollard. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] - beware of the bollards!
v3
now adds extra points either side of the POI to reduce length of
way that has restricted access. Currently points are 25m away from the
POI. It would be nice if they were really close (like 5m) but if you
try that, the map looks crap due to the limited coordinate resolution.
So, 25m is a compromise between visual appearance and minimising the
extent of the restricted zone.
v2 - quick update based on instantaneous feedback from ML!
Now works for any POI that sets access=no (could use the more general
test of any of the access tags being set but let's see how this works
for now).
Default access rights now set in style file.
Any suggestions for a better code for cycle_barrier?
Fed up of being routed in your car down city streets only to find the
way is blocked by a bollard? Well, if so, this is the patch for you.
If a way has a bollard on a point, the segments of the way that
connect to the bollard have access restrictions placed on them. By
default, a bollard implies: access=no, foot=yes, bicycle=yes.
Testing using mapsource shows that it generally works as expected
although if the destination cannot be reached by any other route, it
routes straight through the bollard rather than failing! If the
destination can be reached by some other route, even if the route is
really long, it will avoid the bollard.
I have chosen Garmin code 0x660f (pillar) for the bollard. On my etrex
it appears as a small dot in the way.
As usual, all feedback is welcome.
Cheers,
Mark
diff --git a/resources/styles/default/points b/resources/styles/default/points
index 1c3ae8f..a97fc13 100644
--- a/resources/styles/default/points
+++ b/resources/styles/default/points
@@ -166,3 +166,7 @@ tourism=theme_park [0x2c01 resolution 20]
tourism=viewpoint [0x2c04 resolution 20]
tourism=wine_cellar [0x2c0a resolution 20]
tourism=zoo [0x2c07 resolution 20]
+
+barrier=bollard {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
+barrier=cycle_barier {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
+
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index aa5bab1..4754d07 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -42,6 +42,7 @@ import uk.me.parabola.mkgmap.general.MapPoint;
import uk.me.parabola.mkgmap.general.MapRoad;
import uk.me.parabola.mkgmap.general.MapShape;
import uk.me.parabola.mkgmap.general.RoadNetwork;
+import uk.me.parabola.mkgmap.reader.osm.CoordPOI;
import uk.me.parabola.mkgmap.reader.osm.Element;
import uk.me.parabola.mkgmap.reader.osm.GType;
import uk.me.parabola.mkgmap.reader.osm.Node;
@@ -426,6 +427,89 @@ public class StyledConverter implements OsmConverter {
}
}
+ // process any Coords that have a POI associated with them
+ if(true.equals(way.getTag(mkgmap:way-has-pois))) {
+ ListCoord points = way.getPoints();
+ final double stubSegmentLength = 25; // metres
+ for(int i = 0; i points.size(); ++i) {
+Coord p = points.get(i);
+// check if this POI denies access and if so, copy its
+// access restrictions to the way
+if(p instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p;
+ Node node = cp.getNode();
+ if(node.getTag(access) != null) {
+ if((i + 1) points.size()) {
+ Coord p1 = points.get(i + 1);
+ double dist = p.distance(p1);
+ if(dist = (2 * stubSegmentLength)) {
+// insert a new point after the POI to
+// make a short stub segment
+p1 = p.makeBetweenPoint(p1, stubSegmentLength / dist);
+points.add(i + 1, p1);
+ }
+
+ // split the way at the next point to
+ // limit the region that has restricted
+ // access (taking care not to produce a
+ // short arc)
+ if(!p.equals(p1)
+ ((i + 2) == points.size() ||
+!p1.equals(points.get(i + 2 {
+Way tail = splitWayAt(way, i + 1);
+// recursively process tail of way
+addRoad(tail, gt);
+ }
+ }
+
+ // copy all of the POI's access restrictions
+ // to the way segment
+ for (AccessMapping anAccessMap : accessMap) {
+ String accessType = anAccessMap.type;
+ String accessModifier = node.getTag(accessType);
+ if(accessModifier != null)
+way.addTag(accessType, accessModifier);
+ }
+ }
+}
+
+// see if the next point restricts access and if so,
+// split the way either here, or at a new point that's
+// closer to the POI
+if((i + 1) points.size()) {
+ Coord p1 = points.get(i + 1);
+ if(p1 instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p1;
+ Node node = cp.getNode();
+ if(node.getTag(access) != null) {
+ boolean newPointAdded = false;
+ double dist = p.distance(p1);
+ if(dist = (2 * stubSegmentLength)) {
+// insert a new
Re: [mkgmap-dev] splitter/mkgmap/gmapibuilder on massachusetts.osm, errors
Hi Greg, This produced a gmapsupp.img, as well as overview img and tdb, with the following errors: SEVERE (RoadNetwork): Road null (OSM id 9208777) contains consecutive identical nodes - routing will be broken ... If you specify the --remove-short-arcs option, those errors should go away. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fwd: OpenStreetMap e-mail - mkgmap bug report
Hi Steve, Well, that's a bit odd. If you download this area into JOSM, it looks similar(ish) but by no means exactly the same. If you then run that area through mkgmap and look at the result with mapsource, it looks OK. I am wondering if the map image in the email was made from out of date OSM data that contained the problems the image shows? Cheers, Mark --- I'm am forwarding this email, with permission, in the hope that someone can help before I able to look at it at the weekend. - Forwarded message from Valentijn Date: Wed, 08 Jul 2009 10:47:43 +0100 Subject: OpenStreetMap e-mail - mkgmap bug report Hello Steve, Marvellous piece of work, mkgmap! Incredible, really. Although, naturally, there are a few glitches and here's one of them. It could be that there's glitches between the connections between two parts of a map (as I'd guess that the position is somewhere between two sub-maps), but I'm not 100% sure of that. This http://tile.openstreetmap.nl/?zoom=17lat=52.01375lon=5.11781layers=B0FF is the position on OSM, and this http://valentijn.sessink.nl/temp/CIMG7132.JPG is how it shows up on my Garmin Nüvi 250, while what I did follows shortly. Please note that I did not use remove-short-arcs before, I added it *because* there were a few of these unconnected roads in this region and I thought that --remove-short-arcs would fix that. Now I'm not so sure anymore ;-) I'll be happy to test new options and I hope this will help to improve mkgmap (if not, please ignore ;-) Best regards, Valentijn Sessink #!/bin/sh memory=1700m kaart=`mktemp -d` cd $kaart echo 'Downloading Netherlands...' wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bunzip2 netherlands.osm.bz2 echo Downloading mkgmap.jar... wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz' tar -zxf mkgmap-latest.tar.gz # this turns out to be mkgmap-r1080 echo Downloading splitter... wget 'http://www.mkgmap.org.uk/splitter/splitter.jar' echo Splitting Netherlands.osm... java -Xmx$memory -jar ./splitter.jar --max-nodes=100 netherlands.osm echo done. echo Rendering map... java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr =NL --latin1 --remove-short-arcs=4 --lower-case --route --preserve-element-order --location-autofill-1 --gmapsupp --net -c template.args echo done. echo $kaart ___ 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] Fwd: OpenStreetMap e-mail - mkgmap bug report
Hi, I promise to never again turn assertions off. Yes, unless you are desperate to save time, I would always keep assertions turned on. After all, mkgmap is a work in progress and it's bound to have issues - some of which the assertions will catch. The real issue here is surely why aren't we dealing with this particular problem more gracefully? Thanks for your help and sorry for the confusion. Glad to help. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Valentijn, Did anyone else notice this problem before? Were you able to reproduce it? If it helps, I can prepare a map that will have a routing problem just at the edge (there's a biking tunnel that MapSource avoids, no matter how hard I try, while letting mkgmap render the map without a boundary, the tunnel works just fine). I believe (because the ML is not showered with emails complaining about it failing) that inter-tile routing is generally working OK. Please provide an example of it failing so we can study it. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cannot route when end node is at the tile edge
Hi Maning, The road intersection Daang Hari is exactly at the edge of my tile (made with splitter) routing does not work. But when I created another mapset without the splitter, routing works. http://www.openstreetmap.org/?lat=14.413996lon=121.01714zoom=18layers=B000FTF Which part of this junction actually falls on the exact line of the edge? It can't be the whole junction, just some part of it. Can you please post the XML bounds elements from the two tiles? It's near the top of the OSM file and looks like this example: bounds minlat='51.108398' minlon='-0.527344' maxlat='51.635742' maxlon='-0.131836'/ Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi, Since you know what you're talking about: is there a discussion, explanation or otherwise for the reason that you did not let the maps overlap? An overlap of 300 meters sounds like a good idea for the routing - but as said before, I'm saying this from a position of blessful ignorance. I will answer this one for Steve: The inter-tile routing is accomplished by having a set of boundary nodes that have exactly the same coordinates in each of the tiles that borders the boundary. To route across tiles, it has to go via a boundary node. To ensure the boundary node coordinates are the same in both tiles, there is no overlap in the bounding boxes. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Missing strip at map intersections: is it a regression?
This issue of the area near a tile boundary not being drawn is weird because when I was first working on the inter-tile routing, I never noticed this occurring. So either I was lucky and just didn't come across it or something has changed since then to introduce this issue. So, a question to everyone: has this always been an issue or is it a regression? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cannot route when end node is at the tile edge
Hi Maning,
Even better, don't partition the way as I requested but, instead,
please try this patch and see if it makes any difference.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/general/LineClipper.java b/src/uk/me/parabola/mkgmap/general/LineClipper.java
index 55aa51d..9bf224d 100644
--- a/src/uk/me/parabola/mkgmap/general/LineClipper.java
+++ b/src/uk/me/parabola/mkgmap/general/LineClipper.java
@@ -135,11 +135,18 @@ public class LineClipper {
assert t[1] = 1;
double d = 0.5;
- if (t[0] 0)
- ends[0] = new Coord((int) (y0 + t[0] * dy + d), (int) (x0 + t[0] * dx + d));
+ if (t[0] 0) {
+ Coord c = new Coord((int) (y0 + t[0] * dy + d), (int) (x0 + t[0] * dx + d));
+ if(!c.equals(ends[0]))
+ends[0] = c;
+ }
+
+ if (t[1] 1) {
+ Coord c = new Coord((int)(y0 + t[1] * dy + d), (int) (x0 + t[1] * dx + d));
+ if(!c.equals(ends[1]))
+ends[1] = c;
+ }
- if (t[1] 1)
- ends[1] = new Coord((int)(y0 + t[1] * dy + d), (int) (x0 + t[1] * dx + d));
return ends;
}
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 9bc6b83..5b8d8db 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -103,6 +103,9 @@ public class RoadNetwork {
if(node1 == node2)
log.error(Road + road.getRoadDef().getName() + (OSM id + road.getRoadDef().getId() + ) contains consecutive identical nodes - routing will be broken);
+else if(arcLength == 0) {
+ log.error(Road + road.getRoadDef().getName() + (OSM id + road.getRoadDef().getId() + ) contains zero length arc);
+}
// Create forward arc from node1 to node2
Coord bearing = coordList.get(lastIndex + 1);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - fix clipping when node falls on tile boundary
Hi Maning,
Here's another attempt at a fix. Please try.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java
index 54cdc5f..84df73c 100644
--- a/src/uk/me/parabola/imgfmt/app/Coord.java
+++ b/src/uk/me/parabola/imgfmt/app/Coord.java
@@ -78,6 +78,10 @@ public class Coord implements ComparableCoord {
++highwayCount;
}
+ public void zeroHighwayCount() {
+ highwayCount = 0;
+ }
+
public int hashCode() {
return latitude+longitude;
}
diff --git a/src/uk/me/parabola/mkgmap/general/LineClipper.java b/src/uk/me/parabola/mkgmap/general/LineClipper.java
index 55aa51d..3ead4cc 100644
--- a/src/uk/me/parabola/mkgmap/general/LineClipper.java
+++ b/src/uk/me/parabola/mkgmap/general/LineClipper.java
@@ -135,11 +135,22 @@ public class LineClipper {
assert t[1] = 1;
double d = 0.5;
- if (t[0] 0)
- ends[0] = new Coord((int) (y0 + t[0] * dy + d), (int) (x0 + t[0] * dx + d));
+ if (t[0] 0) {
+ Coord c = new Coord((int) (y0 + t[0] * dy + d), (int) (x0 + t[0] * dx + d));
+ if(c.equals(ends[0]))
+ends[0].zeroHighwayCount(); // flag as boundary node
+ else
+ends[0] = c;
+ }
+
+ if (t[1] 1) {
+ Coord c = new Coord((int)(y0 + t[1] * dy + d), (int) (x0 + t[1] * dx + d));
+ if(c.equals(ends[1]))
+ends[1].zeroHighwayCount(); // flag as boundary node
+ else
+ends[1] = c;
+ }
- if (t[1] 1)
- ends[1] = new Coord((int)(y0 + t[1] * dy + d), (int) (x0 + t[1] * dx + d));
return ends;
}
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 9bc6b83..5b8d8db 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -103,6 +103,9 @@ public class RoadNetwork {
if(node1 == node2)
log.error(Road + road.getRoadDef().getName() + (OSM id + road.getRoadDef().getId() + ) contains consecutive identical nodes - routing will be broken);
+else if(arcLength == 0) {
+ log.error(Road + road.getRoadDef().getName() + (OSM id + road.getRoadDef().getId() + ) contains zero length arc);
+}
// Create forward arc from node1 to node2
Coord bearing = coordList.get(lastIndex + 1);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] - fix clipping when node falls on tile boundary
Yeah, I'm still wondering how on earth did I do that :). Can't wait to try it tonight! It better well work then otherwise you're going to be really disappointed! Well, I now understand what the problem is so even if the latest patch isn't perfect, I'm in the right area (ho ho). I should have fixed this stuff when the inter-tile routing was first implemented - I knew at the time that it wouldn't cope with nodes that fall exactly on the boundary. Just me being lazy and putting off the inevitable. So, finger's crossed that it will fix Maning's example and if it does and we get no issues, I will commit ASAP. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v4] - fix clipping when node falls on tile boundary
This version should do the same as v3 as far as the bug fix is
concerned but I have cleaned things up a little so please test this
version if possible.
Thanks,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Area.java b/src/uk/me/parabola/imgfmt/app/Area.java
index 13b0ee4..9279b40 100644
--- a/src/uk/me/parabola/imgfmt/app/Area.java
+++ b/src/uk/me/parabola/imgfmt/app/Area.java
@@ -149,19 +149,30 @@ public class Area {
}
public boolean contains(Coord co) {
+ // return true if co is inside the Area (it may touch the
+ // boundary)
return co.getLatitude() = minLat
co.getLatitude() = maxLat
co.getLongitude() = minLong
co.getLongitude() = maxLong;
}
+ public boolean insideBoundary(Coord co) {
+ // return true if co is inside the Area and doesn't touch the
+ // boundary
+ return co.getLatitude() minLat
+ co.getLatitude() maxLat
+ co.getLongitude() minLong
+ co.getLongitude() maxLong;
+ }
+
public boolean isEmpty() {
return minLat = maxLat || minLong = maxLong;
}
- public boolean allInside(ListCoord coords) {
+ public boolean allInsideBoundary(ListCoord coords) {
for (Coord co : coords) {
- if (!contains(co))
+ if (!insideBoundary(co))
return false;
}
return true;
diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java
index 54cdc5f..bc84197 100644
--- a/src/uk/me/parabola/imgfmt/app/Coord.java
+++ b/src/uk/me/parabola/imgfmt/app/Coord.java
@@ -36,7 +36,8 @@ import uk.me.parabola.imgfmt.Utils;
public class Coord implements ComparableCoord {
private final int latitude;
private final int longitude;
- private int highwayCount; // number of highways that use this point
+ private byte highwayCount; // number of highways that use this point
+ private boolean onBoundary; // true if point lies on a boundary
/**
* Construct from co-ordinates that are already in map-units.
@@ -75,7 +76,17 @@ public class Coord implements ComparableCoord {
}
public void incHighwayCount() {
- ++highwayCount;
+ // don't let it wrap
+ if(highwayCount Byte.MAX_VALUE)
+ ++highwayCount;
+ }
+
+ public boolean getOnBoundary() {
+ return onBoundary;
+ }
+
+ public void setOnBoundary(boolean onBoundary) {
+ this.onBoundary = onBoundary;
}
public int hashCode() {
diff --git a/src/uk/me/parabola/mkgmap/general/LineClipper.java b/src/uk/me/parabola/mkgmap/general/LineClipper.java
index 55aa51d..7423c3c 100644
--- a/src/uk/me/parabola/mkgmap/general/LineClipper.java
+++ b/src/uk/me/parabola/mkgmap/general/LineClipper.java
@@ -44,7 +44,7 @@ public class LineClipper {
// If all the points are inside the box then we just return null
// to show that nothing was done and the line can be used. This
// is expected to be the normal case.
- if (a == null || a.allInside(coords))
+ if (a == null || a.allInsideBoundary(coords))
return null;
class LineCollector {
@@ -135,11 +135,56 @@ public class LineClipper {
assert t[1] = 1;
double d = 0.5;
- if (t[0] 0)
+ Coord orig0 = ends[0];
+ Coord orig1 = ends[1];
+ if (t[0] 0) {
+ // line is clipped so create the new end point and mark it
+ // as a boundary node
ends[0] = new Coord((int) (y0 + t[0] * dy + d), (int) (x0 + t[0] * dx + d));
+ ends[0].setOnBoundary(true);
+ }
+ else if(!a.insideBoundary(ends[0])) {
+ // point lies on the boundary so it's a boundary node
+ ends[0].setOnBoundary(true);
+ }
- if (t[1] 1)
+ if (t[1] 1) {
+ // line is clipped so create the new end point and mark it
+ // as a boundary node
ends[1] = new Coord((int)(y0 + t[1] * dy + d), (int) (x0 + t[1] * dx + d));
+ ends[1].setOnBoundary(true);
+ }
+ else if(!a.insideBoundary(ends[1])) {
+ // point lies on the boundary so it's a boundary node
+ ends[1].setOnBoundary(true);
+ }
+
+ // zero length segments can be created if one point lies on
+ // the boundary and the other is outside of the area
+ if(ends[0].equals(ends[1])) {
+ // throw away zero length segments
+ return null;
+ }
+
+ // these last two tests catch the situation where the new point
+ // on the clipped line is so close to the original point that
+ // they have the same coordinates - in which case we need to use
+ // the original point so it maintains its identity
+
+ if(ends[0] != orig0 ends[0].equals(orig0)) {
+ // new Coord has same coordinates as original so use the
+ // original Coord and flag it as a boundary node
+ orig0.setOnBoundary(true);
+ ends[0] = orig0;
+ }
+
+ if(ends[1] != orig1 ends[1].equals(orig1)) {
+ // new Coord has same coordinates as original so use the
+ // original Coord and flag it as a boundary node
+ orig1.setOnBoundary(true);
+ ends[1] = orig1;
+ }
+
return ends;
}
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 9bc6b83..5b8d8db 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++
Re: [mkgmap-dev] [PATCH v4] - fix clipping when node falls on tile boundary
Maning, No prob. Will test again if you there is a new patch. I need to work from the same data, what splitter params and original data file are you using? 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 v5] - fix clipping when node falls on tile boundary
Hi Maning, I am happy to report that it is working now either in patch v4 or v5. Thanks! Are you sure that the boundary is still in the same place? If so, that's great. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] still an arc with length 0
Hi Valentijn, SEVERE (RoadNetwork): Road null (OSM id 34394107) contains zero length arc Ah, that's a completely different problem. Please try attached patch. Cheers, Mark mb-loop-split-fix-v1 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] routing and cycleway=track
Hi Sven, quite a lot of cycleways around here alongside major roads (primary,secondary,trunk) are tagged as cycleway=track. In this case the Garmin device does not use this ways if Avoid Highways is enabled in routing option. The result is a very strange routing in these places. Would it be possible to generate fake cycleways in this cases simular to what --make-opposite-cycleways is doing? Should be easy, I will look at that. As I'm already asking for cycle routing here. Is it known to the developers of mkgmap what the option Avoid unpaved roads is actually doing? Looks like this option does not have any effect with current mkgmap generated maps. Is this just a limitation to certain types of roads or is this an additional per way flag which could be mapped in a way that routing does actually avoid tracks of tracktype grade1? At this time, we don't know how to tell the Garmin that a road is unpaved. I have experimented by setting various bits in the per-road data but none, so far, have had the desired effect. It would be great to get that working. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - make cycleway tracks
As requested, here's an option (--make-cycleway-tracks) to enable the
synthesis of cycleways when a (non-cycleway) way is tagged
cycleway=track.
I have also tweaked the code for making opposite cycleways - it now
gives the synthesised way a highway=cycleway tag which it wasn't doing
before.
So anyone who was using the --make-opposite-cycleways option, please
test to see it hasn't been broken.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 5dc82cc..80fff50 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -168,6 +168,11 @@ Misc options:
direction and this option makes a way with the same points as
the original that allows bicycle traffic (in both directions).
+--make-cycleway-tracks
+ Some streets have a separate cycleway just for bicycle traffic
+ and this option makes a way with the same points as the
+ original that allows bicycle traffic.
+
--link-pois-to-ways
If this option is enabled, POIs that are situated at a point
in a way will be associated with that way and may modify the
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 2f463f0..c672dbe 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -87,6 +87,7 @@ class Osm5XmlHandler extends DefaultHandler {
private long nextFakeId = 1;
private final boolean makeOppositeCycleways;
+ private final boolean makeCyclewayTracks;
private final boolean ignoreBounds;
private final boolean ignoreTurnRestrictions;
private final boolean linkPOIsToWays;
@@ -96,6 +97,7 @@ class Osm5XmlHandler extends DefaultHandler {
public Osm5XmlHandler(EnhancedProperties props) {
makeOppositeCycleways = props.getProperty(make-opposite-cycleways, false);
+ makeCyclewayTracks = props.getProperty(make-cycleway-tracks, false);
linkPOIsToWays = props.getProperty(link-pois-to-ways, false);
ignoreBounds = props.getProperty(ignore-osm-bounds, false);
routing = props.containsKey(route);
@@ -293,7 +295,9 @@ class Osm5XmlHandler extends DefaultHandler {
currentWay.addTag(mkgmap:frig_roundabout, frigRoundabouts);
}
}
- if(makeOppositeCycleways currentWay.isBoolTag(oneway)) {
+ if(makeOppositeCycleways
+ !cycleway.equals(highway)
+ currentWay.isBoolTag(oneway)) {
String cyclewayTag = currentWay.getTag(cycleway);
if(opposite.equals(cyclewayTag) ||
opposite_lane.equals(cyclewayTag) ||
@@ -314,13 +318,47 @@ class Osm5XmlHandler extends DefaultHandler {
for(int i = points.size() - 1; i = 0; --i)
cycleWay.addPoint(points.get(i));
cycleWay.copyTags(currentWay);
- cycleWay.addTag(name, currentWay.getTag(name) + (cycleway));
+ cycleWay.addTag(highway, cycleway);
+ String name = currentWay.getTag(name);
+ if(name != null)
+name += (cycleway);
+ else
+name = cycleway;
+ cycleWay.addTag(name, name);
cycleWay.addTag(oneway, no);
cycleWay.addTag(access, no);
cycleWay.addTag(bicycle, yes);
+ cycleWay.addTag(foot, no);
log.info(Making opposite cycleway ' + cycleWay.getTag(name) + ');
}
}
+ if(makeCyclewayTracks
+ !cycleway.equals(highway)
+ track.equals(currentWay.getTag(cycleway))) {
+ // what we have here is a highway with a
+ // separate track for cycles -- to enable
+ // bicyle routing, we synthesise a cycleway
+ // that has the same points as the original
+ // way
+ long cycleWayId = currentWay.getId() + CYCLEWAY_ID_OFFSET;
+ Way cycleWay = new Way(cycleWayId);
+ wayMap.put(cycleWayId, cycleWay);
+ ListCoord points = currentWay.getPoints();
+ for(int i = 0; i points.size(); ++i)
+ cycleWay.addPoint(points.get(i));
+ cycleWay.copyTags(currentWay);
+ cycleWay.addTag(highway, cycleway);
+ String name = currentWay.getTag(name);
+ if(name != null)
+ name += (cycleway);
+ else
+ name = cycleway;
+ cycleWay.addTag(name, name);
+ cycleWay.addTag(access, no);
+ cycleWay.addTag(bicycle, yes);
+ cycleWay.addTag(foot, no);
+ log.info(Making cycleway track ' + cycleWay.getTag(name) + ');
+ }
}
if(motorway.equals(highway) ||
trunk.equals(highway))
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1101: Further work on loop splitting code.
Hi, Incidentally, that way, Road Diemerdreef (OSM id 24975519), is a really dumb bit of OSM. It's a roundabout with about 20 points and has a diameter of about 1m! Why do people do that? I wouldn't know, I'm an IT person. My wife though is a psychologist. Do you want me to file a bug? ;) Sure, start a bugzilla for the human race, there's a thought! http://www.openstreetmap.org/?lat=52.331227lon=4.956253zoom=20 All right, fixed it for you. That's kind. BTW, do you have mini roundabouts? If so, should it have been one of 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] - make cycleway tracks
Hi Sven, Anyway looking at the patch this seems to be incomplete. We should synthesise a cycleway for the following tags: track,left,rigt,lane and yes. Where left or right will imply oneway=yes. I have no problem with matching more tags. However, left, right and yes are not discussed on http://wiki.openstreetmap.org/wiki/Key:cycleway how are they meant to be used? I have also tweaked the code for making opposite cycleways - it now gives the synthesised way a highway=cycleway tag which it wasn't doing before. Hm, I'm not shure if this is a good idea, because the Garmin devices tend to prefer real cycleways over generic roads. This may not be the expected behaviour for one-way roads thus it might be better to assign the real type of highway. Sorry, not sure what you're saying here. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] - make cycleway tracks
On Fri, 24 Jul 2009 13:56:19 + (UTC) Sven Geggus li...@fuchsschwanzdomain.de wrote: Mark Burton ma...@ordern.com wrote: I have no problem with matching more tags. However, left, right and yes are not discussed on http://wiki.openstreetmap.org/wiki/Key:cycleway how are they meant to be used? http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_footway_and_cycleway left and right are major roads with cycleways on one side of the road only. OK - thanks for the link. So, as the cycleway gets generated using the same points as the original way, left and right can't really work as expected. However, we can still generate the cycleway, it just won't be biased to either side of the original way. The tag value yes doesn't get mentioned so I don't think we should accept that. The tags it can match could be: track, lane, both, left and right. Hm, I'm not shure if this is a good idea, because the Garmin devices tend to prefer real cycleways over generic roads. This may not be the expected behaviour for one-way roads thus it might be better to assign the real type of highway. Sorry, not sure what you're saying here. Is this due to my improper english? I'm not a native speaker after all. No, I don't think it is your english, I can perfectly understand everything else you write! I will try to explain along the lines of the patch... You replaced cycleWay.copyTags with new code, this way you end e.g. up with something like this: highway=cycleway (+ more tags) instead of: highway=residential (+ more tags) Yes, but only on the cycleway, not the orginal way. However, this may lead to a situation, where cycling one-way roads into the opposite direction might get _prefered_ over cycling into the ordinary direction in cases where cycleways are prefered over residential roads. This is almost certainly not an expected behaviour. Let me see if I understand this right: you are saying that with the opposite cycleway now tagged as highway=cycleway, it could be possible for that way to be used in preference to another way (that isn't a cycleway) because cycleways have a higher precedence for bicycle routing? Hmm, this will depend on what Garmin codes are assigned to the different ways and the effect that has on the routing. What line type codes do people use for cycleways? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - make cycleway tracks
v2 - Now matches extra tags (lane, left, right, both).
Commented out setting of highway=cycleway until it's agreed that it's a
good idea.
-
As requested, here's an option (--make-cycleway-tracks) to enable the
synthesis of cycleways when a (non-cycleway) way is tagged
cycleway=track.
I have also tweaked the code for making opposite cycleways - it now
gives the synthesised way a highway=cycleway tag which it wasn't doing
before.
So anyone who was using the --make-opposite-cycleways option, please
test to see it hasn't been broken.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 5dc82cc..80fff50 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -168,6 +168,11 @@ Misc options:
direction and this option makes a way with the same points as
the original that allows bicycle traffic (in both directions).
+--make-cycleway-tracks
+ Some streets have a separate cycleway just for bicycle traffic
+ and this option makes a way with the same points as the
+ original that allows bicycle traffic.
+
--link-pois-to-ways
If this option is enabled, POIs that are situated at a point
in a way will be associated with that way and may modify the
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 2f463f0..3b90407 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -87,6 +87,7 @@ class Osm5XmlHandler extends DefaultHandler {
private long nextFakeId = 1;
private final boolean makeOppositeCycleways;
+ private final boolean makeCyclewayTracks;
private final boolean ignoreBounds;
private final boolean ignoreTurnRestrictions;
private final boolean linkPOIsToWays;
@@ -96,6 +97,7 @@ class Osm5XmlHandler extends DefaultHandler {
public Osm5XmlHandler(EnhancedProperties props) {
makeOppositeCycleways = props.getProperty(make-opposite-cycleways, false);
+ makeCyclewayTracks = props.getProperty(make-cycleway-tracks, false);
linkPOIsToWays = props.getProperty(link-pois-to-ways, false);
ignoreBounds = props.getProperty(ignore-osm-bounds, false);
routing = props.containsKey(route);
@@ -293,33 +295,74 @@ class Osm5XmlHandler extends DefaultHandler {
currentWay.addTag(mkgmap:frig_roundabout, frigRoundabouts);
}
}
- if(makeOppositeCycleways currentWay.isBoolTag(oneway)) {
- String cyclewayTag = currentWay.getTag(cycleway);
- if(opposite.equals(cyclewayTag) ||
- opposite_lane.equals(cyclewayTag) ||
- opposite_track.equals(cyclewayTag)) {
- // what we have here is a oneway street
- // that allows bicycle traffic in both
- // directions -- to enable bicyle routing
- // in the reverse direction, we synthesise
- // a cycleway that has the same points as
- // the original way
- long cycleWayId = currentWay.getId() + CYCLEWAY_ID_OFFSET;
- Way cycleWay = new Way(cycleWayId);
- wayMap.put(cycleWayId, cycleWay);
- // this reverses the direction of the way
- // but that isn't really necessary as the
- // cycleway isn't tagged as oneway
- ListCoord points = currentWay.getPoints();
- for(int i = points.size() - 1; i = 0; --i)
-cycleWay.addPoint(points.get(i));
- cycleWay.copyTags(currentWay);
- cycleWay.addTag(name, currentWay.getTag(name) + (cycleway));
- cycleWay.addTag(oneway, no);
- cycleWay.addTag(access, no);
- cycleWay.addTag(bicycle, yes);
- log.info(Making opposite cycleway ' + cycleWay.getTag(name) + ');
- }
+ String cycleway = currentWay.getTag(cycleway);
+ if(makeOppositeCycleways
+ cycleway != null
+ !cycleway.equals(highway)
+ currentWay.isBoolTag(oneway)
+ (opposite.equals(cycleway) ||
+ opposite_lane.equals(cycleway) ||
+ opposite_track.equals(cycleway))) {
+ // what we have here is a oneway street
+ // that allows bicycle traffic in both
+ // directions -- to enable bicyle routing
+ // in the reverse direction, we synthesise
+ // a cycleway that has the same points as
+ // the original way
+ long cycleWayId = currentWay.getId() + CYCLEWAY_ID_OFFSET;
+ Way cycleWay = new Way(cycleWayId);
+ wayMap.put(cycleWayId, cycleWay);
+ // this reverses the direction of the way but
+ // that isn't really necessary as the cycleway
+ // isn't tagged as oneway
+ ListCoord points = currentWay.getPoints();
+ for(int i = points.size() - 1; i = 0; --i)
+ cycleWay.addPoint(points.get(i));
+ cycleWay.copyTags(currentWay);
+ //cycleWay.addTag(highway, cycleway);
+ String name = currentWay.getTag(name);
+ if(name != null)
+ name += (cycleway);
+ else
+ name = cycleway;
+ cycleWay.addTag(name, name);
+
Re: [mkgmap-dev] routing and cycleway=track
Hi Sven, Mark Burton ma...@ordern.com wrote: Here's a question: when you have a cycleway lane/track, are bicycles prohibited from using the road or can they use the road if they wish to? I suppose that this is different in different countries. In Germany there is a term called Radwegebenutzungspflicht which means that you are required to use a cycleway if there is a traffic sign like this: http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_237.svg There are some cases with cycleways not marked by this sign, but this is not the norm. I wonder if when we generate a cycleway, we should be adding a bicycle=no to the original way? As german law is concerned this would be the way to go. It may however not be that important, because I don't care which way the Garmin actually uses as they are on the same place anyway. Thanks a lot for that info. I agree that it doesn't really matter which way gets used as they share the same nodes but if you take away bicycle access from the road, the gps will tell you to route via Foo (cycleway) rather than Foo. It seems to me that would be more consistent and at least in some countries it would agree with what is the normal behaviour. I'm tempted to add: if(currentWay.getTag(bicycle) == null) currentWay.addTag(bicycle, no); so that if the original way doesn't already have the bicycle routing defined, it will be disallowed. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] - make cycleway tracks
v3
renamed option for enabling this to --make-cycleways
added --make-all-cycleways option to turn on all cycleway synthesising
options
Now removes bicycle access from the original way (unless that way has a
bicycle tag) to force the routing to use the cycleway.
BTW - this may be a complete red herring but mapsource was not showing
me the cycleway names like Foo (cycleway) it was only showing the
original road name Foo. I then rebuilt the map without the
--lower-case option and the cycleway names started appearing. So, either
mapsource was just being its usual weird self or there is some badness
related to using --lower-case. Just thought I would mention it!
-
v2 - Now matches extra tags (lane, left, right, both).
Commented out setting of highway=cycleway until it's agreed that it's a
good idea.
-
As requested, here's an option (--make-cycleway-tracks) to enable the
synthesis of cycleways when a (non-cycleway) way is tagged
cycleway=track.
I have also tweaked the code for making opposite cycleways - it now
gives the synthesised way a highway=cycleway tag which it wasn't doing
before.
So anyone who was using the --make-opposite-cycleways option, please
test to see it hasn't been broken.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 5dc82cc..3afd3b4 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -163,11 +163,21 @@ Misc options:
style is applied and only for polygon types that have a
reasonable point equivalent.
+--make-all-cycleways
+ Turn on all of the options that make cycleways.
+
--make-opposite-cycleways
Some oneway streets allow bicycle traffic in the reverse
direction and this option makes a way with the same points as
the original that allows bicycle traffic (in both directions).
+--make-cycleways
+ Some streets have a separate cycleway track/lane just for
+ bicycle traffic and this option makes a way with the same
+ points as the original that allows bicycle traffic and, also,
+ prohibits that traffic from the original way (unless the way
+ is tagged bicycle=yes).
+
--link-pois-to-ways
If this option is enabled, POIs that are situated at a point
in a way will be associated with that way and may modify the
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 2f463f0..81c5a8e 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -87,6 +87,7 @@ class Osm5XmlHandler extends DefaultHandler {
private long nextFakeId = 1;
private final boolean makeOppositeCycleways;
+ private final boolean makeCycleways;
private final boolean ignoreBounds;
private final boolean ignoreTurnRestrictions;
private final boolean linkPOIsToWays;
@@ -95,7 +96,13 @@ class Osm5XmlHandler extends DefaultHandler {
private final String frigRoundabouts;
public Osm5XmlHandler(EnhancedProperties props) {
- makeOppositeCycleways = props.getProperty(make-opposite-cycleways, false);
+ if(props.getProperty(make-all-cycleways, false)) {
+ makeOppositeCycleways = makeCycleways = true;
+ }
+ else {
+ makeOppositeCycleways = props.getProperty(make-opposite-cycleways, false);
+ makeCycleways = props.getProperty(make-cycleways, false);
+ }
linkPOIsToWays = props.getProperty(link-pois-to-ways, false);
ignoreBounds = props.getProperty(ignore-osm-bounds, false);
routing = props.containsKey(route);
@@ -293,33 +300,76 @@ class Osm5XmlHandler extends DefaultHandler {
currentWay.addTag(mkgmap:frig_roundabout, frigRoundabouts);
}
}
- if(makeOppositeCycleways currentWay.isBoolTag(oneway)) {
- String cyclewayTag = currentWay.getTag(cycleway);
- if(opposite.equals(cyclewayTag) ||
- opposite_lane.equals(cyclewayTag) ||
- opposite_track.equals(cyclewayTag)) {
- // what we have here is a oneway street
- // that allows bicycle traffic in both
- // directions -- to enable bicyle routing
- // in the reverse direction, we synthesise
- // a cycleway that has the same points as
- // the original way
- long cycleWayId = currentWay.getId() + CYCLEWAY_ID_OFFSET;
- Way cycleWay = new Way(cycleWayId);
- wayMap.put(cycleWayId, cycleWay);
- // this reverses the direction of the way
- // but that isn't really necessary as the
- // cycleway isn't tagged as oneway
- ListCoord points = currentWay.getPoints();
- for(int i = points.size() - 1; i = 0; --i)
-cycleWay.addPoint(points.get(i));
- cycleWay.copyTags(currentWay);
- cycleWay.addTag(name, currentWay.getTag(name) + (cycleway));
- cycleWay.addTag(oneway, no);
- cycleWay.addTag(access, no);
- cycleWay.addTag(bicycle, yes);
- log.info(Making opposite cycleway ' + cycleWay.getTag(name) + ');
-
Re: [mkgmap-dev] Problem with styles
This works for me: I have a directory called mkgmap-burto-style. In it are: info lines options points polygons relations version I use the following option: --style-file=mkgmap-burto-style That assumes that mkgmap-burto-style is in the current directory. Obviously, you need to put in a pathname (absolute or relative) if it's elsewhere. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error - zero length arc
Hi Rudi,
Yes, I have a custom style file and I want to see the platform as a footway
(routing enabled):
railway=platform {set ...} [0x0d road_class=0 road_speed=0 level 0]
OK - I have just processed that map using a similar rule and I don't get
the short arc message. Sorry, I don't know what the issue is here. Are
you sure you're using the latest mkgmpa?
BTW - the remove short arc processing is done before the style file
processing and it is only applied to highways and ferry routes so if
the style file makes something else into a road (from the routing point
of view) then it will not have had its arcs tweezed. This way of
doing things is unlikely to change anytime soon.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - All ways may contain nodes
This patch should cure the problem where something that isn't a highway
or a ferry route is mutated into a routable way by the style file and,
subsequently, due to its shape/size/topology/etc introduces a short
arc.
I would be grateful if as many people as possible test this and
report any breakage as it could have an effect on any map (although, I
believe it safe enough).
Cheers,
Mark
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 ff804ad..e350483 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -284,11 +284,6 @@ class Osm5XmlHandler extends DefaultHandler {
String highway = currentWay.getTag(highway);
if(highway != null ||
ferry.equals(currentWay.getTag(route))) {
- // the way is a highway (or ferry route), so for
- // each of it's points, increment the number of
- // highways using that point
- for(Coord p : currentWay.getPoints())
- p.incHighwayCount();
// if the way is a roundabout but isn't already
// flagged as oneway, flag it here
if(roundabout.equals(currentWay.getTag(junction))) {
@@ -711,6 +706,7 @@ class Osm5XmlHandler extends DefaultHandler {
}
}
currentWay.addPoint(co);
+ co.incHighwayCount(); // nodes (way joins) will have highwayCount 1
if(minimumArcLength != null)
nodeIdMap.put(co, id);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error - zero length arc
Hi Rudi, Your patch works very well, thanks a lot! I also created a map for germany with your patch, it was generated without errors and the map seems to be ok. In my opinion you can commit the changes. Thanks for the report, I shall commit that change if no one reports any breakage (which I doubt). Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing across multiple tiles
Hi Mark, Sorry forgot to add that bit. I'm using splitter on the UK extracts from geofabrik. OK. The most recent trials have used r1099, but before that I was using r1067 and r1072 all with the same results. OK. As I say going from one tile to an adjacent one works; but anything with an intermediate tile fails. I've tried various routes so I believe the problem is general (for me at least!) rather than a specific road that is causing the problem. Testing with mapsource on tiled maps of the UK and the Netherlands, I can route across multiple tiles (in one case, I counted 7 tiles). However, mapsource often gives up when trying to route long distances (especially with the UK map compared to the NL) so I wonder if there's some complexity contstraint that we're not adhering to. But to answer your original question, multiple tiles can be routed across. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
Hi Valentijn, What's really fascinating about your example is that mapsource will happily route from A to a point within the tile containing B passing right past point C. For example, route from A to the end of Plutoniumweg (damn it, why can't we have funky road names like that instead of the canonical Acacia Avenue!), but if you move the destination a little to the S so that it is in the lower tile, it fails to route - see attached gdb. It's almost as if having traversed B tile it then is happy to locate a destination in it but, for some reason, it's unhappy with a destination in C tile. I can't think at this time what would cause this to happen. It may be a limitation of the Garmin routing engine and it needs something extra from us to cope? Cheers, Mark plutoniumweg.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] a routing problem
Hi, For me, routing to the Plutoniumweg doesn't work at all - but my Mapsource is older than yours, I could not read your Plutoniumweg.gdb (MapSource complains about the file being newer). I am using the latest version (as downloaded by the check for software updates option on the help menu). Utrecht, we have a problem ;) I was thinking about trying to synchronize the vertical split line (i.e. have both maps split at 0x39000, just to make sure that's not the problem. Could be worth trying to see if it changes anything. Oh, btw: the reason I found this strange route is that a much longer inter-tile route, from my home in Zaandam to my parents in Houten, made a weird deviation half way (went off the A2 for no reason, somewhere above point A); also, a route to my wife's family in Culemborg could not be calculated at all. Yes, it's not specific to that particular piece of road. It must be a general problem with being unable to route across a tile in certain circumstances. Just to be sure, I'll check my Nüvi this evening. Please do, it would be useful to know if a real GPS has the same problem (my guess is that it will). Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Clearing mapsource tile cache
Hi Garvan, I just deleted this folder C:\Documents and Settings\markb\Application Data\GARMIN\MapSource\TileCache and I think it did the trick (obviously, change the user name to your own) 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 Nuvi asks province
Hi Valentijn, A bit of a strange thing: my Garmin mkgmap maps ask the provincie (Province? State? County? Whatever you guys call it over there ;) when I want to route to an address. I normally build my map with country=Netherlands and country-abbr=NL, I also tried no country and abbrev, but it keeps asking for a Provincie. Whatever I enter, Garmin can't find it and this makes routing to an address pretty much infeasible. On the regular map, it just asks me if I'm in the Netherlands and then I can enter street and city names. java -enableassertions -Xmx1800m -jar ~/garmintest/mkgmap/dist/mkgmap.jar --country-name= --country-abbr= --family-name=Openstreetmap Netherlands `date -I` --latin1 --remove-short-arcs --lower-case --preserve-element-order --location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args What am I doing wrong? I guess this is just a wrong option somewhere? You're not doing anything wrong. It's a known problem with the address finding. Basically, it's only semi-functional. Searching for addresses or highway exits will probably never work well until the global index stuff is implemented. 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 Nuvi asks province
Hi, Actually, on my GPSMap 76Cxs the address search kind-of-works even without using the --road-name-pois option*. I have to enter a house number of some kind for it to work though (even if the destination doesn't actually have a number) and it only works for some addresses, but I haven't tested it fully as it's not a facility I actually need. *At least, I haven't been enabling the --road-name-pois option when invoking mkgmap and I assume it isn't enabled by default. Enabling road name POIs does not help the address search function. It's a completely separate function. It was provided as a cheap hack to get some form of road name searching. Arguably, it works better than the address search which, as we know, is less than perfect. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] errors in routing
Hi Garvan, Should now be fixed. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] errors in routing
Should now be fixed. Err, that's only for OSM input. For Polish input it's not fixed - you have to fix your data instead. Just make sure that no road is longer than 25Km between nodes. If necessary, add extra nodes. I don't know what the distance constraint is here but with your sample data, I limited the length of the way to 25Km and the problem went away. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Append Name with general rules via style-file
Hi Felix, This is not a comment on your proposed scheme but I do believe that the current handling of name and ref (and the highway shields, etc.) is completely fucked up. IMHO, munging the element name and its refs together in the style file is completely bogus. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - Add support for marine (aka extended) types
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended
types that are used on marine maps.
Extended types are specified as a 6 digit hex number. The first two
digits are always 01. An example type is 0x010200 (point type Buoy).
Points, lines and polygons can all be given extended types.
The cGPSMapper user manual lists all of the types.
Note that routable ways cannot have an extended type. If you try to
give a road an extended type, it will converted into a line.
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.
It now works well enough to warrant testing on more map data but I
am expecting that there will be problems given the extent of the patch
and the nature of what it's doing.
Please test if you can and report success/failure/etc.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java b/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
index c99e807..eb5d520 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
@@ -32,6 +32,7 @@ class LinePreparer {
private final Polyline polyline;
private boolean extraBit;
+ private boolean extTypeLine;
private boolean xSameSign;
private boolean xSignNegative; // Set if all negative
@@ -55,6 +56,8 @@ class LinePreparer {
extraBit = true;
}
+ extTypeLine = line.hasExtendedType();
+
polyline = line;
calcLatLong();
calcDeltas();
@@ -105,6 +108,10 @@ class LinePreparer {
log.debug(y same is, ySameSign, sign is, ySignNegative);
}
+ if(extTypeLine) {
+ bw.put1(false); // no extra bits required
+ }
+
// first extra bit always appears to be false
// refers to the start point?
if (extraBit)
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java b/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
index 9a3c017..0973201 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
@@ -19,9 +19,13 @@ package uk.me.parabola.imgfmt.app.trergn;
import uk.me.parabola.imgfmt.app.Label;
import uk.me.parabola.imgfmt.app.ImgFileWriter;
+import uk.me.parabola.mkgmap.general.MapElement;
+
import java.util.ArrayList;
import java.util.List;
+import java.io.OutputStream;
+
/**
* An object that appears in a map. One of point, polyline, polygon or indexed
* point.
@@ -57,6 +61,8 @@ public abstract class MapObject {
*/
public abstract void write(ImgFileWriter file);
+ public abstract void write(OutputStream stream) throws java.io.IOException;
+
int getDeltaLat() {
return deltaLat;
}
@@ -83,6 +89,10 @@ public abstract class MapObject {
this.type = type;
}
+ public boolean hasExtendedType() {
+ return MapElement.hasExtendedType(type);
+ }
+
/**
* Set an ordinary unshifted latitude. It will be calculated
* relative to the subdivision.
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/Overview.java b/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
index 2f164b5..29f949d 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
@@ -33,6 +33,7 @@ public abstract class Overview implements ComparableOverview {
public static final int SHAPE_KIND = 3;
private final int kind; // The kind of overview; point, line etc.
+ private final char extType;
private final char type;
private final char subType;
private final int minResolution;
@@ -43,6 +44,7 @@ public abstract class Overview implements ComparableOverview {
protected Overview(int kind, int fullType, int minres) {
this.kind = kind;
+ this.extType = (char)((fullType 16) 0xff);
this.type = (char) (fullType 8 0xff);
this.subType = (char) (fullType 0xff);
this.minResolution = minres;
@@ -54,10 +56,18 @@ public abstract class Overview implements ComparableOverview {
}
public void write(ImgFileWriter file) {
- file.put((byte) (type 0xff));
- file.put((byte) maxLevel);
- if (size 2)
- file.put((byte) (subType 0xff));
+ if(extType != 0) {
+ file.put((byte)type);
+ file.put((byte)maxLevel);
+ file.put((byte)subType);
+ file.put((byte)0);
+ }
+ else {
+ file.put((byte) (type 0xff));
+ file.put((byte) maxLevel);
+ if (size 2)
+file.put((byte) (subType 0xff));
+ }
}
/**
@@ -83,7 +93,10 @@ public abstract class Overview implements ComparableOverview {
return false;
Overview ov = (Overview) obj;
- return ov.kind == kind ov.type == type ov.subType == subType;
+ return (ov.kind == kind
+ov.extType == extType
+ov.type == type
+ov.subType == subType);
}
public int
Re: [mkgmap-dev] Commit: r1120: adds some options to the help file
+--enable-assertions + Turn on assertions in the code. This will make the program + more likely to abort and less likely to do the wrong thing. + Use of this option is recommended. + Surely this is either -ea or -enableassertions and the option goes to the java runtime and not to mkgmap? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - styling for the power user
Are you a heavy duty styler? If so, read on:
I notice that quite a lot of postings on the list are from people who
are having problems with complex style files. This little patch won't
(directly) solve those problems but it does provide a useful capability
that could be part of a solution for those people who have complex
styling requirements and are willing to do some coding.
What the patch does is allow elements (nodes, ways) to specify their
garmin type (and a few other things) explicitly using these tags:
mkgmap:gtype the element's type (integer constant)
mkgmap:kind one of node, polyline, polygon (only polygon is used
at this time to differentiate polygons from lines).
mkgmap:minres the element's minimum resolution (needed to make element
visible)
mkgmap:maxres the element's maximum resolution (not required)
mkgmap:roadclass the element's road class (needed for roads)
mkgmap:roadspeed the element's road speed (needed for roads)
If the mkgmap:gtype tag is present, the element will not be passed
through the normal style file process at all.
So how do these tags get added to the OSM data? Well, you could just
add them with an editor but that would get boring pretty quickly so
what I would expect to see is some kind of external filter program that
reads the OSM file and outputs a new OSM file with the appropriate tags
added.
That filter program could be written in any language that has some XML
processing support.
Current issues to be sorted out are handling of the highway shields
(not currently implemented) and also this feature is not compatible with
the cycleway faking code.
All feedback welcome.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 2a549f8..03fdbda 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -144,6 +144,50 @@ public class StyledConverter implements OsmConverter {
lineAdder = overlayAdder;
}
+ public GType makeGTypeFromTags(Element element, int kind) {
+ String s = element.getTag(mkgmap:gtype);
+ GType gt = new GType(kind, s);
+ element.setName(element.getTag(name));
+ s = element.getTag(mkgmap:minres);
+ if(s != null) {
+ try {
+gt.setMinResolution(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error(Bad value for mkgmap:minres tag: + s);
+ }
+ }
+ s = element.getTag(mkgmap:maxres);
+ if(s != null) {
+ try {
+gt.setMaxResolution(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error(Bad value for mkgmap:maxres tag: + s);
+ }
+ }
+ s = element.getTag(mkgmap:roadclass);
+ if(s != null) {
+ try {
+gt.setRoadClass(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error(Bad value for mkgmap:roadclass tag: + s);
+ }
+ }
+ s = element.getTag(mkgmap:roadspeed);
+ if(s != null) {
+ try {
+gt.setRoadClass(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error(Bad value for mkgmap:roadspeed tag: + s);
+ }
+ }
+
+ return gt;
+ }
+
/**
* This takes the way and works out what kind of map feature it is and makes
* the relevant call to the mapper callback.
@@ -157,13 +201,22 @@ public class StyledConverter implements OsmConverter {
if (way.getPoints().size() 2)
return;
- preConvertRules(way);
+ GType foundType = null;
+ if(way.getTag(mkgmap:gtype) != null) {
+ if(polygon.equals(way.getTag(mkgmap:kind)))
+foundType = makeGTypeFromTags(way, GType.POLYGON);
+ else
+foundType = makeGTypeFromTags(way, GType.POLYLINE);
+ }
+ else {
+ preConvertRules(way);
- GType foundType = wayRules.resolveType(way);
- if (foundType == null)
- return;
+ foundType = wayRules.resolveType(way);
+ if (foundType == null)
+return;
- postConvertRules(way, foundType);
+ postConvertRules(way, foundType);
+ }
if (foundType.getFeatureKind() == GType.POLYLINE) {
if(foundType.isRoad())
@@ -182,13 +235,20 @@ public class StyledConverter implements OsmConverter {
* @param node The node to convert.
*/
public void convertNode(Node node) {
- preConvertRules(node);
- GType foundType = nodeRules.resolveType(node);
- if (foundType == null)
- return;
+ GType foundType = null;
+ if(node.getTag(mkgmap:gtype) != null) {
+ foundType = makeGTypeFromTags(node, GType.POINT);
+ }
+ else {
+ preConvertRules(node);
+
+ foundType = nodeRules.resolveType(node);
+ if (foundType == null)
+return;
- postConvertRules(node, foundType);
+ postConvertRules(node, foundType);
+ }
addPoint(node, foundType);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - styling for the power user
v2
now supports ~[0x??] syntax within name to specify highway shields
to reduce the number of tags required, you can now specify all the
values in the mkgmap:gtype tag like this example:
mkgmap:gtype=0x20,19,,1,2
type = 0x20
minres = 19
maxres not specified
roadclass = 1
roadspeed = 2
The one tag per value scheme is still supported (for the moment at
least)
--
Are you a heavy duty styler? If so, read on:
I notice that quite a lot of postings on the list are from people who
are having problems with complex style files. This little patch won't
(directly) solve those problems but it does provide a useful capability
that could be part of a solution for those people who have complex
styling requirements and are willing to do some coding.
What the patch does is allow elements (nodes, ways) to specify their
garmin type (and a few other things) explicitly using these tags:
mkgmap:gtype the element's type (integer constant)
mkgmap:kind one of node, polyline, polygon (only polygon is used
at this time to differentiate polygons from lines).
mkgmap:minres the element's minimum resolution (needed to make element
visible)
mkgmap:maxres the element's maximum resolution (not required)
mkgmap:roadclass the element's road class (needed for roads)
mkgmap:roadspeed the element's road speed (needed for roads)
If the mkgmap:gtype tag is present, the element will not be passed
through the normal style file process at all.
So how do these tags get added to the OSM data? Well, you could just
add them with an editor but that would get boring pretty quickly so
what I would expect to see is some kind of external filter program that
reads the OSM file and outputs a new OSM file with the appropriate tags
added.
That filter program could be written in any language that has some XML
processing support.
Current issues to be sorted out are handling of the highway shields
(not currently implemented) and also this feature is not compatible with
the cycleway faking code.
All feedback welcome.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 2a549f8..eeab3fc 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -25,6 +25,8 @@ import java.util.Map;
import java.util.Properties;
import java.util.Set;
+import java.util.regex.Pattern;
+
import uk.me.parabola.imgfmt.app.Area;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.imgfmt.app.CoordNode;
@@ -53,6 +55,8 @@ import uk.me.parabola.mkgmap.reader.osm.Rule;
import uk.me.parabola.mkgmap.reader.osm.Style;
import uk.me.parabola.mkgmap.reader.osm.Way;
+import uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource;
+
/**
* Convert from OSM to the mkgmap intermediate format using a style.
* A style is a collection of files that describe the mappings to be used
@@ -144,6 +148,86 @@ public class StyledConverter implements OsmConverter {
lineAdder = overlayAdder;
}
+ private static Pattern commaPattern = Pattern.compile(,);
+
+ public GType makeGTypeFromTags(Element element, int kind) {
+ String[] vals = commaPattern.split(element.getTag(mkgmap:gtype));
+ String s;
+
+ element.setName(PolishMapDataSource.unescape(element.getTag(name)));
+
+ for(int i = 0; i vals.length; ++i)
+ vals[i] = vals[i].trim();
+
+ GType gt = new GType(kind, vals[0]);
+
+ if(vals.length = 2 vals[1].length() 0)
+ s = vals[1];
+ else {
+ s = element.getTag(mkgmap:minres);
+ if(s != null)
+s = s.trim();
+ }
+ if(s != null) {
+ try {
+gt.setMinResolution(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error(Bad value for minres: + s);
+ }
+ }
+
+ if(vals.length = 3 vals[2].length() 0)
+ s = vals[2];
+ else {
+ s = element.getTag(mkgmap:maxres);
+ if(s != null)
+s = s.trim();
+ }
+ if(s != null) {
+ try {
+gt.setMaxResolution(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error(Bad value for maxres tag: + s);
+ }
+ }
+
+ if(vals.length = 4 vals[3].length() 0)
+ s = vals[3];
+ else {
+ s = element.getTag(mkgmap:roadclass);
+ if(s != null)
+s = s.trim();
+ }
+ if(s != null) {
+ try {
+gt.setRoadClass(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error(Bad value for roadclass: + s);
+ }
+ }
+
+ if(vals.length = 5 vals[4].length() 0)
+ s = vals[4];
+ else {
+ s = element.getTag(mkgmap:roadspeed);
+ if(s != null)
+s = s.trim();
+ }
+ if(s != null) {
+ try {
+gt.setRoadClass(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error(Bad value for roadspeed: + s);
+ }
+ }
+
+ return gt;
+ }
+
/**
* This takes the way and works out what kind of map feature it is and makes
* the relevant call to the mapper callback.
@@ -157,13 +241,22 @@ public class StyledConverter
[mkgmap-dev] [PATCH v3] - styling for the power user
v3
Now only has 1 tag (mkgmap:gtype) to specify everything.
tag has the format 'kind,code,minres,maxres,roadclass,roadspeed'
Where kind is 1 for node, 2 for polyline and 3 for polygon.
kind, code and minres are all required to be present, the other values
can be ommitted.
Note, this format has changed since v2.
v2
now supports ~[0x??] syntax within name to specify highway shields
to reduce the number of tags required, you can now specify all the
values in the mkgmap:gtype tag like this example:
mkgmap:gtype=0x20,19,,1,2
type = 0x20
minres = 19
maxres not specified
roadclass = 1
roadspeed = 2
The one tag per value scheme is still supported (for the moment at
least)
--
Are you a heavy duty styler? If so, read on:
I notice that quite a lot of postings on the list are from people who
are having problems with complex style files. This little patch won't
(directly) solve those problems but it does provide a useful capability
that could be part of a solution for those people who have complex
styling requirements and are willing to do some coding.
What the patch does is allow elements (nodes, ways) to specify their
garmin type (and a few other things) explicitly using these tags:
mkgmap:gtype the element's type (integer constant)
mkgmap:kind one of node, polyline, polygon (only polygon is used
at this time to differentiate polygons from lines).
mkgmap:minres the element's minimum resolution (needed to make element
visible)
mkgmap:maxres the element's maximum resolution (not required)
mkgmap:roadclass the element's road class (needed for roads)
mkgmap:roadspeed the element's road speed (needed for roads)
If the mkgmap:gtype tag is present, the element will not be passed
through the normal style file process at all.
So how do these tags get added to the OSM data? Well, you could just
add them with an editor but that would get boring pretty quickly so
what I would expect to see is some kind of external filter program that
reads the OSM file and outputs a new OSM file with the appropriate tags
added.
That filter program could be written in any language that has some XML
processing support.
Current issues to be sorted out are handling of the highway shields
(not currently implemented) and also this feature is not compatible with
the cycleway faking code.
All feedback welcome.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 2a549f8..87d 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -25,6 +25,8 @@ import java.util.Map;
import java.util.Properties;
import java.util.Set;
+import java.util.regex.Pattern;
+
import uk.me.parabola.imgfmt.app.Area;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.imgfmt.app.CoordNode;
@@ -53,6 +55,8 @@ import uk.me.parabola.mkgmap.reader.osm.Rule;
import uk.me.parabola.mkgmap.reader.osm.Style;
import uk.me.parabola.mkgmap.reader.osm.Way;
+import uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource;
+
/**
* Convert from OSM to the mkgmap intermediate format using a style.
* A style is a collection of files that describe the mappings to be used
@@ -144,6 +148,85 @@ public class StyledConverter implements OsmConverter {
lineAdder = overlayAdder;
}
+ private static Pattern commaPattern = Pattern.compile(,);
+
+ public GType makeGTypeFromTags(Element element) {
+ String[] vals = commaPattern.split(element.getTag(mkgmap:gtype));
+
+ if(vals.length 3) {
+ log.error(OSM element + element.getId() + has bad mkgmap:gtype value (should be 'kind,code,minres,[maxres],[roadclass],[roadspeed]));
+ log.error( where kind is + GType.POINT + =point, + GType.POLYLINE + =polyline, + GType.POLYGON + =polygon);
+ return null;
+ }
+
+ element.setName(PolishMapDataSource.unescape(element.getTag(name)));
+
+ for(int i = 0; i vals.length; ++i)
+ vals[i] = vals[i].trim();
+
+ int kind = 0;
+ try {
+ kind = Integer.decode(vals[0]);
+ }
+ catch (NumberFormatException nfe) {
+ log.error(OSM element + element.getId() + has bad value for kind: + vals[0]);
+ return null;
+ }
+
+ if(kind != GType.POINT
+ kind != GType.POLYLINE
+ kind != GType.POLYGON) {
+ log.error(OSM element + element.getId() + has bad value for kind, is + kind + but should be + GType.POINT + , + GType.POLYLINE + or + GType.POLYGON);
+ return null;
+ }
+
+ try {
+ Integer.decode(vals[1]);
+ }
+ catch (NumberFormatException nfe) {
+ log.error(OSM element + element.getId() + has bad value for type: + vals[1]);
+ return null;
+ }
+
+ GType gt = new GType(kind, vals[1]);
+
+ try {
+ gt.setMinResolution(Integer.decode(vals[2]));
+ }
+ catch (NumberFormatException nfe) {
+ log.error(OSM element + element.getId() + has bad value for minres: + vals[2]);
+ }
+
+ if(vals.length = 4
Re: [mkgmap-dev] [PATCH v2] - styling for the power user
Hi Garvan, Thanks for the feedback. I tested this patch today, and it worked as advertised. Thanks for your work. Good. I have a suggestion. Would it be better to use tag k=mkgmap:gtype v=0x06,21,,1,2/ instead of tag k=mkgmap:gtype=0x06,21,,1,2/ I know nothing about osm format, other that what I observed, but the latter syntax looks the more obvious to me. If you try this (as I did until in my first try), you will get a NullPointerException. Yes, the first syntax is correct, my blurb used the wrong syntax. I think the long format , with seperate tags, is redundant. It's most likely that people using this syntax will be using a preprocessor of some kind, and I doubt if many preprocessors were written between version 1 and version 2 of your patch. I agree, I have now issued v3 which now only has the one tag 'mkgmap:gtype'. The kind (node, line, area) is now specified as the first value in the list. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - Add support for marine (aka extended) types
v2
Space optimisation - no longer outputs per-subdivision 13-byte record if
the map contains no elements that have an extended type.
---
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended
types that are used on marine maps.
Extended types are specified as a 6 digit hex number. The first two
digits are always 01. An example type is 0x010200 (point type Buoy).
Points, lines and polygons can all be given extended types.
The cGPSMapper user manual lists all of the types.
Note that routable ways cannot have an extended type. If you try to
give a road an extended type, it will converted into a line.
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.
It now works well enough to warrant testing on more map data but I
am expecting that there will be problems given the extent of the patch
and the nature of what it's doing.
Please test if you can and report success/failure/etc.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java b/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
index c99e807..eb5d520 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
@@ -32,6 +32,7 @@ class LinePreparer {
private final Polyline polyline;
private boolean extraBit;
+ private boolean extTypeLine;
private boolean xSameSign;
private boolean xSignNegative; // Set if all negative
@@ -55,6 +56,8 @@ class LinePreparer {
extraBit = true;
}
+ extTypeLine = line.hasExtendedType();
+
polyline = line;
calcLatLong();
calcDeltas();
@@ -105,6 +108,10 @@ class LinePreparer {
log.debug(y same is, ySameSign, sign is, ySignNegative);
}
+ if(extTypeLine) {
+ bw.put1(false); // no extra bits required
+ }
+
// first extra bit always appears to be false
// refers to the start point?
if (extraBit)
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java b/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
index 9a3c017..07933cd 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
@@ -19,9 +19,14 @@ package uk.me.parabola.imgfmt.app.trergn;
import uk.me.parabola.imgfmt.app.Label;
import uk.me.parabola.imgfmt.app.ImgFileWriter;
+import uk.me.parabola.mkgmap.general.MapElement;
+
import java.util.ArrayList;
import java.util.List;
+import java.io.OutputStream;
+import java.io.IOException;
+
/**
* An object that appears in a map. One of point, polyline, polygon or indexed
* point.
@@ -57,6 +62,8 @@ public abstract class MapObject {
*/
public abstract void write(ImgFileWriter file);
+ public abstract void write(OutputStream stream) throws IOException;
+
int getDeltaLat() {
return deltaLat;
}
@@ -83,6 +90,10 @@ public abstract class MapObject {
this.type = type;
}
+ public boolean hasExtendedType() {
+ return MapElement.hasExtendedType(type);
+ }
+
/**
* Set an ordinary unshifted latitude. It will be calculated
* relative to the subdivision.
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/Overview.java b/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
index 2f164b5..29f949d 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
@@ -33,6 +33,7 @@ public abstract class Overview implements ComparableOverview {
public static final int SHAPE_KIND = 3;
private final int kind; // The kind of overview; point, line etc.
+ private final char extType;
private final char type;
private final char subType;
private final int minResolution;
@@ -43,6 +44,7 @@ public abstract class Overview implements ComparableOverview {
protected Overview(int kind, int fullType, int minres) {
this.kind = kind;
+ this.extType = (char)((fullType 16) 0xff);
this.type = (char) (fullType 8 0xff);
this.subType = (char) (fullType 0xff);
this.minResolution = minres;
@@ -54,10 +56,18 @@ public abstract class Overview implements ComparableOverview {
}
public void write(ImgFileWriter file) {
- file.put((byte) (type 0xff));
- file.put((byte) maxLevel);
- if (size 2)
- file.put((byte) (subType 0xff));
+ if(extType != 0) {
+ file.put((byte)type);
+ file.put((byte)maxLevel);
+ file.put((byte)subType);
+ file.put((byte)0);
+ }
+ else {
+ file.put((byte) (type 0xff));
+ file.put((byte) maxLevel);
+ if (size 2)
+file.put((byte) (subType 0xff));
+ }
}
/**
@@ -83,7 +93,10 @@ public abstract class Overview implements ComparableOverview {
return false;
Overview ov = (Overview) obj;
- return ov.kind
Re: [mkgmap-dev] Routing with the default style
Hello Nop, I am just having my first look at creating a routable map. It appears that the default style completely disregards the access tags access=no, vehicle=no, motorvehicle=no and motorcar=no. Naturally I'd like to exclude these from routing, but there seem to be no rules evaluating them in the default style. Is this really the case or are those tags somehow hardcoded in mkgmap? The tags vehicle and motorvehicle are not recognised so you will need to add style rules to convert them to one of the access tags that are recognised which are: access (applies to everything) bicycle foot hgv motorcar motorcycle (same as motorcar) psv taxi emergency delivery goods (same as delivery) 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 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
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
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] 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] 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 {
MapCoord, Integer arcCounts = new IdentityHashMapCoord, Integer();
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()) {
ListCoord 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]
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
[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 ComparableCoord {
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 StyledConverter implements OsmConverter {
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
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
[mkgmap-dev] [PATCH v3] - min arc length fixes
v3
This patch is getting serious!
To reduce the number of short arcs that are being generated at tile
boundaries, this now clips the ways before the short arc removal is
done. However, it isn't a perfect solution because some map data is
very hard to deal with:
a - If a way crosses a tile boundary right in the corner such that both
ends are clipped and the resulting sub-way is less than 5m long, it
will fail to fix that. A possible workaround could be to introduce
extra points to elongate the arc.
b - a much more common problem is where a way forks very close to a
tile boundary and more than one of the connected ways cross the
boundary so you end up with several boundary nodes that should be
merged to remove the short arc(s) but they can't be moved as they are
boundary nodes! I believe that this could be fixed by not merging the
forking node but, instead, moving it away from the boundary such that
the ways connected to it that do cross the boundary are not less than
5m long! Alternatively, adding extra points to elongate the
forking arcs could be done.
With this patch, I processed a 14 tile map of the Netherlands and it
produced 21 of these short arc errors (all due to forks close to the
tile boundaries). I then tested the routing at 5 of these positions
(using mapsource) and only 1 of the 5 showed any sign of breakage, the
other 4 all routed happily in all directions. The one that was broken
was a junction of three ways and one pair of the ways had no
connectivity but the others were ok.
On the upside, the patch removed 147 short arcs introduced by the
clipping.
So more work is required here to fix the corner cases (ha ha) but please
test this patch anyway as I expect it to have problems due to the big
change it has introduced.
As usual, all feedback is appreciated.
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 ComparableCoord {
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
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Hi Valentijn, Thanks for the feedback. I have now posted a new patch that should fix the majority of the short arcs introduced by the clipping. It's not perfect but (I hope) a step in the right direction. My own testing shows that the presence of a short arc does not guarantee that the routing will be borken at that point but it can be. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
