On Thu, Feb 04, 2010 at 08:50:49PM +0100, WanMil wrote:

...

I have doubts if that's a good idea. If multipolygons are splitted by splitter it is possible that some polygons are dropped because they are not inside the tile bounds. This makes it possible that the outer ring survives only.

The definition of the multipolygon says that the tags from the multipolygon are used for the outer polygons ("Tags describing the multipolygon (e.g. landuse=forest) should go on the relation. The outer way(s) should be left untagged, unless they describe something in their own right."). If these multipolygons are dropped the tag information of the multipolygon is lost.

I propose to revert this commit unless there are hard reasons for it.

There is no hard reason for the change. It was just a workaround for splitter problems at tile boundaries. I reverted it in r1560.

How would you find my other patch, which discards ways that are missing some points and have no points in the bounding box? What about multipolygons that contain no resolvable polygons? Could they be dropped safely?

I did not have time to have a look on the patch and I only read some statements from the thread. For mp generation it's a good idea to put the full multipolygons to the tiles. This makes coding much easier. The mp code already discards ways that do not intersect the bounding box. Intersect not having no points in the bounding box (!). In case a multipolygon contains no resolvable polygons mp doesn't do anything (but log some warnings). I hope that lots of things will be solved if the mp code handles the tile boundaries. I have started today but it will need some time. I understand that you want to minimize the number of warnings but I would recommend to wait until the mp code is improved in that way.

I am looking forward to the splitter fixes. In the past few days, I have been correcting multipolygon and coastline errors in Finland, and I hope to be able to enable --generate-sea=multipolygon soon.

That's alway the best way to get a good map! :-)

Marko

WanMil

The definition of the multipolygon says that the tags from the multipolygon are used for the outer polygons ("Tags describing the multipolygon (e.g. landuse=forest) should go on the relation. The outer way(s) should be left untagged, unless they describe something in their own right."). If these multipolygons are dropped the tag information of the multipolygon is lost.

there are 2 common forms of tags on myltipolygon. both are supported in Mapnik and Osmarender. Ideally mkgmap should work the same way

1) tag is on the relation and will overwrite any tag with same key on the outer way. A different tag can still be applied to the ways. 2) tag is on the outer way, again additional tags can be set

in both cases I think the way must be duplicated

All ways are duplicated in mkgmap. When single ways are joined to polygons the new polygons are tagged with a tag merge of the single ways. The merge uses the "first way wins" algorithm (which produces a bit random results, but I don't know a better algorithm). In the end there is a decision which tags are removed: - If the original OSM way is a closed polygon then all tags are removed from the original OSM way. - Otherwise only tags for polygons are removed (at the moment these are "boundary", "natural", "landuse", "land_area", "building", "waterway"). This keeps all line tags (like highway) so the original still make use of their line-tagging. If the multipolygon contains any of the polygon tags, then all tags of the multipolygon are copied to the resulting polygons (additionally to the merge of tags) WanMil

...

All ways are duplicated in mkgmap.

This is no longer true and I don't want every way to be duplicated just in case. Is it possible to duplicate ways as needed in the MP code?

..Steve

I have to be more precise: all ways are duplicated in the multipolygon code of mkgmap. If there is no good reason I don't want to change that. WanMil