I have identified what I think may be a minor bug in mkgmap: If a relation has the same name as one of its components (or perhaps any name), the name of the component is lost. I identified this on way 4798060, a small lake called 'High Dam'. Because there are islands in the lake, it is the outer component of relation 1369084, which also had the name 'High Dam'. Following mkgmap processing, the lake came out with its default name 'Reservoir'. However, when I removed the name from the relation, it came out with its correct name. (It appears correctly on OSM renderings such as mapnik). I am afraid I have already edited the relation name out on the OSM source, so others cannot test this directly. But I have verified the behaviour by manually editing a small local extract of the area. Another (minor) fault which would probably be easy to rectify: if the destination file is open in MapSource when mkgmap runs, it crashes (understandably), but leaves a number of temporary files around. Could these be deleted when the exception is processed? Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
On Wed, Sep 26, 2012 at 12:04:59PM +0100, Roger Calvert wrote:
If a relation has the same name as one of its components (or perhaps any name), the name of the component is lost.
I identified this on way 4798060, a small lake called 'High Dam'. Because there are islands in the lake, it is the outer component of relation 1369084, which also had the name 'High Dam'. Following mkgmap processing, the lake came out with its default name 'Reservoir'. However, when I removed the name from the relation, it came out with its correct name. (It appears correctly on OSM renderings such as mapnik).
I believe that the correct fix would have been to remove the name from the role=outer ways and keep the name in the relation. Similarly, remove any natural=water from the outer way(s) and add them to the relation. This would make the multipolygon unambiguous. Marko
On 26/09/2012 15:42, Marko Mäkelä wrote:
On Wed, Sep 26, 2012 at 12:04:59PM +0100, Roger Calvert wrote:
If a relation has the same name as one of its components (or perhaps any name), the name of the component is lost.
I identified this on way 4798060, a small lake called 'High Dam'. Because there are islands in the lake, it is the outer component of relation 1369084, which also had the name 'High Dam'. Following mkgmap processing, the lake came out with its default name 'Reservoir'. However, when I removed the name from the relation, it came out with its correct name. (It appears correctly on OSM renderings such as mapnik). I believe that the correct fix would have been to remove the name from the role=outer ways and keep the name in the relation. Similarly, remove any natural=water from the outer way(s) and add them to the relation. This would make the multipolygon unambiguous.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I'm sure this is correct, but it is not very intuitive to the mapper, particularly as the relation may be created by someone other than the original mapper. For example, mapper A puts in the lake, and some time later, mapper B puts in more detail, including the islands and the relation. I am sure there are many cases where this may happen or has happened - I found this one by chance as it is in my local area. It would be nice if all mappers were perfect, but ......... It would be helpful if some workround could be found in mkgmap. All the other renderings I have looked at seem able to handle it. If the relation name and the polygon name (or other tags) are different, I agree there is a problem. But if they are the same, I don't think the result should be that the polygon loses its name completely. Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
On Wed, Sep 26, 2012 at 06:47:04PM +0100, Roger Calvert wrote:
It would be helpful if some workround could be found in mkgmap. All the other renderings I have looked at seem able to handle it. If the relation name and the polygon name (or other tags) are different, I agree there is a problem. But if they are the same, I don't think the result should be that the polygon loses its name completely.
Even in cases where mkgmap is able to do some guesswork, it could be useful to log a warning, so that these ambiguous relations can be fixed. I have seen a similar problem with landuse multipolygons. Someone imported huge amounts of very inaccurate landuse data from the EU Corine to OSM in Finland. He simply ignored existing polygons, so that we can have almost-common lines for lakes and forests. Or, we can have forests partially overlapping lakes, or one landuse polygon overlapping multiple islets and the waters between them. To add insult to the injury, the import used the old definition of multipolygons, where you would duplicate the same tags on both role=outer and role=inner ways. This breaks in many ways if some mapper thinks "oh, this inner polygon is not a forest, but a farm". (With the old definition (duplicate all tags on all members), the correct solution would have been to define another polygon on the same nodes, with the tags of the inner area. The new multipolygon definition allows us to reuse the same way for multiple multipolygons.) When mkgmap has complained something about these multipolygons, I have fixed the problem and at the same time moved all common tags from the multipolygon ways to the relation itself. Best regards, Marko
On 26/09/12 12:04, Roger Calvert wrote:
Another (minor) fault which would probably be easy to rectify: if the destination file is open in MapSource when mkgmap runs, it crashes (understandably), but leaves a number of temporary files around. Could these be deleted when the exception is processed?
All the temporary files are marked to be deleted when java exits, however this frequently doesn't work on Windows, since files cannot be deleted if they are in use. Which temporary files do you see? There are ones like "mdr*.tmp" and "strings*.tmp" , do you see both of them? It might not be that easy to fix. ..Steve
On 26/09/2012 21:49, Steve Ratcliffe wrote:
All the temporary files are marked to be deleted when java exits, however this frequently doesn't work on Windows, since files cannot be deleted if they are in use.
Which temporary files do you see? There are ones like "mdr*.tmp" and "strings*.tmp" , do you see both of them?
It might not be that easy to fix.
..Steve _______________________________________________
Yes, both mdr*.tmp and strings*.tmp are there. But they are no real effort to delete, and I have just realised I could delete them anyway (if they are there) at the end of my batch file. Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
I have identified what I think may be a minor bug in mkgmap:
If a relation has the same name as one of its components (or perhaps any name), the name of the component is lost.
I identified this on way 4798060, a small lake called 'High Dam'. Because there are islands in the lake, it is the outer component of relation 1369084, which also had the name 'High Dam'. Following mkgmap processing, the lake came out with its default name 'Reservoir'. However, when I removed the name from the relation, it came out with its correct name. (It appears correctly on OSM renderings such as mapnik).
I am afraid I have already edited the relation name out on the OSM source, so others cannot test this directly. But I have verified the behaviour by manually editing a small local extract of the area.
Another (minor) fault which would probably be easy to rectify: if the destination file is open in MapSource when mkgmap runs, it crashes (understandably), but leaves a number of temporary files around. Could these be deleted when the exception is processed?
Roger
The mkgmap multipolygon algorithm removes all tags from the outer ways that are identical to tags of the relation. Therefore the tag name=High Dam is removed from the way 4798060. (By the way, tagging the multipolygon only with name is definitely wrong. Either add all tags or no tag to the mp). Removing tags from the outer ways is required to handle all mps where the tags are set on the map *and* on the ways. These are a lot (best example: all boundaries). I don't see a good alternative to this algorithm as long as the OSM datamodel does not ensure any multipolygon correctness. WanMil
On 30/09/2012 19:46, WanMil wrote:
The mkgmap multipolygon algorithm removes all tags from the outer ways that are identical to tags of the relation. Therefore the tag name=High Dam is removed from the way 4798060. (By the way, tagging the multipolygon only with name is definitely wrong. Either add all tags or no tag to the mp). Removing tags from the outer ways is required to handle all mps where the tags are set on the map *and* on the ways. These are a lot (best example: all boundaries).
I don't see a good alternative to this algorithm as long as the OSM datamodel does not ensure any multipolygon correctness.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil, Thanks for the explanation. It seems that this process is needed, at least in part, to make sense of incorrectly tagged data. There certainly will always be incorrectly tagged data, which programs such as mkgmap and renderers will have to interpret. But is there any way that the deleted tags could be retained in some form for access in the style files? Perhaps they could be re-named along the lines of 'deleted:name=High Dam' . Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
WanMil, Thanks for the explanation. It seems that this process is needed, at least in part, to make sense of incorrectly tagged data. There certainly will always be incorrectly tagged data, which programs such as mkgmap and renderers will have to interpret. But is there any way that the deleted tags could be retained in some form for access in the style files? Perhaps they could be re-named along the lines of 'deleted:name=High Dam' .
Certainly yes. But I don't see the requirement for it - it has some drawbacks (memory requirement). In your example the outer way is tagged with landuse=reservoir and natural=water. You want to have two polygons - one for the mp (natural=water) and one for the way (landuse=reservoir). Why do you need the two items? Doesn't natural=water and landuse=reservoir tag exactly the same thing? WanMil
On 01/10/2012 18:52, WanMil wrote:
In your example the outer way is tagged with landuse=reservoir and natural=water. You want to have two polygons - one for the mp (natural=water) and one for the way (landuse=reservoir). Why do you need the two items? Doesn't natural=water and landuse=reservoir tag exactly the same thing? Yes, I think they do the same thing (except that the default name is either 'Lake' or 'Reservoir'). The original mapper put them both in, and I don't usually change other people's tags without good reason. I did delete one of them when I was experimenting to find where the name had got lost, then put it back.
Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
participants (4)
-
Marko Mäkelä -
Roger Calvert -
Steve Ratcliffe -
WanMil