Actually, we do have a mean: if there are multiple parallel tracks (each > drawn as a separate way with railway=*), it is a major railway. It > should be doable to merge adjacent ways at lower resolutions and sum the > "weights" of the ways, to decide what to draw. A style file extension > could be useful, to specify e.g., the following: > > * draw individual railways at resolution 24 > * merge parallel tracks to one and draw them at resolution 22..23 > * merge parallel tracks to one and draw if count>1 at resolution 21 > * merge parallel tracks to one and draw if count>3 at resolution 20 > > For polygons, it could be useful to specify the minimum size that > qualifies for inclusion in a given resolution. Of course, small adjacent > polygons would have to be merged together first. > > I am beginning to think that it could be useful to have low-resolution > versions of the OpenStreetMap data, generated by an experimental > algorithm that attempts to merge polygons and lines as suggested above. > If it is not too CPU intensive to merge adjacent areas and lines, > perhaps it could be implemented inside mkgmap after all. > I'm thinking since some time about an algorithm for merging small polygons. Up to now I have not found an suitable algorithm. In another case I have thought about merging parallel lines, especially the both tracks of highways. While reading your mail I got the insight, that this are possibly two similar problems. In both cases there should be two objects with a small space between it be replaced by a merged single one.
The algorithm in general would be: - Increase all polygons/lines with a outline. - Check all increased polygons, if some of them overlap. - If so, merge the original version of them. But I expect this to be a really resource hungry task. Regards, Johann. _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
