[Talk-de] Winkel-Tool

qbert biker qbert1 at gmx.de
So Apr 6 08:31:54 UTC 2008


Hallo,

> Ich glaube nicht, dass es bei Rechtecken bleiben wuerde.

Wenn das Konzept erfolgreich ist, vielleicht nicht.
 
> Du sprichst von der Komplexitaet beim Erfassen. Da sehe auch ich keine 
> Probleme. Ich sprach von der Komplexitaet beim Rendern (oder sonstiger 
> Auswertung); jeder Renderer muesste ergaenzt werden, um aus einem 
> speziell getaggten Geometrie-Node eine saubere Flaeche malen zu koennen. 

'Müssen' ist so ein hartes Wort ;). Und ja, ich halte es einer
Überlegung Wert, dass die Renderer ein Grafikprimitiv dazulernen.
Aber wie schon geschrieben - es ist alles bisher innerhalb der
API realisierbar und deshalb schon rein prinzipiell optional.

>     Und nicht nur die Renderer, auch die Editoren muessten das 
> ordentlich darstellen, und die Exportfilter muessten es geeignet 
> exportieren, und so weiter. Streng genommen muesste sogar die API 
> erweitert werden, denn wenn ich alle Objekte in einem Rechteck 
> anfordere, will ich bitteschoen auch wissen, ob sich in dem Rechteck 
> zufaellig ein halbes Fussballfeld befindet, dessen Geometriekontrollnode 
> aber leider auf der anderen Ecke und damit ausserhalb des angeforderten 
> Bereichs liegt...

Solche Probleme haben wir ja heute schon genug. Sicherzustellen,
dass alles in einem Bereich erfasst wird ist ja alles andere 
als simpel. Eine ziemlich erfolgreiche Methode dazu ist das
umschreibende Rechteck und das lässt sich auf eine symbolisch
beschriebene Form ausweiten. 

Letztens wurde ja mal geschrieben, dass eine längere gerade 
Strecke durch Stützknoten unterbrochen werden soll, weil sie 
sonst u.U von den Renderern nicht erfasst wird. Solche Krücken
könnten dann vielleicht auch gleich unter den Tisch fallen.

Aber zurück zum Ausgangsthema: Bis auf ein paar handwerkliche
Kleinigkeiten spricht derzeit doch nichts gegen das Konzept. 
Der Worstcase nach deiner Antwort ist, dass ein Rechteck nicht
dargestellt wird, wenn die Node ausserhalb ist. 
 
Auf der anderen Seite macht OSM natürlich ein Tor hinter sich
zu, wenn Standarddinge wie Grafikprimitive nicht direkt gespeichert 
werden können. Eine Applikation, die OSM als Quelle verwendet
und mit mehr Grafikprimitiven als Polygenen arbeitet kann 
veredelte Daten als solche nicht in die OSM-DB zurückschreiben, 
sondern nur in aufgeblähter Form unter Informationsverlust.

Grüsse Hubert
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger




Mehr Informationen über die Mailingliste Talk-de