Hi, I just noted with a garmin map from kleineisel.de that my local supermarket is not listed. The reason is that it's an area, not a point. I think this is caused by not applying --add-pois-to-areas (?) I think it's reasonable to make this option the default and only disable it by request. It should be the common case that one wants pois generated also if they are areas. Should I make a patch for that? -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno@hboeck.de http://schokokeks.org - professional webhosting
Hi, Generally, I'd say "Yes, we should make this the default". In the long run, we should consider, if this should be somehow modifiable by the style. Either by letting the style say "Don't go and create a POI" or the other way round. I don't have a particular opinion on this. I just think, we should at least think about it. Elrond On Sat, Aug 15, 2009 at 08:30:13PM +0200, Hanno Böck wrote:
Hi,
I just noted with a garmin map from kleineisel.de that my local supermarket is not listed.
The reason is that it's an area, not a point. I think this is caused by not applying --add-pois-to-areas (?)
I think it's reasonable to make this option the default and only disable it by request. It should be the common case that one wants pois generated also if they are areas.
Should I make a patch for that?
-- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno@hboeck.de
http://schokokeks.org - professional webhosting
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Sat, Aug 15, 2009 at 09:16:36PM +0200, Elrond wrote:
In the long run, we should consider, if this should be somehow modifiable by the style. Either by letting the style say "Don't go and create a POI" or the other way round.
It is already possible for a style to set options. All we have to do for any option that we want to allow a style to set, is to add it to the list in StyleImpl. You can also make it possible for the command line to override the option or to disallow being overriden. ..Steve
On Sat, Aug 15, 2009 at 08:30:13PM +0200, Hanno Böck wrote:
I just noted with a garmin map from kleineisel.de that my local supermarket is not listed.
The reason is that it's an area, not a point. I think this is caused by not applying --add-pois-to-areas (?)
I think it's reasonable to make this option the default and only disable it by request. It should be the common case that one wants pois generated also if they are areas.
I think that --add-pois-to-areas only makes sense for open areas that can be accessed from all directions. For example, supermarkets usually have one or two entrances, and the auto-generated POI could produce wrong results. Here is a real-life example: A shop that is in a fenced area. When I first visited it with the navigator, there was no POI, but I selected the building on the map and asked for a (bicycle) route. It almost got me there, but it told me to go through the fence. I had to make a non-trivial detour to get to the entrance. Thus, I would say that it makes sense to manually create POIs for all areas, at the entrance. Or, if --add-pois-to-areas is to be made the default, it should not add duplicate POIs if there already is a POI nearby with the same name.
Should I make a patch for that?
Please, if you can implement the above suggestion (avoiding duplicate POIs), it would be more useful. (Sorry if it already does that; I have never used the feature.) Marko
Am Samstag 15 August 2009 schrieb Marko Mäkelä:
Thus, I would say that it makes sense to manually create POIs for all areas, at the entrance. Or, if --add-pois-to-areas is to be made the default, it should not add duplicate POIs if there already is a POI nearby with the same name.
If there already is a poi with the same name, it's probably something that should be fixed in the map (or something that is there for a reason). I would not want apps to hide problems in the map. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno@hboeck.de http://schokokeks.org - professional webhosting
On Sat, Aug 15, 2009 at 10:07:54PM +0200, Hanno Böck wrote:
Am Samstag 15 August 2009 schrieb Marko Mäkelä:
Thus, I would say that it makes sense to manually create POIs for all areas, at the entrance. Or, if --add-pois-to-areas is to be made the default, it should not add duplicate POIs if there already is a POI nearby with the same name.
If there already is a poi with the same name, it's probably something that should be fixed in the map (or something that is there for a reason). I would not want apps to hide problems in the map.
I was trying to say that in my opinion, POIs should be placed manually, at a location that makes sense. Automatic placement of POIs is inaccurate and may fail (think of banana-shaped areas or multipolygons). This may be a matter of taste, but I would consider a POI-less area a problem in the map. I have been adding POI nodes to the map data. I find that the option --add-pois-to-areas is exactly hiding problems in the map. The option is better than nothing, but if we are to make it the default, we should try to make sure that it does not cause any collateral damage (duplicate POIs). Marko
Hi Hanno,
I just noted with a garmin map from kleineisel.de that my local supermarket is not listed.
The reason is that it's an area, not a point. I think this is caused by not applying --add-pois-to-areas (?)
I think it's reasonable to make this option the default and only disable it by request. It should be the common case that one wants pois generated also if they are areas.
Should I make a patch for that?
Personally, I prefer mkgmap to not add stuff to the map unless I ask it to do that. I think it's better to request that something extra gets added rather than requesting that the extra stuff is removed. Cheers, Mark
Hi! Mark Burton schrieb:
I think it's reasonable to make this option the default and only disable it by request. It should be the common case that one wants pois generated also if they are areas.
Should I make a patch for that?
Personally, I prefer mkgmap to not add stuff to the map unless I ask it to do that. I think it's better to request that something extra gets added rather than requesting that the extra stuff is removed.
+1 I consider a parameter for wholesale POI creation just a workaround. - The automatic placement works only for very simple objects, if a user sets a POI manually, this placement will always be better - The POI creation creates duplicate POIs if there already is a (better) manual POI - A feature with as much impact as this should be controllable in a very detailed way in the style. I can think of many features where I would want it to add POIs and many where I would refrain from it. E.g. I have recently seen a castle with each building detailed as an area. The result was a forest of castle icons there. bye Nop
Regarding the manual placement of POI objects: http://wiki.openstreetmap.org/wiki/Good_practice says "One feature, one OSM-object Don't place nodes in (equally labelled) areas just to see some icon appear on the map. The renderers will display icons on areas as well and there's no need to have every parking-lot, soccer-ground etc. twice in the database." So having a manual placed POI inside an area that is tagged with the same keys should actually be avoided. We should respect that. If it causes problems with the map creation we should improve the map creation. Regarding the "add-pois-to-areas": This is quite usable as it is now. It actually *does* test whether there is already a POI present. To avoid the "forest of POIs" problem it would be nice to have a function to merge all similar POIs inside a configurable radius into one. This would make sense for all POIs, not only the ones created from areas. What I don't like about the add-pois-to-areas is that the created POI will get the same name as the area. The name-tweaking for the POIs isn't applied to the POIs that are generated from an area. I've already created my own patch to correct that. If somebody likes to integrate this to trunk I'll happily post a patch against trunk for it (my current patch works against trunk plus the multiple-garmin- elements patch and doesn't work against trunk alone). Regards Thilo
Thilo Hannemann wrote:
Regarding the "add-pois-to-areas": This is quite usable as it is now. It actually *does* test whether there is already a POI present. To avoid the "forest of POIs" problem it would be nice to have a function to merge all similar POIs inside a configurable radius into one. This would make sense for all POIs, not only the ones created from areas.
I think the POI creation should be more configurable. POIs for supermarkets do make sense, but I wouldn't want one for every piece of forest or landuse. Perhaps we could make POIs based on new rules for the style files?
On Sun, Aug 16, 2009 at 11:44:17AM +0200, Ralf Kleineisel wrote:
Thilo Hannemann wrote:
Regarding the "add-pois-to-areas": This is quite usable as it is now. It actually *does* test whether there is already a POI present. To avoid the "forest of POIs" problem it would be nice to have a function to merge all similar POIs inside a configurable radius into one. This would make sense for all POIs, not only the ones created from areas.
I think the POI creation should be more configurable. POIs for supermarkets do make sense, but I wouldn't want one for every piece of forest or landuse. Perhaps we could make POIs based on new rules for the style files?
+1 for that. Generally, I don't think that it makes sense to create POIs for unnamed areas (such as farms or forests), except areas that are often unnamed, such as parking areas. Could we have something that allows us to define the POIs in the lines style file, something like this to have POIs created for named forests and all playgrounds, named or not: natural=wood name=* { add-point; } leisure=playground { add-point; } Marko
Hi! Thilo Hannemann schrieb:
"One feature, one OSM-object Don't place nodes in (equally labelled) areas just to see some icon appear on the map. The renderers will display icons on areas as well and there's no need to have every parking-lot, soccer-ground etc. twice in the database."
It is not true that all renderers will display icons for all areas. It is also very questionable whether all renderers will always provide a meaningful positioning of automatically created icons, e.g. a simple approach will place the icon for an L-shaped area outside of the area. I think that a manually placed POI is always preferrable over an automatically created one and the wiki is oversimplifying things here. bye Nop
Am 16.08.2009 um 23:14 schrieb Nop:
Thilo Hannemann schrieb:
"One feature, one OSM-object Don't place nodes in (equally labelled) areas just to see some icon appear on the map. The renderers will display icons on areas as well and there's no need to have every parking-lot, soccer-ground etc. twice in the database."
It is not true that all renderers will display icons for all areas.
Not yet perhaps.
It is also very questionable whether all renderers will always provide a meaningful positioning of automatically created icons, e.g. a simple approach will place the icon for an L-shaped area outside of the area.
If a simple approach won't give the desired result we should implement a better approach. This has to be done only once for the renderer(s) and not for all the items in the database. "We do not tag for the renderers." applies here.
I think that a manually placed POI is always preferrable over an automatically created one and the wiki is oversimplifying things here.
Actually this rule allows you to have manually placed POIs. But then you should not have the area labelled. And I think that is reasonable. Because otherwise a lot of items get duplicated in the database without any reliable way to determine whether they are duplicates or not. Therefore, I think the current algorithm for the add-pois-to-areas is sufficient, because it will correct most instances of those duplicate tags, which are errors in the database and should be corrected in the database anyway. Regards Thilo
Hi! Thilo Hannemann schrieb:
Am 16.08.2009 um 23:14 schrieb Nop:
It is also very questionable whether all renderers will always provide a meaningful positioning of automatically created icons, e.g. a simple approach will place the icon for an L-shaped area outside of the area.
If a simple approach won't give the desired result we should implement a better approach. This has to be done only once for the renderer(s) and not for all the items in the database. "We do not tag for the renderers." applies here.
This is not true. It is a non-trivial problem, it does not make sense to do something every time for rendering that can be solved once statically in the DB and it will have to be implemented for every renderer in a different way as they have very different technical approaches. You are putting a lot of complex work into other peoples laps and make it sound very easy. It is not. You don't tag for the renderers, you tag to avoid ridiculous layout on the maps. And there will always be situations where a user expects a POI in a different place than any technical approach will give you.
Therefore, I think the current algorithm for the add-pois-to-areas is sufficient, because it will correct most instances of those duplicate tags, which are errors in the database and should be corrected in the database anyway.
I agree that if there is a POI and an area, probably only one of them should be named and only the named instance should be used. But if someone deliberately put an additional POI there for a reason, it is not an error in the db - your definition is just too simple. bye Nop
On 08/17/2009 08:42 AM, Nop wrote:
I agree that if there is a POI and an area, probably only one of them should be named and only the named instance should be used.
IMHO if there is a POI and an area and they are related there should be a relation. Otherwise we can never be sure if an area and a POI are really identical. Just think of a big supermarket mapped as an area and a small shop in the same building mapped as a POI.
On Sat, Aug 15, 2009 at 1:30 PM, Hanno Böck<hanno@hboeck.de> wrote:
I just noted with a garmin map from kleineisel.de that my local supermarket is not listed.
The reason is that it's an area, not a point. I think this is caused by not applying --add-pois-to-areas (?)
I think it's reasonable to make this option the default and only disable it by request. It should be the common case that one wants pois generated also if they are areas.
I would say yes, except we need to block creation of POIs for areas that don't have a name. The last map I made has tons of POIs for every unnamed pond and wooded area - that gets a bit distracting when you are trying to search for a POI. -- Jeff Ollie
participants (9)
-
Elrond -
Hanno Böck -
Jeffrey Ollie -
Mark Burton -
Marko Mäkelä -
Nop -
Ralf Kleineisel -
Steve Ratcliffe -
Thilo Hannemann