Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Sarah Hoffmann]

On Mon, Jul 09, 2012 at 11:51:13PM +0200, Christian Müller wrote:
> Am 09.07.2012 21:47, schrieb Frederik Ramm:
> > Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
> > nicht.
> 
> Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
> wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
> Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
> Elementen nur noch in der Relation auftauchen.

Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation
ausser den drei wirklich gebrauchten (Routen, Abbiegerelation,
Multipolygon) nachweinen würden?

Wie Jochen bereits gesagt hat, muss man für die meisten Sachen den
Fall ohne Relationen ohnehin implementieren, weil es dieser Fall
immernoch der häufiger gebrauchte ist.

> Mich hat bisher kein einziges Argument gegen Relationen überzeugt. 
> Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für
> den restlichen OSM-Datenbestand.  Ich sehe z.B. immer wieder nicht
> verbundene Nodes, versehentlich verschobene, etc.

Relationen sind wesentlich leichter versehnlich kaputt zu machen als
Nodes, Wege und Tags, weil sie unsichtbar im Hintergrund herumlungern
und man nicht sofort sieht, dass man da etwas ändert. 

> Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein
> spatiale DB ist.  Es ist ein Mix - whatever works entscheidet, wer wie
> etwas modelliert.  Natürlich bedeuten diese Freiheiten Komplexität in
> der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu
> zwingen, einheitlich zu mappen.  Ein Einwirken auf jeden der dann nach
> Überlegung "falsch" mappt, wird denjenigen die Lust am Mappen verderben.

Wenn du dir zuviel dieser "Freiheiten" herausnimmst, schränkst du
gewaltig die Freiheiten der anderen Mapper ein. Siehe oben. Relationen
sind in erster Linie ein Hindernis für deine Mitmapper. Es geht nicht
darum, 'einheitlich' zu mappen, es geht darum, das ganze so einfach wie
möglich zu halten, damit es für alle verständlich bleibt.

Ausserdem sind Relationen ein Motivationskiller, wenn es darum geht 
Fehler zu korrigieren. Wer mag schon einen Weg anfassen, der Mitglied 
in 15 Relationen ist. Ein Weg mit 15 kryptischen Tags ist zwar auch 
ein bisschen lästig, aber normalerweise kann man die Tags einfach 
ignorieren, frei nach dem Motto 'leben und leben lassen'.

> Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
> der gleiche geografische Sachverhalt eben vielfältig modelliert werden
> kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
> stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
> gesucht, wie es Knoten und Weg nunmal sind?

Geografische Sachverhalte sollte man über Geometrie ausdrücken und
nicht durch irgendwelche künstlichen Strukturen. Natürlich könnten
wir für jede Bushaltestelle eine Relation erstellen, die besagt, ob
sie jetzt rechts von der Strasse liegt oder links. Aber was ist der
Sinn? Diese Information ist bereits in der DB, das heisst die Relation
bringt absolut nichts.

> Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt
> werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit
> zu bewahren und die Pflege zu vereinfachen.  Sie können evtl. 50+
> Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege
> nur den regional üblichen Namen halten.  Auch mit Lookup-Tables/LUT
> versagt irgendwann der minimalistische Ansatz.  Je nachdem, wieviel
> Information über eine Menge von Wegen oder Knoten gehalten werden soll. 
> Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und
> dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum
> dokumentiert und die Art ihrer Implementierung variiert.  Die Live-DB,
> die Live-Toolchain verwendet sie nicht.  Zudem wird mit der Auslagerung
> von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt
> nur nicht vom Menschen.

Jetzt wirfst du irgendwelche technischen Begriffe in den Raum ohne
dir wirklich mal einen Kopf gemacht zu haben, wie das ganze eigentlich
funktioniert. Redundanz in den Tags ist bisher einfach kein grosses Problem 
gewesen. Die Art und Weise wie Datenbanken das handhaben, ist effizient 
genug. Wir haben ganz andere Ecken, wo wir ernsthafte Probleme mit der
Effizienz bekommen. In erster Linie bei der Berechnung der Weggeometrien
und dem Node-Lookup. 

> Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt
> sind, ist das mehr an Information und evtl. auch Redundanz eine Chance,
> gute QM-Tools zu bauen.  Am Beispiel der Bundesstraßen z.B. könnte man
> die Argumente derjenigen aufgreifen, die meinen
> 
> "man könne den Verlauf der Bundesstraße auch programmatisch anhand
> des ref= zusammenbauen und braucht die Relation gar nicht"
> 
> und gegen das prüfen, was manuell gepflegt wird.  In der Summe ergibt
> das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen
> kann:
> 
> -

Re: [Talk-de] ergänzende Frage - bevor diese vergessen wird...

[Jochen Topf]

On Mon, Jul 09, 2012 at 11:59:54PM +0200, Jo wrote:
> komische Frage. Nah ja, ist schon entscheiden dass in Deutschland
> Relationen ersetzt werden? Ich habe nicht die ganze Diskussion gefolgt.
> Macht ihr wirklich einen Schritt rückwerts? Nur in Deutschland, oder alle
> deutschsprachige Gebiete? Oder sogar weltweit?
> 
> Jedenfalls ist so ein Program relativ einfach zu schreiben. Was natürlich
> die Idee das Relationen schwierig auszuwerten sind, löscht..

Quark. Wenn Du schon nicht bereit bist, der Diskussion zu folgen, dann solltest
Du vielleicht auch nicht Deinen Senf dazu geben.

Es ist eben enorm schwierig so ein Programm zu schreiben. Weil es eben lauter
verschiedene Relationen gibt und verschiedene Interpretationen, welche Tags
genau wo hingehören usw. Darüber ging ja nun die ganze Diskussion hier. So
ein Programm kann man allenfalls für genau spezifizierte Einzelfälle schreiben
und daher gibts sowas in der Allgemeinheit, die Jan will, auch nicht.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Jochen Topf]

On Mon, Jul 09, 2012 at 11:51:13PM +0200, Christian Müller wrote:
> Am 09.07.2012 21:47, schrieb Frederik Ramm:
> > Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
> > nicht.
> 
> Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
> wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
> Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
> Elementen nur noch in der Relation auftauchen.

Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten. Die
Konsequenz davon kann natürlich nicht sein, dass man sie einfach abschafft.
Die Konsequenz ist, dass man sie durch etwas besseres ersetzt. Oder,
realistischer, dass man den one-size-fits-all-Ansatz ergänzt durch
Speziallösungen für Spezialfälle, mit denen dann jeweils einfacher zu
arbeiten ist.

Relationen haben uns neue und tolle Möglichkeiten gebracht. Die wollen wir
nicht missen. Aber sie haben uns eben auch eine Menge Schwierigkeiten gebracht.
Alle Leute, die ich kenne, die selbst Code schreiben, um Relationen
auszuwerten, haben Schwierigkeiten damit. Und die Mapper haben auch ihre
Schwierigkeiten damit. Ein kaputter Way hat Auswirkungen nur in der direkten
Nachbarschaft dieses Ways. Eine kaputte Relation kann Auswirkungen auf die
halbe Welt haben.

Das sind einfach Probleme, denen wir uns stellen müssen. Wir müssen überlegen,
wie wir konkret Fortschritte erzielen. Das geht am besten, in dem wir uns die
Erfahrungen mit OSM anschauen und davon lernen. Wir müssen drüber nachdenken,
wie man die OSM-Daten strukturieren so kann, dass sie leichter zu benutzen
und auszuwerten sind, ohne die Mächtigkeit des bestehenden Modells 
einzuschränken.
Und dazu muss man halt erstmal rausarbeiten, wo die Probleme sind. 

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ergänzende Frage - bevor diese vergessen wird...

[Jan Tappenbeck]

Am 09.07.2012 23:59, schrieb Jo:

komische Frage. Nah ja, ist schon entscheiden dass in Deutschland
Relationen ersetzt werden? Ich habe nicht die ganze Diskussion gefolgt.
Macht ihr wirklich einen Schritt rückwerts? Nur in Deutschland, oder alle
deutschsprachige Gebiete? Oder sogar weltweit?

Jedenfalls ist so ein Program relativ einfach zu schreiben. Was natürlich
die Idee das Relationen schwierig auszuwerten sind, löscht..


Hallo Jo,

aber gibt es schon wo frei verfügbare Komponenten / Programme / 
Erläuterungen / Beispiele ?


Gruß Jan :-)


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ergänzende Frage - bevor diese vergessen wird...

[Jo]

komische Frage. Nah ja, ist schon entscheiden dass in Deutschland
Relationen ersetzt werden? Ich habe nicht die ganze Diskussion gefolgt.
Macht ihr wirklich einen Schritt rückwerts? Nur in Deutschland, oder alle
deutschsprachige Gebiete? Oder sogar weltweit?

Jedenfalls ist so ein Program relativ einfach zu schreiben. Was natürlich
die Idee das Relationen schwierig auszuwerten sind, löscht..

Jo

2012/7/9 Jan Tappenbeck 

> Hi !
>
> es wird ja viel diskuttiert und damit habe ich ja auch schon etwas
> erreicht.
>
> Aber bevor es aus dem Blick gerät - meine Frage nochmal..
>
>
> Die HL-Frage gilt es jetzt noch zu klären. Gibt es vielleicht irgendwo
> schon jetzt ein Programm um die Daten der Relations/Proposed/Buildings auf
> die OSM-Objekte zu übertragen. Also File rein und ergänztes File wieder
> aus. Und das ganze Performant. Vielleicht ein C-Teil ???
>
> Gruß Jan :-)
>
>
> __**_
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Christian Müller]

Am 09.07.2012 21:47, schrieb Frederik Ramm:
> Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben
> nicht.

Genau das ist der Punkt.  Schmeißen wir die Relationen weg, verprellen
wir Anwender und Entwickler bestimmter Anwendungsfälle genau so, wie es
Unkenrufe geben wird, wenn plötzlich Namen einer Straße aus mehreren
Elementen nur noch in der Relation auftauchen.

Mich hat bisher kein einziges Argument gegen Relationen überzeugt. 
Einzig evtl., dass sie schlecht gepflegt sind - das gilt aber auch für
den restlichen OSM-Datenbestand.  Ich sehe z.B. immer wieder nicht
verbundene Nodes, versehentlich verschobene, etc.

Ich kann auch Sarah's Argumenten nicht folgen, dass OSM eine rein
spatiale DB ist.  Es ist ein Mix - whatever works entscheidet, wer wie
etwas modelliert.  Natürlich bedeuten diese Freiheiten Komplexität in
der Auswertung - das ist aber imho dennoch weniger Aufwand, als alle zu
zwingen, einheitlich zu mappen.  Ein Einwirken auf jeden der dann nach
Überlegung "falsch" mappt, wird denjenigen die Lust am Mappen verderben.

Für mich bedeuten Relationen Flexibilität - u.U. oft auch, dass ein und
der gleiche geografische Sachverhalt eben vielfältig modelliert werden
kann.  Warum begreifen wir das nicht weiterhin als Chance?  Warum wird
stattdessen der Perfektionismus in primitiveren, unstrukturierten Daten
gesucht, wie es Knoten und Weg nunmal sind?

Relationen sind auch dort, wo eigentlich alles auf dem Weg getaggt
werden könnte, eine sinnvolle Ergänzung, z.B. um die Übersichtlichkeit
zu bewahren und die Pflege zu vereinfachen.  Sie können evtl. 50+
Übersetzungen halten, während die bsp.-haften, sechs zugehörigen Wege
nur den regional üblichen Namen halten.  Auch mit Lookup-Tables/LUT
versagt irgendwann der minimalistische Ansatz.  Je nachdem, wieviel
Information über eine Menge von Wegen oder Knoten gehalten werden soll. 
Auch wenn LUT evtl. in einigen Software-Projekten anzutreffen sind und
dort eine Tag-Redundanz erfolgreich wegoptimieren, sind sie kaum
dokumentiert und die Art ihrer Implementierung variiert.  Die Live-DB,
die Live-Toolchain verwendet sie nicht.  Zudem wird mit der Auslagerung
von Tags in LUT auch nichts anderes als eine Relation geschaffen, halt
nur nicht vom Menschen.

Wenn wir schon so radikal sein wollen und so einen tollen Leitspruch wie
"vermeide Relationen" gebären wollen, warum dann nicht gleich auch auf
die Struktur "way" verzichten.  Eigentlich reicht es doch, wenn wir
alles auf dem Node taggen.  Mapper machen nur Fehler, wenn sie sich mit
der Komplexität eines way's auseinandersetzen sollen.  (..)



Weiterhin spielt die Arbeitsweise beim Mappen in diese Problematik.  Ich
würde weder diejenigen verprellen, die strukturiert arbeiten und sagen:
"Ich lege mir Bundesstraßenrelationen an, weil mir dann die Pflege
dieses Netzes einfacher fällt.", noch diejenigen, die in einem weißen
Gebiet unstrukturiert alles mögliche anlegen und von Relationen gar
nichts wissen und sie aufgrund des Datenstandes evtl. gar nicht brauchen.

Da die Daten, wie die Softwareprojekte drumrum vermutlich nie perfekt
sind, ist das mehr an Information und evtl. auch Redundanz eine Chance,
gute QM-Tools zu bauen.  Am Beispiel der Bundesstraßen z.B. könnte man
die Argumente derjenigen aufgreifen, die meinen

"man könne den Verlauf der Bundesstraße auch programmatisch anhand
des ref= zusammenbauen und braucht die Relation gar nicht"

und gegen das prüfen, was manuell gepflegt wird.  In der Summe ergibt
das eine gewisse Robustness gegen die Fehler, die man beim Mappen machen
kann:

- versehentlich Relation beschädigen
- versehentlich ref löschen

Es ist unwahrscheinlich, das beides zeitgleich passiert.  Gäbe es
hingegen eine explizite Relation nicht, würde ein Fehler durch ein
fehlendes "ref" Tag am way nicht auffallen - allein auf die Heuristik
"alle Wege, die sich einen Knoten teilen" zu bauen, ist weltfremd und
idealisiert imho viel zu stark.  Hier wünscht sich der Informatiker die
Welt herbei, wie sie sein sollte.  Beispielsweise ist der Verlauf von
Landesstraßen heute vielfach in Teilabschnitten durch Bundesstraßen
ersetzt worden und dadurch fragmentiert.  Weiterhin sehe ich nicht ein,
weshalb, nur weil es für Routing und Rendering abkömmlich ist, auf den
exotischeren Anwendungsfall "wieviele Goethestraßen gibt es in X"
verzichtet werden sollte, wenn er mit etwas Grips und gutem Willen in
der DB ohne viel Zauber und Zusatzarbeit modellierbar ist.  Die Fragen,
die sich hier viele stellen, ist doch eher, wieviel Relation ist gut? 
Wie kann vermieden werden, dass die Nutzung von Relationen, die spatiale
Verwendbarkeit einer Auswertung auf einfacheren Ebenen wie Punkt / Weg
schadet?


Gruß
Christian



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Fwd: [OSM-talk] Licence redaction ready to begin

[Simon Poole]

Der "redation-bot" wird am Mittwoch (kleiner Freudischer von Richard
beim Datum) anfangen zu laufen.

Ankündigung siehe nachfolgend.


 Original-Nachricht 
Betreff:[OSM-talk] Licence redaction ready to begin
Datum:  Mon, 09 Jul 2012 21:46:43 +0100
Von:Richard Fairhurst 
An: t...@openstreetmap.org, d...@openstreetmap.org,
annou...@openstreetmap.org



Hello all,

I'm pleased to announce that the licence change bot is ready to get 
underway.

Starting this week, we will be 'redacting' the contributions (less than 
1%) from the live database that are not compatible with the new 
Contributor Terms and Open Database Licence (ODbL) - in other words, 
they will no longer be accessible. We are expecting to begin on 
_Wednesday_ (9th July) assuming a couple of final setup details are 
completed by then.

The bot will run in the following order:
1. Ireland
2. UK
3. Western Europe
4. North America
5. Australia
6. rest of the world

Once it is complete, we will be ready to distribute data under the ODbL 
and we'll advise of that with a separate announcement. The final 
pre-redaction dataset available under CC-BY-SA has now been generated at 
http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has 
been redacted, any attempt to access it from the API or the site's 
'browse' pages will return a response to that effect.

Test runs have shown that the bot is functioning as we want it to, but 
we will of course be monitoring its progress. We are currently expecting 
it to take in the order of one month to complete; given the many 
variables I'm afraid we can't give a more precise steer yet, but we'll 
aim to keep everyone updated as it runs (via the announce@ and talk@ lists).

There will be _no_ API outage and no other interruption to editing. When 
the bot is running in your area, please do save your edits frequently to 
minimise the likelihood of conflict.

(Separate messages are going to talk-ie@ and talk-gb@ as the first two 
areas to be affected. Please do forward and translate this for your 
local mailing lists.)

As you know we were expecting this to start just after 1st April and the 
complexity of the task incurred the delay. Thank you all very much for 
your patience in waiting for it to get underway. Thank you especially to 
those who have contributed to the code, whether by patches, suggestions 
or just helping to firm up the workings.

Richard
for the OSMF board


___
talk mailing list
t...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Flughafenkarte

[Jan Tappenbeck]

hi !

es gab da einmal eine Flughafenkarte auf OSM-Basis die die Ebenen 
getrennt dargestellt hat.


Weiß einer wo diese zu finden war, wenn es diese noch gibt.

Gruß Jan :-)

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] ergänzende Frage - bevor diese vergessen wird...

[Jan Tappenbeck]

Hi !

es wird ja viel diskuttiert und damit habe ich ja auch schon etwas erreicht.

Aber bevor es aus dem Blick gerät - meine Frage nochmal..


Die HL-Frage gilt es jetzt noch zu klären. Gibt es vielleicht irgendwo 
schon jetzt ein Programm um die Daten der Relations/Proposed/Buildings 
auf die OSM-Objekte zu übertragen. Also File rein und ergänztes File 
wieder aus. Und das ganze Performant. Vielleicht ein C-Teil ???


Gruß Jan :-)


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Jochen Topf]

On Mon, Jul 09, 2012 at 09:28:03PM +0200, Stephan Wolff wrote:
> >
> >Klar, die haben dann einen gemeinsamen Node.
> 
> Selbst diese einfache Heuristik erfordert schon viel Programmier- und
> Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen.
> Schon bei Straßen mit zwei Richtungsfahrbahnen oder Straßen mit
> Kreisverkehr scheitert die Heuristik.

Was Du da haben willst ist halt schon eine sehr spezielle Fragestellung. Da
macht das auch nichts, wenn das etwas schwieriger ist. Und was ist, wenn morgen
jemand kommt, der alle 30er-Zonen in Bayern zählen will oder alle Wege auf
Friedhöfen im Ruhrgebiet. Willste dann auch immer neue Relationen einführen und
die alle pflegen lassen?

> >Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand
> >vielleicht richtig angelegt hat oder auch nicht.
> 
> Falsche Daten führen natürlich immer zu falschen Ergebnissen. Falsche
> Relationen fallen genauso auf, wie falsche name-Tags.

Ja, aber falsche Ways sind schnell erkannt und gefixt. Falsche Relationen
sind viel schwieriger zu erkennen und zu fixen. Damit wird es immer so sein,
dass Du Dich auf die Relationen nicht verlassen kannst. Und daher gehste dann
in der Praxis bei der Auswertung den aufwändigeren, aber robusteren Weg ohne
die Relationen. Dann kannste die Dir die Relationen aber einfach sparen.

Ein anderes Beispiel: In Multipolygon-Relationen sollte man eigentlich Rollen
"outer" und "inner" vergeben. Aber das blicken die Leute nicht und machen
es häufig falsch. Wenn man die Multipolygon-Relationen also auswerten will,
dann ignoriert man einfach die Rollen und setzt die Multipolygone auch ohne
diese Information zusammen. Das geht ganz gut. Auf jeden Fall geht es besser,
als sich auf die Angaben der Mapper zu verlassen.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Frederik Ramm]

Hi,

On 09.07.2012 21:28, Stephan Wolff wrote:

Selbst diese einfache Heuristik erfordert schon viel Programmier- und
Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen.


Ja, aber schau Dir mal die aktuellen Nahverkehrsrelationen an und sag 
mir, welche OSM-Nutzer das durchfuehren kann ;)



Der übliche OSM-Ansatz ist es doch, Daten von Ortskundigen erfassen zu
lassen und explizit in die Datenbank zu schreiben.


Ortskundige, die keinen Hintergrund in Informationstechnologie und 
Objektmodellierung haben, ja.


Wir reden im Zeifel von Leuten, die lieber jede Zeile im OpenOffice mit 
10 Leerstellen einruecken als einmal auf "Format->Absatz->von links: 
1cm" zu gehen, wenn Du verstehst, was ich meine ;)



Gerade bei Straßen als namensgebendes Objekte von OSM sollte es ein
Ziel sein, diese als Gesamtobjekt für die unterschiedlichsten
Fragestellungen auswertbar zu machen.


Nein, das "sollte" nicht "das Ziel sein", das hast Du Dir jetzt eben 
gerade ausgedacht, weil Du es gern so haettest. Es gibt m.E. keinen 
zwingenden Grund dafuer. Router oder Renderer koennen schlau genug sein, 
drei aneinanderstossende Goethestrassen als "folgen Sie der 
Goethestrasse" zu interpretieren. Und wenn in der Goethestrasse eine 
Luecke ist, dann darf man auch nicht mehr sagen "folgen Sie...". Wozu 
also die Relation? Nur fuer die fiktive Frage "wie viele Strassen hat 
die Stadt"?


(Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not 
Objekte zu logischen Konstrukten zusammenzufassen, so sollten wie sie 
auch nicht zwingen, eine eigentlich zusammengehoerende Strasse in 
Stuecke zu hacken, bloss weil ein Tempolimit kommt oder der Bus abbiegt...)



Bei getrennten Richtungsfahrbahnen, Unterbrechungen durch Kreisverkehre
oder durch spätere Umbauten bleibt es eine Straße.


Ist halt die Frage, fuer wen. Fuer den Router und den Renderer eben nicht.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Stephan Wolff]

Am 09.07.2012 20:31, schrieb Jochen Topf:

On Mon, Jul 09, 2012 at 08:01:51PM +0200, Stephan Wolff wrote:

Am 09.07.2012 19:17, schrieb Jochen Topf:

On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote:

Was ist ohne Relationen möglich? Man kann (mit kleinen
Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der
"Goethestraßen" in
Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen
vollständig ersetzen eindeutig mit nein zu beantworten.


Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland
ermitteln. Warum sollte das nicht gehen?


Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße
gehören.


Klar, die haben dann einen gemeinsamen Node.


Selbst diese einfache Heuristik erfordert schon viel Programmier- und
Rechenaufwand. Kaum ein OSM-Nutzer könnte das durchführen.
Schon bei Straßen mit zwei Richtungsfahrbahnen oder Straßen mit
Kreisverkehr scheitert die Heuristik.


Außer in dem seltenen Fall, dass
eine Straße eine Unterbrechung hat. Will man das auch noch richtig erfasssen,
dann muss man ggf. über die Nähe gehen.


Das wird niemand mehr programmieren.
Der übliche OSM-Ansatz ist es doch, Daten von Ortskundigen erfassen zu 
lassen und explizit in die Datenbank zu schreiben.

Gerade bei Straßen als namensgebendes Objekte von OSM sollte es ein
Ziel sein, diese als Gesamtobjekt für die unterschiedlichsten
Fragestellungen auswertbar zu machen. Wenn die Tools noch nicht so weit
sind, kann man übergangsweise mit den tagbasierten Daten arbeiten :-))


Wobei sich bei sowas dann schon die
Frage stellt, ob man das als eine Straße oder als mehrere verstehen will. Das
hängt dann von der genauen Fragestellung ab.


Bei getrennten Richtungsfahrbahnen, Unterbrechungen durch Kreisverkehre
oder durch spätere Umbauten bleibt es eine Straße.


Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand
vielleicht richtig angelegt hat oder auch nicht.


Falsche Daten führen natürlich immer zu falschen Ergebnissen. Falsche
Relationen fallen genauso auf, wie falsche name-Tags.

Viele Grüße
Stephan







___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Jochen Topf]

On Mon, Jul 09, 2012 at 08:01:51PM +0200, Stephan Wolff wrote:
> Am 09.07.2012 19:17, schrieb Jochen Topf:
> >On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote:
> >>Was ist ohne Relationen möglich? Man kann (mit kleinen
> >>Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der
> >>"Goethestraßen" in
> >>Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen
> >>vollständig ersetzen eindeutig mit nein zu beantworten.
> >
> >Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland
> >ermitteln. Warum sollte das nicht gehen?
> 
> Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße
> gehören.

Klar, die haben dann einen gemeinsamen Node. Außer in dem seltenen Fall, dass
eine Straße eine Unterbrechung hat. Will man das auch noch richtig erfasssen,
dann muss man ggf. über die Nähe gehen. Wobei sich bei sowas dann schon die
Frage stellt, ob man das als eine Straße oder als mehrere verstehen will. Das
hängt dann von der genauen Fragestellung ab.

Auf jeden Fall ist das viel verlässlicher als einer Relation, die jemand
vielleicht richtig angelegt hat oder auch nicht. Wenn jemand ausversehen eine
Relation falsch angelegt hat, z.B. zwei Relationen statt eine, dann bekommste
mit Relationen falsche Daten und würdest daher eh den Weg über die Nodes bzw.
die Nähe gehen.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Stephan Wolff]

Am 09.07.2012 19:17, schrieb Jochen Topf:

On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote:

Was ist ohne Relationen möglich? Man kann (mit kleinen
Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der
"Goethestraßen" in
Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen
vollständig ersetzen eindeutig mit nein zu beantworten.


Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland
ermitteln. Warum sollte das nicht gehen?


Weil in der Datenbank nicht drinsteht, welche ways zur selben Straße
gehören.

Gruß
Stephan




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Jochen Topf]

On Mon, Jul 09, 2012 at 06:58:29PM +0200, Stephan Wolff wrote:
> Was ist ohne Relationen möglich? Man kann (mit kleinen
> Einschränkungen) eine Karte erstellen. Man kann nicht die Zahl der
> "Goethestraßen" in
> Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen
> vollständig ersetzen eindeutig mit nein zu beantworten.

Klar kann man ohne Relationen die Zahl der Goethestraßen in Deutschland
ermitteln. Warum sollte das nicht gehen?

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Stephan Wolff]

Am 09.07.2012 13:34, schrieb Martin Koppenhoefer:

Dreimal derselbe Name einer Straße an einer Kreuzung mit 3 Straßen
kommt durchaus in der Realität vor und ist nicht mehr ganz eindeutig
(eine Straße ist m.E. für einen Menschen linear, wenn Stiche oder
Aufsplittungen vorkommen wird man nicht mehr unbedingt von *einer*
Straße sprechen bzw. zumindest auf diesen besonderen Umstand
hinweisen).


Natürlich ist es nicht immer eindeutig, ob eine Sache zu Kategorie
A oder B gehört, ob zwei Dinge eigenständig sind oder zusammengehören.
Aber man sollte beide Fälle in den Daten ausdrücken können.

Zusammentreffende Straßen mit gleichem Namen würde ich meist als
eine verzweigte Straße und nicht als mehrere Straßen interpretieren.

Viele Grüße
Stephan


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Stephan Wolff]

Am 09.07.2012 16:43, schrieb Sarah Hoffmann:


Wir haben mit Relationen keine technisches Problem sondern
ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung
von Objekten in der DB explizit mit Relationen modeliert werden müsse
und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich
dass OSM eine spatiale DB ist und keine relationale.


Das ist eine sehr freie Interpretation von OSM. Zu den Geodaten gehört
es auch, die in der realen Welt bestehenden Zusammengehörigkeit von
Objekten abzubilden.


Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen
Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine
Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen
sollte ist die: ist die Relation wirklich nötig oder ist es möglich,
meine Information auch in Form von einfachen Tags und geografischen
Beziehungen in der DB unterzubringen.


Warum sollte man immer Tags gegenüber Relationen bevorzugen? Oft sind
verschiedene Datenmodelle möglich. Ich würde für jeden Einzelfall
eine Abwägung der Vor- und Nachteile vornehmen.

> Die Antwort auf diese Frage
> ist eindeutig, dass es möglich ist, und damit sollte die Sache
> erledigt sein.

Was ist ohne Relationen möglich? Man kann (mit kleinen Einschränkungen) 
eine Karte erstellen. Man kann nicht die Zahl der "Goethestraßen" in

Deutschland bestimmen. Somit ist die Frage, ob Tags die Relationen
vollständig ersetzen eindeutig mit nein zu beantworten.

Viele Grüße
Stephan



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Martin Koppenhoefer]

Am 9. Juli 2012 16:18 schrieb Sven Geggus :
> Das hatten wir ja auch beim Hacking WE im Umfeld Polygondatentyp diskutiert.
> Was wir eigentlich brauchen ist ein Datentyp für Flächen, Routen und
> Abbiegeregeln.


das kann man ja gerne machen und damit den Großteil der Relation
sozusagen "erschlagen" (im Prinzip ist ein Datentyp da doch auch nur
ein Spezialfall einer Relation, oder?).


> Die bisherigen Relationen verführen die Leute IMO Dinge zu
> modellieren, die hinterher kein Mensch mehr auswerten kann.


Menschen können bestimmte Relationen viel eher auswerten als
"Computerprogramme", insbesondere, wenn man anfängt, sich mehr
"Rollen" auszudenken, um damit verschiedene Objekte untereinander in
Beziehung zu setzen. Aufgrund der Kenntnis der Verhältnisse in der
realen Welt kann man sich da sicher meist irgendwas zusammenreimen.
Ein kaum genutzter Relationstyp (oder role eines members) ist so
ähnlich wie ein seltenes tag: nur wenige wenn überhaupt werden das
auswerten, es kann aber trotzdem eine coole Spezialanwendung geben,
die gerade das nutzt.

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Jochen Topf]

On Mon, Jul 09, 2012 at 04:26:26PM +0200, Manuel Reimer wrote:
> Frederik Ramm wrote:
> >Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie
> >Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn
> >sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein 
> >
> >oder  oder  auftaucht, fliegt Dir der XML-Parser
> >entweder um die Ohren oder schmeisst das Ding ganz weg.
> 
> Das schließt aber nicht aus, dass man serverseitig eine gewisse
> "Qualität" von Relationen erzwingt.
> 
> So könnte man z.B. bei "Multipoligon-Relationen" auf dem Server
> direkt deren Plausibilität prüfen und wenn das nicht hinhaut, dann
> direkt ablehnen.
> 
> Genau so kann man die zunehmende "Kreativität" mit Relationen so
> etwas dämpfen. Was der Server nicht kennt, das kann auch nicht
> hochgeladen werden --> Fertig.

Das Problem ist hier wieder die Komplexität und ungeeignete Datenhaltung der
Relationen. Es wäre für den Server mit erheblichem Aufwand verbunden,
Multipolygon-Relationen auf Korrektheit zu prüfen, genauso wie das für jeden
anderen auch schwierig ist. Das dem zentralen Server aufzubürden ist sehr
problematisch.

D.h. wir brauchen m.E. erst eine bessere Datenstruktur, die leichter auf
Korrektheit geprüft werden kann. Insbesondere muss diese Datenstruktur die
Eigenschaft haben, dass es eine genau definierte Liste an Operationen gibt,
die auf ihr ausgeführt werden kann. Und der Server kann sicherstellen, dass
die Datenstruktur als ganzes korrekt bleibt, wenn nur diese Operationen
ausgeführt werden. Und das *ohne* dass jedesmal die gesamten Daten neu
überprüft werden müssen. Sowas müßte sich machen lassen, aber ich glaube
nicht, dass das basierend auf Relationen geht.

Das ganze ist daher so wichtig, weil wir sehr große Objekte haben ("Grenze
von Russland" z.B.). Der Stand der Dinge heute ist so, dass das Verschieben
eines Nodes in Sibirien die gesamte Grenze ungültig machen kann. Und das
läßt sich nur prüfen, wenn man das gesamte Ding betrachtet. Davon müssen
wir wegkommen, wenn wir jemals robusten Datenstrukturen haben wollen.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Sarah Hoffmann]

On Mon, Jul 09, 2012 at 01:20:51PM +0200, Frederik Ramm wrote:
> Bei Relationen ist wenigstens ein generischer Support moeglich -
> gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation
> ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im
> XML halt ploetzlich ein  oder  oder 
> auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder
> schmeisst das Ding ganz weg.
> 
> Eventuell sollte man alle diese neuen Datentypen dann in irgendwas
> gleichartiges kapseln, so dass eine Software, die den Datentyp nicht
> versteht, nicht total aufgeschmissen ist *duck*

Genau aus diesem Grund finde ich Relationen so wie sie sind eigentlich
eine geniale Idee, einfach und flexibel. (Aauch in der Verarbeitung,
wenn man sich mal eine Minute von osm2pgsql lösen kann.)

Wir haben mit Relationen keine technisches Problem sondern
ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung
von Objekten in der DB explizit mit Relationen modeliert werden müsse
und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich 
dass OSM eine spatiale DB ist und keine relationale.
Anstatt also zu überlegen, was man den Leuten alles
verbieten müsste, sollten wir die Mapper besser darüber aufklären,
warum ihre Relationsmania überflüssig und gefährlich ist.

Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen
Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine
Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen
sollte ist die: ist die Relation wirklich nötig oder ist es möglich,
meine Information auch in Form von einfachen Tags und geografischen
Beziehungen in der DB unterzubringen. Die Antwort auf diese Frage
ist eindeutig, dass es möglich ist, und damit sollte die Sache 
erledigt sein.

Ähnliches gilt für Anwendungen, die hier in letzter Zeit diskutiert
wurden. (Ich denke mit Schaudern an den Thread zum Eisenbahn-Tagging.)
Redundanz ist kein Argument für Relationen. "Ich weiss nicht, wie man
es anders in einer spatialen Datenbank verarbeiten kann" ist kein Argument
für Relationen. "Ich kann die Daten so leichter runterladen" ist kein
Argument für Relationen. Das einzige relevante Argument ist: es geht nicht 
anders[1]. Und das sollten wir allen Mappern klar machen. Wie es
eine ungeschriebene "on the ground"-Regel gibt, sollten wir eine 
"vermeide Relationen"-Regel einführen und so oft wie möglich zitieren.

Wenn wir es schaffen mehr Selbstdisziplin zu üben und Relationen auf 
eine Handvoll klar definierter Anwendungsfälle zu begrenzen, braucht 
es keine Änderung an der API.

Gruss

Sarah

[1] Und bevor man mich jetzt zu sehr beim Wort nimmt: das schliesst
auch die Fälle ein, wo es zwar anders ginge, aber nur von hinten
durch die Brust etc.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kreuzungen finden mit Nominatim?

[Matthias Meisser]

Hi Marian,

soweit ich das beurteilen kann, klappt das (noch) nicht
http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview

Ich glaub die Leute von frankfurt-gestalten.de hatten mal ein ähnliches 
Problem, bin mir aber nicht sicher ob/wie die es gelöst hatten.


Matthias

Am 09.07.2012 12:32, schrieb Marian Steinbach:

Hallo!

Gibt es eine Möglichkeit, mit Nominatim die Kreuzung zweier Straßen zu finden?

Danke & Grüße

Marian

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Manuel Reimer]

Frederik Ramm wrote:

Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie
Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst wenn
sie nicht wissen, was sie bedeutet. Aber wenn im XML halt ploetzlich ein 
oder  oder  auftaucht, fliegt Dir der XML-Parser
entweder um die Ohren oder schmeisst das Ding ganz weg.


Das schließt aber nicht aus, dass man serverseitig eine gewisse "Qualität" von 
Relationen erzwingt.


So könnte man z.B. bei "Multipoligon-Relationen" auf dem Server direkt deren 
Plausibilität prüfen und wenn das nicht hinhaut, dann direkt ablehnen.


Genau so kann man die zunehmende "Kreativität" mit Relationen so etwas dämpfen. 
Was der Server nicht kennt, das kann auch nicht hochgeladen werden --> Fertig.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Sven Geggus]

Jochen Topf  wrote:

> Die Alternative zu Relationen sind neue Datenstrukturen, die genau das
> machen, was wir wollen.

Das hatten wir ja auch beim Hacking WE im Umfeld Polygondatentyp diskutiert.
Was wir eigentlich brauchen ist ein Datentyp für Flächen, Routen und
Abbiegeregeln. Die bisherigen Relationen verführen die Leute IMO Dinge zu
modellieren, die hinterher kein Mensch mehr auswerten kann.

Gruss

Sven

-- 
   This APT has Super Cow Powers.
(apt-get --help on debian woody)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Martin Koppenhoefer]

Am 9. Juli 2012 12:50 schrieb Stephan Wolff :
> Das glaube ich nicht. In OSM besteht eine Straße meist aus mehreren
> Objekten mit gleichem Namen und unterschiedlichen Eigenschaften.
> Kein Mensch würde sagen, dass es drei hintereinanderliegende
> "Goethestraßen" gibt.


wirklich einfach ist das aber trotzdem nicht überall. Klar, wenn es
sich um hintereinanderliegende Straßensegmente handelt, die z.B. wegen
unterschiedlichem Belag oder einer Abbiegerestriktion etc.
aufgesplittet wurden, dann würde ein Mensch die zusammenfassen. Habe
aber hier in historischen Stadtkernen in letzter Zeit öfters den Fall
erlebt, dass "mehrere Straßen" denselben Namen hatten, weil auch z.B.
Stichstraßen denselben Namen bekommen hatten, oder weil sich die
Straße geteilt und nach einigen Häusern wieder verbunden hat.

Dreimal derselbe Name einer Straße an einer Kreuzung mit 3 Straßen
kommt durchaus in der Realität vor und ist nicht mehr ganz eindeutig
(eine Straße ist m.E. für einen Menschen linear, wenn Stiche oder
Aufsplittungen vorkommen wird man nicht mehr unbedingt von *einer*
Straße sprechen bzw. zumindest auf diesen besonderen Umstand
hinweisen).

Konkretes Beispiel:
http://www.openstreetmap.org/browse/way/170356491
http://www.openstreetmap.org/browse/way/170431940


> Im idealen Renderer sollte es keinen Unterschied machen, wie ein Objekt
> OSM-intern angelegt ist. Ein Split eines Weges sollte keine Auswirkung
> auf die Darstellung des Namens haben.


+1, da wäre es wünschenswert, wenn Segmente von Straßen für die
Darstellung des Namens im Renderer (bzw. der Datengrundlage)
zusammengefügt würden.

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Frederik Ramm]

Hallo,

On 07/09/12 12:02, Peter Wendorff wrote:

Vermutlich ist der richtige Ansatz genau das Zwischending:
Relationen weiterhin erlauben, aber etablierte Relationentypen nach und
nach in die API fest aufnehmen.


Ja, das ist auch das, was vermutlich passieren wird. Ein spezieller 
Flaechen- und vielleicht sogar ein spezieller Routen-Datentyp in der API 
0.7, dann fallen schonmal 90% aller Relationen raus, und wenn die sich 
mengenmaessig dann wieder aufrappeln, erfindet man wieder was neues...


Ein Problem, das wir haben, ist leider, dass OSM aufgrund der immer 
groesseren Landschaft von Anwendungen immer statischer wird. Die Zeit, 
in der man mal eben von einem auf den andren Tag die API inkompatibel 
veraendern konnte, ist leider vorbei. Jeder neue Datentyp, den wir 
erfinden, muss in Dutzenden von Applikationen unterstuetzt werden, wenn 
es nicht ein Riesengejammer geben soll.


Bei Relationen ist wenigstens ein generischer Support moeglich - gaengie 
Editoren koennen Dir wenigstens sagen, dass da eine Relation ist, selbst 
wenn sie nicht wissen, was sie bedeutet. Aber wenn im XML halt 
ploetzlich ein  oder  oder  auftaucht, 
fliegt Dir der XML-Parser entweder um die Ohren oder schmeisst das Ding 
ganz weg.


Eventuell sollte man alle diese neuen Datentypen dann in irgendwas 
gleichartiges kapseln, so dass eine Software, die den Datentyp nicht 
versteht, nicht total aufgeschmissen ist *duck*


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Stephan Wolff]

Am 09.07.2012 08:49, schrieb Jochen Topf:

On Mon, Jul 09, 2012 at 02:52:02AM +0200, Stephan Wolff wrote:

Ich sehe durchaus die von den anderen Beteiligten genannten
Probleme bei der Relationserstellung, -pflege und -auswertung.
Insbesondere bleibt das Henne-Ei-Problem zwischen Softwareanpassung
und Relationsnutzung. Trotzdem betrachte ich die Zusammenfassung
mehrerer Teilobjekte in Relationen als Zukunftsmodell von OSM.


Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll
zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt
auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen
Objekten in der Art und Weise, wie Relationen das tun.


Das glaube ich nicht. In OSM besteht eine Straße meist aus mehreren
Objekten mit gleichem Namen und unterschiedlichen Eigenschaften.
Kein Mensch würde sagen, dass es drei hintereinanderliegende
"Goethestraßen" gibt. Fast jeder beschreibt eine Straße, deren
Abschnitte sich z.B. in der erlaubten Geschwindigkeit unterscheiden.
Das gleiche gilt für andere zusammengesetzte Objekte.

Natürlich gibt es in OSM abstrakte Relationsobjekte (z.B.
Abbiegerelationen) oder schlecht umsetzbare Konzepte (z.B.
Buslinien mit mehreren Varianten). Aber um solche Relationen
geht es in Jans Frage nicht.


Was wir brauchen sind Objekte, die der Mapper verstehen kann, die sein Bild der
Welt umsetzbar machen.


+1


Man könnte natürlich alles auf die Tools schieben und sagen, dass die Tools
(also Editor, Renderer, usw.) halt diese Objekte, die ein User verstehen
soll, auf Basis von Nodes, Ways, und Relations darstellen sollen.


Im idealen Renderer sollte es keinen Unterschied machen, wie ein Objekt
OSM-intern angelegt ist. Ein Split eines Weges sollte keine Auswirkung
auf die Darstellung des Namens haben.
Eine Suche würde zu einem realen Objekt genau einen Treffer bei OSM liefern.
Im idealen Editor könnten zusammengesetzte Objekte durch "Vererbung"
der Tags fast transparent sein, so dass der Mapper bei Änderungen der
Geometrie nichts von der internen Struktur sieht.
Das ist alles natürlich sehr mühsam umzusetzten.


Und wenn man den Schritt geht, dass man in höheren Abstraktionen denkt, die
die Welt "näher am User" modellieren, dann gibt es eigentlich auch keinen
Grund mehr, das auf Relationen aufzubauen, weil die komplex sind und schwierig
und langsam zu verarbeiten. Dann sollte man besser eine Datenstruktur finden,
die dem Modell angepasst ist und von der man sich sehr genau überlegt hat,
wie man sie effizient verarbeiten kann.


Wie würde sich die Datenstruktur von einer Relation unterscheiden?

Viele Grüße
Stephan





___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Kreuzungen finden mit Nominatim?

[Marian Steinbach]

Hallo!

Gibt es eine Möglichkeit, mit Nominatim die Kreuzung zweier Straßen zu finden?

Danke & Grüße

Marian

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Peter Wendorff]

Vermutlich ist der richtige Ansatz genau das Zwischending:
Relationen weiterhin erlauben, aber etablierte Relationentypen nach und 
nach in die API fest aufnehmen.


Das viel berühmte freie Tagging-Schema ist klasse, funktioniert aber 
eben auch nur, solange die Freiheit sich darauf beschränkt, nicht 
"standardisierte" Bereiche nach bestem Wissen und Gewissen frei 
einzutragen; es ist eben nicht gleichzusetzen mit Anarchie.


Wenn wir Relationen erlauben, ist das das äquivalent zum freien Tagging 
auf der Ebene der Datenstrukturen: Sie erlauben Dinge, die kaum möglich 
wären ohne: rollenbesetzte Bezüge zwischen verschiedenen Objekten in OSM 
nur über Tags abzubilden wäre ziemlich gruselig.


Aber Standards sollten sich eben auch da bilden; und wenn diese soweit 
festliegen, dass sie zum allgemeinen Konsens gehören, dann spricht 
meines Erachtens nach nichts dagegen, diese auch fest in der API einzubauen.


Für wäre dabei als erstes ein Flächentyp fällig, der Multipolygone und 
einfache Polygone unterstützt.


Gruß
Peter


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Sorry II

[Jan Tappenbeck]

Am 08.07.2012 23:33, schrieb Jochen Topf:

On Sun, Jul 08, 2012 at 09:37:10PM +0200, Jan Tappenbeck wrote:

nachdem sich innerhalb eines Tages die Top-Anwendungsentwickler
schon zu Wort gemeldet haben und sich im großen und ganzen Positiv
geäußert haben muss ich eine ergänzende Frage stellen.


Zu was genau haben sich die "Top-Anwendungsentwickler" (wer ist das?)
positiv geäußert? Zu Relationen? Also ich lese die Diskussion eigentlich
so, dass alle, die das schonmal gemacht haben, Relationen für schwierig
in der Handhabung halten und dass man sie eher vermeiden sollte.

Jochen


Hallo Jochen,

das war wohl etwas spät gestern Abend.

Mit Top-Anwendungsentwicklern meine ich das sich nicht irgendwer dazu 
geäußert hat sondern diejenigen die primär schön etwas größeres mit 
Relationen auf die Beine gestellt haben.


Positiv geäußert war dann wohl etwas daneben.

Du hast recht - die meisten sehen in der Auswertung von Relationen harte 
Nüsse die geknackt werden müssen.


Gruß Jan :-)


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Jochen Topf]

On Mon, Jul 09, 2012 at 09:53:38AM +0200, Rainer Kluge wrote:
> On 09.07.2012 08:49, Jochen Topf wrote:
> >Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll
> >zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt
> >auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen
> >Objekten in der Art und Weise, wie Relationen das tun.
> 
> Menschen denken durchaus in Relationen. Wenn jemand sagt, dass der
> Laden X in der Hauptstrasse 47 liegt, dann meint er nichts anderes
> als: das Shop-Objekt mit name=X ist Mitglied der Building-Relation
> mit addr:street=Hauptstrasse und addr:housenumber=47.
> Nichtsdestotrotz, da gebe ich dir recht, haben die meisten Menschen
> Probleme, wenn es darum geht, diese Denkweise in Datenstrukturen
> umzusetzen.
> 
> Relationen sind eine effiziente Methode der Datenmodellierung. Sie
> vermeiden Redundanz, sind änderungsfreundlich und für Anwendungen
> einfach zu verarbeiten. Nicht umsonst sind relationale Datenbanken
> seit Jahrzehnten beliebt und verbreitet. Die Alternative zu

Die Relationen, die wir bei OSM haben, haben NICHTS mit den Relationen
zu tun, wie man sie von relationalen Datenbanken kennt. Die Relationen
bei OSM sind eben keine effiziente Methode der Datenmodellierung, sie
sind nicht änderungsfreundlich und sie sind nicht einfach zu verarbeiten.

> Relationen ist ein Bottom-Up-Ansatz, bei dem die gemeinsamen
> Eigenschaften an jedes Element gehängt werden und die Elemente über
> eine gemeinsame Kennung zusammengefasst werden. Darüber, dass wir
> das nicht wollen, herrscht sicher Konsens.

Die Alternative zu Relationen sind neue Datenstrukturen, die genau das
machen, was wir wollen.

> >Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder 
> >ÖPNV-Linien-Objekte.
> 
> Das sind nichts anderes als Relationen mit fest vorgegebenen
> Eigenschaften und Regeln. So etwas kann und soll man in den Editoren
> realisieren. In der Datenbank sollten wir uns die Flexibilität des
> Relationskonzepts erhalten.

Wie ich beschrieben habe, funktioniert dieser Ansatz nicht. Du kannst nicht
sicherstellen, dass alle Editoren die Daten immer in gültiger Weise editieren,
solange das die zentrale Datenbank nicht macht. Dadurch wird jeder Editor und
jeder User dieser Editoren aber immer mit der Möglichkeit konfrontiert, dass
die Daten ungültig sind, was diese "fest vorgegebenen Eigenschaften und Regeln"
angeht. Und damit sind die dann eben nicht "fest vorgegebenen". Und damit haben
wir das durcheinander, dass wir jetzt haben.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[WanMil]

Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder
ÖPNV-Linien-Objekte.


Das sind nichts anderes als Relationen mit fest vorgegebenen
Eigenschaften und Regeln. So etwas kann und soll man in den Editoren
realisieren. In der Datenbank sollten wir uns die Flexibilität des
Relationskonzepts erhalten.


Aus meiner Sicht bedeutet die Einführung eines Multipolygon-Objekts 
nicht automatisch die Abschaffung der Relationen.
Relationen sind so etwas wie eine eierlegende Wollmilchsau. Man kann 
fast alles damit modellieren. Im Umfeld von OSM, wo es keine genauen 
Reglen für die Modellierung (ich meine das Taggen) gibt, ist dies auf 
Dauer nicht handhabbar. Wenn man sich allein die unterschiedlichen 
Tagmöglichkeiten für Multipolygone anschaut (nur die Wege getaggt, nur 
das MP getaggt, beides getaggt, Wege getaggt aber unterschiedlich etc.), 
dann wird schnell klar, das jede Applikation hier Problem bekommen muss, 
da nicht wirklich klar ist, was denn nun gültig ist und was nicht.


Die Umsetzung einer eierlegenden Wollmilchsau führt immer zu großen 
Problemen mit der Komplexität, wodurch das eigentliche Konzept nicht 
mehr handhabbbar ist.


Also kann ich Jochens Sicht nur zustimmen: Relationen sind zur Zeit eine 
gute Variante um Modellierungen auszuprobieren. Auf Dauer muss man aber 
die wesentlichen Konzepte festlegen und in der Datenbank sicherstellen. 
Eine scheinbare Einschräkung, die sich aber lohnt. Dadurch können sich 
Editoren und andere Applikationen auf die Implementierung einer Variante 
festlegen und die wertvolle Ressource Zeit kann auf sinnvollere 
Tätigkeiten verwendet werden.


WanMil



Rainer




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Rainer Kluge]

Hallo Jochen,

On 09.07.2012 08:49, Jochen Topf wrote:

Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll
zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt
auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen
Objekten in der Art und Weise, wie Relationen das tun.


Menschen denken durchaus in Relationen. Wenn jemand sagt, dass der Laden X in 
der Hauptstrasse 47 liegt, dann meint er nichts anderes als: das Shop-Objekt 
mit name=X ist Mitglied der Building-Relation  mit addr:street=Hauptstrasse und 
addr:housenumber=47. Nichtsdestotrotz, da gebe ich dir recht, haben die meisten 
Menschen Probleme, wenn es darum geht, diese Denkweise in Datenstrukturen 
umzusetzen.


Relationen sind eine effiziente Methode der Datenmodellierung. Sie vermeiden 
Redundanz, sind änderungsfreundlich und für Anwendungen einfach zu verarbeiten. 
Nicht umsonst sind relationale Datenbanken seit Jahrzehnten beliebt und 
verbreitet. Die Alternative zu Relationen ist ein Bottom-Up-Ansatz, bei dem die 
gemeinsamen Eigenschaften an jedes Element gehängt werden und die Elemente über 
eine gemeinsame Kennung zusammengefasst werden. Darüber, dass wir das nicht 
wollen, herrscht sicher Konsens.



Wir haben halt keine Multipolygon-Objekte, oder Site-Objekte, oder 
ÖPNV-Linien-Objekte.


Das sind nichts anderes als Relationen mit fest vorgegebenen Eigenschaften und 
Regeln. So etwas kann und soll man in den Editoren realisieren. In der Datenbank 
sollten wir uns die Flexibilität des Relationskonzepts erhalten.


Rainer


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Jochen Topf]

On Mon, Jul 09, 2012 at 02:52:02AM +0200, Stephan Wolff wrote:
> Ich sehe durchaus die von den anderen Beteiligten genannten
> Probleme bei der Relationserstellung, -pflege und -auswertung.
> Insbesondere bleibt das Henne-Ei-Problem zwischen Softwareanpassung
> und Relationsnutzung. Trotzdem betrachte ich die Zusammenfassung
> mehrerer Teilobjekte in Relationen als Zukunftsmodell von OSM.

Ich sehe das anders. Relationen haben zu wenig Struktur, um Daten sinnvoll
zu halten und effizient verarbeitbar zu machen. Und sie modellieren die Welt
auf der falschen Ebene. Menschen denken nunmal nicht in Verbindungen zwischen
Objekten in der Art und Weise, wie Relationen das tun.

Was wir brauchen sind Objekte, die der Mapper verstehen kann, die sein Bild der
Welt umsetzbar machen. Abstrakte Punkte für POIs, abstrakte Linien für Straßen,
das geht grad noch so. Aber das Konzept "Multipolygon" ist schon schwierig
genug, wenn man es dann noch auf eine ungeeignete andere Abstraktion aufsetzt,
also die Relationen, dann ist das nicht mehr handhabbar. Das zeigt die Praxis
jeden Tag.

Man könnte natürlich alles auf die Tools schieben und sagen, dass die Tools
(also Editor, Renderer, usw.) halt diese Objekte, die ein User verstehen
soll, auf Basis von Nodes, Ways, und Relations darstellen sollen. Das habe
ich eine Weile auch gedacht, dass das funktioniert. Bei einfachen Objekten
klappt das vielleicht. Nicht aber bei Relationen. Eine Relation, die so halber
wie eine Multipolygon-Relation aussieht, aber kein gültiges Multipolygon
erzeugt läßt sich nicht auf einem höheren Abstraktionsgrad als Multipolygon
darstellen. Will man auf dem höheren Abstraktionsgrad arbeiten, so muss
sichergestellt sein, dass die Relation darunter immer gültig ist, immer
gewissen Strukturvorraussetzungen genügt. Das können wir aber nicht, weil
einzig die zentrale OSM-Datenbank diese Gültigkeit sicherstellen könnte. Und
die tut das nicht.

Und wenn man den Schritt geht, dass man in höheren Abstraktionen denkt, die
die Welt "näher am User" modellieren, dann gibt es eigentlich auch keinen
Grund mehr, das auf Relationen aufzubauen, weil die komplex sind und schwierig
und langsam zu verarbeiten. Dann sollte man besser eine Datenstruktur finden,
die dem Modell angepasst ist und von der man sich sehr genau überlegt hat,
wie man sie effizient verarbeiten kann.

Ich sehe Relationen als eine Möglichkeit, "Prototypen" zu bauen. Wir haben
halt keine Multipolygon-Objekte, oder Site-Objekte, oder ÖPNV-Linien-Objekte.
Wir können mit Relationen uns solchen Objekten annähern und ausprobieren,
wie sie vielleicht aussehen könnten. Aber irgendwann müssen wir den Schritt
tun und sagen: Okay, diese Art der Relation ist so wichtig, dass wir ein
"echtes Objektmodell" dafür machen müssen, das genau dieses Modell abbildet
und definiert und sauber zu verarbeiten ist.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de