[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
Hi Mark, I still don't really understand the advantage. 1. maxres, can we really specify this, I was not aware that this is possible. 2. So the only advantage is that it is shorter to tpye and that preprocessing becomes possible? thanks for clarifying a bit here Felix 2009/8/6 Mark Burton <markb@ordern.com>
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix,
Hi Mark, I still don't really understand the advantage.
What it does is give you the possibility of doing all of the style processing outside of mkgmap. If mkgmap's styling support is sufficient for your needs, use that. If not, you can style your data before it gets processed by mkgmap using some other application. I don't have complex styling needs and can achieve what I want using the mkgmap style files so I am not in a great rush to write a styling application but it could easily be done.
1. maxres, can we really specify this, I was not aware that this is possible.
I don't know if you can specify it in the style syntax but it's in the underlying code.
2. So the only advantage is that it is shorter to tpye and that preprocessing becomes possible?
It just seemed excessive to have separate tags for each of the values when they could just be specified using a single tag. Cheers, Mark
Mark Burton schrieb:
What it does is give you the possibility of doing all of the style processing outside of mkgmap. If mkgmap's styling support is sufficient for your needs, use that. If not, you can style your data before it gets processed by mkgmap using some other application.
Also with normal mkgmap you can doo preprocessing of the osm data. But most people seem to try getting most out of the styles without an extra processing step. Right now, I don't really see, how your approach makes things easier. Can you provide an example, how the map generation would look like with your patch? Gruss Torsten
Hi Torsten,
What it does is give you the possibility of doing all of the style processing outside of mkgmap. If mkgmap's styling support is sufficient for your needs, use that. If not, you can style your data before it gets processed by mkgmap using some other application.
Also with normal mkgmap you can doo preprocessing of the osm data. But most people seem to try getting most out of the styles without an extra processing step.
Yes, that's right and from the emails we see on the list, perhaps people are now trying to do stuff that wasn't really imagined when the mkgmap style engine was designed and are, therefore, running into issues.
Right now, I don't really see, how your approach makes things easier. Can you provide an example, how the map generation would look like with your patch?
The way I see it is: 1 - the mkgmap style engine is good for moderately complex styling. 2 - for more demanding styling, either the mkgmap style engine has to be fixed/enhanced to support whatever new demands people want to make on it, or ... 3 - we can provide some simple hooks whereby you can do the styling with some 3rd-party application (not mkgmap) as a pre-processing step. To be honest, I am surprised that people haven't taken to pre-processing the map data already. So the sequence of steps to make the map could be: 1 - split big map into tiles 2 - pre-process tiles to add style info 3 - generate .img files using mkgmap The pre-processing could be done by a dedicated program (java/c/perl/python/...) or by some form of transformation process (xslt?) or even simple text substitution (awk?) I'm not saying this is trivial to implement but if you really want to do some funky styling then it may be easier to create an external pre-processor than trying to express your requirements using the mkgmap style language. Cheers, Mark
Hi Mark, Am 06.08.2009 um 21:49 schrieb Mark Burton:
The way I see it is:
1 - the mkgmap style engine is good for moderately complex styling.
2 - for more demanding styling, either the mkgmap style engine has to be fixed/enhanced to support whatever new demands people want to make on it, or ...
3 - we can provide some simple hooks whereby you can do the styling with some 3rd-party application (not mkgmap) as a pre-processing step.
thank you for your effort, but I would go with the "the mkgmap style engine has to be fixed/enhanced" approach. Of course you could add preprocessing, but that is already possible now (think mp-files). By proposing preprocessing you just divert "programming power" away from mkgmap - everybody starts his own preprocessor instead of improving mkgmap. This will make "decent mapmaking" for starters even more complicated as it is now. Some thoughts about styling: What we see right now is the move from a "conversion table" to a "macro/programming language". As you say, the style files were never intended to be able to do the things we want them to do now. So what can we do about that? We could "improve" them until they are Touring complete. But I don't think we should. Because then we would only create another programming language with another syntax and all the problems that arise from that. What I propose is to keep the style files, perhaps even *stripping* features from them (action rules, default_name). To implement all those nifty new tricks I'd like to have a plug-in interface in mkgmap to add my own Java routines. That could be plug-in at compile time, no need to make it too complicated. It would be a start to sort through all the classes and provide some documented hooks to plug-in your own routines. Then in the style files one could "invoke" the plug-ins that one would like to use. An excerpt of the lines style file might look like this: highway=secondary [0x04 namefinder=default_highway filter=DouglasPeucker(keep_junctions_fixed=true) routebuilder=default_routable(road_class=2, road_speed=3) resolution 20] natural=coastline [0x15 namefinder=fixed(name='coastline') filter=DouglasPeucker resolution 12] By selecting the namefinder, the filter, the routebuilder etc. one has complete control about how the data is processed. The routines could accept parameters in parantheses behind their name for added flexibility. Some (standard) routines are supplied, but it should be easy to add your own. By having a defined interface it gets easier to interchange improvements - currently the patches need often quite some work to get them to compile all together. By partitioning the work between routines each one can be relatively simple. So for example one namefinder routine could just be responsible to find a name for a highway. Another one could be responsible to generate a name for a POI for a building that has address information. This will also mostly eliminate the need for action rules. As I think the action rules code is - say - quite complex, this might remove one area of "oddities". By keeping the style files and out-sourcing the complex programming into Java plug-in-routines the style programming stays simple for the users that only change the style files themselves, but power-users can still program everything they like in plain Java. As the plug-in routines can be selected from the style files, the regular-users can also benefit from the work of the power-users, even if they can't program in Java themselves. Any thoughts about that? Regards Thilo
Hi Thilo,
thank you for your effort, but I would go with the "the mkgmap style engine has to be fixed/enhanced" approach. Of course you could add preprocessing, but that is already possible now (think mp-files). By proposing preprocessing you just divert "programming power" away from mkgmap - everybody starts his own preprocessor instead of improving mkgmap. This will make "decent mapmaking" for starters even more complicated as it is now.
I disagree. The patch simply provides a means for those people who have complex styling requirements to "roll their own" styling engine so they are not obliged to use whatever is built into mkgmap. The presence of the patch will not affect the development of the mkgmap styling system but by providing people with an alternative mechanism, it will encourage innovation and new thinking. One could argue that mkgmap would be better off having no styling function at all and it should focus on the core task of converting an input dataset (styled OSM) into map files (.img, etc.)
Some thoughts about styling: What we see right now is the move from a "conversion table" to a "macro/programming language". As you say, the style files were never intended to be able to do the things we want them to do now. So what can we do about that?
We could "improve" them until they are Touring complete. But I don't think we should. Because then we would only create another programming language with another syntax and all the problems that arise from that. What I propose is to keep the style files, perhaps even *stripping* features from them (action rules, default_name). To implement all those nifty new tricks I'd like to have a plug-in interface in mkgmap to add my own Java routines. That could be plug-in at compile time, no need to make it too complicated. It would be a start to sort through all the classes and provide some documented hooks to plug-in your own routines. Then in the style files one could "invoke" the plug-ins that one would like to use.
An excerpt of the lines style file might look like this:
highway=secondary [0x04 namefinder=default_highway filter=DouglasPeucker(keep_junctions_fixed=true) routebuilder=default_routable(road_class=2, road_speed=3) resolution 20] natural=coastline [0x15 namefinder=fixed(name='coastline') filter=DouglasPeucker resolution 12]
By selecting the namefinder, the filter, the routebuilder etc. one has complete control about how the data is processed. The routines could accept parameters in parantheses behind their name for added flexibility. Some (standard) routines are supplied, but it should be easy to add your own. By having a defined interface it gets easier to interchange improvements - currently the patches need often quite some work to get them to compile all together.
By partitioning the work between routines each one can be relatively simple. So for example one namefinder routine could just be responsible to find a name for a highway. Another one could be responsible to generate a name for a POI for a building that has address information.
This will also mostly eliminate the need for action rules. As I think the action rules code is - say - quite complex, this might remove one area of "oddities".
By keeping the style files and out-sourcing the complex programming into Java plug-in-routines the style programming stays simple for the users that only change the style files themselves, but power-users can still program everything they like in plain Java. As the plug-in routines can be selected from the style files, the regular-users can also benefit from the work of the power-users, even if they can't program in Java themselves.
Any thoughts about that?
Well it's not what I would do. Cheers, Mark
Hi Mark, Am 06.08.2009 um 23:52 schrieb Mark Burton:
I disagree.
The patch simply provides a means for those people who have complex styling requirements to "roll their own" styling engine so they are not obliged to use whatever is built into mkgmap. The presence of the patch will not affect the development of the mkgmap styling system but by providing people with an alternative mechanism, it will encourage innovation and new thinking.
One could argue that mkgmap would be better off having no styling function at all and it should focus on the core task of converting an input dataset (styled OSM) into map files (.img, etc.)
The problem here is that in the end you cannot separate the styling from the map conversion process. When I started using mkgmap I also used preprocessing. But then I found that my preprocessor had to duplicate a lot of the functionality of mkgmap to "do it right". For example finding all the ways that belong to a relation. It was much easier to patch mkgmap to get the same results, because all that information is already accessible there. But of course one could argue if this "convenience" is a reason in itself not to separate styling and map conversion.
Some thoughts about styling: ...
Well it's not what I would do.
Ok. Regards Thilo
Hi Mark, Thilo, list,
The problem here is that in the end you cannot separate the styling from the map conversion process. When I started using mkgmap I also used preprocessing. But then I found that my preprocessor had to duplicate a lot of the functionality of mkgmap to "do it right". For example finding all the ways that belong to a relation. It was much easier to patch mkgmap to get the same results, because all that information is already accessible there. But of course one could argue if this "convenience" is a reason in itself not to separate styling and map conversion.
For what it is worth, I agree with Thilo here. The Unix philosophy of combining simple tools is preferrable when it works, but OSM is huge, and all of the graph has to be kept in memory during the processing. Command pipelines and scripts work nicely when working with simple text files, when linear access to the data is enough. But I wouldn't want to load and dump large volumes of data even more times than currently (bzip2 decompression, splitter, mkgmap). The mkgmap:* would be great for quick prototyping or for those who prefer preprocessing or prefer to work with their favourite scripting language instead of Java. This brings about a question of dependences and coordination. If people start writing preprocessor scripts in their favourite languages, suddenly you might need a host of runtime environments (Perl, Python, Ruby, ...) with all sorts of libraries, in addition to the current Java dependences. Can we have the best of both worlds? The best preprocessing transformations would eventually be ported to mkgmap plugins that would be linked to mkgmap style rules. Examples of such plugins include plugins for naming objects and for filtering or duplicating objects (lines or points, e.g., refactoring the current code of duplicating cycleways or transforming areas into POIs). We can start small; I'd be happy with the naming plugin framework for now. Marko
Hi Marko,
Hi Mark, Thilo, list,
The problem here is that in the end you cannot separate the styling from the map conversion process. When I started using mkgmap I also used preprocessing. But then I found that my preprocessor had to duplicate a lot of the functionality of mkgmap to "do it right". For example finding all the ways that belong to a relation. It was much easier to patch mkgmap to get the same results, because all that information is already accessible there. But of course one could argue if this "convenience" is a reason in itself not to separate styling and map conversion.
For what it is worth, I agree with Thilo here. The Unix philosophy of combining simple tools is preferrable when it works, but OSM is huge, and all of the graph has to be kept in memory during the processing. Command pipelines and scripts work nicely when working with simple text files, when linear access to the data is enough. But I wouldn't want to load and dump large volumes of data even more times than currently (bzip2 decompression, splitter, mkgmap).
I agree, performance could be an issue although not a show-stopper due to the cheapness of multi-core CPUs and RAM.
The mkgmap:* would be great for quick prototyping or for those who prefer preprocessing or prefer to work with their favourite scripting language instead of Java. This brings about a question of dependences and coordination. If people start writing preprocessor scripts in their favourite languages, suddenly you might need a host of runtime environments (Perl, Python, Ruby, ...) with all sorts of libraries, in addition to the current Java dependences.
Exactly, give people a choice. As to the runtime requirements, what is required to be installed depends on whatever technology is used to implement the styling filter but unless it's seriously esoteric, you wouldn't expect it to be a problem. These days, most of the common languages are available for all of the major platforms at the click of a button.
Can we have the best of both worlds? The best preprocessing transformations would eventually be ported to mkgmap plugins that would be linked to mkgmap style rules. Examples of such plugins include plugins for naming objects and for filtering or duplicating objects (lines or points, e.g., refactoring the current code of duplicating cycleways or transforming areas into POIs). We can start small; I'd be happy with the naming plugin framework for now.
Of course. I am not for one moment suggesting that development of the mkgmap styling engine (MSE) should be limited. As you suggest, (with the patch) it would be possible to prototype and develop styling schemes outside of mkgmap. If successful, those schemes could then be incorporated into the MSE. Remember, the zero-style patch only disables the MSE for elements that have a mkgmap:gtype tag, so all other elements that don't have that tag will still be styled by the MSE. This allows "selective styling" by an external program that could be useful for testing styling regimes without having to implement them in a prototype form within mkgmap. So, unless there are compelling reasons not to incorporate the patch, I will commit it before too long as I believe in the long-run it will prove to be useful. Cheers, Mark
Marko Mäkelä wrote:
Can we have the best of both worlds?
I think we already have both possibilities. We can use any preprocessing we like and then use a selfmade style which uses fantasy tags. Or make a preprocessor which outputs the well-known tags. This works best if everything is kept in the style system and next to nothing is hardcoded in the mkgmap code, because changing a style file is not a big deal, but fiddling with the java code isn't for everyone. For the newcomer user mkgmap always should produce a sensible map out-of-the-box.
Hi
"macro/programming language". As you say, the style files were never intended to be able to do the things we want them to do now. So what can we do about that?
The style system was designed to do the little things that were hardwired into the code directly from the style itself. It also pretty much pre-dated routing so that the fact that you can have two separate names for a road (say a name and a reference when both exist) cannot be implemented. I would like to know what people want to do that is not possible. Is anyone other than Felix doing something that is difficult with the current system? Then I need to work out if the main problem is that actions are, in effect, run in a random order. Would guaranteeing that actions were run in the order that they occurred in the file help? It would certainly make it possible to work out what a set of rules did. I probably shouldn't have allowed stand alone actions on rules without a type, without also making them ordered. I think it can be done without a large performance overhead (at least if you make minimal use of actions), but if it is not going to help any power stylers then it is not worth doing and we should do something else instead.
implement all those nifty new tricks I'd like to have a plug-in interface in mkgmap to add my own Java routines. That could be plug-in at compile time, no need to make it too complicated. It would be a start to sort through all the classes and provide some documented hooks to plug-in your own routines. Then in the style files one could "invoke" the plug-ins that one would like to use.
I remember thinking that a style could have a classes directory probably for type resolvers although I forget exactly why. It would certainly be possible, although I would like to see if can make the current system work better for people. ..Steve
Moin, Steve Ratcliffe schrieb:
I would like to know what people want to do that is not possible. Is anyone other than Felix doing something that is difficult with the current system?
I haven't tried your latest modification, which allows to change the items from the condition match, but with previous versions I tried the following processing: 1. I wanted to to set all surface values to either paved or unpaved. So on top of my lines-file I entered rules like surface=sand {set surface=unpaved} surface=concrete {set surface=paved} ... Later I changed the rules to highway=* & surface=sand {set surface=unpaved} highway=* & surface=concrete {set surface=paved} Right now I do not know, whether the later change was necessary at all, and whether the rules are working as expected. But I haven't noticed any errors. 2. I wanted to evaluate the access-tags, replace them with my own flags, and delete the access-tags: highway=* & bicycle=yes {set mkgmap_routing=yes; set bicycle=''} highway=* & bicycle=designated {set mkgmap_routing=yes; set bicycle=''} highway=* & bicycle=* {set mkgmap_routing=false; set bicycle=''} highway=footway & mkgmap_routing!=* {set mkgmap_routing=false} highway=track & mkgmap_routing!=* {set mkgmap_routing=false} ... I did not manage to get such a scheme working. As a workaround I create a single rule for each access condition and each highway type, so that the action part was done together with the conversion. Although it does work in the end, it needs much larger style files and is much harder to maintain. And since you are asking, what I would like to do with styles: For lines and polygons I would like to have the following action rules: - create_start_point -> creates an additional point at the position of the first point of the OSM way with the same tags as the OSM way. This point shall afterwards be processed like all the other OSM points. - create_centre_point -> the same as above but at the position of the geometric centre of the OSM way - create_last_point -> the same as above but at the position of the last point of the OSM way With such rules, you could control via the style file, which areas get an additional POI/icon and which not. Or you could mark some highways with additional icons, e.g. speed_limits, or graphic symbols for special hiking routes. Regarding mkgmap and styles: I would like to see as many features as possible controlled via the style and not hardcoded in mkgmap. For my taste most of the latest additions to the mkgmap parameters would be better realised as action rules in the style rather than general program parameters (e.g. make_cycleways, road-name-pois, add-pois-to-areas), so that the user has more control, when the action shall be applied and when not. Gruss Torsten
Hi Steve, combining tags from multiple relations and the way tags itself should be possible. example some motorways portions share multiple route refs. this can be tagged as ref=ref1;ref2 but since relations are available most add 2 relations and add the same way to both. currently I can't think of a style to accomplish merging the 2 relation refs to a list -- apo On Aug 7, 2009, at 6:17 AM, Steve Ratcliffe wrote:
Hi
"macro/programming language". As you say, the style files were never intended to be able to do the things we want them to do now. So what can we do about that?
The style system was designed to do the little things that were hardwired into the code directly from the style itself. It also pretty much pre-dated routing so that the fact that you can have two separate names for a road (say a name and a reference when both exist) cannot be implemented.
I would like to know what people want to do that is not possible. Is anyone other than Felix doing something that is difficult with the current system?
Then I need to work out if the main problem is that actions are, in effect, run in a random order. Would guaranteeing that actions were run in the order that they occurred in the file help? It would certainly make it possible to work out what a set of rules did. I probably shouldn't have allowed stand alone actions on rules without a type, without also making them ordered.
I think it can be done without a large performance overhead (at least if you make minimal use of actions), but if it is not going to help any power stylers then it is not worth doing and we should do something else instead.
implement all those nifty new tricks I'd like to have a plug-in interface in mkgmap to add my own Java routines. That could be plug- in at compile time, no need to make it too complicated. It would be a start to sort through all the classes and provide some documented hooks to plug-in your own routines. Then in the style files one could "invoke" the plug-ins that one would like to use.
I remember thinking that a style could have a classes directory probably for type resolvers although I forget exactly why. It would certainly be possible, although I would like to see if can make the current system work better for people.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
2009/8/7 Steve Ratcliffe <steve@parabola.me.uk>
Hi
"macro/programming language". As you say, the style files were never intended to be able to do the things we want them to do now. So what can we do about that?
The style system was designed to do the little things that were hardwired into the code directly from the style itself. It also pretty much pre-dated routing so that the fact that you can have two separate names for a road (say a name and a reference when both exist) cannot be implemented.
I would like to know what people want to do that is not possible. Is anyone other than Felix doing something that is difficult with the current system?
Then I need to work out if the main problem is that actions are, in effect, run in a random order. Would guaranteeing that actions were run in the order that they occurred in the file help? It would certainly make it possible to work out what a set of rules did. I probably shouldn't have allowed stand alone actions on rules without a type, without also making them ordered.
To me this would be enough. Best make sure that it is also possible to run several actions against the same road. I think the most difficult is getting the name of a road right, other things are much easier, as there are not many possibilities. Only in case we have the extended types completely covered, it might become a bit more complex, but nothing I can imagine that I couldn't do right now. The other big thing missing for me (other than the extended types) is making corners rounder.... but that has nothing to do with the style-file. As very sharp corners for bicycle/pedestrian impose a too heavy time toll. One thing I have noticed on Garmin Swiss topo maps, is that the calculated length of some ways that curl down mountains is underrated by up to 30%, maybe they do this on purpose to improve the chance of the ways being chosen for autorouting. Off course having the big disadvantage that those roads will not calculate the proper distance anymore. Maybe one could make the autorouting data to believe the road is straight but longer, I don't know whether that is possible.
I think it can be done without a large performance overhead (at least if you make minimal use of actions), but if it is not going to help any power stylers then it is not worth doing and we should do something else instead.
implement all those nifty new tricks I'd like to have a plug-in interface in mkgmap to add my own Java routines. That could be plug-in at compile time, no need to make it too complicated. It would be a start to sort through all the classes and provide some documented hooks to plug-in your own routines. Then in the style files one could "invoke" the plug-ins that one would like to use.
I remember thinking that a style could have a classes directory probably for type resolvers although I forget exactly why. It would certainly be possible, although I would like to see if can make the current system work better for people.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Mark Burton wrote:
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)
I tested this patch today, and it worked as advertised. Thanks for your work. 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. 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. Thanks Garvan
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
participants (9)
-
Apollinaris Schoell -
Felix Hartmann -
Garvan & maew -
Mark Burton -
Marko Mäkelä -
Ralf Kleineisel -
Steve Ratcliffe -
Thilo Hannemann -
Torsten Leistikow