[OSM-talk] conclusions from my postgres / postgis experiments
Andy Robinson
Andy_J_Robinson at blueyonder.co.uk
Thu Nov 23 10:22:02 GMT 2006
David Earl wrote:
>Sent: 23 November 2006 10:09 AM
>To: OSM
>Subject: Re: [OSM-talk] conclusions from my postgres / postgis experiments
>
>
>
>> -----Original Message-----
>> From: talk-bounces at openstreetmap.org
>> [mailto:talk-bounces at openstreetmap.org]On Behalf Of raphael Jacquot
>> Sent: 23 November 2006 09:23
>> To: talk at openstreetmap.org
>> Subject: [OSM-talk] conclusions from my postgres / postgis experiments
>>
>>
>> here's what I found during my little^Wextensive experiment:
>>
>> 1) we have tons of duplicate segments
>> ((s1.from = s2.from) AND (s1.to = s2.to)) OR
>> ((s1.from = s2.to) AND (s1.to = s2.from))
>> 2) we have 4000+ degenerate segments
>> (s.from = s.to)
>> 3) we have ways with no segments
>> 4) we have degenerate ways where the way is neither a proper linear
>> feature nor a proper closed polygon, but rather an unwidedly spaghetti
>> monster. most of those furthermore involve a loop of some sort...
>
>I'm not sure (4) is necessarily wrong or undesirable. I certainly started
>creating some of these quite deliberately before I understood better how
>the
>rendering works. But I shouldn't have to subvert the actual structure to
>the
>needsof a particular renderer. A typical example is a street which branches
>many ways but has the same name throughout. I have come across two
>"streets"
>so far in Cambridge which are basically huge roundabouts with branches
>leading off at many points. Another example is a linear street with dozens
>short side arms. Many, many dead end residential streets are linear with a
>T
>at the end (indeed nearly all, though most are just short turning arms
>which
>I haven't represented, except where they are longer than a car's length).
>Many also end in a little loop with green space in the middle, though these
>can in fact be represented as linear (with the last point incommn wth
>another point in the way).
>
>So the question is, how should these naturally spaghetti-like entities
>actually be represented. More recently (for the above, for example) I've
>been splitting them up into ways that are linear. But this has
>disadvantages
>as well in that it is not immediately (mechanically) obvious that they are
>all part of the same entity.
>
>I think it would be better to allow the spaghetti and have the intelligence
>built into the renderer to make sense of these. It is semantically more
>useful, creates a better index (gazeteer).
I'd agree with your overall comments here and I believe it would be counter
productive to have editors strictly stick to linear ways. However it should
be possible to break a complex way down automatically into its constituent
linear parts and then place them all in a reference container (superways has
be coined). The end users don't need to see this but it would make rendering
and further usage of the data more straightforward.
Cheers
Andy
Andy Robinson
Andy_J_Robinson at blueyonder.co.uk
>
>The other case is where ways end up with segements out of order (which at
>present osmarender causes to destroy the names by splitting the text). But
>if a renderer understands spaghetti it can understand these too.
>
>David
>
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
More information about the talk
mailing list