[Talk-de] Benutzung von is_in

[g.d]

Danke, Christoph.

Le 25 déc. 08 à 23:25, Christoph Eckert a écrit :
> Moin,
.../...

> Verwenden könnte man
> * is_in
> * Polygone
> * Relationen

Wie Du sagst, Relationen wären sicherlich das "logisch" geeignetste  
Mittel,
aber man kann Newcomers nicht da drauf loslassen,
das gäbe fürchterliches Durcheinander,
die Denkweise der Relations ist eben fondamental invers
zu der traditionnellen "tag=Eigenschaft"s-Denkweise,

und wenn ich ansehe,
was hier (gutwillige, begeisterte und willige) Anfänger mit potlach  
anstellen können,
da wird mir Angst und bange beim einfachen Gedanken,
was sie aus Relationen machen könnten...

Solange die Renderers nicht mitspielen (und man sofort das Ergebnis  
sieht),
und diese doppelspurige Logik tag <-> relation nicht klar aufm Wiki  
erklärt wird,
sehe ich wenig praktische Anwendung.
--

Die Geschichte mit Polygonen ist zwar logisch konsequent,
scheint mir aber ein Rückschritt in die Anfangszeiten der GIS/SIGs :-(
Da hat man dann Flâchen, die mit hin-und-her-Linien auf den gleichen  
Nodes zusammenhängen,
die aber auch die gleichen Nodes als Grenzlinien benutzen,
das wird quasi unmöglich zu editen, selbst in JOSM :-(
Dazu braucht man Editoren die besser 'für gemacht sind.
Kommt noch dazu, dass manche Renderer Drehsinn-empfindlich sind.
Das ist "has-been".

> ich stelle mir bildlich das
> interessante Polygon um Grönland und Dänemark vor :)

Oder die Anspruchsgebiete in der Antarktis !
Um diese als Polygone mit ihren Ländern zu verbinden,
kriegt man topologische Probleme,
braucht eine vierte Dimension,
oder muss Alles auf unterschiedliche Layers schieben.

Nö, die tag-Methode hat den Vorteil,
dass man zeichnen kann, was ist,
ohne daß es unbedingt in ein Schema passen muss.
--

Sodass derzeit der Tag "is_in:" der einzige praktikable Ausweg zu  
sein scheint...
Selbst wenn es auch mich ärgert,
die Datenbasis mit redundanten "France,Europe" vollzustopfen !

Irgendwie hätte ich gedacht,
dass wir seit Hollerith diese Einzwängung abgeschüttelt hätten,
und dass unsere Programme diskriminieren könnten
zwischen einem "Neuburg" an der Donau
und einem "Neuburg" in Nordrhein-Westfalen,
schon mal anhand der verschiedenen Grenz-Polygone,
innerhalb welcher sich das eine und das andere Neuburg befindet.

Aber scheints ist die graue Masse noch nicht so weit :-(

Theoretisch müsste ein hierarchisch übergeordnetes Element gar nichts  
"wissen" davon,
aus was es besteht,
es genügt, dass die untergeordneten Elemente "wissen",
zu welchem (eindeutig identifizierten) übergeordneten Element sie  
gehören.
Der "Rest" ist Sache der Abfrage, Definition der Suchbegriffe.

Das gilt auch, wenn ein Element mehreren, unterschiedlichen  
Hierarchien untergeordnet ist :
Mehrere "Wurzelwerke" können sich schneiden und gemeinsame Punkte haben
(Das ist sogar unumgänglich für einen lebenden Organismus).

Umso wniger mag ich die ganze Hierarchie in jedem Dorf und Weiler  
wiederholen.

Meiner Ansicht nach obliegt es den auswertenden Programen,
aus den (eindeutigen) Daten die Zusammenhänge wiederherzustellen, für  
ihre Suche.
Jedes OptimierungsProgramm arbeitet auf solcher Basis.
.../...

Dazu käme noch, wenn man den Teufel im Detail suchen würde,
dass zum Beispiel
Französisch-Guyana zwar geographisch auf dem Kontinent Sudamerika liegt,
Saint-Pierre-and-Miquelon vor der kanadischen Küste,
und Wallis-et-Futuna irgendwo im Pazifik so etwa auf Höhe von Samoa  
schwimmt,
jedoch politisch und verwaltungsmässig irgendwie zur Europäischen  
Union gehören,
also irgendwie "is_in:France,Europe" sind (?).
Wie vermutlich spanische, portugiesische, englische und italienische  
Kolonien auch.

Aber derart Fragen und Aspirinverbrauch überlasse ich der Nachwelt.

Derzeit geht's mir einfach drum,
wie man Zusammenlegungen und Ortsteile taggen kann,
weil's da Widersprüche zwischen Verwaltung un Realität gibt,
und wo OSM eher die Realität wiedergeben will...
.../...

> Um auf die "Suburbs" in Karlsruhe zurückzukommen: Die stammen aus  
> einer Zeit,
> als wie in Karlsruhe froh waren, überhaupt mal was auf der Karte zu  
> haben.

Nu, ist doch gar nicht schlecht,
ich finde Karlsruhe und Umland ziemlich gut strukturiert,
im Vergleich mit manchen anderen Ecken ! :-)
(So in schnellem Überflug, von aussen gesehen...)

> (ich
> verschweige jetzt lieber dass es ein gleichnamiges Dorf in den Staaten
> gibt ;) .

Das müsste ein Vergleich mit den Daten der umliegenden Grenzpolygonen  
klarkriegen,
ohne dass man im "is-in:" bis aufs Niveau Europe beschreibt :-)


> Dann habe ich diesen
> und die einzelnen Ortsteile zusammen in eine Relation gestopft, um den
> administrativen Zusammenhang herzustellen.

Aha, jetzt versteh' ich besser,
weshalb der Text 'Straubenhardt' und auch 'Mannheim' wie 'Ludwigshafen'
ab zoom 15 verschwindet : Das sind relations...
Und wird quasi unmöglich, zu managen :-(
.../...

>  Aber bevor nicht unsere Editoren
> dazugelernt haben, ist das einfach nichts, was man mehr als  
> sporadisch in der
> Datenbank haben möchte.

Und wir wissen auch nicht,
ob es wirklich wünschenswert ist, oder wirklich effizient ist,
derart gegensätzliche Logiken in einem einzigen System zusammenzufassen.
Weil, wenn man den Gedanken der Relationen bis zu Ende führt,
kann er die derzeitige Art und Weise vollständig ersetzen !
Aber mit den derzeitigen UI ist das unmöglich zu editieren :-(
.../...

Deshalb suchen wir,
wie man diese Abhängigkeiten der Orte am Besten deichselt,
und nicht das Rad neu erfinden zu müssen...

Eure Erfahrungen sind uns wertvoll.
--

Grüße aus Südfrankreich,
und schöne Feiertage wünsche ich Euch !
Gerhard
---