Hi list, I found an issue with the --add-pois-to-areas option and don't know if it's a bug or a feature. Areas get only converted to points, if there is a matching rule in the points-style file AND if there is a matching rule in the polygons file. I don't understand the second condition. Imagine I want to show buildings only as a single point and no area. So it would be very useful to get building polygons converted to a point without specifiing it in polygons file. The dirty hack at the moment is to specify a rule in polygons and make the whole area transparent with a typfile, just to get a point created. But this is really stupid, because the polygon exist and the mousepointer could not show what is under this area. Can somebody help me? Christoph
On 28.01.2010 13:48, Christoph Wagner wrote:
Hi list,
I found an issue with the --add-pois-to-areas option and don't know if it's a bug or a feature.
Areas get only converted to points, if there is a matching rule in the points-style file AND if there is a matching rule in the polygons file. I don't understand the second condition.
Imagine I want to show buildings only as a single point and no area. So it would be very useful to get building polygons converted to a point without specifiing it in polygons file.
The dirty hack at the moment is to specify a rule in polygons and make the whole area transparent with a typfile, just to get a point created. But this is really stupid, because the polygon exist and the mousepointer could not show what is under this area. Can somebody help me?
Christoph
That's because it's only a dirty hack alltogether. It would be bit cleaner if there was a seperate file inside the style-file where one can specify the poi to areas keys. Currently mkgmap can only know what kind of POI to create, if it also has a matching Polygon. That's as far as I understood the principle. Even with a seperate file it would still be a rather dirty hack, as it would be much better to have the POI inside openstretmap at first hand. I don't really think it is good style to map POIs for areas. Maybe a better solution would be to not create a poi, but just match in the search indexes (but I don't know if that is possible, I deem this to be impossible).
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann schrieb:
That's because it's only a dirty hack alltogether. It would be bit cleaner if there was a seperate file inside the style-file where one can specify the poi to areas keys. Currently mkgmap can only know what kind of POI to create, if it also has a matching Polygon. That's as far as I understood the principle.
I think I don't understand the point. Why do I need a separate file? Why this is not just the following algorithm? if --add-pois-to-areas is set 1. look if there is a matching polygon rule, make a polygon of specified type 2. independent if there was a polygon rule, look if there is a point rule for this tag and create a point of specified type if so
Even with a seperate file it would still be a rather dirty hack, as it would be much better to have the POI inside openstretmap at first hand. I don't really think it is good style to map POIs for areas.
No, I disagree. If you map a POI as polygon in Openstreetmap there is enough information for a later renderer to get a point out of this if needed. Why should I map an additional point in OSM? That would only increase redundancy and brings not more information.
Maybe a better solution would be to not create a poi, but just match in the search indexes (but I don't know if that is possible, I deem this to be impossible).
I haven't seen yet, that garmin supports searching of areas, but I don't know enough about that. Christoph
On 28.01.2010 15:03, Christoph Wagner wrote:
Felix Hartmann schrieb:
That's because it's only a dirty hack alltogether. It would be bit cleaner if there was a seperate file inside the style-file where one can specify the poi to areas keys. Currently mkgmap can only know what kind of POI to create, if it also has a matching Polygon. That's as far as I understood the principle.
I think I don't understand the point. Why do I need a separate file? Why this is not just the following algorithm?
if --add-pois-to-areas is set 1. look if there is a matching polygon rule, make a polygon of specified type 2. independent if there was a polygon rule, look if there is a point rule for this tag and create a point of specified type if so
Well you might not like to have a POI for every polygon (what's the point in a POI for a city? - cities are entered as seperate points anyhow)
Even with a seperate file it would still be a rather dirty hack, as it would be much better to have the POI inside openstretmap at first hand. I don't really think it is good style to map POIs for areas.
No, I disagree. If you map a POI as polygon in Openstreetmap there is enough information for a later renderer to get a point out of this if needed. Why should I map an additional point in OSM? That would only increase redundancy and brings not more information.
There is absolutely no reason why a POI should be in the middle of a Polygon. It would be stupid to say because we have a city boundary, we don't need a city POI in Openstreetmap. For a building you might want to have the POI at the entry, and not in the middle of the buidling, ..... It is impossible to know whether if there exists a POI inside a Polygon (it will be never checked, cause too much cpu cycles to do so) it should be printed nevertheless, or it shouldn't be printed on the map. There are many many more cases where it is stupid to assume that one can simply assign a POI to a Polygon.
Maybe a better solution would be to not create a poi, but just match in the search indexes (but I don't know if that is possible, I deem this to be impossible).
I haven't seen yet, that garmin supports searching of areas, but I don't know enough about that.
Christoph
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann schrieb:
Well you might not like to have a POI for every polygon (what's the point in a POI for a city? - cities are entered as seperate points anyhow)
Ok, I see there are problems. But I thought that there is an algorithm to check, if there exist a point in the polygon, yet to avoid double points for the same thing.
There is absolutely no reason why a POI should be in the middle of a Polygon.
It is easy and a good approach.
It would be stupid to say because we have a city boundary, we don't need a city POI in Openstreetmap. For a building you might want to have the POI at the entry, and not in the middle of the buidling, ..... It is impossible to know whether if there exists a POI inside a Polygon (it will be never checked, cause too much cpu cycles to do so) it should be printed nevertheless, or it shouldn't be printed on the map.
But I thought there is exactly such algorithm integrated in mkgmap. Did I've seen ghosts? But you are right, this would cost cpu cycles to do it. So I would suggest to provide an extra-option to enable such behaviour.
There are many many more cases where it is stupid to assume that one can simply assign a POI to a Polygon.
Ok, maybe it would be good to define it separately for each feature. I could imagine something like: polygons: building=yes {makepoint} [0x13 resolution 20] # or just: building=yes {makepoint} # if you need only a point but no polygon! points: building=yes [0x6402 resolution 24] Then you should be able to give an extra-option like: --add-pois-to-areas=check-existing-points so no points where created for a polygon if there is a real OSM-point that matches the rule (in our example building=yes) Does it sound sensefull? Christoph
The reason why you need a matching polygon rule for POIs to be generated is that mkgmap needs this to find out that it is a polygon. Why is this? Because there is no way to find out whether a closed line is actually a polygon or a line/way besides looking at the tags. From the OSM standpoint a polygon and a line/way are the same. You can't even claim that only polygons are closed, because ways can also be closed (just think about roundabouts). So mkgmap looks whether it finds a matching tag in the polygons style file and if it does it is handled as a polygon. Then it looks at the lines style file and if it's there it is a line. And AFAIK there is actually a check whether there is a matching POI already inside the polygon. And besides that, I consider the style handling as it is currently done mostly broken. A complete rework (think style branch) is highly welcome, even if I have to rewrite all my style files and patches. Regards Thilo
Thilo Hannemann schrieb:
The reason why you need a matching polygon rule for POIs to be generated is that mkgmap needs this to find out that it is a polygon.
Now I really understand the problem. Would it be enough for mkgmap to specify a rule in polygons-file like this: building=* without any actions and typemappings, just to find out that building is a polygon tag and get a point out of it?
Am 29.01.2010 um 17:47 schrieb Christoph Wagner:
Thilo Hannemann schrieb:
The reason why you need a matching polygon rule for POIs to be generated is that mkgmap needs this to find out that it is a polygon.
Now I really understand the problem. Would it be enough for mkgmap to specify a rule in polygons-file like this:
building=*
without any actions and typemappings, just to find out that building is a polygon tag and get a point out of it?
I don't know, but I think it won't work. mkgmap might complain about the syntax, so you could try building=* { set dummy=dosomething } instead. But actions alone don't invoke the code for the polygon creation at all IIRC, so that probably won't work either. You could try to patch mkgmap so you can have a "dummy" type that won't trigger the creation of the actual polygon. Maybe that's what happens if you specify a type that can't be converted into any Garmin type (say 0xffffffff) anyway. So it would be building=* [ 0xffffff resolution 24 ] or something like that. On the other hand - if the code checks the validity of the Garmin type mkgmap will complain, if it doesn't check it the resulting map will probably be broken. Regards Thilo
participants (3)
-
Christoph Wagner -
Felix Hartmann -
Thilo Hannemann