[OSM-dev] Relation member_roles from Osmosis import

[Jochen Topf]

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 <brfr at metrico.lu>
> To: Jochen Topf <jochen at remote.org>
> CC: dev at openstreetmap.org
> 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  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298