Commit: r2049: Reimplementation of the add-pois-to-area option
Version 2049 was commited by wanmil on 2011-10-10 19:37:26 +0100 (Mon, 10 Oct 2011) Reimplementation of the add-pois-to-area option The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file.
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. Henning
On 10/13/11 11:48, Henning Scholland wrote:
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking.
there was a discussion on irc (#osm) about this yesterday. komzpa uses entrance for his render to show them : http://latlon.org/~komzpa/screenshots/entrance1.png <Komzpa> entrance=yes ref= addr:flats= entrance=yes was also added yesterday to osmarender stylesheet by petchange.
Henning -- Rich
On 10/13/11 11:48, Henning Scholland wrote:
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking.
there was a discussion on irc (#osm) about this yesterday. komzpa uses entrance for his render to show them :
http://latlon.org/~komzpa/screenshots/entrance1.png
<Komzpa> entrance=yes ref= addr:flats=
entrance=yes was also added yesterday to osmarender stylesheet by petchange.
Henning
That's easy to implement. @list: Any objections? Is it necessary to create an additional mkgmap option to define which tags should be used as label node? At the moment there is building=entrance and entrance=yes. WanMil
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking.
At the moment the first node in the polygon tagged building=entrance is used. For the future I propose to use the following order: 1. entrance=main 2. entrance=yes 3. building=entrance If more than one point of the same tag exist the first one is used. I think the other entrance tags should not be used. Ok? WanMil
Henning
If more than one point of the same tag exist the first one is used.
What if there are multiple entrances with different house numbers? This is common in many countries with those huge communist blocks of flats. - Bartosz
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. Henning
Am 10.10.2011 20:37, schrieb svn commit:
Reimplementation of the add-pois-to-area option
The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file.
Didn't follow all the postings. Main question: Existing styles have to be adjusted, right? Or is it downward compatible to existing styles? Chris
Am 13.10.2011 11:19, schrieb Chris66:
Am 10.10.2011 20:37, schrieb svn commit:
Reimplementation of the add-pois-to-area option
The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file. Didn't follow all the postings.
Main question: Existing styles have to be adjusted, right?
Or is it downward compatible to existing styles? If you haven't made any hacks in your Style-File to show more POI's, there shouldn't be a problem.
Henning
Am 13.10.2011 11:19, schrieb Chris66:
Am 10.10.2011 20:37, schrieb svn commit:
Reimplementation of the add-pois-to-area option
The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file. Didn't follow all the postings.
Main question: Existing styles have to be adjusted, right?
Or is it downward compatible to existing styles? If you haven't made any hacks in your Style-File to show more POI's, there shouldn't be a problem.
Henning
Possible hacks that need to be or can be changed now are: 1. In the old implementation there was the requirement to have a rule in the polygons file for polygons for which a POI should be added. Some people added rules with transparent polygons so that the POI is visible but the polygon is not. This is no longer necessary. A rule in the points file is enough if you want to display the POI but not the polygon. 2. For the same reason you might have to change you points style now because for polygons that are not defined in the polygons style a POI is added anyhow if there is a rule in the points style. So you might add a rule like: aeroway=terminal & mkgmap:area2poi!=true [0x2f04 resolution 22] See also Minkos post for full details. Have fun! WanMil
"mkgmap:area2poi=true" Does this mean, if I don't want to have any POI that result from the add-pois-to-area option I can use a rule like: /amenity=restaurant & mkgmap:area2poi!=true/ and only POI for restaurants that have been points in the OSM data, will be set. while amenity=restaurant &/mkgmap:area2poi=true /would match only POI that are generated via add-pois-to-area option/ /
"mkgmap:area2poi=true"
Does this mean, if I don't want to have any POI that result from the add-pois-to-area option I can use a rule like:
/amenity=restaurant & mkgmap:area2poi!=true/
and only POI for restaurants that have been points in the OSM data, will be set.
while amenity=restaurant &/mkgmap:area2poi=true /would match only POI that are generated via add-pois-to-area option/ /
That's correct. WanMil
participants (7)
-
Bartosz Fabianowski -
Chris66 -
Felix Hartmann -
Henning Scholland -
Rich -
svn commit -
WanMil