Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.10 17:30, schrieb Jan Tappenbeck: HI ! das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber wenn ich nur mal kleine anwendungen machen will dann ist das mit der api besser. Prinzipiell ist die api ja für das Editieren zuständig. Für Anwendungen wäre die xapi ausreichend, wenn es dort entsprechende Funktionalitäten geben würde. Leider ist die xapi in einer obskuren Sprache geschrieben, an die sich niemand rantraut :-( Von der Verfügbarkeit der Server mal abgesehen... Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo am 13.10.2010 00:01 schrieb Frederik Ramm: Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). Prima Idee. Hast du auch eine Idee, wie man dann ohne zusätzlichen Aufwand Grenzen und andere Multipoligone herunterläd um sie zu reparieren? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
On Wed, Oct 13, 2010 at 12:01:07AM +0200, Frederik Ramm wrote: C. Brause wrote: Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne kurze Antwort geben (glaub ich aber nicht). Mapper tun das oft, weil sie dadurch - vorausgesetzt, sie kennen die Relations-ID - sehr leicht saemtliche dieser Objekte herunterladen koennen (mit der /relation/xxx/full-Abfrage). Das ist komfortabler, als sich die betr. Objekte anhand der Tags herauszusuchen. Allerdings sind Relationen dafuer eigentlich nicht gedacht (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu entfernen, ein nützlicheres zu schaffen, das dann alle verwenden? Offensichtlich gibt es hier ja eine Anforderung der User. Sie wollen alle Features eines bestimmten Typs leicht finden. Das kann man durch den Trick mit der Relation machen. Oder man benutzt die XAPI. Zumindest solange es nur um einen einzigen Tag geht, macht die XAPI das ja ganz brav. Und bei der XAPI kann ich auch eine Bbox angeben, was man bei dem Weg über die Relation nicht kann. Schwieriger wird es bei geographisch geschachtelten Relationen: Alle Stolpersteine in Bayern oder sowas. Hier ist in der Relation nicht nur der Tag kodiert, sondern eine geographische Information. Und zwar eine, die derzeit sehr schwierig aus der Datenbank zu bekommen ist. Die Alternative ist derzeit, eine eigene Datenbank aufzusetzen mit einem Mirror der Daten, die Grenze von Bayern zusammenzusetzen und dann auszuschneiden. Klar, das das kaum jemand hinbekommt. Vielleicht gibt es noch andere Gründe, warum manche Leute, die Relationen gerne haben. Falls ja, dann sagt Bescheid. Die Gegner der Relationen für diese Zwecke sagen: Informationen in Tags sind leichter zu Verarbeiten und Pflegen als Relationen zu machen, die gerade für Anfänger schwer zu verstehen sind. Wird so eine Relation ausversehen gelöscht, ist das Geschrei groß. Und die Verarbeitung mag zwar einfacher sein für den Gelgenheitsuser, der nur die Relation als XML runterlädt und damit was macht, aber datenbanktechnisch ist es ein Riesenaufwand, weil wir Abhängigkeiten zwischen verschiedenen Objekten haben. Wird z.B. ein Node gelöscht, der in der Relation ist, muss man diese auch immer mit anfassen. Dahinter steckt aber noch ein ganz anderes Problem, verschiedene Ansichten, die so meist nicht formuliert werden, weil beide Seiten sie für selbstverständlich halten und garnicht sehen, dass ihre Weltbilder hier auseinanderlaufen: Der durchschnittliche Mapper, der nur gelegentlich mit den Daten ein bischen was basteln will (z.B. eine Karte aller Stolpersteine in Bayern), erwartet, dass ihm die OSM-Datenbank diese Daten auf einfache Weise rausrückt. Der Hacker oder Informatiker hingegen sieht, dass es sehr aufwändig ist für eine zentrale Datenbank die Informationen in all den Formen zur Verfügung zu stellen, die die verschiedenen Leute brauchen. Er geht also davon aus, dass die zentrale Datenbank nur zum Editieren da ist und alle anderen Formen der Nutzung aus einer Kopie der Datenbank heraus erfolgen, die für die jeweilige spezielle Nutzung optimiert ist. Aber natürlich können die wenigsten eine solche spezielle Datenbank aufsetzen. Der Mapper wird also die pragmatische Lösung wählen (also z.B. Relationen anlegen). Und bei OSM ist die pragmatische Lösung *immer* die richtige Lösung, so ist unser Projekt groß geworden, das gehört eigentlich zu unserer Kultur. Wir wollen keine theoretisch gute Lösung, die aber nicht umsetzbar ist, wir wollen die pragmatische Lösung. Dummerweise ist aber natürlich die Welt komplex und die pragmatischen Lösungen können und werden zu neuen Problemen führen. Aber wenn man die pragmatische Lösung für falsch hält, dann gibt es in unserem Projekt eigentlich nur eine Möglichkeit dem zu entgegnen, nämlich in dem man eine *noch pragmatischere* Lösung schafft, nicht in dem man die pragmatische Lösung verbietet oder verhindert. Wir haben hier also eine Schwierigkeit. Beide Seiten haben vernünftige Argumente, die aus ihrer Sicht Sinn machen. Wir sollten überlegen, was man machen kann, um hier einen Schritt weiter zu kommen, statt immer wieder alte Argumente zu wiederholen. Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und weiter auszubauen. Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Ich bin sicher, wenn wir genauer darüber nachdenken, was wir
Re: [Talk-de] Relation als Sammelobjekt
am Dienstag, 12. Oktober 2010 um 23:58 schrieb C. Brause: Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne kurze Antwort geben (glaub ich aber nicht). Also bei den Stolpersteinen schwanke ich auch ein wenig. Man kann immerhin so argumentieren, daß diese Steine ein Gesamtkunstwerk eines Künstlers darstellen. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo, Jochen Topf wrote: Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu entfernen, ein nützlicheres zu schaffen, das dann alle verwenden? Die beste Idee waere gewesen, dieses Feature gar nicht erst anzubieten, denn dann haette sich laengst irgendjemand etwas gescheites ausgedacht; solange es die Moeglichkeit des kompletten Relationsdownloads gibt, werden die Leute weiterhin den Weg des geringsten Widerstandes gehen. Daher sehe ich die Entfernung dieses Features als einen sinnvollen ersten Schritt zur vernuenftigen Loesung des Problems; eine vernuenftige Loesung des Problems wird nicht stattfinden, solange es das Feature gibt. Der Mapper wird also die pragmatische Lösung wählen (also z.B. Relationen anlegen). Und bei OSM ist die pragmatische Lösung *immer* die richtige Lösung, so ist unser Projekt groß geworden, das gehört eigentlich zu unserer Kultur. Meiner Ansicht nach war es ein Versehen, dass dieser .../full-Download jemals angeboten wurde. Es gibt sehr viele Dinge, die man als pragmatisch bezeichnen koennte (z.B.: anstatt einen Bot alle highway=residentail in highway=residential umsetzen zu lassen, machen wir doch einfach ein UPDATE-Statement auf der Datenbank), und die der Mapper unter Garantie sofort einsetzen wuerde, wenn man es anboete; wir bieten es aber nicht an. Dem Pragmatismus sind also immer, auch in OSM, Grenzen gesetzt, und ich denke, dass diese Grenze hier korrigiert werden muss. Dummerweise ist aber natürlich die Welt komplex und die pragmatischen Lösungen können und werden zu neuen Problemen führen. Aber wenn man die pragmatische Lösung für falsch hält, dann gibt es in unserem Projekt eigentlich nur eine Möglichkeit dem zu entgegnen, nämlich in dem man eine *noch pragmatischere* Lösung schafft Das ist in dieser Allgemeinheit falsch (s.o. mit den Bots). Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und weiter auszubauen. Oder OSM halt einfach naeher zu den Usern bringen - ein kleines Klickibuti-Interface auf Osmosis oben drauf, welche Daten haetten Sie denn heute gern..., dann soll sich das Ding von irgendwo her Bayern oder Luebeck laden und raussuchen, was der User will... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo, man sollte m.E. unterscheiden zwischen geordneten Relationen, bei denen es auf die Reihenfolge der Elemente und ggf. auf die Rolle der Elemente ankommt und den sog. Sammelrelationen (oder virtuelle Relationen oder Gruppen), die diese Eigenschaften nicht benötigen! Am 13.10.2010 09:22, schrieb Jochen Topf: Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Also ich könnte mir vorstellen, z.B. nur mit einem hierarchisch gegliederten Tag (group) zu arbeiten, also so wie es mal für is_in vorgeschlagen wurde: Also z.B. so: group=Stolpersteine oder mit geografischer Komponente group=Stolpersteine/DE/Bayern/München Will man alle haben, so kann man sie mit Stolpersteine* selektieren, braucht man nur die in Bayern, dann eben Stolpersteine/DE/Bayern* Alternativ könnte man natürlich auch so arbeiten group=Stolpersteine group:country=DE group:district=Bayern group:city=München finde ich aber nicht so gut, denn dann ist die Gefahr größer, dass Tags fehlen. Eine dritte Variante wäre diese: group:Stolpersteine=yes oder mit Lage group:Stolpersteine=DE/Bayern/München Das wäre eigentlich mein Favorit, denn so ist klar, dass ein Element auch mehreren Gruppen angehören könnte. Der Vorteil der Gruppen (=virtuelle Relationen) liegt auf der Hand: Man muss nur das Tag pflegen und nicht noch eine Relation Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 00:01, schrieb Frederik Ramm: Allerdings sind Relationen dafuer eigentlich nicht gedacht (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). Wird lustig wenn hier mal die Überland-Buslinien erfasst werden. Da sind dann Riesendownloads des Gebiets vorprogrammiert, wenn man die Relation nicht mehr einzeln runterladen kann. Will man das? Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo Frederik, meiner Meinung nach ist das der falsche Weg. Bei Routen ist dies bspw. die einzige sinvolle Möglichkeit an die Daten zu kommen. Es ist großer Schwachsinn, dass ich mir für einen einfachen gpx-Track eines Radfernweges Deutschland als Extract herunterladen muss. Besser wäre, wie du schon sagst, ein kleines Klickibunti-Programm als GUI für den API-Aufruf. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630023.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
On Wed, Oct 13, 2010 at 10:19:32AM +0200, Stefan Dettenhofer (StefanDausR) wrote: Am 13.10.2010 09:22, schrieb Jochen Topf: Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Also ich könnte mir vorstellen, z.B. nur mit einem hierarchisch gegliederten Tag (group) zu arbeiten, also so wie es mal für is_in vorgeschlagen wurde: Also z.B. so: group=Stolpersteine oder mit geografischer Komponente group=Stolpersteine/DE/Bayern/München Will man alle haben, so kann man sie mit Stolpersteine* selektieren, braucht man nur die in Bayern, dann eben Stolpersteine/DE/Bayern* Alternativ könnte man natürlich auch so arbeiten group=Stolpersteine group:country=DE group:district=Bayern group:city=München finde ich aber nicht so gut, denn dann ist die Gefahr größer, dass Tags fehlen. Eine dritte Variante wäre diese: group:Stolpersteine=yes oder mit Lage group:Stolpersteine=DE/Bayern/München Das wäre eigentlich mein Favorit, denn so ist klar, dass ein Element auch mehreren Gruppen angehören könnte. Der Vorteil der Gruppen (=virtuelle Relationen) liegt auf der Hand: Man muss nur das Tag pflegen und nicht noch eine Relation Was genau bringen diese Gruppen jetzt gegenüber normalen Tags? Das ist doch jetzt nichts anderes, ob man group:Stolpersteine=DE/Bayern/München tagged oder stolpersteine=yes is_in=DE, Bayer, München oder? Im Gegenteil, hier werden zwei Konzepte vermischt: Nämlich Geographie und Tags. Bei is_in ist wenigstens die Geographie noch getrennt von dem, um was es sich hier handelt. 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] Relation als Sammelobjekt
On 13.10.2010 07:03, Jan Tappenbeck wrote: Am 13.10.2010 01:06, schrieb Walter Nordmann: C. Brause wrote: ...ich möchte Jans neu gestarteten Thread nicht kapern, daher neu: sorry, ich habs gerade gemacht (das kapern) :( bevor ich deinen beitrag gelesen hab. die darstellung von frederik ist ja wohl klar. ich hatte selber mal solche gruppen-relationen für rettungspunkte, da mir das ganze damals nicht so klar war; aber die sind schon lange draußen. gruss walter das ganze ist eine relativ hartnäckige sache. - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg hi ! aber wie wollt Ihr dann die Möglichkeit haben alle Stolpersteine für einen Bereich oder eines Thema (Stolpersteine in xyz) , was wiederum eine Untermenge (alle Stolpersteine) darstellt. Mann könnte aber Daten über ein Rechteck ermitteln - aber in engen / verschachtelten Siedlungsgebieten ist das nur schwer möglich. Die API läßt keinen Download für eine unregelmäßige Form zu ! Einerseits ist das für API 0.7 vorgeschlagen, auch Polygone als Bounding-box zu erlauben, andererseits ist die API keine direkte Anwendungsschnittstelle. Anwendungsentwickler sollten sich einfach endlich dran gewöhnen, dass ein Postprocessing der API-Antwort der Regelfall ist, und nicht eine Ausnahme für exotische Anwendungen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.10 10:06, schrieb Frederik Ramm: Hallo, Jochen Topf wrote: Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu entfernen, ein nützlicheres zu schaffen, das dann alle verwenden? Die beste Idee waere gewesen, dieses Feature gar nicht erst anzubieten, denn dann haette sich laengst irgendjemand etwas gescheites ausgedacht; solange es die Moeglichkeit des kompletten Relationsdownloads gibt, werden die Leute weiterhin den Weg des geringsten Widerstandes gehen. Dann nenn doch mal funktionierende Alternativen. Xapi lädt keine komplette Relation runter, osmosis kann keine komplette Relation ausschneiden, openlayers braucht zur grafischen Darstellung einer Relation den /full-Download. Um nur mal die wichtigsten Anwendugen zu nennen. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 09:22, schrieb Jochen Topf: Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und weiter auszubauen. Bzw. mal neu und schön zu implementieren. Wenn es z.B. eine verlässliche und stabile Möglichkeit gäbe (dies bitte als API 0.7 Vorschlag verstehen), die einzelnen Elemente über ihre Tags anzusehen: http://www.openstreetmap.org/browse/tag/historic/stolpersteine für den Tag historic=stolpersteine würde bald keiner mehr die Relation nutzen, da dieser Link - einfacher zu merken / zu identifizieren - immer aktuell - unkaputtbar ist. Leider ist derzeit der Weg über die XAPI aber so unattraktiv, das ihn nur sehr wenige Leute gehen wollen. Nehmt den Leuten nicht die Möglichkeit (-relation-full-requiest) sondern gebt ihnen besser Möglichkeiten, damit sie von den alten ablassen. *) Lg Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Ich bin sicher, wenn wir genauer darüber nachdenken, was wir eigentlich machen bzw. machen wollen, welche Probleme die verschiedenen Leute, versuchen zu lösen, dann werden wir auch einer Lösung näher kommen. Jochen *) Klingt irgendwie wir ein Bibel-Zitat, ists aber nicht ^^ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
ganz einfach - api vergessen und was richtiges verwenden. die api ist 99% tag-bezogen. da muss alles aus tags herausgezogen werden, was irgendwie geht. tags sind dafür da, um zu beschreiben, WAS für ein objekt es ist aber nicht dafür, WO es ist. von einigen ausnahmen abgesehen (is_in, addr:*), die aber nur aus der not heraus geschaffen wurden. die wesentlich bessere information sind diese beiden kleinen werte lat und lon. damit läßt sich das aus osm herauskitzeln, was WIRKLICH interessant/wichtig ist. in dem speziellen fall der stolpersteine benutz man halt die grenzen der interessanten bereiche (stadt, kreis, ...) soweit sie vorhanden sind. und wenn jetzt einer ankommt und meint die sind aber nicht alle drin, dem kann ich nur raten, dagegen was zu tun. gruss walter so, jetzt hol ich mir nen kaffee und bin dann wieder lieb ;) - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630202.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo Peter, Polygone als Bounding-box erlauben Das würde vieles erleichtern! Damit könnten viele geografische Bezüge abbgebildet werden. Zusätzlich braucht man aber m.E. noch irgendein ein System für normale relationale / hierarchische Bezüge (Kategorien): z.B. für alle Stolpersteine, alle netten Toiletten, etc) Die Idee von Frederik, für solche Abfragen eine besondere DB anzubieten, in der mit einer GUI simpel alle denkbaren Kombinationen von Werten und Schlüsseln (auch geschachtelt) und kombiniert mit einem Grenz-Polygon abgefragt werden können finde ich genial! Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13. Oktober 2010 11:36 schrieb Markus liste12a4...@gmx.de: Zusätzlich braucht man aber m.E. noch irgendein ein System für normale relationale / hierarchische Bezüge (Kategorien): z.B. für alle Stolpersteine, alle netten Toiletten, etc) das sind keine hierarchischen Bezüge m.E., und das System gibt es von Anfang an, es heisst: Tag (k/v). Ich kann allen raten, die sich wie Jan sowieso Tag und Nacht mit OSM beschäftigen, schaut Euch mal Postgres/Postgis an. Mit der Anleitung von Richard (oder einer anderen je nach System, gibts alles im Wiki) installiert man das Teil in ner viertel Stunde, dann noch mal ein bisschen fürs Einlesen der Daten, und schwuppdiwupp macht man die tollsten Abfragen, anfangs durch Abändern von Beispielen, und irgendwann auch freihand. Wenn man nett fragt schreibt einem vielleicht auch hier auf der Liste jemand ein Beispielquery (im ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen, nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im Zweifel auch nicht immer, was da im Hintergrund passiert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 09:28, schrieb Christian H. Bruhn: am Dienstag, 12. Oktober 2010 um 23:58 schrieb C. Brause: Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne kurze Antwort geben (glaub ich aber nicht). Also bei den Stolpersteinen schwanke ich auch ein wenig. Man kann immerhin so argumentieren, daß diese Steine ein Gesamtkunstwerk eines Künstlers darstellen. Christian Bei dem Argument reicht ja etwas wie Künstler=Stolpersteinmacher oder sowas. Aber inzwischen wurden ja einige größere Probleme angesprochen. Da gibt es wohl noch mehr. Trotzdem möchte ich, wenn ich einen Stolperstein sehe, den einfach eintragen und nicht noch die irgendwelche Relationen raussuchen und hoffen, dass ich die richtige erwische. Das kann dann zur Not auch der machen, der die auswerten möchte. (Zur Not dann lokal mit runtergeladenen Daten) LG Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
{quote]Wenn man nett fragt schreibt einem
vielleicht auch hier auf der Liste jemand ein Beispielquery (im
ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist
hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen,
nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im
Zweifel auch nicht immer, was da im Hintergrund passiert.
hi, es hat zwar keiner gefragt, aber so sieht das aus:
gis= select id
gis- from nodes left join relation_members
gis- on id = member_id
gis- where member_id is null
gis- and nodes.tags @ 'memorial:type=stolperstein'
gis- ;
und dann kommen 27 sst. raus, die NICHT in irgendeiner relation drin sind.
(meine auch)
für die profis: hstore im neuen osmosis simple schema 0.37, - nicht
osm2psql, aber da gehts ähnlich.
gruss
walter
-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
--
View this message in context:
http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630573.html
Sent from the Germany mailing list archive at Nabble.com.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hi Ich denke auch, die (Re)implementation der XAPI innerhalb der API wäre der richtige Weg. Die XAPI ist unheimlich praktisch - aber meistens überlastet. Wie oft brauche ich z.B. alle Bushaltestellen in gegebener BBox? XAPI - einfach möglich; API - bbox insgesamt laden :( Die Sammelrelationen bieten da nunmal abhilfe, das macht sie praktisch. Ein Verbot, Relationen müssten aber unterschiedliche Rollen für ihre Elemente haben oder so (was dem vorbeugen könnte), halte ich auch für blöd. Die Abfrage nach gemeinsamen Tags dagegen ist IMHO eine sehr gute Möglichkeit. Das ist vermutlich ziemlich aufwändig, auch das ist richtig; aber ich denke, es lohnt sich, das in Angriff zu nehmen. Wenn dann noch propagiert wird, wie weniger anfällig Sammlungen über diese Abfragen für Schäden und Unvollständigkeit sind, sollte sich das auch rumsprechen, dass es sinnvoll verwendbar ist. Gruß Peter On 13.10.2010 11:18, Peter Körner wrote: Am 13.10.2010 09:22, schrieb Jochen Topf: Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und weiter auszubauen. Bzw. mal neu und schön zu implementieren. Wenn es z.B. eine verlässliche und stabile Möglichkeit gäbe (dies bitte als API 0.7 Vorschlag verstehen), die einzelnen Elemente über ihre Tags anzusehen: http://www.openstreetmap.org/browse/tag/historic/stolpersteine für den Tag historic=stolpersteine würde bald keiner mehr die Relation nutzen, da dieser Link - einfacher zu merken / zu identifizieren - immer aktuell - unkaputtbar ist. Leider ist derzeit der Weg über die XAPI aber so unattraktiv, das ihn nur sehr wenige Leute gehen wollen. Nehmt den Leuten nicht die Möglichkeit (-relation-full-requiest) sondern gebt ihnen besser Möglichkeiten, damit sie von den alten ablassen. *) Lg Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Ich bin sicher, wenn wir genauer darüber nachdenken, was wir eigentlich machen bzw. machen wollen, welche Probleme die verschiedenen Leute, versuchen zu lösen, dann werden wir auch einer Lösung näher kommen. Jochen *) Klingt irgendwie wir ein Bibel-Zitat, ists aber nicht ^^ ___ 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] Relation als Sammelobjekt
Am 13. Oktober 2010 13:45 schrieb Peter Wendorff wendo...@uni-paderborn.de: Ich denke auch, die (Re)implementation der XAPI innerhalb der API wäre der richtige Weg. Die XAPI ist unheimlich praktisch - aber meistens überlastet. wenn wir gerade bei wünsch-Dir-was sind: ich würde eine Methode gut finden, um eine lokale db über Diffs synchron zu halten, aber nicht für den kompletten planet, sondern deutlich kleinere Einheiten wie z.B. einzelne Länder / Staaten (was man mit einem normalen bis schwachen PC noch handlen kann). Evtl. könnte man das auch auf lokaler Seite beim Einspielen der Diffs filtern (nur was innerhalb einer gewissen BB oder Polygon ist)? Oder kann man nicht jetzt schon die planet-diffs auf eine Extrakt-Datenbank einspielen und dann was ausserhalb liegt wieder rausschmeissen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 11:50, schrieb M∡rtin Koppenhoefer: Am 13. Oktober 2010 11:36 schrieb Markusliste12a4...@gmx.de: Zusätzlich braucht man aber m.E. noch irgendein ein System für normale relationale / hierarchische Bezüge (Kategorien): z.B. für alle Stolpersteine, alle netten Toiletten, etc) das sind keine hierarchischen Bezüge m.E., und das System gibt es von Anfang an, es heisst: Tag (k/v). Ich kann allen raten, die sich wie Jan sowieso Tag und Nacht mit OSM beschäftigen, schaut Euch mal Postgres/Postgis an. Mit der Anleitung von Richard (oder einer anderen je nach System, gibts alles im Wiki) installiert man das Teil in ner viertel Stunde, dann noch mal ein bisschen fürs Einlesen der Daten, und schwuppdiwupp macht man die tollsten Abfragen, anfangs durch Abändern von Beispielen, und irgendwann auch freihand. Wenn man nett fragt schreibt einem vielleicht auch hier auf der Liste jemand ein Beispielquery (im ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen, nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im Zweifel auch nicht immer, was da im Hintergrund passiert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de HI ! das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber wenn ich nur mal kleine anwendungen machen will dann ist das mit der api besser. wenn mir z.b. nur ein netbook zur verfügung steht dann wäre das mit der db wohl etwas hoch gegriffen. ich für meinen teil komme so wie es jetzt ist gut aus. für die stolpersteine brauche ich 1 min, für die tankstellen etwas länger. es werden sowieso nur die aktuellen themen (PoiM) und kleinigkeiten täglich upgedatet - die anderen karten 7/14-tägig und dafür baue ich keine db auf. außerdem kann man bei der api auch mal eben von unterwegs ein update fahren. ansonsten siehe ich für karten in größeren ordnungen (garmin) ein osm-file von der geofabrik. nochmal zu (k/v)... wenn sich jeder ein tag für irgendetwas ausedenkt dann ist der wildwuchs nicht weit - bei den tankstellen gab es schon über 250! tags. dann schon lieber relationen. gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 17:41, schrieb M∡rtin Koppenhoefer: Am 13. Oktober 2010 17:30 schrieb Jan Tappenbecko...@tappenbeck.net: das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber wenn ich nur mal kleine anwendungen machen will dann ist das mit der api besser. mag sein, für den Durchschnittsanwender gilt das sicher, für Dich persönlich m.E. eher nicht, wenn ich mir so ansehe, wieviele OSM Projekte Du betreibst. wenn mir z.b. nur ein netbook zur verfügung steht dann wäre das mit der db wohl etwas hoch gegriffen. Ich habe Postgis/Mapnik auf einem Asus 1001p installiert (1,6Ghz Intel Atom, 1GB RAM, 160GB HD, 249,-EUR vor fast nem Jahr). Ist überhaupt kein Problem, habe ganz Italien drin, dauerte vielleicht ne halbe Stunde oder Stunde das Importieren, aber man muss ja nicht ununterbrochen zusehen ;-) hi ! pro import ??? und das ggf. täglich ??? gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
--- Original Nachricht --- Absender: Frederik Ramm Datum: 13.10.2010 00:01 Mapper tun das oft, weil sie dadurch - vorausgesetzt, sie kennen die Relations-ID - sehr leicht saemtliche dieser Objekte herunterladen koennen (mit der /relation/xxx/full-Abfrage). Das ist komfortabler, als sich die betr. Objekte anhand der Tags herauszusuchen. Allerdings sind Relationen dafuer eigentlich nicht gedacht (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). JOSM nutzt diese Möglichkeit ja auch. Da können die Programmierer, von JOSM, dies ja schonmal versuchen anders umzusetzen. Was ist eigentlich so schlimm an dieser Abfrage-Möglichkeit? Gruß Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
M∡rtin Koppenhoefer wrote: schwachen PC noch handlen kann). Evtl. könnte man das auch auf lokaler Seite beim Einspielen der Diffs filtern (nur was innerhalb einer gewissen BB oder Polygon ist)? Oder kann man nicht jetzt schon die planet-diffs auf eine Extrakt-Datenbank einspielen und dann was ausserhalb liegt wieder rausschmeissen? ich hab früher einfach ne bbox in das osm2pgsql-script eingebaut. dort wo osmosis den job macht. dennoch kamen viele daten in die db. bei der - für mich besseren - osmosis/simple geht das ja nicht, da osmosos das mit diff-files nicht zuläßt. da wird die db bald riesig, auch wenn man nur z.b. mit castrop-rauxel angefangen hat. irgendwann sind die osterinseln auch drin gewesen. inzwischen schmeiss ich sehr viele daten einfach raus, die zu weit draussen liegen. zuletzt mussten 28 mio nodes dran glauben. das verfahren für osm2pgsql ist im ansatz hier beschrieben: http://wiki.openstreetmap.org/wiki/User:Stephankn/knowledgebase ich musste das aber erheblich an die osmosis/simple 0.37 anpassen, weil die datenstruktur total anders ist. das prinzip ist bei beiden ganz einfach: schritt 1: alle nodes raus, die weg sollen schritt 2: alle ways raus, die keine nodes (mehr) haben schritt 3: alle relationen raus, die (jetzt) leer sind (keine nodes UND keine ways). dazu hab ich mir dann noch ne relativ große bbox definiert, damit ich in den grenzgebieten nichts verliere das ganze per chron: a) import des diffs b) cleanup gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5632642.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 21:37, schrieb Steffen: Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). [...] Was ist eigentlich so schlimm an dieser Abfrage-Möglichkeit? Das Problem ist wohl nicht die Abfragemöglichkeit an sich, sondern dass die API hier momentan Relationen gegenüber anderen Möglichkeiten der Gruppierung bevorzugt - dass es also für Relations-Mitglieder eine Abfragemöglichkeit direkt in der API gibt, aber für z.B. Objekte mit gleichen Tags oder Objekte innerhalb einer Grenze derzeit keine ebenso komfortable Anfrage existiert. Hätten Mapper die Disziplin, Relationen trotzdem nur dort zu verwenden, wo sie angebracht sind, wäre das ja kein Problem. Aber diese technische Wettbewerbsverzerrung wird eben zunehmend als Anlass genommen, Dinge, für die etwa Tags oder Grenzen eigentlich die bessere Lösung wären, stattdessen oder zusätzlich mit Relationen einzutragen. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation als Sammelobjekt
Hallo, ich möchte Jans neu gestarteten Thread nicht kapern, daher neu: Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne kurze Antwort geben (glaub ich aber nicht). LG Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo, C. Brause wrote: Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne kurze Antwort geben (glaub ich aber nicht). Mapper tun das oft, weil sie dadurch - vorausgesetzt, sie kennen die Relations-ID - sehr leicht saemtliche dieser Objekte herunterladen koennen (mit der /relation/xxx/full-Abfrage). Das ist komfortabler, als sich die betr. Objekte anhand der Tags herauszusuchen. Allerdings sind Relationen dafuer eigentlich nicht gedacht (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). 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] Relation als Sammelobjekt
C. Brause wrote: ...ich möchte Jans neu gestarteten Thread nicht kapern, daher neu: sorry, ich habs gerade gemacht (das kapern) :( bevor ich deinen beitrag gelesen hab. die darstellung von frederik ist ja wohl klar. ich hatte selber mal solche gruppen-relationen für rettungspunkte, da mir das ganze damals nicht so klar war; aber die sind schon lange draußen. gruss walter das ganze ist eine relativ hartnäckige sache. - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5628975.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 01:06, schrieb Walter Nordmann: C. Brause wrote: ...ich möchte Jans neu gestarteten Thread nicht kapern, daher neu: sorry, ich habs gerade gemacht (das kapern) :( bevor ich deinen beitrag gelesen hab. die darstellung von frederik ist ja wohl klar. ich hatte selber mal solche gruppen-relationen für rettungspunkte, da mir das ganze damals nicht so klar war; aber die sind schon lange draußen. gruss walter das ganze ist eine relativ hartnäckige sache. - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg hi ! aber wie wollt Ihr dann die Möglichkeit haben alle Stolpersteine für einen Bereich oder eines Thema (Stolpersteine in xyz) , was wiederum eine Untermenge (alle Stolpersteine) darstellt. Mann könnte aber Daten über ein Rechteck ermitteln - aber in engen / verschachtelten Siedlungsgebieten ist das nur schwer möglich. Die API läßt keinen Download für eine unregelmäßige Form zu ! ... bin mal gespannt wie Ihr das denn machen würdet. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
