October 2013 - mkgmap-dev - The mkgmap lists

Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?
by Anna Leuchter 29 Oct '13

29 Oct '13

Hi Henning, 1. >Option could be: --add-poi-to-routes="100,1000,10000" Does this mean that every 100 meters + every 100meters + every 10000 meters of the route a mark would be set? So at 1000m there would be 2 marks? One for 100m + one for 1000m? This imo wouldn't make sense for waymarks or? 2. if way is part of multiple routes in this case, like actually with the "--add-poi-to-lines" option, the created marks also might created at the same distances/place and than overlaying each other. Hardley affected will be only those routes which starts at the same point and following partially the same way. Anyway that can happens to in the other cases if routes only share some intermediate part. In that case the those overlaying marks must be shifted a bit, so that all are visisble. regards Gert

3 2

Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?
by Anna Leuchter 29 Oct '13

29 Oct '13

Hi Henning, >Typical Garmin software shows all POI, if you click next to them. Yes, i know. But mayor intention of that waymark signs is to have a better visualization of hiking routes on the map. (Like we have it in paper hiking maps) If the marks overlaps this visualization gets lost for the overlayed signs. >I don't think that shifting is a good solution, because the distance >depends on zoom level and on the number of routes. Yes, i'm aware of that problems and think that it's difficult finding a perfect solution for all situations(zoom, route count...) Regarding zoomlevel it will always be a compromise: Having a parameter with whom you can determine the shift which will be used in that case, could help you to find the compromise which fits best your needs. Regarding the count of routes which shares the same way: Maybe here the count of routes which will be shifted(if needed), can be restricted to e.g. the first 3 matching routes or handeld via parameter, too. With both parameter imo you have not perfect but good tools to find a good compromise in creation of that points. For more perfection the angle of turns in the way could beused to determine if a mark is needed or not. Straight ways needs less marks than curvy ways. But i don't have any idea how much effort it is to implement such things. regards Gert

1 0

Commit: r2794: merge from mergeroads branch to prepare for new frigRoundabouts method
by svn commit 28 Oct '13

28 Oct '13

Version mkgmap-r2794 was committed by gerd on Mon, 28 Oct 2013 merge from mergeroads branch to prepare for new frigRoundabouts method

2 1

final fields in Coord
by GerdP 28 Oct '13

28 Oct '13

Hi programmers, I'd like to add a method like Coord.moveTo(int lat, int long) to set new values in an existing Coord. To do that I have to remove the final attribute from the latitude and longitude fields. Is that known to cause problems? If not, the method could also be used to simplify removeShortArcs (we could drop the IdentityHashMap replacements and other stuff around that) Gerd -- View this message in context: http://gis.19327.n5.nabble.com/final-fields-in-Coord-tp5783182.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 4

Commit: r2788: Revert previous change to styled converter and modify the test code instead.
by svn commit 28 Oct '13

28 Oct '13

Version 2788 was committed by steve on Thu, 24 Oct 2013 Revert previous change to styled converter and modify the test code instead. Now create a new converter for each operation. I don't think calling end() more than once is a good idea even if it can be made to work.

3 2

Commit: r2793: Add back modifiedRoads=null, removed by accident.
by svn commit 28 Oct '13

28 Oct '13

Version mkgmap-r2793 was committed by steve on Mon, 28 Oct 2013 Add back modifiedRoads=null, removed by accident.

1 0

Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?
by Anna Leuchter 27 Oct '13

27 Oct '13

Hi WanMil, Hello Henning, thanks. i had been afraid that it does not work. Wouldn't it be enough to add something like a mkgmap:line2poilength to the poi which than can be used later in style.? Ok, probably is the idea of Henning the better solution. regards Gert

3 2

Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?
by Anna Leuchter 27 Oct '13

27 Oct '13

Hi, i try to create a map including hiking trail markings usin r2748. So far i succeded using --add-poi-to-lines option and making the needed setting within relation and points style files. For every way part of a hiking route a poi is created. But to prevent map to be overcrowded by those trail marking pois, i would like to create those kind of POIs only for way parts with a minimum length. Something like "highway=* & length() >100 {set mkgmap:line2poi=false}" in the lines file, doesn't seems to work. (As far as i read meanwhile, points are processed before lines, so this can't work.) Is there a way with actuall code version to achieve it? best regards Gert

3 2

bearing/heading influence on routing
by Gerd Petermann 26 Oct '13

26 Oct '13

Hi Programmers, first see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/014145.html I see two different interpretations: 1) mkgmap encodes the initial heading (A-B) and the final heading (C-D), always using one byte "curve data " for the final heading. 2) display tool displays the initial heading as "direction", and one or two bytes curve data My theory is that the two byte curve data is used when we have a road where initial heading AND final heading are (very) different from the direction (A-D). Question is: what value is stored in the different fields? Does anybody already know more details? If not, what is the best way to find out? I could either try to write a program that displays the data in real maps, or I could simply use try and error in the mkgmap write routine to find out how MapSource reacts one different codings. I played a little bit with the latter and I see differences in the calculated times. Gerd

3 4

Request to rollback at least rev 2747 - or give the access part a complete rework, as of right now it's broken...
by Felix Hartmann 26 Oct '13

26 Oct '13

addaccess / setaccess = either it's not working, or I don't understand it! - merge-roads branch So, today for the first time since a couple of weeks I had full day time to work through mkgmap changes, and I must say I don't understand the addaccess / setaccess concept at all. mkgmap:access is far better, the intention of making styles-files easier by addaccess/setaccess definitely turned wrong, or I don't understand it... How can I mass replace the old rules? Or better, how can I replace this old rule at all? I don't see how this is possible now. e.g. ( mkgmap:access=no | mkgmap:access=private ) & ( mkgmap:bicycle=yes | mkgmap:bicycle=permissive ) {delete mkgmap:access} ? (XXXX | YYYY & ( mkgmap:bicycle=yes | mkgmap:bicycle=permissive ) {????} # I put mkgmap:bicycle here, because it makes much more sense than mkgmap:bike.... (setaccess=no | setaccess=private) & ( mkgmap:bicycle=yes | mkgmap:bicycle=permissive ) {????} ? 1. XXXX : testing for access=no is wrong, because I don't want to test on what has been in the data, but what value I previously set. And no - setting a second key to verify what happend using addaccess setaccess would completly destroy any making it simpler... Therefore I suppose now there is one term, and if I put it in {} then it means an action, but if it's not, then it means it is a test. Very very bad idea too. 2. YYYY: well as long as "setaccess private" works - and you can search for it by setaccess=private, it's still the same problematic case as above. 3. ???? {delete setaccess} what about if it was using add? It makes no sense at all. And as I often wrote before, there is a difference between setaccess=yes and setaccess not existing. 4. As for a complete rework, I still don't see why the old system needed to be changed! There is no new functionality at all, mkgmap didn't get faster but slower, and style-files get much more complicated! If it's about making it possible to merge more roads, then I still don't see it. mgkmap shouldn't look if the tags in the data are the same, but if the outcome as it will be put into the map, is the same. So yes, also for the old notation a highway=primary & bicycle=private should be merged with a highway=primary & bicycle=no, but not with highway=primary & bicycle=yes... I reworked my style to use mkgamp:?? notation, so going back will mean again lot's of hours of work (or alternatively trying to backport all changes since that change), so I would be happy if we keep mkgmap:??, but I think the easiest would be to keep the old notation system, and add a file to the style-file where you can define how e.g. private or destination are handled (yes or no). -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

4 11