@kollege
Hast ja Recht, und ich bin auch schon dran. Ich muss dazu nur alles ein wenig umbauen und das dauert jetzt erstmal.
Besser wär’s. Bisherige Versuche, derlei zu automatisieren, führten stets zu Problemen, etwa mit Doppeleinträgen. Ohne Dir zu nahe treten zu wollen: bei bisher vier OSM-Änderungssätzen im Jahr 2008 traue ich Dir eher nicht zu, das automatisch hinzubekommen.
Mit melden meinst Du eintragen bzw. das OSM-Objekt bearbeiten? Da gibt es keine Untergrenze, selbst Tippfehlerkorrekturen sind durchaus üblich. Bloß “triviale” Bearbeitungen (also nur eine neue Version ohne jede Änderung) sind sehr ungern gesehen.
Was meinst Du mit anzeigen? Irgendwo den Fehler melden, damit ein OSMler ihn korrigieren möge? Dafür gibt es OpenStreetBugs. Bei einfachen Fehlern wie Doppeleinträgen, die keine Ortskenntnis erfordern, würde ich aber empfehlen, sie gleich selbst zu beheben. Es gibt weite Landstriche, da kümmert sich kein Mensch um OpenStreetBugs, sodaß Fehlermeldungen dort jahrelang versauern.
Wenn man über die API ein neues Objekt in der OSM-DB erstellt, antwortet die API mit der Nummer des neuen Objekts - also ja. Wie gesagt, möchte ich Dir aber dringend davon abraten, solche Einträge automatisch vorzunehmen. Alternativ erstellt man das Objekt mit einem der Mainstream-Editoren und schaut sich anschließend den betreffenden Änderungssatz auf der OSM-Website an, wo alle bearbeiteten Objekte mit ihren Nummern aufgeführt sind. Oder man liest die Nummer nach dem Hochladen gleich im Editor ab.
Da ist zunächst die Frage, ob und inwieweit solche Einträge überhaupt wünschenswert sind. Eine Richtschnur bei OSM lautet, daß man Dinge (nur) nach eigener Kenntnis einträgt. Wenn Du unter Deinem Benutzernamen einen Campingplatz einträgst, weil irgendjemand sagt, er sei dort, ist das problematisch, und fällt im Zweifelsfall auf Dich zurück. Du solltest zumindest prüfen, ob der Eintrag plausibel ist: also mindestens im Luftbild schauen, ob der Fleck tatsächlich nach Campingplatz aussieht. Und ggf. den angegebenen Namen etc. übernehmen, wenn Du Deinen Website-Nutzern hinreichend vertraust (und sie darauf aufmerksam gemacht hast, daß ihre Einträge in der OSM-DB landen und sie keinesfalls Informationen aus fremden Quellen kopieren sollen).
Für “bitte kontrollieren” gibt es fixme-Tags, also fixme=/sinnvolle Problembeschreibung/. Derlei nun aber gleich an jedes hochgeladene Objekt zu hängen, halte ich für kontraproduktiv. Es haben schon Leute flächendeckend etwa Briefkästen mit fixme=“bitte Leerungszeiten eintragen” und dergleichen versehen. Das wird dann eher ignoriert bzw. kurzerhand gelöscht. Also fixme-Tags lieber nur verwenden, wenn einzelne Eigenschaften fragwürdig sind und sich die Zweifel konkret benennen lassen.
Danke Oli-Wan,
klingt alles plausibel und logisch. Und ich möchte Dir/Euch hiermit versichern, dass ich mir allergrösste Mühe geben werde nichts kontraproduktives zu tun. Darum meine Fragen.
Und noch zwei Fragen zu Overpass:
- Wenn ich eine Abfrage mit [newer= …] mache, bekomme ich dann nur neue Einträge oder auch Änderungen zurück?
- Gibt es eine sinnvolle Reihenfolge der Argumente im Query? Wie arbeitet Overpass die Argumente ab?
Gruß
Christian
Ich wolle dich auch nicht antreiben. Ist ja noch ein wenig hin, bevor die Saison wieder richtig losgeht 
Wenn es dieses Wochenende nicht regnet, wird bei mir dieses Jahr wohl campingtechnisch endgültig mit einer Biwaktour abgeschlossen. 
Das schließt alle Objekte ein, deren Zeitstempel neuer ist, d.h. sowohl geänderte als auch neue Objekte. Das einzige, was zur Differenzbildung dort fehlt sind gelöschte Objekte.
Dafür würden sich im Prinzip die Augmented Diffs eignen, aber der Anwendungfall, nach Tags zu filtern, ist dort noch in Entwicklung.
Von Semikolon zu Semikolon. Das ist beim Zugriff mit XAPI-Syntax allerdings nicht zu sehen. Dort ist die Reihenfolge der Klauseln effektiv egal.
Tatsächlich führt die Overpass API die verschiedenen Klauseln verschränkt aus, z.B. wirkt eine kleine Bbox (unter 1x1 Grad) immer als erstes vor allen Tag-Kriterien, egal wo sie steht.
So liegt die Laufzeit zweier kombinierter Klauseln sehr häufig noch unter der Laufzeit beider Klauseln einzeln.
So, da bin ich wieder.
Die Seite ist im Moment offline, da ich gerade am Umstellen bin.
Auf der Suche nach dem tag tourism=camp_site bin ich nun bei nodes, ways, relations und areas fündig geworden.
Ich bin nun dabei die Daten so aufzuarbeiten, dass die nodes nur übernommen werden, wenn sie nicht Teil eines way oder einer relation sind, Das Selbe mit den ways in Bezug auf die relations. Danach versuche ich aus den Nodes eines ways bzw. einer relation den Mittelwert zu ermitteln und das dann so in meine Karte einzubinden.
Oder ist das viel zu kompliziert gedacht?
Wo ich jetzt noch nicht ganz durchsteige sind die Areas.
Mit folgender Abfrage bekomme ich zwar alle Areas mit dem Tag tourism=camp_site inkl. der relations, ways und node. Aber da fehlt noch die Verknüpfung zwischen den areas und dem Rest.
<osm-script element-limit="1073741824" timeout="3600">
<union into="_">
<query into="_" type="area">
<has-kv k="tourism" v="camp_site"/>
</query>
<area-query from="_" into="_" ref=""/>
<recurse type="node-relation" into="rels"/>
<recurse type="node-way"/>
<recurse type="way-relation"/>
</union>
<print/>
</osm-script>
Wie Ihr bestimmt merkt steige ich da noch nicht ganz durch und taste mich durch rumprobieren ran.
Noch was:
Ist es möglich bei der Abfrage eines Nodes gleich zu erfahren in welchem Land er liegt?
Gruß Christian
Die Seite ist jetzt wieder online - mit OSM-Plätzen.
Da sich einiges geändert hat, habe ich einen neuen Thread gestartet:
=> http://forum.openstreetmap.org/viewtopic.php?id=19393