[Talk-de] Relationsstruktur fuer geografische Einordnung - is_in

marcus.wolschon at googlemail.com marcus.wolschon at googlemail.com
Do Okt 8 10:32:07 UTC 2009


On Thu, 08 Oct 2009 12:20:43 +0200, Ulf Lamping
<ulf.lamping at googlemail.com>
wrote:
>> Mit dem is_in -Tag werden wir immer Einträge haben, die nicht zusammen
>> passen
>> und jede Menge die halt fehlen.
> 
> Ja, eine Unschärfe bleibt leider. Allerdings ist mir ein unscharf (nicht

> falsch) eingetragener is_in lieber als eine garnicht eingetragene 
> Relationszugehörigkeit.

Ich kann bei einer Suche keinen Unterschied erkennen ob kein is_in gefunden
wird oder ob das Objekt nicht in einer entsprechenden Relation (Variante B)
oder nicht in einem entsprechenden Polygon(Variante A, robuster) ist.


>> Das ist einfach ein technisch schlechter Lösungsansatz um ein
>> enthalten-sein
>> auszudrücken.
> 
> Beide Varianten haben so ihre Vor- und Nachteile.
> 
> Technisch sind die Relationen zwar auch aus meiner Sicht besser, aber 
> für einen Crowdsourcing Ansatz ist is_in für den Mapper "da draussen" 
> (zumindest aktuell) einfacher.
> 
> is_in kann man halt recht einfach aus dem Kopf machen:
> 
> Kleinkleckersdorf, Landshut, Bayern, Deutschland, Europa, Erde, 
> Sonnensystem, Milchstraße

In der Tat ist es natürlich einfacher zu mappen, nur ist es genauso
einfach eine Ebene zu vergessen oder eine andere Schreibweise zu verwenden
oder bei einer Änderung nicht alle Vorkommnisse zu bemerken.

Bei einem Polygon kann das nicht passieren und bei einer Relation
ist jedes in sie eingetragene Objekt auch mit grosser Sicherheit richtig.

Unterhalb der Ebene der Ortschaft/Stadtteil halte ich Relationen für
zu aufwendig, da muss es ein Polygon sein. Darüber ist mir beides Recht
aber is_in lehne ich dort ab.

> Die passende Relation muß man erstmal finden bzw. anlegen. Die aktuelle 
> "einfache Benutzbarkeit" der Editoren auf dem Gebiet der Relationen ist 
> hoffentlich bekannt.

Ich sehe das eher anders herum. Wenn keiner sie benutzt, werden die
Editoren auch nicht besser da weder Anforderungen erkannt werden noch
eine Priorität (um nicht Leidensdruck zu sagen) für solche Verbesserungen
besteht.

> Ergo: Solange das Handling der Relationen noch nicht wirklich "schön" 
> ist, kommen wir mit is_in erstmal schneller voran. Wenn wir später die 
> Editoren soweit haben, können wir die is_in immer noch mit vertretbarem 
> Aufwand in Relationen umwandeln ...

Genau diesen "vertretbaren Aufwand" bezweifle ich.


Marcus




Mehr Informationen über die Mailingliste Talk-de