[PATCH] --ignore-builtin-relations
There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}). This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes. OK to commit this? Marko
Hi, Am 16.04.2011 11:27, schrieb Marko Mäkelä:
There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}).
This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes.
OK to commit this?
+1 -- PGP Schlüssel: 311D1055 http://keyserver.pgp.com
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 when using this option, correct? So it's a quick and dirty hack to speedup mapprocessing. On 16.04.2011 11:27, Marko Mäkelä wrote:
There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}).
This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes.
OK to commit this?
Marko
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
On 16.04.2011 16:23, Torsten Leistikow wrote:
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.
okay, that should be clearer in the description. But hiking routes are often relations, or superrelations. Would it be wise then to use that option? For the other usage cases I see the advantage (but I don't think it will help at all with contour lines, as in how can there be a speedup if no relation data is present in the data anyhow).
Am 16.04.2011 16:13, schrieb Felix Hartmann:
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 when using this option, correct?
So it's a quick and dirty hack to speedup mapprocessing.
I don't think so. In German there is a region, where someone uses relations for simple buildings and areas, with the effect that Merkaartor has a problem to show them correct. Or, a member of a relation is a highway and the relation itself has tag highway=.. both ways lie upon each other. Maybe there can be solution in the styles. But this is to high for me.
On 16.04.2011 11:27, Marko Mäkelä wrote:
There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}).
This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes.
OK to commit this?
Marko
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- PGP Schlüssel: 311D1055 http://keyserver.pgp.com
Am 16.04.2011 17:10, schrieb Josef Latt:
Or, a member of a relation is a highway and the relation itself has tag highway=.. both ways lie upon each other. Maybe there can be solution in the styles. But this is to high for me.
Example for the above und BTW I don't understand the scope of such constructs. http://www.openstreetmap.org/?lat=50.5721489&lon=7.2946530&zoom=18 -- PGP Schlüssel: 311D1055 http://keyserver.pgp.com
On Sun, Apr 17, 2011 at 09:04:18AM +0200, Josef Latt wrote:
Am 16.04.2011 17:10, schrieb Josef Latt:
Or, a member of a relation is a highway and the relation itself has tag highway=.. both ways lie upon each other. Maybe there can be solution in the styles. But this is to high for me.
Example for the above und BTW I don't understand the scope of such constructs. http://www.openstreetmap.org/?lat=50.5721489&lon=7.2946530&zoom=18
I downloaded this in JOSM. The landuse=residential multipolygon http://www.openstreetmap.org/browse/relation/1535811 looks incorrect. I guess that you are referring to the highway=pedestrian multipolygon on the west. Its west border is a way that has highway=service. Pedestrian areas are a normal thing to have, but I would not use highways as area borders. The highway line should be drawn on the centerline of way, and I would expect the pedestrian plaza to be separated from the centerline of the highway=service in some way. Either the highway=service way is completely inside the highway=pedestrian area, or the highway=service way should be completely outside the pedestrian area. In other words, this looks like bad mapping. If you feed this to any software, you can expect GIGO (garbage in, garbage out). Marko
Am 17.04.2011 10:21, schrieb Marko Mäkelä:
On Sun, Apr 17, 2011 at 09:04:18AM +0200, Josef Latt wrote:
Am 16.04.2011 17:10, schrieb Josef Latt:
Or, a member of a relation is a highway and the relation itself has tag highway=.. both ways lie upon each other. Maybe there can be solution in the styles. But this is to high for me.
Example for the above und BTW I don't understand the scope of such constructs. http://www.openstreetmap.org/?lat=50.5721489&lon=7.2946530&zoom=18
I downloaded this in JOSM. The landuse=residential multipolygon http://www.openstreetmap.org/browse/relation/1535811 looks incorrect.
I guess that you are referring to the highway=pedestrian multipolygon on the west. Its west border is a way that has highway=service. Pedestrian areas are a normal thing to have, but I would not use highways as area borders. The highway line should be drawn on the centerline of way, and I would expect the pedestrian plaza to be separated from the centerline of the highway=service in some way. Either the highway=service way is completely inside the highway=pedestrian area, or the highway=service way should be completely outside the pedestrian area.
Yes, that's one thing. The other is the complete construct, which consists of 3 relations. IMHO an overkill as well as other simple areas in this region which are mapped as multipolygons. I would prefer, mapping the hole area as amenity=school and highways and building on it. Because of those constructs I voted for this option meaning that than I have in may card only the highways. The multipolygons are drawn with ways without tags. Are they gone too with this patch: When not how can I do this?
In other words, this looks like bad mapping. If you feed this to any software, you can expect GIGO (garbage in, garbage out).
ACK Josef -- PGP Schlüssel: 311D1055 http://keyserver.pgp.com
On Sun, Apr 17, 2011 at 11:45:40AM +0200, Josef Latt wrote:
The multipolygons are drawn with ways without tags. Are they gone too with this patch: When not how can I do this?
I'm not sure if it is sane to disable all multipolygon processing. With my patch, the multipolygon processing would be gone. In fact, in the posted form, all relations would be gone (see my earlier reply today for the right patch). My intention is to disable the multipolygon and turn-restriction processing when processing additional layers. On my map, I would like to generate a map with the default style as the "main" map. All the "bells and whistles" would be enabled when generating the main layer. On top of the map layer, I would generate a number of transparent layers: * foot and hiking routes * bicycle routes (lcn, ncn, etc.) * bus routes * rail routes (train, tram, subway) * ferry routes * ski routes (not sure if I am going to generate this for my map, but it should not be too much data) I would not be generating road network relations, as I find them unnecessary clutter on the tiny GPS display. For the rare occasion when you want to follow a historic route or something, you can generate a special map containing just that route, or load the route in GPX format. These layers would be enabled or disabled by the user when needed. Most of the time, it would make sense to enable the display of zero or one layers. The style rules for these layers are extremely simple: just one rule in the "relations" file and another in the "lines" file.
In other words, this looks like bad mapping. If you feed this to any software, you can expect GIGO (garbage in, garbage out).
ACK
BTW, I think that mkgmap should be able to complain something about the area. I generate the map of Finland almost every day and fix all mkgmap reported errors. Maybe you could start doing something similar in your home city, province or state (whole Germany would be too much for one person). Best regards, Marko
On Sat, Apr 16, 2011 at 04:13:36PM +0200, Felix Hartmann wrote:
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).
For what it is worth, I tested the option with styles derived from --style=routes. The styles only contain a "relations" and a "lines" file, and they were processed just fine. The style-driven processing of relations is not affected by the option. The option only disables the built-in processing of relations, which is independent of the style definition. Marko
There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}).
This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes.
OK to commit this?
Marko
I don't want to veto this option but I really don't like it. I assume that processing of multipolygons take most of the 30s saved time. So maybe we could better think of how to avoid unneccessary multipolygon processings. Commits for r1913 and r1914 were a first small step but I think some more of these will be possible. Some ideas: * The polygon tags of the style maybe could additionally be used by the mp processing to check if it makes sense to process the mp. * More of the tags used in the builtin-tags file could be loaded dynamically. This reduces the number of mp processing. E.g. addr:* tags make sense only if the index option is set or if they are referenced in the style files. * The HighwayHook uses lots of tags. Maybe the highway hook makes sense only if some mkgmap option are set? --net, --route? * Some tags are used statically in the StyleConverter. Maybe this processing makes sense only if some special mkgmap options are set? Then these tags could be removed from the builtin-tags-file and some mps would no longer be processed. Your simple layer map is a good test case to remove and detect unneccessary mkgmap actions. Let's find out and remove them instead of using the new main off-switch ignore-builtin-relations with some possible non-intutional side effects. WanMil
On Sat, Apr 16, 2011 at 08:59:57PM +0200, WanMil wrote:
I assume that processing of multipolygons take most of the 30s saved time.
All of it, because the baseline was --ignore-turn-restrictions. I do not like extra knobs either. They would be contradictory to our aim of simplifying the command line options.
So maybe we could better think of how to avoid unneccessary multipolygon processings. Commits for r1913 and r1914 were a first small step but I think some more of these will be possible.
Sure, that would benefit the processing of all styles.
* The polygon tags of the style maybe could additionally be used by the mp processing to check if it makes sense to process the mp.
This sounds reasonable. If there are no polygon rules, that should hopefully throw out most multipolygons. But this would still imply some overhead.
* More of the tags used in the builtin-tags file could be loaded dynamically. This reduces the number of mp processing. E.g. addr:* tags make sense only if the index option is set or if they are referenced in the style files.
Actually, addr:* are added to POI details even without --index. Select a POI, and you will see addr:* and phone if they are set. (That reminds me, we should start supporting contact:phone.)
* The HighwayHook uses lots of tags. Maybe the highway hook makes sense only if some mkgmap option are set? --net, --route?
I guess that we should remove the --make-opposite-cycleways option, and add the corresponding rules to the default style. The fixme/FIXME node tags and mkgmap:dead-end-check are only needed when --report-dead-ends is set, so that warnings about certain dead-end oneways can suppressed. By the way, do we keep a collection of the needed tags based on element type? The FIXME or fixme would only apply to nodes (end nodes of a oneway), not to ways or relations. Generally, ways (polygons) and relations (multipolygons) would inherit the set of needed tags from nodes if --add-pois-to-areas is set. But the FIXME processing in HighwayHooks only applies to real (not generated) nodes.
* Some tags are used statically in the StyleConverter. Maybe this processing makes sense only if some special mkgmap options are set?
I guess that the access tags depend on --net or --route.
Your simple layer map is a good test case to remove and detect unneccessary mkgmap actions. Let's find out and remove them instead of using the new main off-switch ignore-builtin-relations with some possible non-intutional side effects.
Good idea. If we can improve the execution speed so that omitting --ignore-builtin-relations would grow execution time by less than 1% (it currently grows the time by 25%), then it is not reasonable to add yet another option. If a justification for --ignore-builtin-relations remains, instead of introducing the command line option we could perhaps coin a style attribute that says which internal processing is needed. I would imagine that for transparent map layers that only add some points or non-routeable lines but no polygons, you would not need any of the fancy processing, such as --index, --route, --net, --dead-end-check, --generate-sea, multipolygon/boundary/restriction relations. Best regards, Marko
On Sat, Apr 16, 2011 at 12:27:30PM +0300, Marko Mäkelä wrote:
Index: src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java =================================================================== --- src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java (revision 1916) +++ src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java (working copy) @@ -145,6 +147,9 @@ public class ElementSaver { * @param rel The osm relation. */ public void addRelation(Relation rel) { + if (ignoreBuiltinRelations) + return; + String type = rel.getTag("type"); if (type != null) { if ("multipolygon".equals(type) || "boundary".equals(type)) {
Sorry, this was a brain-fart. Initially, I had the check like this: - String type = rel.getTag("type"); + String type = ignoreBuiltinRelations ? null : rel.getTag("type"); But then I confused the type != null check with the rel != null later in the function. Interestingly, the execution time is about the same, even if the processing of all relations is skipped. There are not that many route relations in my map, after all. My initial tests were with the correct patch yielded the largest .img file for the bus routes, about 900 kB. Other .img files were smaller, starting from 15 kB. The empty .img files produced by this incorrect patch are 9728 bytes. The whole gmapsupp.img is about 90 MB. Sorry for the confusion, Marko
On Sat, Apr 16, 2011 at 12:27:30PM +0300, Marko Mäkelä wrote:
There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}).
This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes.
Here is a corrected, tested version of the patch. Meanwhile, it takes 2.5 minutes to process --style=routes-bus on finland.osm.pbf with this patch applied. OK to commit? Marko
Marko, I do not like that very much because relations are now a very common element of OSM and you need to know in detail what you are doing if you set this option. From my point of view it makes sense only if the polygons file of the style file is empty. So why do we need the option? What about adding a simple check if the polygons style file is empty? Anyhow I would change the name of the tag to --ignore-relations. That's what the patch is doing (as far as I understand): do nothing with relations. WanMil
On Sat, Apr 16, 2011 at 12:27:30PM +0300, Marko Mäkelä wrote:
There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}).
This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes.
Here is a corrected, tested version of the patch. Meanwhile, it takes 2.5 minutes to process --style=routes-bus on finland.osm.pbf with this patch applied.
OK to commit?
Marko
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Anyhow I would change the name of the tag to --ignore-relations. That's what the patch is doing (as far as I understand): do nothing with relations.
I think I am wrong?!? You want to have some relation processing in the relations style file, correct? But what do you think of the idea to check if there is any polygon rule? Mmh, this is also not a 100% idea. The mp processing creates ways tagged with the mp tags so that they can be processed by the ways file. Example: you want to draw the borders of boundaries. So there will be no polygon rule if someone wants to create a border layer but the multipolygon processing is still required. Ok, so I have no more objections against committing. Could you please add some more description what the option is for? And maybe a warning hint and/or an example when it is a good or a bad choice to use it? WanMil
WanMil
On Sat, Apr 16, 2011 at 12:27:30PM +0300, Marko Mäkelä wrote:
There is an option to disable the processing of turn restriction relations (--ignore-turn-restrictions), but no option to disable the processing of multipolygon relations. The attached patch introduces --ignore-builtin-relations, which disables the built-in processing of all relations (currently, type={boundary,multipolygon,restiction}).
This patch reduces the processing time of my simple map layers from 2.5 minutes to 2 minutes.
Here is a corrected, tested version of the patch. Meanwhile, it takes 2.5 minutes to process --style=routes-bus on finland.osm.pbf with this patch applied.
OK to commit?
Marko
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Thu, Aug 25, 2011 at 11:43:06PM +0200, WanMil wrote:
I think I am wrong?!? You want to have some relation processing in the relations style file, correct?
Right. I would like to disable the built-in (non-style-file) processing of relations when creating auxiliary map layers, meant to be enabled or disabled on the device as needed. I have defined a number of routes-* styles for highlighting various route relations. Typically, you would not want to display all types of routes at the same time. For example, it is not likely to be useful to display bus and bicycle routes at the same time. I think that the turn restrictions only need to be processed for the layer(s) that are used for routing. Or, in other words, the absence of --route or --net should imply --ignore-turn-restrictions.
But what do you think of the idea to check if there is any polygon rule? Mmh, this is also not a 100% idea. The mp processing creates ways tagged with the mp tags so that they can be processed by the ways file. Example: you want to draw the borders of boundaries. So there will be no polygon rule if someone wants to create a border layer but the multipolygon processing is still required.
Right, I was thinking roughly along the same lines. I am not sure, but would it be possible to skip the multipolygon processing of type=boundary relations when you only want to draw boundary lines (no polygons)?
Ok, so I have no more objections against committing. Could you please add some more description what the option is for? And maybe a warning hint and/or an example when it is a good or a bad choice to use it?
OK, I will extend the help file description if we go along this route. In other news, there are more and more boundaries being defined for Finland. I think I will soon have to switch to --index and generating the map with MapSource. Currently, I am using mkgmap r2001, so that I get the half-broken way search with reasonable city names. After r2008 (the branches/location merge) without --index, all streets seem to be assigned to one town (Nurmijärvi), even though the boundaries are valid. Marko
On Thu, Aug 25, 2011 at 11:43:06PM +0200, WanMil wrote:
I think I am wrong?!? You want to have some relation processing in the relations style file, correct?
Right. I would like to disable the built-in (non-style-file) processing of relations when creating auxiliary map layers, meant to be enabled or disabled on the device as needed. I have defined a number of routes-* styles for highlighting various route relations. Typically, you would not want to display all types of routes at the same time. For example, it is not likely to be useful to display bus and bicycle routes at the same time.
I think that the turn restrictions only need to be processed for the layer(s) that are used for routing. Or, in other words, the absence of --route or --net should imply --ignore-turn-restrictions.
Sounds reasonable although I think it does not make a noticable difference. But if turn restrictions are not processed the tags used for it need not be loaded. Maybe that's a noticable improvement. One should test it. Compare processing time: 1. Compile a map without --route or --net with the CVS version 2. Compile the same map but remove the turn-restrictions tag from the builtin-tag-list file. The tags to remove are: restriction except exception
But what do you think of the idea to check if there is any polygon rule? Mmh, this is also not a 100% idea. The mp processing creates ways tagged with the mp tags so that they can be processed by the ways file. Example: you want to draw the borders of boundaries. So there will be no polygon rule if someone wants to create a border layer but the multipolygon processing is still required.
Right, I was thinking roughly along the same lines.
I am not sure, but would it be possible to skip the multipolygon processing of type=boundary relations when you only want to draw boundary lines (no polygons)?
I don't think so. I am not up2date what the latest recommendations in the wiki are but if the boundaries follow the multipolygon rules the ways itself should not be tagged (although it is tolerated and mostly done). So without the mp processing you get lots of ways without any tags. I give an exmaple for another: http://www.openstreetmap.org/browse/way/27503381 It is tagged with admin_level = 7 boundary = administrative but is a member of 4 boundaries (2 x 7 and 2 x 8). So in the end you get 4 lines with distinct border information but only if multipolygons are processed. Maybe you can do that with the relations style file too? I don't know.
Ok, so I have no more objections against committing. Could you please add some more description what the option is for? And maybe a warning hint and/or an example when it is a good or a bad choice to use it?
OK, I will extend the help file description if we go along this route.
In other news, there are more and more boundaries being defined for Finland. I think I will soon have to switch to --index and generating the map with MapSource. Currently, I am using mkgmap r2001, so that I get the half-broken way search with reasonable city names. After r2008 (the branches/location merge) without --index, all streets seem to be assigned to one town (Nurmijärvi), even though the boundaries are valid.
r2001 is from the locator branch, isn't it? Is there any special reason why you use the locator branch without --index? There should be no advantage to the trunk without --index.
Marko
WanMil
On Fri, Aug 26, 2011 at 07:02:53PM +0200, WanMil wrote:
Compare processing time: 1. Compile a map without --route or --net with the CVS version 2. Compile the same map but remove the turn-restrictions tag from the builtin-tag-list file. The tags to remove are: restriction except exception
OK, I will test this with --style=route-foot or some other sparse style. Actually, the --ignore-builtin-relations should be improved to remove these tags (as well as boundary and multipolygon) from the builtin-tags-list too.
I am not sure, but would it be possible to skip the multipolygon processing of type=boundary relations when you only want to draw boundary lines (no polygons)?
I don't think so. I am not up2date what the latest recommendations in the wiki are but if the boundaries follow the multipolygon rules the ways itself should not be tagged (although it is tolerated and mostly done). So without the mp processing you get lots of ways without any tags.
Only the built-in processing of type=boundary relations would be affected. If the style rules specify some processing for boundaries, then that should still be applied. What does the built-in processing of type=boundary relations actually do? Does it have any effect if the style does not define any polygon rules for boundaries?
I give an exmaple for another: http://www.openstreetmap.org/browse/way/27503381 It is tagged with admin_level = 7 boundary = administrative
but is a member of 4 boundaries (2 x 7 and 2 x 8). So in the end you get 4 lines with distinct border information but only if multipolygons are processed. Maybe you can do that with the relations style file too? I don't know.
I think I did implement this in the default style a year or more ago. This is what the style actions do in the relations file: (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } } The $() syntax is something that I implemented. It will apply all the names from the relations on the relation members. And this is the relevant rule from the lines file: boundary=administrative { name '${mkgmap:boundary_name}' }
In other news, there are more and more boundaries being defined for Finland. I think I will soon have to switch to --index and generating the map with MapSource. Currently, I am using mkgmap r2001, so that I get the half-broken way search with reasonable city names. After r2008 (the branches/location merge) without --index, all streets seem to be assigned to one town (Nurmijärvi), even though the boundaries are valid.
r2001 is from the locator branch, isn't it?
No, r2001 from trunk is the last revision before the location branch was merged to trunk. It was merged in r2008.
Is there any special reason why you use the locator branch without --index? There should be no advantage to the trunk without --index.
The special reason is my reluctance to use a closed-source Windows program on my Linux system. As far as I can see, there is an advantage of using the old trunk. It will apparently assign streets in the street search index to the closest place node. The location branch merge would assign each street around my area to addr:postcode=01900 addr:city=Nurmijärvi. I have not checked if the city assignment is different in other tiles. I do know that the street search requires --index in order to work properly on most devices. The street search sort-of works on the Edge 705 if I enter any housenumber (such as 1) and a street name. Then I get to select the street and city (I guess the list is from the current tile, or from a 100km radius or so). The location of the street will about mid-way in the street (or way segment). Best regards, Marko
On Fri, Aug 26, 2011 at 07:02:53PM +0200, WanMil wrote:
Compare processing time: 1. Compile a map without --route or --net with the CVS version 2. Compile the same map but remove the turn-restrictions tag from the builtin-tag-list file. The tags to remove are: restriction except exception
OK, I will test this with --style=route-foot or some other sparse style. Actually, the --ignore-builtin-relations should be improved to remove these tags (as well as boundary and multipolygon) from the builtin-tags-list too.
I think it should be the other way round. Remove the tags from the builtin-tag-list and add it to the list of used tags if the tags are required. That's the common behaviour of all other hooks and styles.
I am not sure, but would it be possible to skip the multipolygon processing of type=boundary relations when you only want to draw boundary lines (no polygons)?
I don't think so. I am not up2date what the latest recommendations in the wiki are but if the boundaries follow the multipolygon rules the ways itself should not be tagged (although it is tolerated and mostly done). So without the mp processing you get lots of ways without any tags.
Only the built-in processing of type=boundary relations would be affected. If the style rules specify some processing for boundaries, then that should still be applied. What does the built-in processing of type=boundary relations actually do? Does it have any effect if the style does not define any polygon rules for boundaries?
There is no difference between boundary relations and multipolygon relations at the moment.
I give an exmaple for another: http://www.openstreetmap.org/browse/way/27503381 It is tagged with admin_level = 7 boundary = administrative
but is a member of 4 boundaries (2 x 7 and 2 x 8). So in the end you get 4 lines with distinct border information but only if multipolygons are processed. Maybe you can do that with the relations style file too? I don't know.
I think I did implement this in the default style a year or more ago. This is what the style actions do in the relations file:
(type=boundary | type=multipolygon)& boundary=administrative& name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } }
The $() syntax is something that I implemented. It will apply all the names from the relations on the relation members.
And this is the relevant rule from the lines file:
boundary=administrative { name '${mkgmap:boundary_name}' }
In other news, there are more and more boundaries being defined for Finland. I think I will soon have to switch to --index and generating the map with MapSource. Currently, I am using mkgmap r2001, so that I get the half-broken way search with reasonable city names. After r2008 (the branches/location merge) without --index, all streets seem to be assigned to one town (Nurmijärvi), even though the boundaries are valid.
r2001 is from the locator branch, isn't it?
No, r2001 from trunk is the last revision before the location branch was merged to trunk. It was merged in r2008.
Mmmh, http://www.mkgmap.org.uk/svn/wsvn/mkgmap/?op=log&isdir=1& shows the log of the trunk without any revision between 1995 and 2008.
Is there any special reason why you use the locator branch without --index? There should be no advantage to the trunk without --index.
The special reason is my reluctance to use a closed-source Windows program on my Linux system. As far as I can see, there is an advantage of using the old trunk. It will apparently assign streets in the street search index to the closest place node. The location branch merge would assign each street around my area to addr:postcode=01900 addr:city=Nurmijärvi. I have not checked if the city assignment is different in other tiles.
There should be no difference regarding address search between revisions before and after merging the locator branch as long as you define --location-autofill=XXX where XXX does not contain "bounds". Can you please check if you see a difference? If so it would be good to check why there is a difference. WanMil
I do know that the street search requires --index in order to work properly on most devices. The street search sort-of works on the Edge 705 if I enter any housenumber (such as 1) and a street name. Then I get to select the street and city (I guess the list is from the current tile, or from a 100km radius or so). The location of the street will about mid-way in the street (or way segment).
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Fri, Aug 26, 2011 at 09:15:02PM +0200, WanMil wrote:
On Fri, Aug 26, 2011 at 07:02:53PM +0200, WanMil wrote:
Compare processing time: 1. Compile a map without --route or --net with the CVS version 2. Compile the same map but remove the turn-restrictions tag from the builtin-tag-list file. The tags to remove are: restriction except exception
OK, I will test this with --style=route-foot or some other sparse style. Actually, the --ignore-builtin-relations should be improved to remove these tags (as well as boundary and multipolygon) from the builtin-tags-list too.
I think it should be the other way round. Remove the tags from the builtin-tag-list and add it to the list of used tags if the tags are required. That's the common behaviour of all other hooks and styles.
OK, that makes sense. Here are 3 test runs: First, without --ignore-builtin-relations, not touching builtin-tags-list: time java -Xmx1024m -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --product-id=1 --code-page=1252 --adjust-turn-headings --remove-short-arcs --country-abbr=FIN --country-name=Finland --family-id=2 --family-name=foot --transparent --mapname=61241000 --description=foot --style=routes-foot finland.osm.pbf real 4m35.303s user 4m24.981s sys 0m2.176s Second, with --ignore-builtin-relations, not touching builtin-tags-list: time java -Xmx1024m -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --product-id=1 --code-page=1252 --adjust-turn-headings --remove-short-arcs --country-abbr=FIN --country-name=Finland --family-id=2 --family-name=foot --transparent --ignore-builtin-relations --mapname=60241000 --description=foot --style=routes-foot finland.osm.pbf real 2m47.759s user 2m39.870s sys 0m1.932s Third, with --ignore-builtin-relations, and with the reduced builtin-tags-list: time java -Xmx1024m -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --product-id=1 --code-page=1252 --adjust-turn-headings --remove-short-arcs --country-abbr=FIN --country-name=Finland --family-id=2 --family-name=foot --transparent --ignore-builtin-relations --mapname=62241000 --description=foot --style=routes-foot finland.osm.pbf real 2m46.723s user 2m40.770s sys 0m1.876s The longest run (without --ignore-builtin-relations) did generate some log: warnings about turn restrictions and multipolygons. Curiously, reducing the builtin-tags-list does not seem to cause any difference, or the difference is smaller than the variation (noise) in the execution times. I guess that there are relatively few turn restriction relations in the input data.
Only the built-in processing of type=boundary relations would be affected. If the style rules specify some processing for boundaries, then that should still be applied. What does the built-in processing of type=boundary relations actually do? Does it have any effect if the style does not define any polygon rules for boundaries?
There is no difference between boundary relations and multipolygon relations at the moment.
With the default style, do you have an example where the built-in processing of boundary relations as multipolygons affects the result?
No, r2001 from trunk is the last revision before the location branch was merged to trunk. It was merged in r2008.
Mmmh, http://www.mkgmap.org.uk/svn/wsvn/mkgmap/?op=log&isdir=1& shows the log of the trunk without any revision between 1995 and 2008.
Sorry, I was being inaccurate. Indeed, svn info says that 1995 is the last changed revision. I am using http://svn.parabola.me.uk/mkgmap/trunk/, effectively r1995.
There should be no difference regarding address search between revisions before and after merging the locator branch as long as you define --location-autofill=XXX where XXX does not contain "bounds".
OK, I am guilty of not defining --location-autofill. Thanks for the hint, I will try to add it. There are broken boundaries in finland.osm.pbf, but both Nurmijärvi and my home city Vantaa are correct. That is why I was suspecting some bug. Anyway, as long as there are any broken boundaries in the input, I think that you can legitimately claim "garbage in, garbage out". Marko
On Fri, Aug 26, 2011 at 10:51:14PM +0300, Marko Mäkelä wrote:
There should be no difference regarding address search between revisions before and after merging the locator branch as long as you define --location-autofill=XXX where XXX does not contain "bounds".
OK, I am guilty of not defining --location-autofill. Thanks for the hint, I will try to add it.
Indeed, setting --location-autofill=nearest works in the old way. Thanks for the hint! Marko
participants (5)
-
Felix Hartmann -
Josef Latt -
Marko Mäkelä -
Torsten Leistikow -
WanMil