Opened 10 years ago

Closed 10 years ago

#1435 closed enhancement (fixed)

Extended multipolygon-support

Reported by: R2D2_C3PO Owned by: osm@…
Priority: major Milestone:
Component: osmarender Version:
Keywords: Cc: frederik@…

Description

As JOSM supports the advanced multipolygons (http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Suggestion_for_advanced_multipolygons) now, I wanted renderer support. So I added it (at least partially).

Multiple outer ways are supported, even disjunct ones. There is no support for inner rings that are made of more than one way, but I'll add this in the next days if there are no big problems with this patch.

The patch and an example file are attached.

Attachments (3)

multipolygon2.osm (3.0 KB) - added by R2D2_C3PO 10 years ago.
Updated example (2 inner ways with different tags)
multipolygon2.diff (1 bytes) - added by R2D2_C3PO 10 years ago.
deleted
multipolygon.diff (19.3 KB) - added by R2D2_C3PO 10 years ago.

Download all attachments as: .zip

Change History (16)

Changed 10 years ago by R2D2_C3PO

Attachment: multipolygon2.osm added

Updated example (2 inner ways with different tags)

comment:1 Changed 10 years ago by R2D2_C3PO

WARNING: Do not apply this patch in it's current form! While it worked well for my testcases is fails on many real-world files. I'll upload a fixed version when it's ready.

comment:2 Changed 10 years ago by openstreetmap@…

Also note the JOSM test file at http://josm.openstreetmap.de/svn/trunk/data/multipolygon.osm

Supply more test cases for this file when you spot problems, which should be included.

comment:3 Changed 10 years ago by openstreetmap@…

Regarding your example: To get that working you need a second multipolygon, which has the included "outer" part as inner. The current advanced multipolygon description does not have automatic detection of that case and I'm not really convinced we should add that.

comment:4 Changed 10 years ago by osm@…

What's the current status here?

comment:5 Changed 10 years ago by R2D2_C3PO

Sorry for not updating my patch, but I had some exams and therefore little time to work on OSM. I hope that I'll be able to provide a working patch next week.

comment:6 Changed 10 years ago by R2D2_C3PO

I now have a patch, that correctly handles multiple outer ways. However the tags still have to be on the ways and not in the relation.

I'm also trying to implementing Bob Kare's polygon-center algorithm with support for multipolygons and the code gets quite complicated when multipolygon handling is done in many places. So I came to the conclusion that my complete design is flawed and I'm going to add a preprocessing step, that first creates new objects for multipolgons and then uses these objects for further processing. I'm currently working on this...

Changed 10 years ago by R2D2_C3PO

Attachment: multipolygon2.diff added

deleted

comment:7 Changed 10 years ago by R2D2_C3PO

Completely changed the patch. It now correctly processes the JOSM testfile. Only a few tests in the "errors" section are rendered differently, but as the tagging for these tests is invalid anyways there's reason to render them the same.

However this patch is not complete at the moment. It does not support circles, text, etc. and needs some cleanup. I expect the final patch to be ready in one or two days.

Using the current patch to find bugs in my algorithm or providing comments is encouraged.

Changed 10 years ago by R2D2_C3PO

Attachment: multipolygon.diff added

comment:8 Changed 10 years ago by R2D2_C3PO

Now the patch should be ready for general use. It works on the josm testfile and my own testfiles and I was not able to find regressions on realworld data (with old multipolygon style).

This version now also handles multipolygons where the "inner" ways are at the same time "outer" ways for another multipolygon.

comment:9 Changed 10 years ago by osm@…

Cc: frederik@… added
Status: newassigned

Frederik, could you please review this patch?

comment:10 Changed 10 years ago by R2D2_C3PO

In IRC bobkare requested a plain text description of what this patch does:

This patch preprocesses each multipolygon relation:

  • Create a list of all inner and a list of all outer ways
  • Tag each way with $way->{'multipolygon'} = 1, so all multipolgyon aware functions ignore it
  • Form closed ways for all inner and outer polygons. These new ways have the sum of all tags of the ways they are built from.
  • Add all inner ways to $way_storage, so they are processed to fill the inner polygons.
  • The outer ways are NOT added to $way_storage, but a new "multipolygon" object is created, with these properties
    • outer: All outer ways
    • inner: All inner ways
    • tags: All tags of the outer ways combined
  • This multipolygon object is added to $way_storage and returned for all rules that select "way" or "way|node". Functions that don't support multipolygons skip over these objects.
  • To draw a multipolygon for each combined (i.e. closed) outer and inner way a SVG path is created and the fill rule set to "fill-rule:evenodd".
  • Other functions only use multipolygons to find area-centers and just pass then on to the area_center functions.

comment:11 Changed 10 years ago by Deelkar

What happens if the multipolygon is not downloaded completely, e.g. the outer and some of the inner ways cannot be combined into closed ways, because ways outside the bbox are missing?

comment:12 in reply to:  11 Changed 10 years ago by Teemu Koskinen

Replying to osm@deelkar.net:

What happens if the multipolygon is not downloaded completely, e.g. the outer and some of the inner ways cannot be combined into closed ways, because ways outside the bbox are missing?

Could the areas be closed with the same method as the coastlines are?

comment:13 Changed 10 years ago by R2D2_C3PO

Resolution: fixed
Status: assignedclosed

This patch is commited for some time now and it did not show any problems I'm aware of, so I close this ticket.

If a polygon not completely downloaded it can't be rendered correctly. This is a real problem, but I don't know how to solve it. For example consider this situation: A polygon enclosed a Z12 tile, but does not intersect with it. Osmarender will have no chance of knowing that it should color the whole tile, because neither any node of the polygon nor the multipolygon relation are present in the data. In my opinion this can only be avoided when OSM gets a real area data type and the api makes sure all areas are correctly downloaded for a given bbox.

Note: See TracTickets for help on using tickets.