Re: [mkgmap-dev] [proposal] Display the destination
Moin, Chris66 schrieb am 05.10.2012 10:22: When using the Garmin Types 0x08 and 0x09 (Ramp), Garmin is evaluating the first way behind all the _link ways. ... So the idea is a new mkgmap option --process-destination which does following pre-processing: For all _link ways which have a destination-Tag copy the tag to the following non-link way (motorway or trunk). I think, a better solution would be the splitting of the concerned link ways in two parts. The first part could get the types 0x08 or 0x09 assigned and the second part could get the destination tag for the display name. Modifying the following way might have some negative consequences for the display or routing information of this way, when you are not coming from the link. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] side effects add-pois-to-lines
Greg Troxel schrieb am 27.11.2011 17:12:
I still don't understand why it would make sense to make a POI
per node. What I'm getting at is that perhaps the line2poi code should
somehow default to making only one synthetic point POI.
Below is an example from my points-style, where I generate icons for incline
values set to a line, similar to the highway=incline POIs. Perhaps it would be
enough, to generate a single icon for each way marked with incline=*, but by
generating the icons for all nodes of the way, it is better visible, where the
inlcine starts and where it ends.
Gruss
Torsten
highway=incline
[0x4009 resolution 24 continue]
highway=incline_steep
[0x400a resolution 24 continue]
highway=* mkgmap:line2poitype=* mkmap_incline_type!=done incline ~
'^-?[0-9].*' {set mkmap_incline_type=numeric}
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?[2-9][0-9].*' incline ~ '.*%' {set name=20%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?19.*' incline ~ '.*%' {set name=19%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?18.*' incline ~ '.*%' {set name=18%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?17.*' incline ~ '.*%' {set name=17%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?16.*' incline ~ '.*%' {set name=16%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?15.*' incline ~ '.*%' {set name=15%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?14.*' incline ~ '.*%' {set name=14%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?13.*' incline ~ '.*%' {set name=13%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?12.*' incline ~ '.*%' {set name=12%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?11.*' incline ~ '.*%' {set name=11%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?10.*' incline ~ '.*%' {set name=10%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?9.*' incline ~ '.*%' {set name=9%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?8.*' incline ~ '.*%' {set name=8%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?7.*' incline ~ '.*%' {set name=7%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?6.*' incline ~ '.*%' {set name=6%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?5.*' incline ~ '.*%' {set name=5%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?4.*' incline ~ '.*%' {set name=4%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?3.*' incline ~ '.*%' {set name=3%; set ref=; set
mkmap_incline_type=done} [0x4009 resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?[2-9][0-9].*' incline ~ '.*°' {set name=20%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?19.*' incline ~ '.*°' {set name=20%; set ref=; set
mkmap_incline_type=done} [0x400a resolution 24 continue with_actions]
highway=* mkgmap:line2poitype=* mkmap_incline_type=numeric incline ~
'^-?18.*' incline ~ '.*°' {set name=20%; set ref=; set
mkmap_incline_type=done}
Re: [mkgmap-dev] side effects add-pois-to-lines
Moin,
Felix Hartmann schrieb am 17.11.2011 19:35:
There are only very very few cases where I
can see this option having any sense for me, so I would have to use
quite a lot of
mkgmap:line2poi!=true
statements.
Actually you do not need so many statements like this, since you can combine
them and delete the main-tag via an action rule. So e.g. if you know, that you
do not want any natural POIs based on lines, you could add a rule like
natural=* mkgmap:line2poi=true {set natural=}
Surely it would be more straight forward, if could could positively mark the
lines (or areas) in the style for the POI generation, but in the end you can
achieve the same results with both. So I am quite satisfied with the actual
implementation.
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] value (string) handling via style file
Moin, I want to do some modifications of the tag-values via the style file. I know this has been a topic here before, but I can not find the neccessary hints right know. - How can I check the first character of the value in a style file? (I want to detect whether the first character is a minus sign -.) - How can I check the last character of the value in a style file? (incline allows either % or °) - How can I remove the first character of the value in a style file? (-5% - 5%) - How can I check, whether a character is numeric? (in [0..9]) Can anybody help me? Gruss Torsten PS: The definition of the incline tag is really a nightmare for automated evaluation. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] value (string) handling via style file
Moin, Marko Mäkelä schrieb am 03.11.2011 19:37: I hope that this helps. Thanks, with your help I was at least able to filter out the non-numeric values by using incline ~ '^-?[0-9]*.' instead of inlcine=* I did not succeed in removing the minus sign from the out put (since the direction of the ways is not visible in my map, there is no point in having the sign when using the grade of the incline as a label). So I would be glad, if anybody knows, how to use the substring filter. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] add-pois-to-lines
Moin, WanMil schrieb am 31.10.2011 21:35: I have modified the patch by the following things: 1. The relation style is now applied before the POIs are added Today I had the idea of solving the problem the other way around: Add the artificially created POIs as members to the relation. But doing the relation processing as soon as possible is perhaps in general a good idea, since anything can be member of a relation. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] add-pois-to-lines
Moin, I tried the patch and I think the add-pois-to-lines option is quite usefull. Although I have some issues with the actual implementation. 1. Tags originating from the line are correctly transfered to the points (e.g. incline=* on the highway can be used to generate symbols at the highway nodes). But if the tags are originating from a relation and only generated on the way during the relation processing by the apply command, then this tags ar enot transfered to the points. So it is not possible to create POIs at all nodes belonging to ways belonging to a route. 2. I think it should be possible to differentiate whether a single tag belongs really to this node or is create by the add-pois-to-lines processing. For example: We have a line highway=primary and this line contains a node marked with highway=trafic_signals. With the actual implementation the node would only have one highway-Tag, the other on gets lost. Perhaps it would be better, to not only transfer the tags from the line to the nodes, but add a prefix to the keys, e.g. mkgmap:line2poi:highway=primary 3. I think the tag mkgmap:line2poi=true is not required, since all nodes are marked with mkgmap:line2poitype=* anyway. 4. A single node can be member of multiple lines. E.g. a highway crossing can be the inner node of one line and also the start node of another line. Will this create any problems? With my suggestion 2 you could at least differentiate, when the line2poitype is different, but if the crossing is an inner node of two lines, you are still kind of lost. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] add-pois-to-lines
Moin, WanMil schrieb am 30.10.2011 14:10: The relation style is applied after the pois-to-lines. Maybe this could be changed but I don't know about side effects. That is bad news, because using the add-pois-to-line options for marking hiking routes is one of the uses I had in mind. It is either possible to create completely new nodes (this is implemented) or to add the tags from the line to the existing nodes (then you get a merge problem if both line and node contains the same tag with different values). I decided to implement the first solution which is much easier. Ah. That's the better solution and should also solve my issue No.4, where a single node is member in multiple lines. So you will have multiple nodes on the same coordinates: - 1 node with all the original tags from this node - 1 node for each line, with the tags mkgmap:line2poi=true, mkgmap:line2poitype=* and all the tags from this line You report that the information of original node is lost. I don't think so. I can confirm, that the information from the original node is not lost. I feared, that in case of a conflict the information from the line would get lost. But know I understand your implementation better. So beside the relation topic I am happy with your patch, even with this limitation I think it is worthwhile extension of the mkgmap possibilities. Thanks. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] add-pois-to-lines
Moin, Chris66 schrieb am 28.10.2011 17:52: So it works. Can you please provide your mkgmap.jar file? I do not have a development environment for mkgmap at the moment but would like to try out the patch. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] add-pois-to-lines ?
Moin, I really would like to have an add-pois-to-lines feature. Henning Scholland schrieb am 26.10.2011 00:24: This would also be a great feature to show route-signs (hiking, cycling etc.) But it would be overkill, to create such a node for each way. Actually it wouldn't be enough, to create one node for each way, for route signs you would need multiply symbols for each way. A first version could be, to copy the way tags (already inherited from a relation) to each node of the way. A nicer version would be, to leave out some nodes, when they are to close together. Another use might require to mark the first and/or the last node of a way with a specific icon. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Too many pois on multipolygon areas
WanMil schrieb am 27.09.2011 23:28: Do I understand you correct?: The polygons style should be used for polygons created by mp processing but only one POI should be created for the whole multipolygon and not one for each mp created polygon. I think, we are in agreement here: 1. A mp-relation is converted into multiple single polygons to be used by the polygon style processing. and now your suggestion (as I understand it): 2. Additionally a single POI is created for the whole mp-relation, with all the tags from the relation plus a mkgmap:poly2poi=true What I wanted to point out: If you are now creating POIs from the areas, you have to make sure in your style files, that you do not get additional POIs from the polygons created in step one. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Too many pois on multipolygon areas
WanMil schrieb am 27.09.2011 19:27: Maybe it's not be too difficult to fix that. Here is my idea: Just before the style conversion one point for each polygon is added with a copy of all tags plus mkgmap:poly2poi=true. Polygons contained in or created by a multipolygon are excluded but additionaly one point for each multipolygon is added. Now the rules in the points style are applied automatically. I think you also have to change the style file, so that all the polygons created by the mp processing are not used by the style conversion. This should be easy by checking that there is no mkgmap:mp_created tag. I think (in a first step) you need not to care, whether teh created POI is within the mp area or within a hole, because also for normal (concave) polygons right now it is not ensured, that the created POI is within the polygon. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How to track an error in OSM data ? (and style's behavior, error) (David)
David schrieb am 01.08.2011 19:20: My first idea was an error in OSM file, but I cannot find bad data. You could try to put the OSM-ID into the name of the object (via the style-file). As a result on your Garmin you would be able to figure out, which OSM object is the source for your trouble. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] suggested use of add-pois-to-areas
Moin, Rich schrieb am 24.07.2011 18:58: what is the current suggested use of add-pois-to-areas - have any changes like http://gis.638310.n2.nabble.com/POIs-for-areas-td6043656.html been introduced recently ? This modification was never merged into the trunk, because it is not backward compatible with the add-pois-to-areas parameter. I want to start this topic again later (perhaps with an ugly workaround for the backward compatibility), but first I am waiting for the locator branches to be settled/merged. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Using exit refs in routing directions
Felix Hartmann schrieb am 14.07.2011 12:16: Is the ramp two sections?? For me (with my style), ramps do work with the name of the next street segment behind. Not sure what happens if the ramp is several sections (I suppose the first real street behind should be used). 0x09 needs to be used! Doublecheck if that type is really used. Other types wont work (not so sure about 0x08, which might work too). I get the same results. I have thought about a mkgmap extension, which would split the ramps automatically into two ways, to get the name of the exit into the routing direction and not the name of the following street. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Mysterious capitalisation (or not) of labels
Charlie Ferrero schrieb am 03.07.2011 08:55: In Mapsource (6.16.3) these labels render differently (see attached). Building 1 renders as Khalidiya Palace Tower a Building 2 label renders as Khalidiya Palace Tower C Is this a bug in mkgmap or a bug in Mapsource? I think, this is a Garmin problem. A single letter A is always displayed in lower case. I guess, this is due to the indefinite article of the english language. In my maps I have this problem with the german motorways, which have a name like A 1, A 2 and so on, but in my maps they are always displayed as a 1 and a 2 and so on. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
MarkS schrieb am 03.05.2011 22:58: Would something like this work? highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue] highway=motorway oneway=yes [0x10f01 level 6] highway=motorway oneway!=yes [0x10f02 level 6] Then style 0x01 with no style (so nothing is drawn) - 0x01 would be used for the routing information. Then style 0x10f02 as plain motorway and 0x10f01 as motorway with arrows. The problem is, that the oneway overlay is not only to motorways. So you would need two line styles for motorways, two linestyles for primaries, ... And if you want to add overlays for access restrictions, speed limits or what ever, th enumber of line styles required is growing exponentially. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Non way element X in multipolygon Y
Charlie Ferrero schrieb am 28.04.2011 09:46: Why is the warning correct? The wiki says that a boundary multipolygon can contain a node tagged admin_centre. Isn't this mkgmap warning a false positive? Actually this is depending on the type of the relation. With type=multipolygon there shouldn't be any non-way member in the relation, with type=boundary the role admin_centre is defined. There is no such thing as a boundary multipolygon, you have either one or the other. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
Thorsten Kukuk schrieb am 03.05.2011 20:53: But with both statements, the arrow is always drawn below the street. Is it somehow possible to have the arrow on top of the street? The drawing order of the lines in a single map is not really understood and can not be set via the style file. For such tasks I use multiple map layers (base layer + overlay layer), the display order of the complete maps can be defined via mkgmap command line parameter (draw-priotrity) Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] --ignore-builtin-relations
Felix Hartmann schrieb am 16.04.2011 16:13: I don't understand for whom this option is usable. If I use a relations file, then I assume I may not use this option (else relations won't be processed). And also one will be missing stuff like boundaries and maybe some forests My understanding is, that right now the multipolygon-processing is performed by mkgmap even when the map layer shall contains no polygons at all. So this patch might speed up processing for such map layers, e.g. contour lines, hiking routes overlay, POI overlays. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Idea: map layers (multiple output tiles per input tile)
Moin, since my GPS-maps rely heavily on multiple layers, there would be some benefit, if producing of these layer could happen within a single mkgmap run, so that the common proccesing steps would be executed only once. Whether this can be achieved, depends on the time of the processing step. I would guess, that most steps are not performed on the whole OSM input data, but only on the output data of the styled converter (there is no need to process any data not used in the map). So if you want to use multiple styles in parallel, most of the processing must be done anyway multiple times. I don't like the proposal to put the multiple layer support into the style files, I think such a mechanism should be controlled via command line parameters, so that you could the same styles either for single layers or for a multiple layers mkgmap run. I would like an extension, which would allow such a usage of mkgmap: input.osm - style-A, parameters-A - outputA.img - style-B, parameters-B - outputB.img Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New locator branch
WanMil schrieb am 17.03.2011 21:12: I observed that a lot of admin_level boundaries (2,3,4,5 and sometimes 6,7,8,9,10,11) are not useable because they are not completely contained in the tile data. The polygons are closed automatically but this is only a good guess in which direction they have to be closed. The probability is quite high that they are closed in the wrong direction. Moin, just as an idea: How about collecting the is_in data of the objects and trying to use this data for recovering the missing boundary information? If you have some is_in data points inside of an area, then the is_in data should (mostly) match the boundary data. For an unclosed boundary this could be used for guessing, to which side of the boundary it is relating to. And for a boundary completely surrounding the tile, this could be used to provide the missing information. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] -- index vs --overview-mapname
Moin, I had some trouble getting the search in Mapsource working when building my maps with r1871. Finally I got it working, but only after removing the --overview-mapname option. Doers the --index option not work in combination with --overview-mapname? Is there any documentation about th enew --index feature yet? I haven't followed the development, so I am not sure, what is needed for the search feature. (location=autofill? boundaries? place POIs?) Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overlays issue
Ralf Kleineisel schrieb am 08.03.2011 18:09: Lines file: junction=roundabout highway=secondary [0x11f02 road_class=2 road_speed=3 level 4] Overlays file: 0x11f02: 0x0c, 0x04 Then I created a test typ file with a very broad pink 0x0c just to see if the two lines are really there. They are, I can see the 0x04 on top of the 0x0c as expected. BUT: The roundabout is never used for routing now. It is treated as if it was a non-routable line. Do I do something wrong or is the routing info not created properly? If I remember correctly, the overlay file does not guarantee, which line is displayed on top. So if not one of the lines is transparent, the display of such a structure will vary. If you are using a transparent code for the roundabout, you could also add a second non-routable line for the display, without using the overlays file, e.g.: Lines file: junction=roundabout highway=secondary [0x0c road_class=2 road_speed=3 level 4 continue] junction=roundabout highway=secondary [0x04 level 4] Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Preparing patches (Re: POIs for areas)
Marko Mäkelä schrieb am 03.03.2011 22:54: Could you elaborate what your patch does? Does it remove the option add-pois-to-areas altogether? Even though an add_poi action would replace add-pois-to-areas, I think that we should support both forms for some time. Sadly this patch disables the add-pois-to-areas option completely. I also would like to have both capabilities for backward compatibiliy, but in the style processing the command line arguments are not visible at the moment. So there is no easy way for testing either whether the addpoi command is set in the style or whether the command line argument is set. The trunk version generates in the style processing the basis for the POI generation for ALL objects regardless the command line argument. During the map generation the command line argument is test, for whether the available POIs are generated or not. In my patch during the style creation only the basis for the POI generation of the objects with the addpoi command is created. And during the map generation a POI is ALWAYS created, if for an object the corresponding basis is found. You may ignore the rest of this message. I did a too quick read of the patch and thought that you had changed accidentally white space in some lines. You did that on purpose, because you removed one level of indentation when removing the check for the add-pois-to-areas parameter. I have read the rest of your message, but probably only understood half of it. (I am neither familiar with eclipse nor with svn, so I hardly now what I am doing when building my own mkgmap.) What is the desired approach on the indentation when a patch has such a structure change like removing an if-bracketing? In my change I also corrected the indentation of otherwise unchanged lines. Shouldn't such changes be included in the patch? If they are not included, how is the indentation then corrected? Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Preparing patches (Re: POIs for areas)
Jeffrey Ollie schrieb am 04.03.2011 16:09: Whitespace-only changes should be included in a separate patch that does not change any functionality. That makes it easier to review changes. Thanks for the clarification. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Preparing patches (Re: POIs for areas)
Moin,
my mkgmap build process is very shaky, but finally I managed to create a patch
of my changes. Perhaps it is even working?
Gruss
Torsten
Index: src/uk/me/parabola/mkgmap/osmstyle/TypeReader.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/TypeReader.java (Revision 1878)
+++ src/uk/me/parabola/mkgmap/osmstyle/TypeReader.java (Arbeitskopie)
@@ -69,6 +69,8 @@
gt.propagateActions(true);
} else if (w.equals(no_propagate)) {
gt.propagateActions(false);
+ } else if (w.equals(add_poi)) {
+gt.setAddPoi(true);
} else if (w.equals(oneway)) {
// reserved
} else if (w.equals(access)) {
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (Revision 1878)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (Arbeitskopie)
@@ -541,12 +541,14 @@
clipper.clipShape(shape, collector);
- nodeRules.resolveType(way, new TypeResult() {
- public void add(Element el, GType type) {
-if(type != null)
- shape.setPoiType(type.getType());
- }
- });
+ if (gt.isAddPoi()) {
+ nodeRules.resolveType(way, new TypeResult() {
+public void add(Element el, GType type) {
+ if(type != null)
+ shape.setPoiType(type.getType());
+}
+ });
+ }
}
private void addPoint(Node node, GType gt) {
Index: src/uk/me/parabola/mkgmap/main/MapMaker.java
===
--- src/uk/me/parabola/mkgmap/main/MapMaker.java (Revision 1878)
+++ src/uk/me/parabola/mkgmap/main/MapMaker.java (Arbeitskopie)
@@ -151,47 +151,39 @@
}
private void makeAreaPOIs(CommandArgs args, LoadableMapDataSource src) {
- String s = args.get(add-pois-to-areas, null);
- if (s != null) {
- MapPointFastFindMap poiMap = new MapPointFastFindMap();
+ MapPointFastFindMap poiMap = new MapPointFastFindMap();
- for (MapPoint point : src.getPoints())
- {
-if(!point.isRoadNamePOI()) // Don't put road pois in this list
- poiMap.put(null, point);
- }
+ for (MapPoint point : src.getPoints())
+ {
+ if(!point.isRoadNamePOI()) // Don't put road pois in this list
+poiMap.put(null, point);
+ }
- for (MapShape shape : src.getShapes()) {
-String shapeName = shape.getName();
+ for (MapShape shape : src.getShapes()) {
+ String shapeName = shape.getName();
-int pointType = shape.getPoiType();
+ int pointType = shape.getPoiType();
-// only make a point if the shape has a name and we know what type of point to make
-if (pointType == 0)
- continue;
+ // only make a point if the shape has a name and we know what type of point to make
+ if (pointType == 0)
+continue;
-
-// We don't want to add unnamed cities !!
-if(MapPoint.isCityType(pointType) shapeName == null)
- continue;
-
-// check if there is not already a poi in that shape
+ // check if there is not already a poi in that shape
-if(poiMap.findPointInShape(shape, pointType, shapeName) == null) {
- MapPoint newPoint = new MapPoint();
+ if(poiMap.findPointInShape(shape, pointType, shapeName) == null) {
+MapPoint newPoint = new MapPoint();
- newPoint.setName(shapeName);
- newPoint.setType(pointType);
+newPoint.setName(shapeName);
+newPoint.setType(pointType);
- copyAddressInformation(shape, newPoint);
+copyAddressInformation(shape, newPoint);
- newPoint.setLocation(shape.getLocation()); // TODO use centroid
+newPoint.setLocation(shape.getLocation()); // TODO use centroid
- src.getPoints().add(newPoint);
+src.getPoints().add(newPoint);
- log.info(created POI , shapeName, from shape);
-}
+log.info(created POI , shapeName, from shape);
}
}
Index: src/uk/me/parabola/mkgmap/reader/osm/GType.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/GType.java (Revision 1878)
+++ src/uk/me/parabola/mkgmap/reader/osm/GType.java (Arbeitskopie)
@@ -59,6 +59,9 @@
// actions will always be executed
private boolean propogateActionsOnContinue;
+ // only applicable for ways (roads, lines and shapes)
+ private boolean addPoi = false;
+
public GType(int featureKind, String type) {
this.featureKind = featureKind;
try {
@@ -198,4 +201,12 @@
public void setContinueSearch(boolean continueSearch) {
this.continueSearch = continueSearch;
}
+
+ public void setAddPoi(boolean addPoi) {
+ this.addPoi = addPoi;
+ }
+
+ public boolean isAddPoi() {
+ return addPoi;
+ }
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1867: Translate leisure=track into a line (footway) unless area=yes.
Marko Mäkelä schrieb am 28.02.2011 13:04: The wiki http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dtrack says that leisure=track is to be used on nodes and ways. This hints that you should add area=yes when you mean an area. The wiki http://wiki.openstreetmap.org/wiki/Map_Features also allows this tag for areas. It is a known problem, that the OSM data does not differentiate between lines and areas. And I don't think we should rely always on an area=yes tag to solve this mess. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
Moin, Marko Mäkelä schrieb am 27.02.2011 10:32: I got 2386 additional warnings. Some are for thin man_made=pier that have been drawn as lines. There is man_made=* in the polygons style file. I have not tested the polygonclose_v2.patch but it sounds like it has the inverse effect of the previous restrict_polygon_v1.patch, which sounds like a very bad idea to me. In the OSM data we have sometimes identical tags for line objects and for area objects. The restrict_polygon_v1.patch was build, so that the polygon rules were only applied, if the OSM-way is closed. Now the new patch seems to close automatically all ambigous ways, making the previous problem even worse. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
WanMil schrieb am 27.02.2011 16:53: Your example will result in 1. line with 0x01 2. a) nothing more if node1 or node2 is within the tiles bounding box b) a polygon 0x02 if node1 and node2 is outside or on the tiles bounding box. Ok, I will try out r1865 when it is availbale as a download. But in my opinion 2.b) is a fault: If the polygon is not closed in the OSM data, it shouldn't be closed by mkgmap, no matter whether the start and end nodes are inside or outside the bounding box. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygones and tags in outer line
Chris66 schrieb am 22.02.2011 11:05: Indeed the most MPs are tagged like this: relation: type=multipolygon outerway: landuse=forest (example) innerway: no-tags (or tags for inner area). The forest is of course only the area between inner and outer. This is one of the accepted taggings for a multipolygon. The other possibility (for the same example) is: relation: type=multipolygon landuse=forest (example) outerway: no-tags (or tags for whole area) innerway: no-tags (or tags for inner area). For a render the only way to decide, which tagging scheme is used by the mapper, is checking the tags in the relation. Is there any tag on the relation beside the type=multipolygon, then second scheme is obviously used. If there is no other tag on the relation, then the first scheme is used. Everything else should be considered as a data error. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Weird behavior and problem with splitter r161
Jean-Marc Meessen schrieb am 20.02.2011 14:24: * Am I using the latest version of the PBF splitter branch (I also tried the compiled r161-3) ? * Is this a known problem ? * Is something wrong with my parameters ? I was using a windows 7 PC for this. Thanks in advance to any hint or advise you could give me. This sound like a known (and already solved) problem, where splitter had problems with files 4GB on windof PCs. In the lates version of r-161 this problem was solved, previous versions of r-161 had this problem. Are you sure, you are using the latest versin of r-161? (My splitter.jar has the date 27.01.2011.) Are smaller maps working ok? Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Weird behavior and problem with splitter r161
Jean-Marc Meessen schrieb am 20.02.2011 14:53: The file I am trying to split is fairly small, Torsten. It is about 30kb large (while the european data is 5gb). The splitter version is from end january. Isn't the extract too small and thus the Osmosis extract went wrong ? I am extracting 50km around the borders of Belgium. I haven't read your first mail correctly: I think the Osmosis cutting is your problem. Splitter and Osmosis use the same librarys for the pbf handling, so they both had the same 4GB bug. Is your Osmosis actual? It should also have a date from end of january. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon problem
WanMil schrieb am 08.01.2011 11:44: I have attached that patch to limit polygon creation to closed ways. It's untested and I assume there are some unwanted effects at tile borders. Please check and if you (and others) find it usefull it can be committed. Did anybody else try this patch? I haven't noticed any problems and would like to see this patch comitted. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
Ben Konrath schrieb am 03.02.2011 12:51: That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out. No, in the OSM data is only a polygon, and AFTER the POI is added to the area, I have the node and the polygon. The style processing afterwards has no chance to detect, whether there is a polygon belonging to the node or not. So in the resulting map I get both, a polygon area and a symbol. For some types this might be ok, but for some types I do not want the symbol in addition to the polygon. But the add-pois-to-areas function is only working on all types or not working at all. And I can not remove such types from the point style, because in the OSM data there are also nodes of the same type without a corresponding polygon. So my suggestion would be, to mark all created POIs with an extra tag, e.g. mkgmap_created=add-pois-to-areas or something like that. Then I could use in the points-style a rule like type=xyz mkgmap_created!=add-pois-to-areas ... which would only place a symbol in the map if there is no corresponding polygon. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
Moin, Henning Scholland schrieb am 31.01.2011 21:41: Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon? In OSM some objets can be mapped in OSM as a node or as an area, depending on the availability of the source data. If they are mapped as a node, I want them to be displayed as a symbol in my map. If they are mapped as an area, I want them to be displayed as a polygon. With the pois-to-area function the latter ones are displayed in a map twice, as a polygon AND as a symbol. Therefor there is some need, to disable the POI generation for some polygons, or for detecting the automatically generated POIs, to prevent there inclusion in the map. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Marko Mäkelä schrieb am 31.01.2011 20:16: On a related note, I believe that an alternative to add-pois-to-areas should be implemented, by introducing an add_poi action in the polygons style file. In that way, one could flexibly choose which polygons deserve a POI. I just started using add-pois-to-areas last week. Before I was put off by the problem of unwanted POIs. But due to the Bing images, more and more objects are mapped as areas instead of POIs now. I still think, that an add_poi action is highly desirable (it could be easily extended so that you could specify, whether you want the POI in the centre, on the first/last node, on all nodes, between the nodes...) But a much easier solution for the unwanted POIs would be, if the add-pois-to-areas function would add a predifined tag to each created POI (e.g. mkgmap_created=add-pois-to-areas). With such a marking it should be possible to ignore all unwanted POIs within the points style processing. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New splitter build for pbf format
dom Team OiD schrieb am 28.01.2011 19:24: Is also the big file problem fixed? I think about the europe file splitting. Is this problem solved? Yes, that is the new of the new version. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How to solve/debug weird problem
Johannes Formann schrieb am 13.01.2011 22:32: The generate_ways_from_relations.patch is used to give cycleroutes good attributes (road_class, speed), so they were preferred over normal roads, independed on which roads they actually run. (But dependent on the network different, rcn other than ncn and so on). I haven't loked at the patch, but for this task you need not to patch mkgmap, you can get such a result just by using an appropriate style during the map creation. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon problem
Moin, I think the problem is not the multipolygon, but that some of the outer ways are tagged with surface=sand. These tags are not considered for the multipolygon, but for these ways mkgmap creates single surface=sand polygons. But if you change your polygon style from surface=sand [0x1b resolution 20] to surface=sand natural!=coastline [0x1b resolution 20] this shouldn't happen any more. Just for a try: What happens, if you remove the surface=sand lines from your polygon styles completely? And one other thing: There was once a patch, which limited the polygon creation to closed ways. Does anybody know, what happened to this patch? I really liked it. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] first map-tile is missing in tdb-file?
Valentijn Sessink schrieb am 25.12.2010 11:03: I remember having this problem with an older version of Java. See the mailing list messages Map missing from r1363++ and weird: file missing when # of files 10?, november 2009. Java version 1.6.0_16 had this problem, java version 1.6.0_17 did not have it. Does that help? This might be my problem, I am using version 1.6.0_07. So I guess I have to update my Java environment. (Shit, I hate updating a running system. For sure something else will not work any more afterwards.) Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] first map-tile is missing in tdb-file?
Valentijn Sessink schrieb am 25.12.2010 11:03: Java version 1.6.0_16 had this problem, java version 1.6.0_17 did not have it. Does that help? An update of my Java version solved the problem. Thanks! gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] increase precision of node coordinates?
Maks Vasilev schrieb am 08.12.2010 14:25: How to increase precision of node coordinates? In general there is no way to increase the precision of node coordinates. The only cause for problems is sometimes the remove-short-arcs option. I donÄt know whether there is a default value, so you could try setting it explicitly to zero and check, whether this will improve the map optics. But be aware: Setting this option to zero will break the routing. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error splitting binary files
aighes schrieb am 06.12.2010 19:33: I've the same problem with todays europe.osm.pbf. Extract of 02.12. works fine (was the last I used). Me too. The resulting map contains only POIs and no lines or polygons. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] first map-tile is missing in tdb-file?
Moin, I tried some changes in my map generation, but I was not able to clearly identify the problem: - If I reduce the number of map tiles in my arguments file, all tiles are included in the tdb-file. I have never seen it go wrong with less than 8 tiles, I have never seen it working with more than 16 tiles. Between these numbers I have seen it working and going wrong with the same setting just by repeating the tries. - The problem seems not to be related to any other command line arguments. I did a try with only default options beside the arguments file containing the tile list. And even in this try the first tile was missing in the tdb-file, Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] first map-tile is missing in tdb-file?
Moin,
I am creatig my maps with mkgmam-r1733 with the following command:
java -jar -Xmx8096M ../../mkgmap-r1733/mkgmap.jar
--style-file=../../styles/topo_v005 --remove-short-arcs=5
--generate-sea=extend-sea-sectors --family-id=62 --country-name=Deutschland
--country-abbr=D --family-name=Topo Map --series-name=Topo Map
--description=Topo Map --tdbfile --max-jobs=3 --draw-priority=11 -c
maplist.txt
The configuration file maplist.txt is the following:
mapname: 8001
description: FR - Macon
input-file: ../../osm/Europa/8001.osm.gz
mapname: 8002
description: FR - Dijon
input-file: ../../osm/Europa/8002.osm.gz
mapname: 8003
description: CH - Geneve
input-file: ../../osm/Europa/8003.osm.gz
mapname: 8004
description: FR - Besancon
input-file: ../../osm/Europa/8004.osm.gz
mapname: 8005
description: CH - Aigle
input-file: ../../osm/Europa/8005.osm.gz
...
The problem now is the first map tile 8001. The img file is correctly
created, but the tile is missing in mapsource and it looks like, the tile is
missing in the tdb-file:
PC �Topo Map d Topo Map � ' D� OSM
Street map http://www.openstreetmap.org/ Map data licenced under
Creative Commons Attribution ShareAlike 2.0
http://creativecommons.org/licenses/by-sa/2.0/ Map created with mkgmap-r1733
Program released under the GPL R �Test preview map B% @�� �'
� � Overview Map Ll �e�...@�� @ � @! FR - Dijon (8002)
3
��� a � � 8002.TRE 8002.RGN 8002.LBL Lm �e�...@�� 0! � �
�CH - Geneve (8003) X% �_A � � � 8003.TRE 8003.RGN
8003.LBL Lo �e�...@�� @ � 0! �FR - Besancon (8004) \* y
;N � � 8004.TRE 8004.RGN 8004.LBL Ll �e�...@�� 0! � �
�CH
- Aigle (8005) �# H�, = � � 8005.TRE 8005.RGN
8005.LBL Lk �e�...@�� �! � 0! �CH - Bern (8006) �F ��Z �(
�
� 8006.TRE 8006.RGN 8006.LBL Lo �e�...@�� @ ` �! �FR -
Mulhouse (8007)
...
I dont't get any error messages from mkgmap. So where is the map tile lost?
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ! not working -- problem with conditions in style-file.
Felix Hartmann schrieb am 17.11.2010 22:30: Below is the outcome I want to have for tracktype=1 and respectively tracktype=5 if tracktypeadded=yes THEN build 0x07 (no matter if tracktype exists, and no matter which value it has). if tracktype=5 THEN do build 0x07 (if tracktype does not exist, or tracktype has any value but 1-4 then it should also go through) if tracktype=1 but tracktypeadded!=yes THEN do not build 0x07 I am not sure, I understand your intention correctly. So I will provide a table for the tracktype value and the expected outcome (tracktypeadded!=yes is always assumed, since this extra condition shouldn't be the problem): tracktype -build 0x07 not set no 1 no 2 no 3 no 4 no 5 yes any other value no This should be achieved by (tracktypeadded=yes | tracktype=5) This look so easy, so I probably have misunderstood your intention. So please provide such a table with your expected outcome. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ! not working -- problem with conditions in style-file.
Felix Hartmann schrieb am 18.11.2010 17:18: table should look like this for tracktype!4 tracktype -build 0x07 not set yes 1 no 1 no 2 no 3 no 4 no 5 yes 5yes any other value yes (any other value, meaning non numeric). this can currently be achieved by ( tracktypeadded=yes | (tracktype!=* | tracktype4 )) I think not not, any non-numeric value for tracktype would give a different result than your table. but I think for the above command the easier structure would be ( tracktypeadded=yes | tracktype!5 ) I think inventing such an operator would be a bad idea. It would be much easier to have a genenral negation i.e. !(expression) But in general you can rework any boolean expression by exchanging the operators, so that you coul go without a simple negation. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon
maning sambale schrieb am 17.11.2010 14:36: AFAIK, the correct way of tagging is: way 1 - amenity=townhall way 2 - no tag relation type=multipolygon way 1 = outer way 2 = inner I'll check other data to verify. This one of the possible solutions. Also ok would be way 1 - no tag way 2 - no tag relation type=multipolygon amenity=townhall way 1 = outer way 2 = inner In the beginning of multipolygon usage also the following scheme was used, but is considered faulty now. way 1 - amenity=townhall way 2 - amenity=townhall relation type=multipolygon way 1 = outer way 2 = inner Such an outdated tagging would result in two icons and should be considered as a tagging fault. If one of the first two solutions results in two icons, than the add-pois-to-areas function of mkgmap does not work correctly in combination with multipolygons. (In my point of view the add-pois-to-areas function should be reworked anyway, to give more control via the style file about which areas should generated which POIs.) Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ! not working -- problem with conditions in style-file.
aighes schrieb am 17.11.2010 20:21: instead of ! you could use = or =. I don't know if there is a difference. For example: ( tracktype=5 | tracktypeadded=yes ) I think he wants to have (tracktype!=* | tracktype5) The difference is, when there is no tracktype defined at all. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] motorway_link not always oneway
maning sambale schrieb am 26.10.2010 10:53: The default style treats motorway_link as oneway by default. I've seen some cases (in the Philippines) where this isn't so. Is it the same case for other countries? If so, I propose we modify the default style. Or, any suggestions to modify the style? I checked some examples in Germany: Here it is quite normal, that part of the motorway_links have to lanes, one for each direction. These are either mapped as two separated lines (but mostly they are not separated, so imho this is actually a mapping error), or they are mapped as one single line, but normally without any oneway attribute. What happens in case our default assumption is wrong? - If we assume oneway=yes as default and our assumption is wrong, then some motorway junctions are not usable at all for the routing (either for leaving or for entering the motorway). So the user will be routed to another junction further away. - If we do not assume oneway=yes and our assumption is wrong, the the routing might give some false turn commands (in most cases this will not happen, since the allowed way is also mostly the fastest way), but will always use the nearest junction. As a consequence, I think we shouldn't assume one=yes as default for motorway_links. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue command in combination with add-pois-to-areas
Steve Ratcliffe schrieb am 12.10.2010 00:16: if anyone has any ideas please post. As a user I would like to have an action command in the polygon (and also in the lines) style rules for generating a POI for a specific area (and also for a specific line). Actually I would like to have multiple commands, e.g. add-centre-node (new node in the geometric centre of the polygon) add-start-node (first node of the polygon) add-end-node (last node of the polygon) add-middle-node (middle node of the polygon) add-inner-node (all nodes of the polygon beside the first and the last one) add-all-node (all nodes of the polygon) I could think of multiple uses for such a feature. I do not know, whether this would be possible, since it would require a processing of the polygon and line rules before the processing of the point rules. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Some bounderies shown as river
Josef Latt schrieb am 07.10.2010 11:23: one of the river (tracks Rhein) where the boundaries, shown as river, starts has two ways. One with tag boundary and waterway=river, the other only with waterway=river. I don't understand your problem. When the way ist tagged as boundary and as river at the same time, you shouldn't be surprised, when this is displayed as a river. So right now this sounds to me like a mapping error and not like a mkgmap problem. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Some bounderies shown as river
Josef Latt schrieb am 07.10.2010 20:03: That means that a tagging like this is false? ... tag k=boundary v=administrative/ ... tag k=waterway v=river/ If the river itself is the boundary, then this tagging is ok. But in such a case, you can't complain, that the boundary is shown as a river, because the displayed element is a river as well as a boundary. So it is just a matter of display priority. From your screenshot I can now guess, what you mean: There are also other ways in the map, which are dislpayed as river, although they are only tagged as boundary AND NOT as river at the same time? If this is the case, I would guess, that the complete boundary is made up out of a multipolygon. In this case the multipolygon tagging seems to be faulty. Either all outer ways must be tagged the same (this can not be, since one part is tagged as a river, while other parts shouldn't be rivers), or the tag values for the multipolygon must be placed on the relation instead of the outer ways (this is also not done in the example, since the boundary tag is on the way and not on the relation). Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
char...@cferrero.net schrieb am 27.09.2010 15:20: As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)? It should use both: The nature reserve should cover the complete area. The wood should cover only the area defined by the multipolygon. This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be: 1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B 2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B 3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B 4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area). Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
char...@cferrero.net schrieb am 27.09.2010 16:49: OK, but in practical terms if mkgmap generated a nature reserve polygon, a wood multipolygon and an inner water polygon, wouldn't the visible results be undefined? In other words, you could end up with either: a) Wood multipolygon water polygon hidden underneath a nature reserve polygon, or b) A nature reserve polygon hidden underneath the wood mp and water polygon depending on draw order of the polygons (which afaik you can't control). You can control the draw order of the polygons via the style file. So depending on the targeted use of your map, the result will look differently but clearly defined. In case of the example: My map style would display the wood and the water next to each other. The nature reserve is displayed on top of both, but it is a semi transparent texture. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 19:29: My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area. You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know. I tried your patch today, and I think it looks quite promising. Implementing such a strict scheme will certainly show some faulty multipolygon (e.g. Aussenalster in Hamburg), but perhaps this will encourage a cleaner tagging of such relations. I think the patch has still one problem: If the tags of the outerpolygon are not used for the multipolygon area, they must still be used as a stand-alone polygon. As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] line features are converted to a closed way
WanMil schrieb am 20.09.2010 20:44: Attached patch performs only the line styles on unclosed ways (the patch is untested!!). I tried your patch and I didn't notice any unwanted side effects. Since this is quite a change from the previous behaviour, perhaps it would be a good idea to control this via a command line parameter. Another idea would be, to control this seperately for each line in the style file. But from my point of view this is not neccessary, since all non closed area polygons are a mapping error and should be corrected in the data base. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 17:35: The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list. My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area. There shouldn't be a list of concerned tags, since any area tags may be used. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Binary-Format
Scott Crosby schrieb am 22.09.2010 20:42: My advice is to wait a few weeks for new releases to come out. For a production version: yes, sure. But this is the development list of mkgmap, so it is all about trying out new stuff and getting it fixed. This is how the new releases in a few weeks are made. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with mkgmap r1699
WanMil schrieb am 21.09.2010 23:30: This has been fixed with r1700 so the problem should not exist any more. I can confirm, that r1701 does not crash any more. Thanks for the fast fix. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with mkgmap r1699
WanMil schrieb am 20.09.2010 20:37: But I am not sure in what situations the bug happens. Could you do me a favour and run mkgmap with the following log.properties file? Is this problem already solved with r1700? Otherwise I have to admit, that I do not know how to run mkgmap with a log.properties file. So could you please explain me, how to use such a file. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] line features are converted to a closed way
char...@cferrero.net schrieb am 20.09.2010 07:52: Personally, I would love it if some logic could be added to mkgmap for it to be able to detect whether something is a closed polygon or not, which would make it much more robust in these instances. I would also like to see such a feature, perhaps implemented via a command line switch. The problem occurs for me, when I want to display access restrictions on my map. access=* can be placed on any area element (e.g. amenity=parking) or it can be placed on any line element e.g. highway=* Right now there is no way to tell mkgmap, that the polygon rules shall not be applied to the line elements. If the polygon rules could be limited to closed polygons only, than this problem would not be solved completely but to a very large degree. (There can still be line elements forming a closed loop.) Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problem with mkgmap r1699
Moin, I have a problem with mkgmap version r1699: it crashes while generating my maps. With r1673 everything was ok. It does not seem to be related to the style, I tried different layers of my maps and all are crashing. I use the following mkgmap command line and get this error message: java -jar -Xmx6144M ../../mkgmap-r1699/mkgmap.jar --style-file=../../styles/09_maxspeed --remove-short-arcs=5 --transparent --family-id=49 --country-name=Deutschland --country-abbr=D --overview-name=Tempolimits --family-name=Tempolimits --series-name=Tempolimits --description=Tempolimits --tdbfile --draw-priority=23 --max-jobs=3 -c maplist.txt java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processEle (MultiPolygonRelation.java:818) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endRelation( mlHandler.java:620) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endElement(O lHandler.java:590) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.end nt(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.endE t(XIncludeHandler.java:1014) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann l.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann l$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.n MLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl (XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann l.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.pa ML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.pa ML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLPa java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.par stractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXPar arse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at javax.xml.parsers.SAXParser.parse(SAXParser.java:198) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5 taSource.java:84) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:1 at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:30 at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoo utor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExe .java:907) at java.lang.Thread.run(Thread.java:619) Exiting - if you want to carry on regardless, use the --keep-going option Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tag values of relations and tag values of its members
Marko Mäkelä schrieb am 10.09.2010 22:55: Yes, apply role=value (role ~ 'regexp' would be nicer, but not implemented). It would also be nice to check for the type of the member (node, way, relation), but there is no syntax for that. See src/uk/me/parabola/mkgmap/osmstyle/actions/ActionReader.java, the role=value parsing is in readAllCmd. In ActionReader there is also an apply_once command included. Can this be used to prevent the forward/backward-doubling? Or what is the intended use of apply_once vs. apply? Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] tag values of relations and tag values of its members
Hallo,
is there any way to use the tag values of the members of a relation within the
apply command in the relations style file?
With
apply {set Member_Tag_Value=${Relation_Tag_Value}}
I can set the tag value of the relation to all its members.
Instead of just setting the tag in the member, I would like to combine it with a
tag value from the member. Something like
apply {set Member_Tag_Value='${Member_Tag_Value} and ${Relation_Tag_Value}'}
Can this be done somehow?
And as a related question: I it possible to include tags of the member of the
relation in the tag test of a relation rule?
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tag values of relations and tag values of its members
Apollinaris Schoell schrieb am 10.09.2010 18:41: long time ago I have done it with a temporary tag name in the relations file. and then in the line style test for existence of the temporary tag and combine with the tag values from the lines the only change you need is to test the existence of Relation_Tag_Value in the line style I think this wouldn't solve my problem. What I want to achieve is, that multiple relations can add information to a single way. E.g. A way A is member of relation relation B and also member of relation C, beside their name both relations are tagged in the same way. And in the map I want to have a name for the way like A is member of B and member of C. With a temporary tag I think I will eitehr get the result A is member of B or A is member of C But I do not see any way rigth now, how both relations can add their information to way A at the same time. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tag values of relations and tag values of its members
Marko Mäkelä schrieb am 10.09.2010 22:12:
I implemented the $(variable_name) syntax some time ago, to get bus
route relations translated properly. An excerpt from --style=routes:
[relations file]
type=route ... {
apply { set mkgmap:route='$(mkgmap:route),${ref}' | '${ref}' }
}
[lines file]
highway=* mkgmap:route=* { name '${mkgmap:route}' } [0x1d resolution 16]
Note that in the apply rule, the $(mkgmap:route) is referring to an
attribute of the relation member, and the ${ref} is referring to an
attribute of the relation.
Thank you very much, that was the information I was mainly looking for.
I will add this information also on the style rules page in the Wiki.
What I would like to see is apply sorted by some criterion, and the
possibility to filter out duplicates, for example, when the same way is
part of opposite-direction bus route relations. (Opposing bus routes of
the same line can consist of oneway segments as well as shared
non-oneway segments. Now I will see 742,742 on the non-oneways and
just 742 on the oneways.)
Is there any way to check for the role of the member inside the style rules?
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing does not work since December.
Paul Ortyl schrieb am 09.08.2010 18:00: Should I expect, that routing in MapSource should work? Yes. I do not use the default style, but in general routing does work (atleast when the routes are not to long). Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maintaining generated sea polygons
Moin, NopMap schrieb am 21.05.2010 07:57: For three weeks I have been unable to grab a planetfile with correct coastline for central europe - they are broken at about the same speed we can fix them. So even though I was able to build a really nice map a while ago, all update attempts were broken. I always use the same tile borders for my maps. So when the generation of a single tile fails, I can use the last usable version of this tile for getting a complete mapset. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Boundary Lines
Chris-Hein Lunkhusen schrieb am 28.03.2010 14:22: I don't know how the MP code works, but it should not copy tags like boundary=* to the multipolygon cutting lines. They should stop putting the boundaries into multipolygons. The problem is, that the boundaries are tagged as areas (thats the meaning of using multipolygons), but they are drawn on the maps as lines around the border of the area. The boundary multipolygons are handled the same way as all multipolygons. If a multipolygon is cut into smaller pieces, all pieces are tagged in the same way as the original multipolygon. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Do not process boundary relations
WanMil schrieb am 28.03.2010 21:43: The patch excludes the boundary relations from the multipolygon processing. This can be changed with the new option --process-boundary-relations. This might solve the actual problem, but I think it is a dirty hack. When we have the next tag with such a problem, will we add another option switch? Instead we should look for a cleaner solution, where either the mp processing can be better controlled via a style file (e.g. a new style file applicable tags for the mp-processing or perhaps limit the mp-processing to the expressions listed in the polygon file), or where the results of the mp-processings will be marked, so that the original and the artifical polygons can be distinguished in the following processings. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Boundary Lines
Chris-Hein Lunkhusen schrieb am 27.03.2010 20:44: I see in Mapsource many boundary lines which are not existing in the OSM data. See attached screen shot. Are these lines coming from the multipolygon processing? Probably yes. On 17.02. WanMil provided a patch, that allowed the distinction between the original (source) ways of a multipolygon and the artifical (generated) ways from the mkgmap multipolygon processing. But to make use of this patch you must adapt your style file, so it was never commited to the trunk. Gruss Torstebn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug in name command when combined with continue with_actions
Steve Ratcliffe schrieb am 25.03.2010 00:49: The difference is down to the 'name' command being like 'add' and not like 'set'. If you use add instead of set, then it behaves consistently with the way that name behaves. Ah, thanks for the explanation. Actually where is the best description/user guide for the different commands of the style files? The help for the command line parameters is maintained within the help parameter of mkgmap, but details of the style-commands are hard to find. I don't even know a single list on the net containing all the possible commands. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug in name command when combined with continue with_actions
Steve Ratcliffe schrieb am 25.03.2010 18:24: The best place is on the wiki at: http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules On the whole it doesn't include things that were not added by me though. Obviously there are some features missing. At least now I know, where I should add missing information. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Using multiple TYP files
Toby Speight schrieb am 23.03.2010 11:03: That's a bit more difficult for me - I'd have to generate it on the fly, as I don't know how many tiles the splitter is going to throw out. Unless there's a way around that? If you are always splitting the same areas, you can use an area list as parameter for splitter for defining the cuttings (parameter --split-file). I think splitter always outputs such a split file. So I have done once the splitting without the split-file parameter to get such a file, and afterwards I am using always this as input parameter for the following cuttings, so that I always get the same tiles. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] bug in name command when combined with continue with_actions
Moin,
I want to create two symbols for a single element (tagged with key=value), and
both symbols shall have different name (alpha and bravo).
If my points style looks like the following
key=value {name 'alpha'} [0x6005 resolution 20 continue with_actions]
key=value {name 'bravo'} [0x5001 resolution 20 continue with_actions]
then I will get the two symbols, but both have the name alpha.
If I rewrite my style to
key=value {set name=alpha} [0x6005 resolution 20 continue with_actions]
key=value {set name=bravo} [0x5001 resolution 20 continue with_actions]
then I will get the two symbols with the correct names alpha and bravo.
Interestingly, if I just use the first version but without the with_actions
extension
key=value {name 'alpha'} [0x6005 resolution 20 continue]
key=value {name 'bravo'} [0x5001 resolution 20 continue]
then I will again get the two symbols with the correct names alpha and bravo.
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Multipolygon: Allow nested inner polygons
Jeffrey Ollie schrieb am 02.03.2010 21:07: I've listened to that argument for a while and I'm tired of it. And I have tried to fight this anarchy and I got tired of it. So I accepted it as a fact and became much more relaxed and satisfied with OSM :-) Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Buildings without POIs cannot be found
Daniela Duerbeck schrieb am 03.03.2010 01:05: What if you add a list where one can add explicitely which POIs should be generated (supermarket, shop, restaurant, etc.)? I would like to have some action commands for the lines and polygons style files, where you could specify, that an extra point with the same tags as the way should be created: create_centre_point - for creating a point in the middle of all points of the way. With such a rule you could selectivly generate additional POIs for areas. create_start_point - for creating a point at the position of the first point of the ways. With such a rule you could add POIs at the beginning of an inlcine, speed limit or what ever. create_end_point - for creating a point at the position of the last point of the ways. With such a rule you could add POIs at the end of an inlcine, speed limit or what ever. If someone is capable of implementing such an extension, I would be very greatful. This is the top item on my mkgmap wish-list, after the improved style handling, the generation of sea polygons and the multipolygon support were added lately. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Multipolygon: Allow nested inner polygons
WanMil schrieb am 02.03.2010 18:48: The patch supports the complete multipolygon specification. And additionally it is tolerant towards incorrect (but reasonable) multipolygons. So why should mkgmap be restrictive if it doesn't need to? Since there is not really a specification for the OSM tagging, mkgmap should not check the data for correctness but try to support as much taggings as possible. So for example in a style file you must also check for typical typing errors, e.g. centre vs center. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problems with POI names
Moin,
I have a problem with POIs, which have an ref-tag (using mkgmap-r1586).
First of all, if the POI does not have a name, then the ref-tag is displayed in
the map. In my lines file, I have specially a rule for adding the ref-tag to the
name, so I am a little bit surprised, that this is happening for the POIs
automatically.
Are there some other tags wich will be used instead of the name tag?
My second problem is, that I wanted to delete the reference, by adding this
action part to my style rule: {set ref=}
As a result, all POIs where I wanted to delete the reference, now get their name
from a totally unrelated POI.
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon artificial tagging
Moin, I tried a slightly modified patch provided by WanMil, where also mkgmap:mp_*=no tags are added: the patch for the mp code does not remove any tags from the source polygons and lines. Instead it tags all mp-source lines and polygons with mkgmap:mp_source=yes and mkgmap:mp_created=no. All artificially created polygons during the mp processing are tagged with mkgmap:mp_created=yes and mkgmap:mp_source=no. Example: Polygon A - natural=water, role=outer Polygon B - landuse=grass, role=inner Result after mp processing Polygon A - natural=water, role=outer, mkgmap:mp_source=yes Polygon B - landuse=grass, role=inner, mkgmap:mp_source=yes Polygon A1 - natural=water, mkgmap:mp_created=yes Polygon A2 - natural=water, mkgmap:mp_created=yes Polygon B1 - landuse=grass, mkgmap:mp_created=yes With this patch I was able to fix the multipolygon borders commonly used in Germany, by modifying my style as follows. For the border lines I don't want to have the artificially created polygons, I am only interested in the original polygons from the multi-polygon. So I added to each border check the condition mkgmap:mp_created!=yes. As a result only the original polygons from a multi-polygon are drawn as borderlines as well as all lines not belonging to a multi-polygon. The second change was done in the polygon files. Here I added to every check the condition mkgmap:mp_created!=no. As a result only the artificially created polygons are drawn as areas as well as all polygons not belonging to a multi-polygon. So in my eyes with this patch the multi-polygon processing is much better controllable via the style file. But you have to adjust your style accordingly, so that you do not output both polygons, the original and the artificial one. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] access restrictions and routing
Mark Burton schrieb am 20.02.2010 14:02:
motor_vehicle is not understood by mkgmap - how about:
{set access=no; set foot=yes}
Ah, that does the trick. Thanks!
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Help from the style file gurus
Moin, Minko schrieb am 17.02.2010 16:05: I don't know if this already has been discussed, but some combinations of TYP file and overlays wont work in Mapsource. I don't know, whether they are not working, or whether you are expecing too much. I didn't follow the discussion, when the overlay were introduced, but based on my own observations, the overlays provide the following: They give you an easy way, to create multiple Garmin-lines out of a single OSM-way. But they do not help in changing the drawing order of the lines in the map. I think, the drawing oder of the lines in a map can not be specified, but I might be wrong and also my understanding of the overlays feature might be wrong. If I want a line always drawn on top of another line, than I create a second (and transparent) map layer with a higher draw priority for the upper line. For the Garmin units both map layers can be combined into a single gmapsupp.img by mkgmap and they are displayed fine. In Mapsource I haven't found a solution for this problem, here I only know how to display one map layer at a time. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dent in street and bounds problem
Felix Hartmann schrieb am 14.02.2010 21:10: That is a bug in Mapsource and won't get solved. Use Mapsource 6.13.6 (for x64 systems) or Mapsource 6.13.7 for x32 system. This might help, I am using a 6.11 version of Mapsource. Unfortunately my Nuevi displays it in the same way Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dent in street and bounds problem
Mark Burton schrieb am 14.02.2010 23:15: How about: the RHS of the dent is S of the junction with Bruchweg because the small footway has been completely removed by the remove-short-arcs option and so the node at the N end of that footway has been merged into the node at the S end of the footway which is why the way ends up kinked to the S. I haven't noticed this, but your right: The footway is misisng in the garmin map. But is this not a much bigger problem? Now in the Garmin map two roads are connected, which are not connected in the OSM data. I think the remove-short-arcs option mustn't remove complete elements, because the routing is now broken. And such a case is not so exceptional: Here it is quite common, that an end of a road is closed for vehicle traffic or declared as oneway for reducing the traffic in residential areas. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dent in street and bounds problem
Mark Burton schrieb am 14.02.2010 20:05: Yes, as the Garmin map resolution is approx 2.2m, it is understandable for your road to have those dents. But the offset of the points look much bigger than 2.2m. And this doesn't explain, why the north-south ordering of the two points is in JOSM inverse to the ordering in Mapsource or on my Nuevi. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bridleway=Fussweg?
Dave F. schrieb am 06.02.2010 14:01: I now understand, I don't think so ;-) I was under the impression that a line or polygon in the TYP file could be used to represent multiple entities in the OSM data, but as the 'type of entity' name comes from that file, I have to create separate lines/polygons for each different one. A bit labourious. The name from the typ-file is only used, if the OSM does not have a name on is own. So for example in your typ-file the line 0x01 is called primary If you have a way in your OSM-data, wich is converted to a line 0x01 and which has a tag name=Examplestreet, than the resulting element in the garmin map will have the name Examplestreet. If you have another way in your OSM-data, wich is converted to a line 0x01 and which does not have a tag name=*, than the resulting element in the garmin map will have the name primary. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1540: Change the signature of resolveType so that continue
Steve Ratcliffe schrieb am 30.01.2010 16:13:
No it was just a mistake, I meant it is as if with_actions is always
given - I find the terminology very confusing! I would prefer that
continue not change the normal effect of the actions and there be a
without_actions (or no_carry_forward or no_propagate which would be more
descriptive of what happens) command that prevented the carry forward.
I would approve such a change. In my opinion the with_actions is the more
usual/natural case and so it should be the default.
I think, the command for the other case should still include actions, so that
it is clear, what is not propagated. Or perhaps a wording without a negation,
e.g. actions_only_here.
When I have the following lines in my style file
key1=value1 {set first_action=true}
key1=value1 {set second_action=true} [0x01 resolution 20 no_propagate continue]
first_action=true second_action!=true [0x02 resolution 20]
I would assume, that two lines will be created. I.e. the actions of the first
rule are propagated, and the actions of the second rule are only applied
locally. Do you agree?
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Polygon with barrier problem
Dave F. schrieb am 24.01.2010 03:47:
Could you explain the continue statement please. I couldn't find
anything on it in the wiki.
For each OSM-object mkgmap normally scans through all rules in your style file
and searches for the rule with the highest priority, i.e. the first rule, that
matches. This rule is executed, i.e. the corresponding garmin item is created,
and afterwards the nect OSM-object is processed.
If the applied rule contains a continue statement, e.g. highway=primary [0x01
resolution 20 continue], than mkgmap will apply this rule and afterwards
continue scanning the style file (right now it does not scan any additional
style files) for the next matching rule.
If the matching rule has also an actions part, e.g. {set oneway=yes}, than this
part is only applied to the garmin element created by this rule and not for the
following elements created from the same OSM item If you use instead of
continue the continue with_actions statement, than the action part is
applied to the actual item as well as to all follwing items.
The best example for the continue statement is a node, which is tagged as
restaurant and as hotel at the same time. Without continue statement you can
only get one garmin element, either a hotel or a restaurant. With the continue
statement you can get both at the same time.
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Felix Hartmann schrieb am 22.01.2010 16:24:
Well until 1497 auxiliary tags worked, now they are broken. I tried it
too. At least if you provide a list of say 15 auxiliary keys. Maybe only
one or two are parsed???
I can't really comment on the latest changes, since my main styles are depending
on the correct execution of the action rules, which is only done by the style
branch.
My styles are much more simple than yours, but nevertheless I will never build
such complex. Instead of checking
( highway=primary | highway=secondary | highway=tertiary | highway=minor |
highway=unclassified ) ...
in a single rule, I use something like the following:
highway=primary {set road_usable=yes}
highway=secondary {set road_usable=yes}
highway=tertiary {set road_usable=yes}
highway=minor {set road_usable=yes}
highway=unclassified {set road_usable=yes}
highway=* road_usable!=* {set road_usable=no}
Now in the following rules I just have to check
highway=* road_usable=yes ...
Based on my experiance this gives much more maintainable style rules. Because if
I have to change the conditions for the auxiliary tag, e.g. I have to include
another road type, then I just have to change the rules where the road_usable
flag is set and all concerned output rules can stay unchanged.
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Felix Hartmann schrieb am 22.01.2010 16:30:
highway=* copy=99 mtb:scale:uphill!=5 mtb:scale:uphill!=4 {
set dontadd=yes; set taxi=no; set dontadd=oneway; set mkgmap:unpaved=1
}[0x10711 resolution 21 continue with_actions] *output*
Actually, what is the difference between continue with_actions and continue?
I think I have never really understood, which version must be used in what case.
Can you provide an easy example, wich demonstrates the different results,
whether the with_actions flag is used or not?
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Polygon with barrier problem
Dave F. schrieb am 22.01.2010 19:03: In my line style: barrier=wall In my polygon style: landuse=farmyard barrier=wall landuse=farmyard What do I need to do to get it to render? I think, right now it is not possible, to get from one garmin element a polygon as well as a line in the map. A possible solution is to get rid of the wall. You could change your line style to barrier=wall landuse!=*, so that a wall line will not be generated, if there is also a landuse tag. Or another solution is to place two lap layers above each other. You can generate one map with the landuse polygon, and on top of that (with a higher draw_priority and with the transparent flag) you can put a second map containing the wall line. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question on license for style-file
Felix Hartmann schrieb am 21.01.2010 02:31: I already had quite a few ideas/concepts copied by Garmin map compilers (e.g. using assymetric transparent lines - which was so forgotten by Garmin or not intended that they stopped supporting it until copying many parts for the Garmin Transalpin - if you look at their typfile it really shows many traces of the typfiles I used when starting my then called mtb maps on the osm wiki, or first versions of my openmtbmap.). I can't really understand your problem. For once, in my the eyes the ideas/concepts your are mentioning not so groundbraking, that nobody else is able to think of them. (Today they might still be good enough for a patent :-) I really admit your work, but i think the greatest part is not getting the ideas but getting everything done. So I would not say that somebody copied your ideas/concepts, i would rather say that they were inspired by your work. Above you write, that some of your concepts were forgotten by Garmin. So actually you are also copying their ideas :-) And as a second point, why do you worry about someone copying your work as closed source? It is certainly not nice, but is it really a problem? If you give away your maps for free (free beer as well as really free), what would change, if Garmin would sell identical maps for money? They will make some money, but you will not loose any money. I do not care if anybody earns some money with the aid of my free contributions, as long as my work is still available for free to other people. It migth look different, if you want to earn some money yourself with your maps. But then the problem would not be, to stop other companies yousing your work in a closed source manner, but to stop other people using your work at all. By the way, I think you could earn some money (not much but at least some), if you would sell ready to use flash-cards with your maps on ebay. You could sell them with the recquired free-to-copy license, since most buyers wouldn't bother about copying, if they could by an actual map for perhaps 10 or 15EUR. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Felix Hartmann schrieb am 21.01.2010 13:51: This has come since the latest additions to the style-file rules. And once again I plead for a resurrection of the style branch, so that we can clean-up the style handling of mkgmap. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Steve Ratcliffe schrieb am 21.01.2010 18:26: OK I shall start on it very soon. That's great news for me, Steve. Thanks! Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Felix Hartmann schrieb am 21.01.2010 19:07: I wouldn't see (except the strange handling of oneway=reverse - but maybe there is some error on my side) any strange behaviour with the trunk currently. We had quite some topics lately, e.g. that you can not use the same expression twice, or that two independent style rules only worked, when they were arranged in a specific order. Basically I think, that you have fine-tuned your style to the current style handling of the trunk. If there was a problem in the style handling, it was not fixed but you found a way around it. Well continue never worked in any way predictable and my maps were output with half of the lines missing, routing broken,. I guess, this was caused by some of your workarounds, which were based on errors in the trunk's style interpretation. In my experience the style brunch provides every capability of the continue patch, but some of the rules must be rephrased (actually they must be corrected) so that they would work as before. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] overlays file for POIs
Felix Hartmann schrieb am 18.01.2010 15:42: The style branch never worked with continue at all, that was the main problem. At least for me. I can not confirm this. I am using the style branch combined with the continue statement. The style branch is not 100% error free, but in my opinion its style handling is never worse than the trunk. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Split barrier=* and traffic_calming=* to a separate layer?
Marko Mäkelä schrieb am 13.01.2010 10:05: I am not suggesting that mkgmap should generate multi-layered maps by default. What I would like to have is a simple set of scripts and styles that users could adapt. Currently, several people have built multi-layered maps and many have not released the scripts. Having open source scripts (and later TYP files) would better follow the spirit of OpenStreetMap. I think the problem I not, that most map generating people haven't released their scripts. The real problem is, to find these scripts. I do not think, that a set of such scripts should be included into mkgmap. It is too much overhead for the different style developer to keep their scripts in the mkgmap repository up to date. A much better solution would be a central page in the OSM-wiki, where you would get an overview of the different styles and a link to the corresponding script files. There is already an overview page for complete garmin maps (but I do not know, how up to date this page ist). Perhaps it would be a good idea to add a special section to this page containing not the complete maps but only style related files for selfmade mapbuilding. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multiple .img files in one gmapsupp.img: Some will not show up
Simon Eugster schrieb am 09.01.2010 19:33: Any idea? Anyone? :) Actually I have no idea, why every tile of your map gets its own family-ID. I am not sure whether this is related to your problem, but typically all maps belonging to the same mapset (or layer) get all the same family-ID. And normally the family-ID is uch lower than your values, typically in the two digit range. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
