suggested use of add-pois-to-areas
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 ? is it correct that w/o this options garmins won't be able to find, let's say, hotels that are mapped as an area, instead of a node ? -- Rich
Am 24.07.2011 18:58, schrieb Rich:
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 ?
I don't think so.
is it correct that w/o this options garmins won't be able to find, let's say, hotels that are mapped as an area, instead of a node ?
Yes. So you need: 1) set the --add-pois-to-areas option 2) Have corresponding entries in your polygon AND point file. In the default style you have all shops in the polygon-file (shop=*) but no amenity=library or amenity=pharmacy, so these are not found when mapped as area. Chris
On Sun, Jul 24, 2011 at 07:36:30PM +0200, Chris66 wrote:
In the default style you have all shops in the polygon-file (shop=*) but no amenity=library or amenity=pharmacy, so these are not found when mapped as area.
We could of course add these key=value pairs to the polygons file, but I am not sure if it makes sense to generate polygons for them, even for shop=*. The POI would be enough. In my opinion, natural=* and landuse=* polygons are usually enough. Building polygons can be useful, but having additional amenity=* or shop=* polygons on top of building polygons is simply clutter in my opinion. The patch that Torsten Leistikow posted at http://gis.638310.n2.nabble.com/POIs-for-areas-td6043656.html is a good start. It adds an explicit add-poi action to the style language. Torsten proposed syntax like this: amenity=bank [0x2f06 level 3 add_poi] As far as I understand, add-pois-to-areas does something to avoid generating duplicate POIs in case there is an explicit POI for the polygon. The add_poi action should do something similar, perhaps have an optional 'duplicate search radius' parameter? It could also be useful to generate the POI in the OSM domain instead of generating it directly in the map. In that way, the points file could add some additional mapping, such as amenity=bank { name '${name} (${currency})' | '${name}' } to give an artificial example. Best regards, Marko
On 24/07/2011 18:36, Chris66 wrote:
In the default style you have all shops in the polygon-file (shop=*) but no amenity=library or amenity=pharmacy, so these are not found when mapped as area.
"building=yes" is though*, so I'd expect that that would be enough - at least in the case where the entire building is a library and "amenity=library" is set for its way? Cheers, Andy * or was last time I downloaded the default style, which was a while ago.
Am 25.07.2011 10:30, schrieb SomeoneElse:
On 24/07/2011 18:36, Chris66 wrote:
In the default style you have all shops in the polygon-file (shop=*) but no amenity=library or amenity=pharmacy, so these are not found when mapped as area.
"building=yes" is though*, so I'd expect that that would be enough - at least in the case where the entire building is a library and "amenity=library" is set for its way?
My example is assuming that there is no additional building=yes for the library or pharmacy. And even if there is a building=yes additional to the amenity=pharmacy: I don't know if mkgmap creates the POI in this case. But anyway: In my personal style I added a building-polygon for these objects. amenity=library [0x13 resolution 24] amenity=pharmacy [0x13 resolution 24] Chris
If you use --add-pois-to-areas and one rule in polygon file is used for an object, then mkgmap goes through points style and creates an POI for the first matching rule. If you just want to have an POI and no area shown, then you can create an transparent bitmap in TYP-File and use this ID for all areas, which should be only converted to a POI. Henning
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
On 25.07.2011 13:28, Torsten Leistikow wrote:
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 That patch should really be added to trunk. Couldn't you simply change it by offering a new syntax.
a) add-pois-to-areas -- behaves as present b) add-pois-to-selected-areas uses your patch. else go opposite direction. a) instead of an explicit add command, use a no-poi command in the style-file on areas, so one can exclude them. then it wouldn't clash with current behavirour either.
participants (7)
-
Chris66 -
Felix Hartmann -
Henning Scholland -
Marko Mäkelä -
Rich -
SomeoneElse -
Torsten Leistikow