Common. There are many, many broken multipolygon relations. See http://tools.geofabrik.de/osmi/debug.html?view=multipolygon&lon=13.04883&lat=44.58577&zoom=5
Whatever you do with OSM data you have to take into account that its not perfect and work around that. Jochen On Thu, Oct 28, 2010 at 02:48:12PM +0200, Frank Broniewski wrote: > Date: Thu, 28 Oct 2010 14:48:12 +0200 > From: Frank Broniewski <[email protected]> > To: Jochen Topf <[email protected]> > CC: [email protected] > Subject: Re: [OSM-dev] Relation member_roles from Osmosis import > > Hello Jochen, > > thanks for your answer, that makes it clear. I have another question > about relations. > > I found a relation, a lake in Germany, (id=1104680, Schweriner See > (Außensee)), which has serveral inner relations to ways. Some of these > ways form a closed ways, so it's easy to create a polygon from it. But > other ways with the relation role "inner" are not closed, but they form > together an island in the lake. > > Should't those form a relation of themselves before relating them to the > lake relation with an inner relation? The ways I am speaking of are > > 24563810 > 70191810 > 70191809 > 70191807 > > Luckily those ways form an island but if there would be another island > formed by ways without relating them together it is quite difficult to > recreate them properly. Is this situation an exception or is this a > common situation? > > Frank > > > > Am 27.10.2010 11:01, schrieb Jochen Topf: >> On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: >>> During my examinations from an OSM import (osmosis pbf to postgis) I >>> found some strange looking entries in the relation_members table. My >>> goal is to make (GIS) polygons from the linestrings table and therefore >>> I examined the relations a little closer. >>> >>> Doing a >>> select distinct relation_id, member_role from relation_members >>> >>> I find these entries in the result, which I suspect to be wrong >>> >>> "relation_id", "member_role" >>> 22852;"forward_stop_0" >>> 22852;"forward_stop_11" >>> 22852;"forward_stop_19" >>> 22852;"forward_stop_9" >>> 22852;"stop_1" >>> 22852;"stop_10" >>> 22852;"stop_12" >>> 22852;"stop_13" >>> 22852;"stop_14" >>> 300710;"backward_stop_%n" >>> 207675;"forward_stop_%n" >>> >>> I think that numbering the member_role is not the intended way ;-) >> >> Thats a left-over from the time when relation members were not ordered. >> >> Jochen > > > -- > Frank BRONIEWSKI > > METRICO s.à r.l. > géomètres > technologies d'information géographique > rue des Romains 36 > L-5433 NIEDERDONVEN > > tél.: +352 26 74 94 - 28 > fax.: +352 26 74 94 99 > http://www.metrico.lu > -- Jochen Topf [email protected] http://www.remote.org/jochen/ +49-721-388298 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
