Am 18.07.2012 20:24, schrieb Tobias Knerr:
Die Lösung mit dem Wikipedia-Tag hingegen funktioniert heute bereits
gut. Es genügt zwar nicht, wenn es z.B. um Karten in Sammelartikeln
für mehrere geografische Objekte geht, die selbst keinen eigenen
Artikel bekommen. Diesen Anspruch erhebt es
Am 17.07.2012 17:52, schrieb Christian Müller:
Am 17.07.2012 08:38, schrieb Frederik Ramm:
Allein schon die einfache Frage: Ein Way, der in einer Relation
steckt, wird zweigeteilt; wie wirkt sich das auf die Relation aus?
kann nicht beantwortet werden, ohne die Relation zu verstehen.
Das sehe
Am 17.07.2012 20:08, schrieb Werner Hoch:
Am Dienstag, den 17.07.2012, 02:11 +0200 schrieb Stephan Wolff:
Am 16.07.2012 23:04, schrieb Peter Wendorff:
- Verlinkung - Ein Wikipediaartikel zu einer Straße sollte nicht
mit jedem way sondern mit einem Gesamtobjekt verbunden werden.
Inwiefern
Lieber Christian,
On Tue, Jul 17, 2012 at 04:09:55PM +0200, Christian Müller wrote:
Apropos Nominatim - da könnte man erstmal is_in aufräumen.. Da werden
teilweise Gebiete nach ausdehnungslosen place=region nodes benannt, die
hunderte km von den Objekten, zu deren Bennenung sie herangezogen
Peter Wendorff schrieb:
ohne kuriose Relationen wie Denkmalgeschützte Häuser in
Buxtehude anlegen zu müssen.
[@Frederik: Dein Einsatz bitte] ;-)
Zitat von http://lists.openstreetmap.org/pipermail/talk-de/2012-July/096616.html
Relationen sind *nicht*
Am Mittwoch, den 18.07.2012, 10:28 +0200 schrieb Peter Wendorff:
Am 17.07.2012 20:08, schrieb Werner Hoch:
Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2]
nützlich. (Karte-Link neben der Koordinate)
s. http://de.wikipedia.org/wiki/Rhein
s.
Am 18.07.2012 18:34, schrieb Werner Hoch:
Am Mittwoch, den 18.07.2012, 10:28 +0200 schrieb Peter Wendorff:
Am 17.07.2012 20:08, schrieb Werner Hoch:
Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2]
nützlich. (Karte-Link neben der Koordinate)
s.
Am 18.07.2012 10:28, schrieb Peter Wendorff:
Am 17.07.2012 20:08, schrieb Werner Hoch:
Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2]
nützlich. (Karte-Link neben der Koordinate)
[...]
Damit können die geographischen Objekte aus OSM in der Karte in
Wikipedia dargestellt
Am 18.07.2012 20:24, schrieb Tobias Knerr:
Am 18.07.2012 10:28, schrieb Peter Wendorff:
Am 17.07.2012 20:08, schrieb Werner Hoch:
Die Wikipedia-Links sind zumindest seit der Einführung von WIWOSM [2]
nützlich. (Karte-Link neben der Koordinate)
[...]
Damit können die geographischen Objekte
Hallo,
On 07/17/12 02:11, Stephan Wolff wrote:
Bei Multipolygon, Abbiege- oder Nahverkehrsrelationen mag es zutreffen,
bei einfachen Objektrelationen sehe ich es nicht. Durch welche
Operationen würde die Relation zerstört?
Was sind denn einfache Objektrelationen? Den Begriff hoere ich zum
On Tue, Jul 17, 2012 at 02:11:37AM +0200, Stephan Wolff wrote:
Wozu
also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat
die Stadt?
Für alle Fragen, die Straßen (im üblichen Sinn) betreffen:
- Suche: Wo ist die ...straße? - Aktuell liefert Nominatim zu einer
langen Straße
Sarah Hoffmann lon...@denofr.de schrieb:
On Tue, Jul 17, 2012 at 02:11:37AM +0200, Stephan Wolff wrote:
Wozu
also die Relation? Nur fuer die fiktive Frage wie viele Strassen hat
die Stadt?
Für alle Fragen, die Straßen (im üblichen Sinn) betreffen:
- Suche: Wo ist die ...straße? - Aktuell
Am 17.07.2012 13:22, schrieb Christian Müller:
Sarah Hoffmann lon...@denofr.de schrieb: [...]
Auf wessen Todo-Liste und woher nimmst Du diese Sicherheit? Klingt wie ein
Alleingang.
Alleingang nicht unbedingt, aber da Sarah Nominatim-Maintainerin ist,
würde ich das mal so akzeptieren ;)
Peter Wendorff wendo...@uni-paderborn.de schrieb:
Am 17.07.2012 13:22, schrieb Christian Müller:
Sarah Hoffmann lon...@denofr.de schrieb: [...]
Auf wessen Todo-Liste und woher nimmst Du diese Sicherheit? Klingt wie ein
Alleingang.
Alleingang nicht unbedingt, aber da Sarah
Am 17.07.2012 08:38, schrieb Frederik Ramm:
Jede Relation modelliert eine bestimmte Art von Beziehung, und diese
Beziehung muss man verstehen, um sie richtig editieren zu koennen.
+1
Allein schon die einfache Frage: Ein Way, der in einer Relation
steckt, wird zweigeteilt; wie wirkt sich das
Am Dienstag, den 17.07.2012, 02:11 +0200 schrieb Stephan Wolff:
Am 16.07.2012 23:04, schrieb Peter Wendorff:
- Verlinkung - Ein Wikipediaartikel zu einer Straße sollte nicht
mit jedem way sondern mit einem Gesamtobjekt verbunden werden.
Inwiefern der Wikipediaartikel überhaupt von osm
Am 17.07.2012 08:38, schrieb Frederik Ramm:
Hallo,
On 07/17/12 02:11, Stephan Wolff wrote:
Bei Multipolygon, Abbiege- oder Nahverkehrsrelationen mag es zutreffen,
bei einfachen Objektrelationen sehe ich es nicht. Durch welche
Operationen würde die Relation zerstört?
Was sind denn einfache
Moin,
meine erste Antwort hat gmane letzte Woche offenbar verschluckt.
Am 09.07.2012 21:47, schrieb 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.
Am 16.07.2012 19:06, schrieb Stephan Wolff:
Moin,
meine erste Antwort hat gmane letzte Woche offenbar verschluckt.
Am 09.07.2012 21:47, schrieb Frederik Ramm:
Hi,
On 09.07.2012 21:28, Stephan Wolff wrote:
Selbst diese einfache Heuristik erfordert schon viel Programmier- und
Rechenaufwand.
Moin!
Am 16.07.2012 23:04, schrieb Peter Wendorff:
Am 16.07.2012 19:06, schrieb Stephan Wolff:
Ich traue vielen Mappern zu, einfache Relationen anzulegen.
Das Problem liegt gar nicht so sehr beim Anlegen der Relationen - das
ist einfach.
Das Problem liegt darin, dass die Relationen
Am 11.07.2012 18:01, schrieb Christian Müller:
Woher weißt du eigentlich bei aneinandergereihten Gebäuden, ob die
Wand an der Stoßstelle wirklich nur eine Wand ist? In aller Regel
gibt es diese Wand in der Tat zweimal.
In diesem Fall liegen sie dann aber auch nebeneinander ;-) Ich weiß,
Am 10. Juli 2012 15:44 schrieb Christian Müller cmu...@gmx.de:
Stand, keine Befürchtung). Von Jochen wurde weiterhin angeführt, dass zur
Not die geografische Nähe genutzt werden könne - ein Beispiel, das die
Grenzen dieses Ansatzes klar aufzeigt, sind die Relationen, die Powermapper
bilden,
Am 12.07.2012 um 13:47 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
Man könnte stattdessen auch einfach den Umriss jeder Brücke zeichnen
(und z.B. mit building=bridge oder so taggen), dann bräuchte man z.B.
solche Krücken wie bridge_name nicht (name und Varianten auf dem
Brückenobjekt
Am 11. Juli 2012 16:48 schrieb Tobias Knerr o...@tobias-knerr.de:
Am 10.07.2012 21:17, schrieb Christian Müller:
Aneinandergereihte Gebäude nutzen häufig overlapping ways, da stimme ich
Dir ebenso zu. Eigentlich gibt es die Wand nur einmal, welche da durch
zwei Wege in OSM repräsentiert wird.
Am 12. Juli 2012 14:04 schrieb Martin Vonwald (Imagic) imagic@gmail.com:
Das wiederum erinnert mich jetzt stark an das von mir vorgeschlagene
highway=junction, was im Prinzip das selbe für Kreuzungen machen will.
nur dass es bei Brücken klar ist, was dazu gehört, aber Kreuzungen
bzw. eine
Am 12.07.2012 14:05, schrieb Martin Koppenhoefer:
Übrigens sind Wände (barrier=wall / retaining_wall) als linearer way
auch nicht immer ausreichend, weil man bei an der Wand angebrachten
Objekten nicht mehr weiss, auf welcher Seite sie sind (sofern diese
Objekte als node repräsentiert werden,
Am 11.07.2012 00:50, schrieb Christian Müller:
Am 10.07.2012 21:21, schrieb Peter Wendorff:
Wenn ich einen overpass-link erzeuge wie (nicht geprüft, nur
schematisch) [bbox=][highway][ref=B 7], dann kann man anhand
!dieses Links! genausogut diskutieren wie anhand der relations-id
0815, die
Am 11.07.2012 07:53, schrieb Manuel Reimer:
Christian Müller cmue81 at gmx.de writes:
Ich stimme Dir zu, dass overlapping ways dem Nahe kommen. Nur ist die
Fangemeinde von overlapping ways auch nicht besonders groß, da sie
ebenso wie mancher Relationstyp schlecht oder gar nicht visualisiert
Peter Wendorff wendo...@uni-paderborn.de schrieb:
Nein. Wie der ANWENDER die Daten bekommt, ist den meisten Entwicklern
tatsächlich egal; nur sollten die Informationen, wo möglich, auch außerhalb
der Relation vorhanden sein, weil sie sonst von den Anwendungen oft ignoriert
werden.
Das
Am 11.07.2012 13:12, schrieb Christian Müller:
Peter Wendorff wendo...@uni-paderborn.de schrieb:
Nein. Wie der ANWENDER die Daten bekommt, ist den meisten Entwicklern
tatsächlich egal; nur sollten die Informationen, wo möglich, auch außerhalb der
Relation vorhanden sein, weil sie sonst von
Mal ein Beispiel aus der Vergangenheit zu Radrouten/Wanderrouten:
Zu Beginn wurden diese einfach an den Weg getaggt, über den diese
verlaufen (Bsp: ref_rcn=ThSk). Das funktionierte sehr gut, bis es
gehäuft vorkam, dass über manche Wege mehrere Routen verliefen (Bsp:
ref_rcn=Ilm;ThSk;Fei).
Peter Wendorff wendo...@uni-paderborn.de schrieb:
Wenn eine Anwendung nicht mit Relationen umgehen kann, ist das ihr
Problem, das ist richtig.
Wenn aber die Nutzung von Relationen die Hürde sowohl für
Anwendungsentwickler als auch für Mapper anhebt, dann ist das für mich
ein eindeutiges
Am 10.07.2012 21:17, schrieb Christian Müller:
Aneinandergereihte Gebäude nutzen häufig overlapping ways, da stimme ich
Dir ebenso zu. Eigentlich gibt es die Wand nur einmal, welche da durch
zwei Wege in OSM repräsentiert wird. Das geschieht aus Bequemlichkeit,
nicht weil es logisch und/oder
Am 11.07.2012 07:53, schrieb Manuel Reimer:
Zudem wäre mal eben nachmalen auch einfacher wie Wege zerstückeln
und dann alles in Relation kippen. Folge der Relationen ist, dass die
Wanderwege von Unwissenden immer wieder kaputt gemacht werden. Man
wird also schon deshalb nie arbeitslos werden,
Tobias Knerr o...@tobias-knerr.de schrieb:
Das Einzeichnen aneinander gebauter Gebäude mit overlapping ways ist
also nicht bloß bequemer und verständlicher, sondern auch 100% korrekt.
Meinetwegen, jeder Architekt und jedes Katasteramt würde das zwar eindeutig
anders sehen, aber für OSM ist es
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
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
Obwohl ich sicher eine PostGIS DB installieren kann auf Linux oder Windows,
ist das fuer mich viel Aufwand, nur zum bestimmen ob etwas in etwas anderes
liegt. Auf Android gelingt das schon nicht mehr. Da bin ich dann froh wenn
ich sowas nur abfragen kann mittels eine Relation.
Auch um Daten, die
On Tue, Jul 10, 2012 at 09:14:10AM +0200, Jo wrote:
Obwohl ich sicher eine PostGIS DB installieren kann auf Linux oder Windows,
ist das fuer mich viel Aufwand, nur zum bestimmen ob etwas in etwas anderes
liegt. Auf Android gelingt das schon nicht mehr. Da bin ich dann froh wenn
ich sowas nur
Hallo,
On 07/10/12 09:14, Jo wrote:
Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an
Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API
sind Relationen unschatzbar wertvoll.
Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen
2012/7/10 Frederik Ramm frede...@remote.org
Hallo,
On 07/10/12 09:14, Jo wrote:
Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an
Collections von Netzwerke von Routes), herunterzuladen mit der Overpass
API
sind Relationen unschatzbar wertvoll.
Das ist ein Missbrauch
Hallo Jochen,
On 10.07.2012 08:13, Jochen Topf wrote:
Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.
Das liegt weniger am Konzept Relation als an der Komplexität mancher
Anwendungsfälle, die wir
2012/7/10 Rainer Kluge rklug...@web.de
Hallo Jochen,
On 10.07.2012 08:13, Jochen Topf wrote:
Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.
Das liegt weniger am Konzept Relation als an der
On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote:
On 10.07.2012 08:13, Jochen Topf wrote:
Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in dieser
Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.
Das liegt weniger am Konzept Relation als an
2012/7/10 Jochen Topf joc...@remote.org
On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote:
On 10.07.2012 08:13, Jochen Topf wrote:
Keiner hat je davon geredet, Relationen wegzuschmeissen. Es ging in
dieser
Diskussion darum, dass es schwierig ist, mit Relationen zu arbeiten.
On 10.07.2012 10:49, Jochen Topf wrote:
On Tue, Jul 10, 2012 at 10:09:23AM +0200, Rainer Kluge wrote:
auch
mit einem Perl-Skript und einem XML-Extrakt kann man die Member von
geschachtelten Relationen recht einfach ermitteln. Problematisch ist
in der Regel der Umgang mit den Daten, sowohl für
On 10.07.2012 10:24, Jo wrote:
Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls
in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das
warscheinlich noch etwas laenger dauern...
Das zeigt doch, dass diese Lösungen nicht für den Normalmapper ohne besondere
2012/7/10 Rainer Kluge rklug...@web.de
On 10.07.2012 10:24, Jo wrote:
Die Loesungen sind da, man muss die nur entdecken und benutzen. Jedenfalls
in ein Editor wie JOSM. In Vespucci fuer Android oder ILoE wird das
warscheinlich noch etwas laenger dauern...
Das zeigt doch, dass diese
Ihr redet ein klein wenig an einander vorbei.
Die Relation ist einfacher. Aber eben nicht alle Goethestraßen sind auf
diese weise eingetragen und für diese muss man dann trotzdem den
komplexeren Algorithmus entwerfen.
Wenn man also gleich nur den komplexeren Algorithmus nutzt, spart man
Hi,
Am 10.07.2012 08:33, schrieb Sarah Hoffmann:
Kannst du konkrete Beispiele nennen von Anwendern, die irgendeiner Relation
ausser den drei wirklich gebrauchten (Routen, Abbiegerelation,
Multipolygon) nachweinen würden?
Es ist deine Ansicht, dass dies die drei einzigen sind, die wirklich
Am 10.07.2012 09:43, schrieb Frederik Ramm:
Das ist ein Missbrauch von Relationen, und wenn ich solche Sammlungen
sehe, loesche ich sie.
Relationen sind *nicht* dazu da, um Objekte in praktische Eimer fuer
das Herunterladen zu sortieren.
Siehe auch:
Hallo Christian,
manchmal frage ich mich bei Deinen Beitraegen, ob Du sie absichtlich
so lang und vielschichtig machst, dass niemand darauf in Gaenze
antworten kann, damit Du dann das letzte Wort hast ;)
Dennoch, es ist
ohne eine solche Relation (momentan) mitnichten wirklich einfach
Christian Müller wrote:
Der Theorie dazu schließe ich mich an, nur wenn die Praxis so aussehen soll,
dass jeder, der einen längeren Wasserlauf, das Netz der Bundesstraßen, etc.
laden will, Overpass kennen, lernen und nutzen muss, um diesen praktischen
Eimer zu vermeiden, funktioniert das
Frederik Ramm wrote:
(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
Am 10.07.2012 17:09, schrieb Frederik Ramm:
Also: Relationen, deren Hauptzweck das einfachere Abrufen der Daten
ist, sind nicht ok. Und die von Dir angebrachte Begruendung andere
Methoden sind halt zu schwierig mag zwar stimmen und sie koennte ein
Grund dafuer sein, dass diese Relationen
Am 10.07.2012 17:56, schrieb Manuel Reimer:
Christian Müller wrote:
Der Theorie dazu schließe ich mich an, nur wenn die Praxis so
aussehen soll,
dass jeder, der einen längeren Wasserlauf, das Netz der
Bundesstraßen, etc.
laden will, Overpass kennen, lernen und nutzen muss, um diesen
Am 10.07.2012 18:02, schrieb Manuel Reimer:
Frederik Ramm wrote:
(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,
Am 10.07.2012 19:12, schrieb Christian Müller:
[...]
Allerdings bedeutet diese Umverteilung von Information (preset-query
statt explizite Sammelrelation) auch eine gewisse Dezentralisierung
und es ist mehr als fraglich, ob sich diese Verfahrensweise beim
Umgang mit gewünschten Kategorien
Am 10.07.2012 19:48, schrieb Christian Müller:
Am 10.07.2012 18:02, schrieb Manuel Reimer:
Frederik Ramm wrote:
(Zugegeben: Genauso, wie wir Nutzer nicht zwingen sollten, ohne Not
Objekte zu
logischen Konstrukten zusammenzufassen, so sollten wie sie auch nicht
zwingen,
eine eigentlich
Am 10.07.2012 20:48, schrieb Peter Wendorff:
Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja
(zum Glück) auch keine Sammlung von Relations-IDs, die man komplett
herunterladen kann, sondern höchstens einzelne Relationen, die auf
einzelnen Wikiseiten verlinkt sind oder so.
Es
Am 10.07.2012 20:52, schrieb Peter Wendorff:
Am 10.07.2012 19:48, schrieb Christian Müller:
imho gibt es dazu keine Alternative. Es sei denn man verbietet Wege in
Relationen zukünftig und definiert auch die Routen nur über nodes - um
letztere wiederzuverwenden, bräuchte man einen Weg nicht zu
Am 10.07.2012 21:03, schrieb Christian Müller:
Am 10.07.2012 20:48, schrieb Peter Wendorff:
Mit Relationen für Bundesstraßen und ähnlichen Blödsinn gibt es ja
(zum Glück) auch keine Sammlung von Relations-IDs, die man komplett
herunterladen kann, sondern höchstens einzelne Relationen, die auf
Am 10.07.2012 21:21, schrieb Peter Wendorff:
Wenn ich einen overpass-link erzeuge wie (nicht geprüft, nur
schematisch) [bbox=][highway][ref=B 7], dann kann man anhand
!dieses Links! genausogut diskutieren wie anhand der relations-id
0815, die die gleichen Elemente enthält:
- Das Abfragen
Christian Müller cmue81 at gmx.de writes:
Ich stimme Dir zu, dass overlapping ways dem Nahe kommen. Nur ist die
Fangemeinde von overlapping ways auch nicht besonders groß, da sie
ebenso wie mancher Relationstyp schlecht oder gar nicht visualisiert werden.
Werden Wanderwege, bzw. deren
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
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
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
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
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,
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
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
Am 9. Juli 2012 12:50 schrieb Stephan Wolff s.wo...@web.de:
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
Jochen Topf joc...@remote.org 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.
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 area
oder route oder turnrestriction auftaucht,
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 area
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
Am 9. Juli 2012 16:18 schrieb Sven Geggus li...@fuchsschwanzdomain.de:
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
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
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
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
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
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
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
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 ;)
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
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
Hallo,
siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen so
unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht
geben.
spatialite bietet für kleinere Projekte gute Möglichkeiten mit OSM-Daten zu
arbeiten, erfordert aber etwas Ahnung von SQL.
Ich
Subject: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder
Fluch??
Moin !
ich möchte mal wieder eine Frage an die Allgemeinheit stellen auch
auf die Gefahr hin zerrissen zu werden.
Es geht konkret um ein Zenario was Relationen und Hausnummern
betrifft und nachfolgend
On Sat, Jul 07, 2012 at 11:58:14PM +0200, Christian Müller wrote:
siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen so
unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht geben.
Das sind einige der wenigen Ausnahmen. Und schau Dir mal an, was für ein
Hallo zusammen,
Es geht konkret um ein Zenario was Relationen und Hausnummern betrifft
und nachfolgend bitte keine Diskussion über diese Relation ist aber
doof, weil Es geht um die Frage wie ist soetwas überhaupt
vernünftig und performant in der Auswertung zu realisieren. Das Beispiel
Am 08.07.2012 11:02, schrieb Roland Olbricht:
Hallo zusammen,
Es geht konkret um ein Zenario was Relationen und Hausnummern betrifft
und nachfolgend bitte keine Diskussion über diese Relation ist aber
doof, weil Es geht um die Frage wie ist soetwas überhaupt
vernünftig und performant in
On Sat, Jul 07, 2012 at 11:09:31PM +0200, Jan Tappenbeck wrote:
Moin !
ich möchte mal wieder eine Frage an die Allgemeinheit stellen auch
auf die Gefahr hin zerrissen zu werden.
Es geht konkret um ein Zenario was Relationen und Hausnummern
betrifft und nachfolgend bitte keine Diskussion
Am 08.07.2012 12:28, schrieb Florian Lohoff:
Relationen sind schoen um dinge abzubilden die sich anders nicht
abbilden lassen. Gerade bei Geschaeften spricht aber nichts dagegen
die Adresse auf allen nodes zu haben. Das ist einfach und fuer jeden
gut zu pflegen. Flo
On Sun, Jul 08, 2012 at 05:06:25PM +0200, Jimmy_K wrote:
Am 08.07.2012 12:28, schrieb Florian Lohoff:
Relationen sind schoen um dinge abzubilden die sich anders nicht
abbilden lassen. Gerade bei Geschaeften spricht aber nichts dagegen
die Adresse auf allen nodes zu haben. Das ist einfach
Am 08.07.2012 17:06, schrieb Jimmy_K:
Am 08.07.2012 12:28, schrieb Florian Lohoff:
Relationen sind schoen um dinge abzubilden die sich anders nicht
abbilden lassen. Gerade bei Geschaeften spricht aber nichts dagegen
die Adresse auf allen nodes zu haben. Das ist einfach und fuer jeden
gut zu
Am 08.07.2012 11:26, schrieb Peter Wendorff:
Es ist daher auch noch niemand auf die Idee gekommen, jede Straße als
eine
eigene Relation zu schreiben, um den Straßennamen nicht redundant zu
speichern.
...abgesehen von Ausnahmen wie z.B. Autobahnen, bei denen das IMHO
auch nicht notwendig
Hallo!
ich möchte mal wieder eine Frage an die Allgemeinheit stellen auch auf
die Gefahr hin zerrissen zu werden.
doof, weil Es geht um die Frage wie ist soetwas überhaupt
vernünftig und performant in der Auswertung zu realisieren. Das Beispiel
kann sicherlich auch auf andere Relationen
Hallo!
Ich möchte in dem Zshg. auf [1] verweisen - dato hat fast jede
Bundesstraße ihre eigene Relation, so auch viele Landes-, bzw.
Staatsstraßen. Auch innerorts ist OSM mit immerhin rund 12.000
Relationen vom Typ street dabei [2], welche gesplittete Wege gleichen
Namens explizit in Relation
Christian Müller wrote
siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen
so unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht
geben.
Das würde ich so nicht unterschreiben. Der Umgang mit Relationen ist in der
ÖPNV-Karte alles andere als
Moin,
ich finde Jans Ansatz grundsätzlich sinnvoll.
Für die meisten Relationstypen wäre auch eine universelle
Vorverarbeitung möglich, bei der alle key/value Paare der
Relation mit einem Präfix in die Mitgliedselemente kopiert
werden. Dann könnten die bestehenden Programme diese Daten
wie
1 - 100 von 103 matches
Mail list logo
