[PATCH v1] Reimplementation of add-pois-to-areas option
The patch realizes the reimplementation of the add-pois-to-areas option as discussed in thread http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012391.html Some notes: * Each POI created by the new Area2POIHook is tagged with mkgmap:area2poi=true * For each multipolygon one POI is created at the center of the largest polygon (largest = biggest covered area; size of inner polygons is subtracted). This means that the POI may be located outside the multipolygon area. * The old implementation contained some additional rules which have not been implemented in the new implementation. I wonder if they are really required: 1. Skip road name POIs => Probably you don't have a rule for that in your points file 2. Skip cities without name => I don't know. Maybe that check is relevant. 3. Skip areas which contains a POI with the same name => If you follow the rule "don't tag for renders" there should be an area OR a POI but not both. The patch is tested a little but if you are interested in you can help me by sending your opinion if it's a good replacement for the old implementation or what can be improved. Have fun! WanMil
On Mon, Oct 03, 2011 at 10:09:28PM +0200, WanMil wrote:
3. Skip areas which contains a POI with the same name => If you follow the rule "don't tag for renders" there should be an area OR a POI but not both.
I would like to keep this, if possible. For large buildings, the location of the entrance is not always obvious. If you are approaching the building from the "wrong" direction, going to the center of the polygon will not always work. Sometimes, if the building is located near an intersection of highway=trunk or similar or surrounded by fences, a long detour may be needed to go to the right side of the building. Therefore, I have been tagging the main entrance with the same tags as the building polygon, replacing building=yes with building=entrance. Is this really tagging for renderers? Marko
Therefore, I have been tagging the main entrance with the same tags as the building polygon, replacing building=yes with building=entrance. Is this really tagging for renderers?
I would say it is not tagging for the renderer but it is odd tagging nonetheless. A building=entrance should be all you need. Why repeat all the other tags? This creates unnecessary duplicate data and makes it harder to maintain the POI in the future. - Bartosz
On Tue, Oct 04, 2011 at 09:32:40AM +0300, Bartosz Fabianowski wrote:
Therefore, I have been tagging the main entrance with the same tags as the building polygon, replacing building=yes with building=entrance. Is this really tagging for renderers?
I would say it is not tagging for the renderer but it is odd tagging nonetheless. A building=entrance should be all you need. Why repeat all the other tags? This creates unnecessary duplicate data and makes it harder to maintain the POI in the future.
OK, you are probably right. If we think about Garmin routing, it takes the routing network and two points: source and destination. Then it computes the route as follows: 1. straight line from source to the closest point on the closest way 2. follow the route network 3. straight line from the closest point on the closest way to destination So, if there is a POI in the middle of an area, this routing should actually work, as long as the way to the entrance has been mapped. If there are multiple entrances, then it will help to have the major corridors inside the building (such as a large shopping facility) on the map. Best regards, Marko
Maybe it would be a good solution, to look at first, if one node of the polygon is tagged as building=entrance. If there is one, use this node as POI-node, else create an node in the centre of the polygon. @WanMil: Do you see a more or less easy way to control the creation of POI out of areas with a style-file? So that it is possible to have POI out of polygons, which should not be rendered as a polygon. Now this is only possible with a transparent polygon. Henning
Maybe it would be a good solution, to look at first, if one node of the polygon is tagged as building=entrance. If there is one, use this node as POI-node, else create an node in the centre of the polygon.
That would be easy to realize. For mulitpolygons one could also check if there is a point with role "label" and use this point for the POI.
@WanMil: Do you see a more or less easy way to control the creation of POI out of areas with a style-file? So that it is possible to have POI out of polygons, which should not be rendered as a polygon. Now this is only possible with a transparent polygon.
Did you try the patch? I think you no longer need any rule in the polygons file. For each polygon (no matter if there is a rule or not) a POI is created and processed by the points style file. So the solution is: * Add a rule to your points style file * Remove the rule from your polygons style file (Please let me know if it works :-) WanMil
Henning
On Tue, Oct 04, 2011 at 07:18:43PM +0200, WanMil wrote:
Maybe it would be a good solution, to look at first, if one node of the polygon is tagged as building=entrance. If there is one, use this node as POI-node, else create an node in the centre of the polygon.
That would be easy to realize. For mulitpolygons one could also check if there is a point with role "label" and use this point for the POI.
Great idea! The role=label nodes would allow "taggging for the renderers" in those cases when the default POI would be in an awkward position, such as outside the polygon. If we generated POIs for boundary=administrative polygons, the default POI location should be the role=admin_center node. But, I guess such nodes would already carry place=* and name=*. How are country labels generated, or are they generated at all? Marko
Marko Mäkelä <marko.makela@iki.fi> writes:
On Tue, Oct 04, 2011 at 07:18:43PM +0200, WanMil wrote:
Maybe it would be a good solution, to look at first, if one node of the polygon is tagged as building=entrance. If there is one, use this node as POI-node, else create an node in the centre of the polygon.
That would be easy to realize. For mulitpolygons one could also check if there is a point with role "label" and use this point for the POI.
Great idea! The role=label nodes would allow "taggging for the renderers" in those cases when the default POI would be in an awkward position, such as outside the polygon.
I agree this is a good plan. But it's not tagging for the renderer. It's saying that the proper location of a POI is in a given place, and that's a true statement about the world and generally useful. So I don't think there's any reason not to do this. It probably merits discussion more broadly; the concept is not about mkgmap.
I have uploaded a mkgmap.jar r2045+patch for easier testing purposes. WanMil
The patch realizes the reimplementation of the add-pois-to-areas option as discussed in thread http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012391.html
Some notes: * Each POI created by the new Area2POIHook is tagged with mkgmap:area2poi=true * For each multipolygon one POI is created at the center of the largest polygon (largest = biggest covered area; size of inner polygons is subtracted). This means that the POI may be located outside the multipolygon area. * The old implementation contained some additional rules which have not been implemented in the new implementation. I wonder if they are really required: 1. Skip road name POIs => Probably you don't have a rule for that in your points file 2. Skip cities without name => I don't know. Maybe that check is relevant. 3. Skip areas which contains a POI with the same name => If you follow the rule "don't tag for renders" there should be an area OR a POI but not both.
The patch is tested a little but if you are interested in you can help me by sending your opinion if it's a good replacement for the old implementation or what can be improved.
Have fun! WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
... and will also tell you where it is uploaded to... ;-) http://files.mkgmap.org.uk/detail/34 (my send button finger is too fast...) WanMil
I have uploaded a mkgmap.jar r2045+patch for easier testing purposes.
WanMil
The patch realizes the reimplementation of the add-pois-to-areas option as discussed in thread http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012391.html
Some notes: * Each POI created by the new Area2POIHook is tagged with mkgmap:area2poi=true * For each multipolygon one POI is created at the center of the largest polygon (largest = biggest covered area; size of inner polygons is subtracted). This means that the POI may be located outside the multipolygon area. * The old implementation contained some additional rules which have not been implemented in the new implementation. I wonder if they are really required: 1. Skip road name POIs => Probably you don't have a rule for that in your points file 2. Skip cities without name => I don't know. Maybe that check is relevant. 3. Skip areas which contains a POI with the same name => If you follow the rule "don't tag for renders" there should be an area OR a POI but not both.
The patch is tested a little but if you are interested in you can help me by sending your opinion if it's a good replacement for the old implementation or what can be improved.
Have fun! WanMil
_______________________________________________ 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
Hi Wanmil, I tried to test your uploaded version, but it seems not to work with pbf. Is it just a compiler-thing or is this an error caused by your patch? Henning Error at line 1, col 1 Bad file format: 17000001.osm.pbf Error parsing file
Henning, my build file contained a wrong path to the pfb jars. I got no warning because the build file detects automatically if the pbf jars are not available and deactivates the pbf support. The new file http://files.mkgmap.org.uk/detail/35 should work now. WanMil
Hi Wanmil, I tried to test your uploaded version, but it seems not to work with pbf. Is it just a compiler-thing or is this an error caused by your patch?
Henning
Error at line 1, col 1 Bad file format: 17000001.osm.pbf Error parsing file
Hi Wanmil, I still get an error parsing file... wanmil wrote: my build file contained a wrong path to the pfb jars. I got no warning because the build file detects automatically if the pbf jars are not available and deactivates the pbf support. The new file http://files.mkgmap.org.uk/detail/35 should work now. WanMil
Hi Minko, you must put the two jar files osmprotobuf.jar and protobuf.jar into the same directory like mkgmap.jar. WanMil
Hi Wanmil,
I still get an error parsing file...
wanmil wrote:
my build file contained a wrong path to the pfb jars. I got no warning because the build file detects automatically if the pbf jars are not available and deactivates the pbf support.
The new file http://files.mkgmap.org.uk/detail/35 should work now.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Wanmil, osmpbf.jar and protobuf.jar are included in your zip file, but that didnt help.
On 05/10/2011 00:48, WanMil wrote:
... and will also tell you where it is uploaded to... ;-) http://files.mkgmap.org.uk/detail/34
(my send button finger is too fast...)
WanMil
Looking good to me: http://cferrero.net/maps/img/patch.html In the second example you can see how the POI for the hotel is being placed outside the boundary of the hotel polygon. -- Charlie
participants (7)
-
Bartosz Fabianowski -
Charlie Ferrero -
Greg Troxel -
Henning Scholland -
Marko Mäkelä -
Minko -
WanMil