Joachim Kast schrieb:
Allerdings hast Du an jeden Stein noch ein wikipedia=de:Stolpersteine
angehängt, wodurch entspechende Anwendungen von immer gleichlautenden
Wikipedia-Einträgen überschwemmt werden. Dazu habe ich in der gesamten
Diskussion nichts gefunden.
[...]
Ich möchte hiermit die
Am 5. Februar 2014 18:20 schrieb malenki o...@malenki.ch:
Spätestens dann, wenn ich konkurrierende, undokumentierte Tags im
zweistelligen Bereich aufräume.
Finde ich auch problematisch. Jeder neue tag hat mal klein angefangen.
Klar, wenn es um values geht, die nicht dokumentiert sind und
Martin Koppenhoefer schrieb am 04.02.2014 18:51:
Am 4. Februar 2014 18:34 schrieb malenki o...@malenki.ch:
AFAIK sind wikipedia:de= und wikipedia=de:* synonym?
nicht ganz, wikipedia=de ist zu bevorzugen für alle Artikel, die allgemein
gelten (auch in den anderen Sprachen), während
Joachim Kast schrieb am 03.02.2014 23:23:
inzwischen hast Du die Relationen gelöscht, was ich auch als sinnvoll
betrachte. Allerdings hast Du an jeden Stein noch ein
wikipedia=de:Stolpersteine angehängt, wodurch entspechende Anwendungen
von immer gleichlautenden Wikipedia-Einträgen
Walter Nordmann schrieb:
malenki wrote
weil der Tag in der (deutschen) Hauptrelation vorhanden war und nicht
verloren gehen sollte.
Das hast du aber für *alle* Stolpersteine gemacht und nicht nur die,
die in diesen schrottigen Relationen waren. Wohl kurz mal die Overpass
über alle
Hallo,
On 05.02.2014 18:20, malenki wrote:
Der Policy zufolge darf man nicht einmal hier¹ nach
Feldweg | Waldweg suchen, um die entsprechenden Objekte zu
korrigieren - nämlich highway=track setzen und name=* entfernen.
Die Policy verlangt, dass Du immer dann, wenn Du unbesehen und rein
nach
Am 3. Februar 2014 23:23 schrieb Joachim Kast osm...@dd1gj.de:
Ich möchte hiermit die Wikipedia-Aktion in Frage stellen und plädiere
dafür, diese rückgängig zu machen.
naja, ist ein bisschen ein Randfall. In vielen Fällen von Objekten, die wir
in OSM mappen (z.B. Fluss, Kirche, See, Haus,
Joachim Kast schrieb:
Hallo Thomas,
inzwischen hast Du die Relationen gelöscht, was ich auch als sinnvoll
betrachte. Allerdings hast Du an jeden Stein noch ein
wikipedia=de:Stolpersteine angehängt,
weil der Tag in der (deutschen) Hauptrelation vorhanden war und nicht
verloren gehen sollte.
An
Am 4. Februar 2014 18:34 schrieb malenki o...@malenki.ch:
AFAIK sind wikipedia:de= und wikipedia=de:* synonym?
nicht ganz, wikipedia=de ist zu bevorzugen für alle Artikel, die allgemein
gelten (auch in den anderen Sprachen), während wikipedia:de=* ein
Spezialtag für die Fälle ist, wo entweder
Am 04.02.2014 18:15, schrieb Martin Koppenhoefer:
naja, ist ein bisschen ein Randfall. In vielen Fällen von Objekten, die wir
in OSM mappen (z.B. Fluss, Kirche, See, Haus, Straße, Autobahn, ...) ist
es sicher nicht sinnvoll oder gewünscht, auf einen allgemeinen Artikel zu
linken. Andererseits
Tobias Knerr schrieb:
Ich sehe es nicht als Randfall, sondern als eindeutig falsch. Der
wikipedia-Schlüssel ist genau dann anzuwenden, wenn der verlinkte
Artikel über dieses konkrete Objekt ist. Der Artikel Stolpersteine
ist aber kein Artikel über den Stolperstein für Max Mustermann in der
Am 04.02.2014 20:58, schrieb malenki:
Wie verhält es sich dann mit den bereits zuvor von anderen Usern
(teilweise massenhaft) genutzten
wikipedia=de:Liste von Stolpersteinen in xyz?
Das ist nun aus meiner Sicht wirklich ein Grenzfall, den ich noch
akzeptabel finde. Zwar sind Listenartikel
Am 4. Februar 2014 20:49 schrieb Tobias Knerr o...@tobias-knerr.de:
Zur Betrachtung als ein einziges dezentrales Kunstwerk: Auf dieser
Grundlage wäre auch die Begründung für die Relationslöschung falsch
gewesen. Die Einstufung als Sammelrelation ergibt nur dann Sinn, wenn
wir die
malenki wrote
weil der Tag in der (deutschen) Hauptrelation vorhanden war und nicht
verloren gehen sollte.
Das hast du aber für *alle* Stolpersteine gemacht und nicht nur die, die in
diesen schrottigen Relationen waren. Wohl kurz mal die Overpass über alle
Stolpersteine laufen lassen und
Am 04.02.2014 18:34, schrieb malenki:
Joachim Kast schrieb:
wodurch entspechende Anwendungen von immer gleichlautenden
Wikipedia-Einträgen überschwemmt werden.
|sort|uniq :)
Was sind entsprechende Anwendungen?
z.B.: www.openlinkmap.org
Wenn jemand immer auf die allgemeine
Hallo Thomas,
inzwischen hast Du die Relationen gelöscht, was ich auch als sinnvoll
betrachte. Allerdings hast Du an jeden Stein noch ein
wikipedia=de:Stolpersteine angehängt, wodurch entspechende Anwendungen
von immer gleichlautenden Wikipedia-Einträgen überschwemmt werden. Dazu
habe ich in der
--- Original Nachricht ---
Absender: Peter Wendorff
Datum: 31.01.2014 09:14
Wenn Sammelrelationen nicht gewünscht sind, dann sollte es technisch
verhindert werden solche anzulegen.
Da bin ich aber auf einen Lösungsansatz gespannt.
Beispiel Buslinien:
- keine Sammelrelation, weil die Reihenfolge
Am 02.02.2014 09:25, schrieb Steffen:
--- Original Nachricht ---
Absender: Peter Wendorff
Datum: 31.01.2014 09:14
Wenn Sammelrelationen nicht gewünscht sind, dann sollte es technisch
verhindert werden solche anzulegen.
Da bin ich aber auf einen Lösungsansatz gespannt.
Beispiel Buslinien:
-
Am 31.01.2014 06:37, schrieb Steffen:
--- Original Nachricht ---
Absender: Hartmut Holzgraefe
Datum: 30.01.2014 22:01
Das Abfragen mit der api hat doch nix mit dem Sinn einer Relation zu
tun. Wenn ich die alle Objekte (nodes) abfrage und diese dann
zusammenführe, bilde ich doch eine Relation
Moin !
also ich brauche die Relationen nicht mehr für meine
Stolperstein-Auswertung.
Eine Liste, aus der man automatisch Overpass-Abfragen nach dem Schema
Stolpersteine in $Ort basteln kann, bereite ich gerade vor.
Gibt es das nicht schon auf der zugehörigen Wiki-Seite bei den Orten?
Auch wenn ich die Relationen selbst nicht brauche, sind die Relationen
dafür da das eigentlich ein großes Objekt welches sich räumlich auf
einen größeren Raum (Europa) befindet, zusammengehörig zu beschreiben.
Eine Stolpersteinrelation ist für mich nichts anders als Relationen wie
die für
Am 30. Januar 2014 11:20 schrieb gmbo g...@kilometerfresser.eu:
Auch wenn ich die Relationen selbst nicht brauche, sind die Relationen
dafür da das eigentlich ein großes Objekt welches sich räumlich auf einen
größeren Raum (Europa) befindet, zusammengehörig zu beschreiben.
redundant
On 01/30/2014 11:20 AM, gmbo wrote:
Auch wenn ich die Relationen selbst nicht brauche, sind die Relationen
dafür da das eigentlich ein großes Objekt welches sich räumlich auf
einen größeren Raum (Europa) befindet, zusammengehörig zu beschreiben.
Nein ...
Eine Stolpersteinrelation ist für
Hallo gmbo.
Ich stimme dir ebenfalls NICHT zu.
Eine Relation beschreibt, wie der Name schon sagt, die RELATION zwischen
Objekten.
Die Stolpersteine sind aber nur eine Menge gleicher Objekte.
Am 30.01.2014 11:20, schrieb gmbo:
[...]
Eine Stolpersteinrelation ist für mich nichts anders als
Mir persönlich geht es nicht um die Relationen, z.B. Stolpersteine. Ich
versuche zu verstehen warum dieser Overhead so stört. Alles was wir in
OSM einflegen bringt auf der einen Seite einen Nutzen auf der Anderen
stört es.
Mir war der Zweck der Relationen nicht 100% klar Trotzdem habe ich wenn
Am 30/gen/2014 um 14:22 schrieb gmbo g...@kilometerfresser.eu:
Leider bin ich noch nicht so lange im Mapgeschehen, dass ich die
Zusammenhänge, warum die einzelnen Relationen erstellt wurden für mich
nachvollziehbar sind.
prinzipiell gilt, dass alles was man nicht über relationen
On 30.01.2014 11:29, Martin Koppenhoefer wrote:
Am 30. Januar 2014 11:20 schrieb gmbo g...@kilometerfresser.eu:
bei den Verkehrsbetriebsnetzwerken mag man noch diskutieren können
(die könnten im Prinzip auch über den operator oder network tag o.Ä.
ausreichend beschrieben werden), während
Hallo Gisbert,
das meiste hat Martin ja schon geschrieben.
Wenn Du eine Idee hast, wie man Nutzer gezielt informieren oder auch
vorab informieren kann, sag Bescheid - das wäre tatsächlich eine
vielleicht recht spannende Geschichte, also:
Ich, Peter, will vorab informiert werden, wenn sich die
On 30.01.2014 14:22, gmbo wrote:
Mir persönlich geht es nicht um die Relationen, z.B. Stolpersteine.
Ich versuche zu verstehen warum dieser Overhead so stört. Alles was
wir in OSM einflegen bringt auf der einen Seite einen Nutzen auf der
Anderen stört es.
Bitte nenne einen konkreten Nutzen.
malenki schrieb:
Ich finde, auf die Netzwerke von Busrouten kann man ebenso verzichten
wie auf eine Relation Radwege in Sachsen (aus der Luft gegriffenes
Beispiel mit real existierenden Anwendungen...).
Nicht dass man mich falsch versteht: an den Netzwerkrelationen will ich
derzeit nichts ändern
Am 30.01.2014 18:30, schrieb malenki:
malenki schrieb:
Ich finde, auf die Netzwerke von Busrouten kann man ebenso verzichten
wie auf eine Relation Radwege in Sachsen (aus der Luft gegriffenes
Beispiel mit real existierenden Anwendungen...).
Nicht dass man mich falsch versteht: an den
On 01/30/2014 05:09 PM, malenki wrote:
Bitte nenne einen konkreten Nutzen.
Nachteile wurden bereits aufgezählt.
einer fehlt glaube ich noch in der bisherigen Auswertung:
* Replikationen zu verarbeiten, zum Beispiel beim Datenbank-Import,
ist teuer
Beim Import mit osm2pgsql zB. hat man ein
gmbo schrieb:
Am 30.01.2014 18:30, schrieb malenki:
Nicht dass man mich falsch versteht: an den Netzwerkrelationen will
ich derzeit nichts ändern – wie ich auch sonst die Finger vom ÖPNV
lasse.
Ing^W^Thomas
das macht morgen dann ein anderer.
Hoffentlich
Am 30. Januar 2014 17:09 schrieb malenki o...@malenki.ch:
On 30.01.2014 14:22, gmbo wrote:
Mir persönlich geht es nicht um die Relationen, z.B. Stolpersteine.
Ich versuche zu verstehen warum dieser Overhead so stört. Alles was
wir in OSM einflegen bringt auf der einen Seite einen Nutzen auf
Am 30.01.2014 17:09, schrieb malenki:
On 30.01.2014 14:22, gmbo wrote:
Mir persönlich geht es nicht um die Relationen, z.B. Stolpersteine.
Ich versuche zu verstehen warum dieser Overhead so stört. Alles was
wir in OSM einflegen bringt auf der einen Seite einen Nutzen auf der
Anderen stört es.
--- Original Nachricht ---
Absender: malenki
Datum: 30.01.2014 17:09
Bitte nenne einen konkreten Nutzen.
Nachteile wurden bereits aufgezählt.
Eine Relation ist doch eine Verknüpfung zwischen einzelnen
Objekten. Um den Zusammenhang zwischen diesen Objekten
herzustellen. Um mal bei den
Hallo zusammen,
Könntest du mir so eine einfache Abfrage, die mir alle z.B.
Bushaltestellennodes listet die nicht in einer bestimmten Relation sind.
Das habe ich bisher nicht hinbekommen.
http://overpass-turbo.eu/s/2kh
Viele Grüße,
Roland
___
Am 30.01.2014 20:55, schrieb Steffen:
Für was sollen den Relationen in OSM genutzt werden?
Wenn eine Relation zwischen Objekten besteht, die nicht durch eine
einfache Gruppierung ausgedrückt werden kann.
Beispiel 1:
Multipolygon, also Fläche mit Loch.
Polygon A mit role=inner,
Polygon B mit
On 01/30/2014 08:55 PM, Steffen wrote:
Eine Anwendung würde dann die Relation auslesen mit den enthaltenen
Tags. Sowie die einzelnen Nodes mit den jeweiligen Tags. Und müsste
diese zusammensetzen.
und jede Anwendung muss dann für jeden Knoten oder Weg prüfen ob,
und wenn ja in welchen,
--- Original Nachricht ---
Absender: Hartmut Holzgraefe
Datum: 30.01.2014 22:01
Das Abfragen mit der api hat doch nix mit dem Sinn einer Relation zu
tun. Wenn ich die alle Objekte (nodes) abfrage und diese dann
zusammenführe, bilde ich doch eine Relation hinterher doch nach.
Nein, eine gute
Ich bin auch fürs löschen. Ich würde dann auch mit helfen, die Wikiseite
anzupassen.
Am 28. Januar 2014 21:58 schrieb malenki o...@malenki.ch:
Eine Liste, aus der man automatisch Overpass-Abfragen nach dem Schema
Stolpersteine in $Ort basteln kann, bereite ich gerade vor.
Was genau meinst
Gertrud Simson schrieb:
Ich bin auch fürs löschen.
Ich würde dann auch mit helfen, die Wikiseite anzupassen.
Vielen Dank für das Angebot; ich werde darauf zurückkommen.
Gibt es eigentlich schon ein Template für Overpass-Abfragen á la
key=value in XY?
Wäre das überhaupt sinnvoll (bei
42 matches
Mail list logo
