splitter: relations to be checked with keep-complete=true
Hi, splitter r260 with --keep-complete=true puts all members of all intersecting relations and all subrelations into a tile. This leads to "interesting" data in tiles, e.g. if a tile is crossed by an e-road (e.g. E 35 http://www.openstreetmap.org/browse/relation/2148378) the complete e-road is added to the tile. I think this is not required as long as mkgmap is not able to handle all of such relations: * subrelations: I think subrelations are not handled by mkgmap so they can be ignored completely by keep-complete. (Keep the code, sometime mkgmap will handle them ;-) * relations: I found code for the following relation types only: multipolygon boundary (is ignored by splitter?) restriction through_route I think all other relations can be ignored by keep-complete. (I don't know about the special marine code...) What do you think about? Any objections? WanMil
Am 16.12.2012 13:26, schrieb WanMil:
Hi,
splitter r260 with --keep-complete=true puts all members of all intersecting relations and all subrelations into a tile. This leads to "interesting" data in tiles, e.g. if a tile is crossed by an e-road (e.g. E 35 http://www.openstreetmap.org/browse/relation/2148378) the complete e-road is added to the tile.
I think this is not required as long as mkgmap is not able to handle all of such relations:
* subrelations: I think subrelations are not handled by mkgmap so they can be ignored completely by keep-complete. (Keep the code, sometime mkgmap will handle them ;-)
* relations: I found code for the following relation types only: multipolygon boundary (is ignored by splitter?) restriction through_route I think all other relations can be ignored by keep-complete. (I don't know about the special marine code...)
What do you think about? Any objections? A relation with route=ferry should be handled, because there are some (many ?) ferry-routes are tagged as such a relation and member are empty ways.
If superrelation are handled by splitter, I would keep this and improve mkgmap. Maybe type=route could be handled like type=boundary. So keep relation and all ways in a tile, which crossing the tile or have at least one node in the tile. Henning
A relation with route=ferry should be handled, because there are some (many ?) ferry-routes are tagged as such a relation and member are empty ways.
Can you give an example of such a route and how you work with it in mkgmap? Why must all parts of the relation be complete in a tile?
If superrelation are handled by splitter, I would keep this and improve mkgmap. Maybe type=route could be handled like type=boundary. So keep relation and all ways in a tile, which crossing the tile or have at least one node in the tile.
superrelations are not handled by mkgmap (AFAIK) so there is no need to handle them with splitter? Once there is a good reason to process them with mkgmap splitter should also handle them but not the other way round.
Henning
WanMil
Am 16.12.2012 13:46, schrieb WanMil:
A relation with route=ferry should be handled, because there are some (many ?) ferry-routes are tagged as such a relation and member are empty ways. Can you give an example of such a route and how you work with it in mkgmap? Why must all parts of the relation be complete in a tile? This example has no empty way, but only a waterway=seaway and two route=ferry-relation
http://www.openstreetmap.org/browse/way/124862398 I'm using in relations-file: type=route & route=ferry { apply { set route=ferry ; set rrk_name='$(rrk_name),${name}' | '${name}' } } and in lines: route=ferry & name=* { set mkgmap:ferry=yes } [0x1b road_class=3 road_speed=2 resolution 16] route=ferry & name!=* { set mkgmap:ferry=yes ; set name='${rrk_name}' } [0x1b road_class=3 road_speed=2 resolution 16] There is one problem unsolved: If way is tagged with a name and rrk_name is different (e.g. second ferry or two relations etc.), then name is taken only from the way. Henning
A relation with route=ferry should be handled, because there are some (many ?) ferry-routes are tagged as such a relation and member are empty ways. Can you give an example of such a route and how you work with it in mkgmap? Why must all parts of the relation be complete in a tile? This example has no empty way, but only a waterway=seaway and two route=ferry-relation
http://www.openstreetmap.org/browse/way/124862398
I'm using in relations-file: type=route & route=ferry { apply { set route=ferry ; set rrk_name='$(rrk_name),${name}' | '${name}' } }
and in lines: route=ferry & name=* { set mkgmap:ferry=yes } [0x1b road_class=3 road_speed=2 resolution 16] route=ferry & name!=* { set mkgmap:ferry=yes ; set name='${rrk_name}' } [0x1b road_class=3 road_speed=2 resolution 16]
You are copying tags from the relation to ways and the ways are converted as lines. That gives the need of complete ways but it doesn't matter if the relation is incomplete and some members not intersecting the tile bounding box are missing. So I can add a third rule to make it more clear: * subrelations: can be ignored by splitter * relations: only relations with type multipolygon, restriction and through_route must be complete. boundary relations are ignored. * member of relations: An element (way or a node) is part of a tile and the element belongs to a relation. This relation must also be put in the tile but the relation itself needn't be complete which means one or more members can be missing. Agree? WanMil
There is one problem unsolved:
If way is tagged with a name and rrk_name is different (e.g. second ferry or two relations etc.), then name is taken only from the way.
Henning
Attached is a patch for r263 that tries to implement WanMils proposals. Gerd
Date: Sun, 16 Dec 2012 22:07:17 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter: relations to be checked with keep-complete=true
A relation with route=ferry should be handled, because there are some (many ?) ferry-routes are tagged as such a relation and member are empty ways. Can you give an example of such a route and how you work with it in mkgmap? Why must all parts of the relation be complete in a tile? This example has no empty way, but only a waterway=seaway and two route=ferry-relation
http://www.openstreetmap.org/browse/way/124862398
I'm using in relations-file: type=route & route=ferry { apply { set route=ferry ; set rrk_name='$(rrk_name),${name}' | '${name}' } }
and in lines: route=ferry & name=* { set mkgmap:ferry=yes } [0x1b road_class=3 road_speed=2 resolution 16] route=ferry & name!=* { set mkgmap:ferry=yes ; set name='${rrk_name}' } [0x1b road_class=3 road_speed=2 resolution 16]
You are copying tags from the relation to ways and the ways are converted as lines. That gives the need of complete ways but it doesn't matter if the relation is incomplete and some members not intersecting the tile bounding box are missing.
So I can add a third rule to make it more clear: * subrelations: can be ignored by splitter * relations: only relations with type multipolygon, restriction and through_route must be complete. boundary relations are ignored. * member of relations: An element (way or a node) is part of a tile and the element belongs to a relation. This relation must also be put in the tile but the relation itself needn't be complete which means one or more members can be missing.
Agree?
WanMil
There is one problem unsolved:
If way is tagged with a name and rrk_name is different (e.g. second ferry or two relations etc.), then name is taken only from the way.
Henning
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
GerdP wrote
Attached is a patch for r263 that tries to implement WanMils proposals.
Stupid error: the patch did not filter type=route relations because route is contained in through_route. Here is the corrected version. limit_relation_types_v2.patch <http://gis.19327.n5.nabble.com/file/n5740697/limit_relation_types_v2.patch> The amount of removed data is quite big, so it would be nice if that still is all that we need for mkgmap. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-co... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi all, attached is version 4 of the patch, based on the problem-list branch. WanMil and I found out that it reduces the size of splitter output files (and run time) quite nice, but it also sometimes adds boundary relations that were not output with r263, which in turn changes the output of mkgmap a little bit. We are not sure if this is acceptable for all, so please try this. Gerd
Date: Mon, 17 Dec 2012 06:41:40 -0800 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter: relations to be checked with keep-complete=true
GerdP wrote
Attached is a patch for r263 that tries to implement WanMils proposals.
Stupid error: the patch did not filter type=route relations because route is contained in through_route. Here is the corrected version. limit_relation_types_v2.patch <http://gis.19327.n5.nabble.com/file/n5740697/limit_relation_types_v2.patch>
The amount of removed data is quite big, so it would be nice if that still is all that we need for mkgmap.
Ciao, Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-co... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I want to go a bit more into detail. Splitter now puts the following things into a tile (Gerd, please correct me if I am wrong ;-): 1. All nodes that are within the tiles bounding box 2. All ways that intersect the bounding box including all nodes (no matter if they are within the bbox) 3. All relations that contain a node or a way that is in the tile. These relations need not be complete. Some nodes or ways can be missing if they do not match the first two rules. Subrelations are not handled. Special rule: Relations of the following type are always complete: multipolygon restriction through_route In more simple words these rules put all data into the tile that lies directly in the tile or that might modify some data in the tile. Obviously this will generate some questions. - Why are subrelations not ignored? Subrelations are not handled by mkgmap so they can be ignored. - Shouldn't route relations be complete in the tile? Route relations contain ways. It is possible with the relations style file to modify ways and nodes based on the relation tags. But this makes sense only with ways and nodes lying within or intersecting the tile bounding box. - Shouldn't boundary relations like multipolygons be complete in the tile? Yes, but... Adding all related boundary data to a tile increases the tile size very much and makes sense only if the boundaries are used as polygons. At the moment we don't know anybody who uses boundaries as polygons but lots of users use them as lines to display the border names. All relevant data for this is available in the tile (some relations are missing with the current trunk version!). - Why are the tiles sizes noticeably smaller compared to the trunk version? The main reason is that the trunk version puts complete relations to the tile. If you have a motorway in the tile that is part of an e-road the trunk version adds the whole e-road to the tile although you need only the ways that intersect the bounding box. So my conclusion is: The patch fixes a (small) bug in the trunk version (some missing boundary relations) and optimizes the tile size by putting only data into the tile that theoretically can be used by mkgmap. If someone wants to test that more in detail I propose to run splitter with a small polygonfile, a small max-nodes number and xml output. Then you can open the tiles with JOSM and see if everything you would expect is contained in the tile. WanMil
Hi all,
attached is version 4 of the patch, based on the problem-list branch. WanMil and I found out that it reduces the size of splitter output files (and run time) quite nice, but it also sometimes adds boundary relations that were not output with r263, which in turn changes the output of mkgmap a little bit. We are not sure if this is acceptable for all, so please try this.
Gerd
Date: Mon, 17 Dec 2012 06:41:40 -0800 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter: relations to be checked with keep-complete=true
GerdP wrote
Attached is a patch for r263 that tries to implement WanMils proposals.
Stupid error: the patch did not filter type=route relations because route is contained in through_route. Here is the corrected version. limit_relation_types_v2.patch
<http://gis.19327.n5.nabble.com/file/n5740697/limit_relation_types_v2.patch>
The amount of removed data is quite big, so it would be nice if that
still
is all that we need for mkgmap.
Ciao, Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-co... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, thanks for the detailed explanation. One small addition: splitter does also check if a way is closed. If that is the case, it calculates the bbox of the way and writes the complete way to all tiles that intersect with its bbox. If the way is not closed, it calculates the intersection based on the line segments. The same kind of calculation is done for multipolygons. A precise implementation would use java.awt.geom.area for these calculations, but I fear that will be very time consuming and not much better. Gerd WanMil wrote
I want to go a bit more into detail.
Splitter now puts the following things into a tile (Gerd, please correct me if I am wrong ;-):
1. All nodes that are within the tiles bounding box 2. All ways that intersect the bounding box including all nodes (no matter if they are within the bbox) 3. All relations that contain a node or a way that is in the tile. These relations need not be complete. Some nodes or ways can be missing if they do not match the first two rules. Subrelations are not handled. Special rule: Relations of the following type are always complete: multipolygon restriction through_route
In more simple words these rules put all data into the tile that lies directly in the tile or that might modify some data in the tile.
Obviously this will generate some questions.
- Why are subrelations not ignored? Subrelations are not handled by mkgmap so they can be ignored.
- Shouldn't route relations be complete in the tile? Route relations contain ways. It is possible with the relations style file to modify ways and nodes based on the relation tags. But this makes sense only with ways and nodes lying within or intersecting the tile bounding box.
- Shouldn't boundary relations like multipolygons be complete in the tile? Yes, but... Adding all related boundary data to a tile increases the tile size very much and makes sense only if the boundaries are used as polygons. At the moment we don't know anybody who uses boundaries as polygons but lots of users use them as lines to display the border names. All relevant data for this is available in the tile (some relations are missing with the current trunk version!).
- Why are the tiles sizes noticeably smaller compared to the trunk version? The main reason is that the trunk version puts complete relations to the tile. If you have a motorway in the tile that is part of an e-road the trunk version adds the whole e-road to the tile although you need only the ways that intersect the bounding box.
So my conclusion is: The patch fixes a (small) bug in the trunk version (some missing boundary relations) and optimizes the tile size by putting only data into the tile that theoretically can be used by mkgmap.
If someone wants to test that more in detail I propose to run splitter with a small polygonfile, a small max-nodes number and xml output. Then you can open the tiles with JOSM and see if everything you would expect is contained in the tile.
WanMil
Hi all,
attached is version 4 of the patch, based on the problem-list branch. WanMil and I found out that it reduces the size of splitter output files (and run time) quite nice, but it also sometimes adds boundary relations that were not output with r263, which in turn changes the output of mkgmap a little bit. We are not sure if this is acceptable for all, so please try this.
Gerd
Date: Mon, 17 Dec 2012 06:41:40 -0800 From:
gpetermann_muenchen@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] splitter: relations to be checked with keep-complete=true
GerdP wrote
Attached is a patch for r263 that tries to implement WanMils proposals.
Stupid error: the patch did not filter type=route relations because route is contained in through_route. Here is the corrected version. limit_relation_types_v2.patch
<http://gis.19327.n5.nabble.com/file/n5740697/limit_relation_types_v2.patch&g...;
The amount of removed data is quite big, so it would be nice if that
still
is all that we need for mkgmap.
Ciao, Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-co... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-co... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I think this is not required as long as mkgmap is not able to handle all of such relations:
* subrelations: I think subrelations are not handled by mkgmap so they can be ignored completely by keep-complete. (Keep the code, sometime mkgmap will handle them ;-)
no problem, I can just comment out the call of markParentRels()
* relations: I found code for the following relation types only: multipolygon boundary (is ignored by splitter?) restriction through_route I think all other relations can be ignored by keep-complete. (I don't know about the special marine code...)
What do you think about? Any objections?
Up to now, splitter r260 doesn't ignore any relation. It just has a special handling for multipolygon relations to find enclosed tiles. This was previously also done for boundaries, but that turned out to be too much data. Gerd
participants (4)
-
Gerd Petermann -
GerdP
-
Henning Scholland -
WanMil