Re: [Talk-de] Waterway Relation / Unterschiedliche Namen Unter/Oberlauf

[Werner Hoch]

Am Donnerstag, den 14.04.2016, 15:49 +0200 schrieb Christoph Hormann:
> On Thursday 14 April 2016, Florian Lohoff wrote:
> > 
> > 
> > Ich halte hier die Relation eigentlich auch für Mißbräuchlich. Das
> > ist wieder nur eine Sammelrelation. Eigentlich müsste die
> > Fließgewässernummer einfach als ref auf alle Teilstücke und gut.
> > Das
> > wieder mit einer Sammelrelation zusammenzuführen - ist - ähm -
> > naja.
> Die Idee hinter den waterway-Relationen ist eigentlich Namen-
> basierend - 
> der Fluss mit dem Namen 'Elbe' existiert als Relation, obwohl er
> ggf. 
> aus vielen hundert einzelnen ways besteht.  Die Namen in x 
> verschiedenen Sprachen sowie wikidata-Tags etc. muss man dann nicht
> an den ganzen ways anbringen, sondern nur einmal und die 
> waterway-Relation 'Moldau' erhält als destination-Tag 'Elbe', so dass
> sogar die Struktur des Flussnetzwerkes abgebildet wird.

Das optionale destination tag wurde mit aufgenommen, um durch diese
kleine Redundaz zwischen dem destination tag und der Verbindung von
Wasserwegen durch Nodes und Ways, die Kontrolle zu vereinfachen.

Ein Fluss mit destination=Rhein sollte dann auch in den Rhein fließen
(durch verbundene Waterway ways).

> In der Praxis funktioniert das natürlich nicht, denn die Elbe heißt
> bei der Mündung der Moldau lokal 'Labe', so dass das Ganze in die
> Hose geht:
> 
> http://www.openstreetmap.org/relation/1730536
> http://www.openstreetmap.org/relation/123822
> 
> Und das ist nur ein ganz einfaches Beispiel, geht noch deutlich 
> komplizierter wie hier:
> 
> http://www.openstreetmap.org/relation/1067987
> 
> Das Problem ist dabei weniger der Charakter als Sammel-Relation,
> sondern dass das Konzept eines eindeutigen und überprüfbaren Namens
> in der Realität einfach nicht existiert.  Flüsse werden lokal benannt
> und die 
> Benennung der waterway-Relationen ist im Allgemeinen eine recht 
> willkürliche und subjektive Extrapolation.  Bei Wikipedia
> funktioniert 
> das, denn ein Wikipedia-Artikel kann ggf. unterschiedliche
> Sichtweisen darstellen oder im ungefähren bleiben, bei einer Geo-
> Datenbank muss jedoch eine eindeutige Geometrie vorhanden sein.

Viele Flüsse sind neben Wikipedia auch in Wikidata gelistet. Diese
Daten lassen sich (neben den reinen Verbindungsdaten) auswerten.
Wikidata hat in seinen Eigenschaften ebenfalls Eigenschaften, die die
Verbindung von Flüssen beschreibt. (mouth_of_watercourse, lake_outflow,
...)

http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html

Hier die Daten der Schweiz:
http://www.h-renrew.de/h/osm/osmchecks/07_watershed/planet/wikidata_osm
_CH.html

MfG
Werner

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

Re: [Talk-de] Waterway Relation / Unterschiedliche Namen Unter/Oberlauf

[Werner Hoch]

Hallo,

Am Donnerstag, den 14.04.2016, 11:56 +0200 schrieb Volker Schmidt:
> http://wiki.openstreetmap.org/wiki/Relation:waterway
> sagt:
> 
> *name*
> Name of the river  *... *When a river gets multiple names (f.e.
> because it
> passes in multiple language regions), use all different names in the
> name
> tag, ordered from source to mouth, and split by hyphens. The
> individual
> sections can still get their localised name for that section.

Leider wurde die Seite ohne Diskussion geändert. da ist auch diese
komische name-Definition gemacht worden:
http://wiki.openstreetmap.org/w/index.php?title=Relation%3Awaterway&typ
e=revision&diff=1114522&oldid=1103161

Eine Aufzählung im Namen mit Semicolon habe ich in der Praxis noch
nicht gesehen.

Die lokale Bezeichnung kommt immer an den Way und wird auch so
gerendert.
Die Relation ist für den gesamten Wasserlauf gedacht, da hier dann auch
die Verbindung zu Wikidata, wikipeda, ref, ... hergestellt wird.

MfG
Werner


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

Re: [Talk-de] Fwd: plötzlich leere Relation Radverkehrsnetz NRW, Stadt Köln

[Werner Hoch]

Hallo Johannes,

Am Freitag, den 01.01.2016, 23:42 +0100 schrieb Johannes:
> Kleiner Nachtrag.
> 
> Beim Auslesen der History der Relation gab es, nachdem es mir
> aufgefallen war, mehrere Male Timeouts.

Die Historie ist einfach zu lang. (708 Versionen). Du kannst dir das XML
anzeigen lassen, indem du hinten an die URL die version dran hängst

http://www.openstreetmap.org/api/0.6/relation/55607/708  ... ist leer
http://www.openstreetmap.org/api/0.6/relation/55607/707  ... hat noch
die members.

Werner



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

Re: [Talk-de] OSM: ein bißchen Statistik

[Werner Hoch]

Hi,

spiele seit längerem mit ähnlichen Statistiken:
http://www.h-renrew.de/h/osm/osmchecks/03_Statistik/planet/statistic.html

Die Daten sind vom April.

mfg
Werner

Am Dienstag, den 22.07.2014, 06:36 + schrieb Elstermann, Mike:
> Dank Pascal Neis können wir uns wieder auf eine kurzweilige und interessante
> OSM-Statistik freuen... Danke dafür!
> 
> http://neis-one.org/2014/07/age-of-osm-objects/ oder
> http://geoobserver.wordpress.com/2014/07/22/osm-ein-bischen-statistik/



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

Re: [Talk-de] subareas in administrativen boundaries

[Werner Hoch]

Am Donnerstag, den 16.01.2014, 10:26 -0800 schrieb Walter Nordmann:
> in den letzten Wochen sind viele unserer deutschen administrativen Grenzen
> (z.b.  www.openstreetmap.org/browse/relation/51477
>   ) mit subareas
> "beglückt worden. 
> d.h. dort stehen jetzt nicht nur die Ways der Grenze an sich sondern auch
> noch die Relationen der Bundesländer als Member drin.
> 
> So als Information "das sind die Gebiete aus dem sich das Land
> zusammensetzt".
> 
> Dies halte ich - und das nicht nur alleine - für ziemlichen Blödsinn, dem
> ich keinerlei Nutzen entnehmen kann.
> 
> Das gleiche läßt sich durch eine einfache spatiale Abfrage in einer mit
> osm2pgsql erzeugten Datenbank jederzeit herausfinden. Und genau dieser Typ
> von DB wird von den Mappern in der großen Mehrzahl  eingesetzt, falls sie
> überhaupt einen DB verwenden.

Hat diese "einfache" Auswertung schonmal jemand gemacht und sind die
Ergebnisse verfügbar. Ich erinnere mich, das es vor längerer Zeit eine
Diskussion über eine automatisierte Auswertung gab.

Damit ließen sich auch die vorhandenen Grenzen perfekt kontrollieren und
überwachen. Gleichzeitig hätte man ein zusätzliches Argument, dass
subareas nicht benötigt werden.

http://taginfo.openstreetmap.org/relations/boundary#roles
derzeit ca. 55000 subareas.

Grüße
Werner



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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

[Werner Hoch]

Am Montag, den 13.01.2014, 19:56 +0100 schrieb fly:
> On 13.01.2014 19:20, Martin Koppenhoefer wrote:
> > Am 13. Januar 2014 20:08 schrieb Werner Hoch :
> >> Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in
> >> Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick
> >> erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht.
> >> s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools
> > 
> > Der Mehraufwand besteht darin, dass ich die OSB erstmal suchen muss (deren
> > Webseite etc.), während die Notes mir über osm.org auf einem Silbertablett
> > daherkommen.
> 
> Zugegeben, das JOSM-Plugin würde vielleicht ein bischen früh
> abgeschaltet, allerdings besteht immernoch die Möglichkeit es manuell
> vom SVN herunterzuladen und zu installieren.
> 
> Optimal wäre wohl an Version ohne Möglichkeit neue Bugs zu erstellen.

Das josm-plugin läuft noch ... und man kann damit keine Bugs erstellen.
Was fehlt dir?

Zugegeben. Die Notes-Meldungen werden mittlerweile von mehr mappern
bearbeitet als die alten OSBs.

Grüße
Werner



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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

[Werner Hoch]

Am Montag, den 13.01.2014, 00:38 +0100 schrieb Wolfgang Hinsch:
> Am Sonntag, den 12.01.2014, 18:56 +0100 schrieb Werner Hoch:
> > Du nennst es "voreilig". Konstruktive Vorschläge für die schrittweise
> > Abschaltung sind willkommen. Welcher Zeitraum wäre für dich sinnvoll
> > gewesen, in welchen Schritten?
> 
> Worin bestand eigentlich das Problem, die bisherigen OSB-Einträge in die
> Notes zu übernehmen und dann OSB abzuschalten? Der Aufwand, die OSBs
> manuell zu überprüfen und ggf. zu übertragen dürfte in jedem Fall
> wesentlich größer sein.

OSBs sind zu 80% entweder leicht zu beheben oder aber wurden schon
behoben. Hätte man alle nach Notes übernommen, dann müsste man die
Fehler ja immer noch bearbeiten --> sehr viel unnütze Fehlereinträge in
Notes.

Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in
Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick
erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht.
s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools

Grüße
Werner


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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

[Werner Hoch]

Am Sonntag, den 12.01.2014, 12:31 +0100 schrieb Florian Lohoff:
> ich sehe hier seit 3 Tagen das irgendjemand einfach ohne irgendwas zu
> machen OSB Bugs schliesst. Die Bugs gehen ohne Username und Ohne
> Kommentar einfach zu. Mittlerweile sind >30 Bugs von mir im Umkreis
> Guetersloh/Rheda-Wiedenbrück geschlossen worde.

Dieses mal gibst du immerhin das Gebiet an auf das du dich beziehst.


> ICH MUSS KOTZEN !
> 
> Was soll das? 
> 
> 1. Es geht nicht drum die OSB Bugs so schnell es geht einfach
>zuzumachen, das geht schneller - einfach ein drop all tables in
>der Datenbank.
> 2. Wenn man Bugs schliesst bitte mit Kommentar was geaendert worden ist
>und vor allem mit Namen. So kann ich denjenigen nichtmal per
>Nachricht wüst beschimpfen was das soll.

Ich habe eine Empfehlung ergänzt, wie bugs geschlossen werden sollen:
https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#General_hints

> Ich würde ja neue Bugs aufmachen in dem Gebiet und denjenigen Wüst
> beschimpfen aber das geht ja bei OSB nicht mehr weil ja voreilig
> das neu eröffnen abgeschaltet worden ist.

Das stimmt so nicht. Die API ist noch offen  auch wenn im Forum eine
harte Abschaltung gefordert wurde und ich darüber unglücklich bin, dass
geovelo ihr Seite noch nicht auf Notes umgestellt hat. Offene Frontends
siehe:
https://wiki.openstreetmap.org/wiki/OpenStreetBugs#Tools_for_Using_and_Exporting_Data
(zweite Spalte)

Du nennst es "voreilig". Konstruktive Vorschläge für die schrittweise
Abschaltung sind willkommen. Welcher Zeitraum wäre für dich sinnvoll
gewesen, in welchen Schritten?

PS: Verwendet für neue Bugs trotzdem bitte das Notes System.

Grüße
Werner



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

Re: [Talk-de] OpenStreetBugs Ablösung: Freiwillige für Mappingparty gesucht

[Werner Hoch]

Am Dienstag, den 24.12.2013, 09:32 -0800 schrieb Walter Nordmann:
> Werner Hoch wrote
> > Deine zweite Graphik mit OSB-Notes könnte stimmen wobei die Tools
> > OSB2Notes und osb_fixing unterschiedliche Signaturen beim schießen von
> > OSBs bzw. beim öffnen von OSNotes verwenden. Ich kann deiner Graphik
> > nicht entnehmen nach welcher Signatur du gesucht hast.
> 
> ganz banal nach OSB im ersten Eintrag, also dem Text, den der
> Eröffner/Kopierer geschrieben hat. Ich habe es jetzt auf /upper(text) like
> '%OSB%'/ umgestellt. Dadurch ist Klein-/Großschreibung egal.
> Da ich alle Notes in meiner PostgreSQL-DB drin habe, war das kein großer
> Akt. Es soll ja auch nur der grobe Trend gezeigt werden.

Bei OSB2Notes ist Openstreetbugs ausgeschrieben, die fehlen in deiner
Statistik.

Folgende Bugs sind mit OSB2Notes und osb_fixing-Signaturen in der
OSB-Datenbank geschlossen worden (Graphik fast am Ende):
http://www.h-renrew.de/h/osm/osmchecks/09_osb_phaseout/

> > 2. Es können noch neue Bugs auf OSB erstellt werden
> > Ja das stimmt. Es wurde nur das Webfrontend abgeschaltet. 
> > ...
> > Die neu erstellten Bugs stammen noch von alten OSMAND-Versionen. Die
> > meisten werden in Moskau eingetragen. Weiter stammen von der
> > geovelo-Seite.
> 
> genau deshalb sollte die API ja schnellstens abgeschaltet werden.

Bin hier anderer Meinung, wir sollten erstmal die allermeisten
Webseiten/Tools umstellen, bevor die API abgeschaltet wird.

Ich habe mal den Moskauer Mapper angeschrieben. Ist wahrscheinlich nur
ein User, der die Bugs erzeugt.

> > PS: kannst du im Forum auf diese Wikiseiten verweisen:
> > https://wiki.openstreetmap.org/wiki/Openstreetbug
> > https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out
> > 
> > ... dann können sich die besonders aktiven Poster auch aktive an der
> > Fehlerbehebung beteiligen.
> 
> Ich mach das morgen gerne, aber: du kannst dich jederzeit ohne Registrierung
> mit deiner OSM-ID und deinem OSM-Passwort im Forum einloggen - ein
> Kommentar, den ich normalerweise nur an Newbies schicke ;)

Danke für den Hinweis. bzgl. Forum bin ich ein Newbie. Ich schreibe
einen Kommentar dort rein.

Frohe Weihnachten
Werner


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

Re: [Talk-de] OpenStreetBugs Ablösung: Freiwillige für Mappingparty gesucht

[Werner Hoch]

Hallo Walter,

Am Dienstag, den 24.12.2013, 03:53 -0800 schrieb Walter Nordmann:
> könnte es sein, dass genau diese "geploppten" OSB dann nach Notes verschoben
> wurden?

Teilweise. Auf der PhaseOut-Seite im Wiki habe ich diese Methode
vorgeschlagen:
https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Moving_OSB_entries_to_Notes

Damit ist jederzeit nachvollziehbar, welche OSB und Notes-Einträge
zusammengehören.

Während der Reviews habe ich auch weniger eindeutige Einträge gesehen.
* OSB2Notes: Datenübertragung ohne Referenzen (s. Quelltext)
* OSBs ohne Kommentar geschlossen. Inhalt manuell nach Notes übernommen
* manuelle Kommentare ohne Referenz.
* Notes erstellt, OSB aber nicht geschlossen

> Schau mal  hier
>    auf die
> Grafiken. Danach nimmt die Anzahl der ehemaligen OSB-Nodes in Notes
> permanent zu und wird fast überhaupt nicht abgearbeitet.

Deine zweite Graphik mit OSB-Notes könnte stimmen wobei die Tools
OSB2Notes und osb_fixing unterschiedliche Signaturen beim schießen von
OSBs bzw. beim öffnen von OSNotes verwenden. Ich kann deiner Graphik
nicht entnehmen nach welcher Signatur du gesucht hast.

Es bleiben je nach Region 5-20% an Fehlern übrig, die man beim Review
nicht schließen kann. Diese Bugs (und nur diese) verschiebe ich nach
Notes. Aus 100 OSBs entstehen beim Review ca. 12 Notes.

s. Tools:
https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools

Ich werde meine Statistikseiten mal um die mit OSB2Notes und osb_fixing
verschobenen Bugs ergänzen (nach Weihnachten).

s. vorhandene Statistiken:
http://www.h-renrew.de/h/osm/osmchecks/09_osb_phaseout/


Zwei Einträge aus dem Forum ärgern mich:
1. "Mit den Admins von OSB hat man nicht gesprochen"

Die Abschaltung der homepage habe ich zusammen mit Emka durchgeführt.
Details s. github:
https://github.com/emka/openstreetbugs/issues/50
und entsprechende Commits in seinem Repo:
https://github.com/emka/openstreetbugs/commits/master

2. Es können noch neue Bugs auf OSB erstellt werden
Ja das stimmt. Es wurde nur das Webfrontend abgeschaltet. Würde man die
API abschalten, dann wären davon auch einige andere Webseiten und Mobile
Apps betroffen. Wir versuchen die Webseitenbetreiber und App-Entwickler
zu erreichen und auf einen Umstieg zu Notes zu bewegen.
https://wiki.openstreetmap.org/wiki/Openstreetbug#Tools_for_Using_and_Exporting_Data

Die Methode, die mit der OSB-API erstellten Bugs gleich an Notes
weiterzuleiten wird dort auch erwähnt.

Die neu erstellten Bugs stammen noch von alten OSMAND-Versionen. Die
meisten werden in Moskau eingetragen. Weiter stammen von der
geovelo-Seite.
s. Blog-Post:
http://www.openstreetmap.org/user/werner2101/diary


PS: kannst du im Forum auf diese Wikiseiten verweisen:
https://wiki.openstreetmap.org/wiki/Openstreetbug
https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out

... dann können sich die besonders aktiven Poster auch aktive an der
Fehlerbehebung beteiligen.

Grüße
Werner



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

[Talk-de] OpenStreetBugs Ablösung: Freiwillige für Mappingparty gesucht

[Werner Hoch]

Hallo allerseits,

seit zwei Monaten können ober die OSB Homepage keine neuen Fehler mehr
eingetragen werden.
Seit letzter Woche hat OSNotes mehr offene Fehler als OSB.
OpenStreetbugs: 29000
Notes: 31000

Die meisten Bugs sind in Deutschland (1), Russland (6200),
Großbritanien (2500), Italien, ..
Komplette Länderstatistik am Ende von [1]

Seit Mitte Oktober wurden 1/3 aller offenen Fehler geschlossen. Wenn wir
in demselben Tempo weitermachen, dann dautert es noch 4 Monate, bis alle
OSB-Einträge bearbeitet sind.

Nach Weihnachten (27.12) möchte ich deshalb eine Mappingparty machen,
bei der die noch offenen Fehler bearbeitet werden sollen.

Für die Koordination der Mapping-Party habe ich vor einiger Zeit eine
Wikiseite erstellt. [2]

Selber verwende ich folgende Tools zum bearbeiten der Fehler:
* JOSM mit OpenStreetBugs und OpenStreetMap Notes plugin
* osb_fixing tool siehe [1]
* http://translate.google.de für die Übersetzung von Fehlermeldungen

Ihr könnt natürlich auch alle anderen Tools für die Bearbeitung von
OSB-Fehlern verwenden.

[1] http://www.h-renrew.de/h/osm/osmchecks/09_osb_phaseout/
[2] https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out

Regards
Werner (werner2101)


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

[Talk-de] OpenStreetBugs, bitte helft mit die restlichen Fehler zu beheben.

[Werner Hoch]

Hallo,

im April wurde die Notes Funktion in der OSM-Seite aktiviert.

Viele Anwender verwenden seither Notes (OSN) anstelle von OpenStreetBug
(OSB). Unglücklicherweise werden auch bevorzugt die OSN-Einträge
behoben, sodass immer noch viele offene Fehlerberichte in OSB vorhanden
sind.

Ich versuche deshalb die Verwendung von OSB mit verschiedenen Methoden
abzuschließen:

* Wiki-Seiten zu OSB markieren und auf OSN hinweisen [1]
* Infos zu Apps und Programmen sammeln, die noch OSB verwenden [2]
* dann habe ich mal einen Blogeintrag erstellt, wie den die Ablösung von
OSB aussehen könnte [3]
* dazu habe ich ein paar Statistiken und Graphiken erstellt, welche die
Verteilung der Fehler zeigen [4] ... und ich habe mal angefangen die
Fehler in abgelegenen Gegenden mit nur wenigen Fehlern zu überprüfen und
zu schießen (Afrika, Alaska, Australien).
* dann habe ich noch eine Wikiseite erstellt, auf der noch Ideen zur
Ablösung von OSB gesammelt werden. [5]

Die meisten offenen Fehler befinden sich in Deutschland und Russland:
[DE]15125
[RU]6474
[GB]2740
[US]1586
[IT]1227
[FR]1091
[BE]1068

Insgesamt sind es noch ca. 41000 offene Fehler. (3000 wurden in den
letzten zwei Wochen behoben.)

Ich denke es wäre am sinnvollsten, jetzt noch so viele Fehler wie
möglich zu beheben und veraltete oder bereits behobene Fehlermeldungen
zu schließen.

In zwei Monaten würde ich gerne eine Mapping Party veranstalten, bei der
dann alle noch offenen Fehler nochmals betrachtet und entweder
geschlossen oder zu OSN verschoben werden. s. auch [5].

Bei 15000 Fehlermeldungen sind bestimmt auch ein paar in eurer Nähe
dabei. Schaut euch doch mal die Fehler an und versucht sie zu beheben.

In meiner Gegend liegen auch noch 20 Bugs, die ich mir mal vor Ort
ansehen muss.

Grüße
Werner (werner2101)


[1]https://wiki.openstreetmap.org/wiki/OpenStreetBugs
[2]
https://wiki.openstreetmap.org/wiki/OpenStreetBugs#Tools_for_Using_and_Exporting_Data
[3]http://www.openstreetmap.org/user/werner2101/diary/20213
http://www.openstreetmap.org/user/werner2101/diary/20268
[4]http://www.h-renrew.de/h/osm/osmchecks/09_osb_phaseout/
[5]https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out


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

Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?

[Werner Hoch]

Am Dienstag, den 28.08.2012, 01:42 +0200 schrieb Stephan Wolff:
> Am 27.08.2012 17:11, schrieb Werner Hoch:
> > Hier müsste man nur die Wasserflächen mit auswerten. Ein See hat nunmal
> > meist mehrere Zuflüsse und ein Abfluss. Die Auswertung wird zwar ein
> > bischen komplizierter, aber es ist nicht unmöglich. Ein virtueller
> > Zusammenfluss in einem See vereinfacht natürlich die Auswertung.
> 
> Ein durchgehender virtueller Fluss vereinfacht die Zuordnung deutlich,
> insbesondere wenn mehrere Seen aneinandergrenzen (siehe 5-Seen-Fahrt)
> oder ein See mehrere Ausflüsse hat.
> Man müsste aber virtuelle Flüsse durch ein Zusatztag von normalen
> Flussstrecken unterscheiden.
> 
> >> Bei Kanälen muss man unterscheiden, ob es eine eindeutige Richtung
> >> des Wassers gibt.
> >
> > Das lässt sich mit geeignetem Tagging erledigen.
> 
> Hast du einen Vorschlag dafür? Bei Kanälen mit mehreren Schleusen
> muss man berücksichtigen, dass die Scheitelstrecke zu beiden
> Seiten, die anderen Teilstrecken nur zu einer Seite entwässern.

Wenn der Fluss immer in eine Richtung fließt dann ist die Way-Richtung
ja schon vorgegeben.

Ansonsten ein oneway=no, direction=both, ... 

> >> Eine Auswertung über waterway-Verbindungen ist keinesfalls trivial.
> >> Wenn wir Flusseinzugsgebiete aus den OSM-Daten ableiten wollen,
> >> erscheinen mir explizite Verbindungen über Relationen sinnvoller.
> >
> > Mir nicht. Selbst mit einer einfachen Auswertung (ohne Seen-Auswertung)
> > lassen sich die Einzugsgebiete größtenteils auswerten:
> >
> > http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html
> 
> Die Auswertung sieht schon gut aus, aber es gibt auch einige Fehler.
> In Schleswig-Holstein sind mir folgende Probleme aufgefallen:
> bei Kanälen wird (willkürlich?) eine Flussrichtung angenommen.
> Der Oberlauf der Eider fließt in den Nord-Ostsee-Kanal, der Unterlauf
> aber in die Nordsee. Der Fehler betrifft auch alle Nebenflüsse der
> Untereider.

Bei diesem Spezialfall muss auch ein explizites Relationsmodel (bzw.
dessen Auswertung) einen Fallunterscheidung machen.
Die Darstellung als Baum (wie bei mir in der Übersicht) reicht dann
nicht mehr.

In der Detailauswertung sieht man auch, dass die Eider in den NO-Kanal
fliest und daraus gespeißt wird:

http://www.h-renrew.de/h/osm/osmchecks/07_watershed/de/407956.html

In der Baum-Darstellung ist der Fluss halt nur einmal aufgeführt, weil
ich eine Relation als zusammenhängendes Objekt (Graphen-Knoten)
betrachte.

> Das Wasser der Wakenitz fließt normalerweise durch den Dükerkanal und
> einen Düker unter der Kanal-Trave hindurch in die Trave, nur bei 
> Hochwasser in die Kanal-Trave. Den aktuellen OSM-Daten kann man diese
> Information nicht entnehmen.

Ein Relationsmodell für diesen Fall will ich erst mal sehen.

> Selbst deine "einfache Auswertung" enthält schon mehr Code, als für eine
> rekursive Relationsauswertung nötig wäre. Wieviel Rechenzeit braucht 
> denn ein Durchlauf?

ca. 12h für das planet file.
Kleine OSM-Gebiete z.B. Africa ca. 30 min.

> > Insgesamt erscheint mir der Aufwand der Auswertung sehr viel kleiner als
> > das manuelle Verknüpfen mittels Relationen.
> 
> Auch der Aufwand für explizite Verknüpfungen ist eher klein (ein Element
> pro Gewässer). Wichtiger ist aber die Frage, ob man ohne explizite
> Zuordnungen die Flusseinzugsgebiete korrekt berechnen kann.

Ich denke schon.

Die einzelnen Way-Segmente haben eine Fließrichtung und so können auch
komplexere Flusssystem noch besser ausgewertet werden. Das Problem ist
die Darstellung als Graph (hier ein DAG).
DAG = http://en.wikipedia.org/wiki/Directed_acyclic_graph

Grüße
Werner


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

Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?

[Werner Hoch]

Am Dienstag, den 28.08.2012, 07:08 +0200 schrieb Florian Groß:
> On Mon, Aug 27, 2012 at 05:24:54PM +0200, Werner Hoch wrote:
> > Am Montag, den 27.08.2012, 11:22 +0200 schrieb Peter Wendorff:
> > > Am 27.08.2012 02:57, schrieb Werner Hoch:
> > > > Gerade bei langen Flüssen ist das nicht so einfach.
> > > > Der Name der Flüsse ist u.U. in jedem Land (in der Schweiz in jeder
> > > > Sprachregion) anders.
> > > Dagegen sollte aber üblicherweise helfen, lokalisierte name-Tags 
> > > anzuwenden: name:de, name:fr, name:it - und bei Bedarf eben noch 
> > > name:de_ch oder so - aber das sollte sich doch machen lassen.
> > 
> > Der Aufwand der Tag-Vereinheitlichung und/oder das Erstellen einer
> > Relation ist ungefähr gleich groß.
> > 
> > Die Pflege einer Fluss-Relation ist IHMO einfacher.
> 
> Die ursprüngliche Frage lautete ob es Sinn macht komplette Flussysteme
> inklusive aller Nebenflüsse sowie deren Zuflüsse usw. in eine
> Relation zu werfen und nicht nicht einen einzelnen Fluß von seiner
> Quelle/seinen Quellen bis zur Mündung.

Ich habe hier auf Peters Post geantwortet, nicht auf den OP.

> Und da baust dann schnell eine Monsterrelation zusammen, die sehr
> anfällig für (unbeabsichtigte) Schäden wird.
> Wie willst du solche Relationen intakt halten?
> Das wird in meinen Augen unnötig schwer.

Im Gegensatz zu Wanderwegen, Radrouten, Autobahnen, ... werden Flüsse
sehr selten geändert. Man kann also mit sehr wenigen Relations-Elementen
eine sehr große Strecke überbrücken.

Rhein: 50 Members, Version 140
Donau: 158 Members, Version 124

Wanderwege oder Europastraßen haben nicht selten eine Versionsnummer
über 1000 und auch über 1000 Members.

Zum Vergleich:
ein regionaler Wanderweg in Baden Württemberg: HW9: 720 Members, Version
110 ist schon sehr viel komplexer wie Donau und Rhein zusammen.

Grüße
Werner









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

Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?

[Werner Hoch]

Am Montag, den 27.08.2012, 11:22 +0200 schrieb Peter Wendorff:
> Am 27.08.2012 02:57, schrieb Werner Hoch:
> > Gerade bei langen Flüssen ist das nicht so einfach.
> > Der Name der Flüsse ist u.U. in jedem Land (in der Schweiz in jeder
> > Sprachregion) anders.
> Dagegen sollte aber üblicherweise helfen, lokalisierte name-Tags 
> anzuwenden: name:de, name:fr, name:it - und bei Bedarf eben noch 
> name:de_ch oder so - aber das sollte sich doch machen lassen.

Der Aufwand der Tag-Vereinheitlichung und/oder das Erstellen einer
Relation ist ungefähr gleich groß.

Die Pflege einer Fluss-Relation ist IHMO einfacher.

Weshalb sollen wir uns das mappen unnötig schwer machen?

Grüße
Werner


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

Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?

[Werner Hoch]

Am Montag, den 27.08.2012, 12:03 +0200 schrieb Stephan Wolff:
> Am 27.08.2012 03:51, schrieb Werner Hoch:

> > Um zwei Flüsse zu verbinden muss man nur den waterway mit dem nächsten
> > Fluss verbinden. Das ist viel einfacher als ein Relationsmitglied zu
> > erzeugen.
> >
> > Diese einfache Verbindungen können auch von allen Mappern erzeugt
> > werden, die sich nicht mit Relationen beschäftigen.
> 
> Dafür braucht man Regeln, wie die Verbindungen über Seen, Kanäle, 
> Flussnebenarme etc. herstellt und auswertet. Bei Seen mit mehreren
> Zuflüssen ist ein virtueller Zusammenfluss irgendwo im See nötig.

Hier müsste man nur die Wasserflächen mit auswerten. Ein See hat nunmal
meist mehrere Zuflüsse und ein Abfluss. Die Auswertung wird zwar ein
bischen komplizierter, aber es ist nicht unmöglich. Ein virtueller
Zusammenfluss in einem See vereinfacht natürlich die Auswertung.

> Bei Kanälen muss man unterscheiden, ob es eine eindeutige Richtung
> des Wassers gibt. 

Das lässt sich mit geeignetem Tagging erledigen.

> Flussnebenarme müssen sinnvoll in der Auswertung
> berücksichtigt werden. 

Ist nicht wirklich ein problematisch.

> An Wasserkraftwerken, Pumpwerken oder Dükern
> sind auch Rohrleitungen als Teil eines Flusses möglich.

Die Flüsse lassen sich auch durch Wasserkraftwerke verfolgen.
Unterm Damm von Wasserkraftwerken sind die Flüsse häufig mit dem
Zusatztag tunnel=yes versehen. Aber auch pipelines von
Pumpspeicherwerken ließen sich verfolgen.

> Eine Auswertung über waterway-Verbindungen ist keinesfalls trivial.
> Wenn wir Flusseinzugsgebiete aus den OSM-Daten ableiten wollen,
> erscheinen mir explizite Verbindungen über Relationen sinnvoller.

Mir nicht. Selbst mit einer einfachen Auswertung (ohne Seen-Auswertung)
lassen sich die Einzugsgebiete größtenteils auswerten:

http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html

Insgesamt erscheint mir der Aufwand der Auswertung sehr viel kleiner als
das manuelle Verknüpfen mittels Relationen.


Grüße
Werner




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

Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?

[Werner Hoch]

Am Sonntag, den 26.08.2012, 18:37 +0200 schrieb Tobias Knerr:
> Man mag es für überflüssig halten,
> da es sich prinzipiell berechnen lässt, aber es ist eine denkbare und
> nachvollziehbare Modellierung.

Es ist zwar nachvollziehbar, aber wie bei vielen anderen hierarchischen
Gliederungen lässt sich die Gliederung aus den Geo-Daten ermitteln.

Ein Beispiel für hierarchische Relationen/Beziehungen:

continent --> country --> ...
Auch dafür gabs mal relationen, ein paar sind sicher noch in boundary
oder collection-Relationen vorhanden.

is_in-Tags

> Allerdings wäre es im Sinne der Größe und Wartbarkeit der Relationen
> vielleicht praktikabler, den Hauptfluss als "destination"-Member (o.ä.)
> im Zufluss einzufügen als umgekehrt.

Nicht wirklich. 

Um zwei Flüsse zu verbinden muss man nur den waterway mit dem nächsten
Fluss verbinden. Das ist viel einfacher als ein Relationsmitglied zu
erzeugen.

Diese einfache Verbindungen können auch von allen Mappern erzeugt
werden, die sich nicht mit Relationen beschäftigen.

Grüße
Werner


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

Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?

[Werner Hoch]

Am Sonntag, den 26.08.2012, 18:17 +0200 schrieb malenki:
> Werner Hoch schrieb:
> >Meine Meinung ist, dass die watershed relationen schrittweise durch
> >waterway-relationen (eine pro großem Fluss) ersetzt werden können.
> 
> Die waterway-relationen sind bereits vorhanden.
> Relationen für die Wasserwege braucht es imho aber auch nicht unbedingt.
> Wenn ein Wasserweg ordentlich mit waterway=river und (e.g.) name=Blue
> Nile gemappt ist, kann man ihn auch anhand dieser Werte definieren
> beziehungsweise bequem mit der Overpass-API herunterladen.

Gerade bei langen Flüssen ist das nicht so einfach.
Der Name der Flüsse ist u.U. in jedem Land (in der Schweiz in jeder
Sprachregion) anders.

Grüße
Werner


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

Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?

[Werner Hoch]

Am Samstag, den 25.08.2012, 22:43 +0200 schrieb Norbert Kück:
> > Gerade stolperte ich wieder über ein "exzellentes" Beispiel:
> > http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=de&title=Garonne
> > (Sieht man, wenn man im Wikipedia-Artikel¹ auf "Karte" klickt")
> ...was man an diesem Beispiel schön sieht. Man kann auf der Karte kaum 
> noch ausmachen, wo der Fluss, um den es im Artikel geht, verläuft.

Die Auswertung von WIWOSM sieht es nicht vor die tributary Flüsse nicht
mit darzustellen.

siehe:
http://wiki.openstreetmap.org/wiki/Talk:WIWOSM#selective_traversal_of_nested_relations

Grüße
Werner


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

Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?

[Werner Hoch]

Hallo,

Am Samstag, den 25.08.2012, 19:29 +0200 schrieb malenki:
> Welchen Nutzen hat es, wenn von einem Fluss alle einmündenden Flüsse
> (mit weiteren Rekursionen) in die Relation des erstgenannten Flusses
> gepackt werden?

Dieses mapping haben ein paar user in Frankreich angefangen, damit die
watersheds "einfach" ermittelt werden können.

Der Plegeaufwand der tributaries ist aber irrsinnig hoch.

> Gerade stolperte ich wieder über ein "exzellentes" Beispiel:
> http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=de&title=Garonne
> (Sieht man, wenn man im Wikipedia-Artikel¹ auf "Karte" klickt")

Ist bekannt s. WIWOSM Diskussion:
http://wiki.openstreetmap.org/wiki/Talk:WIWOSM#selective_traversal_of_nested_relations

> Der Wiki-Artikel sagt zum Glück nichts zum Mappen von Zuflüssen als
> role=tributary

Das haben wir in mühsamen Diskussionsrunden verhindert. Im user-raum von
frodrigo hat er seine mapping-Variante dokumentiert:
http://wiki.openstreetmap.org/wiki/User:Frodrigo/Relation:Waterway

> Ähnlich nützlich finde ich watershed-Relationen:
> http://wiki.openstreetmap.org/wiki/Waterways#Watersheds.2FRiver_basins

Mit den watersheds hat user:katpatuka schon sehr früh angefangen und
sind noch vor den waterway relations entstanden.
Ich denke er ist bereit die watershed relations aufzugeben.

Die Pflege von watershed relationen ist sowieso kaum möglich.
Der Missisipi besteht aus mehr als 5 waterway ways.

Eine einfache watershed/basin analyse existiert bereits:
http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html


Meine Meinung ist, dass die watershed relationen schrittweise durch
waterway-relationen (eine pro großem Fluss) ersetzt werden können.

Mit den Franzosen muss man separat diskutieren.

Grüße
Werner


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

Re: [Talk-de] Permanente/stabile OSM IDs!

[Werner Hoch]

Hallo,

Am Sonntag, den 22.07.2012, 21:22 +0200 schrieb Stefan Keller:
> 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs
> "ungewollt/unfreiwillig"?
> 
> Oben wird die Overpass Permanent ID erwähnt
> (http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID ) und
> dort steht: "...you shouldn't use an object ID, because the OSM IDs
> may change at any time." Das würde ich gerne mal näher analysieren:
> 
> Ein klarer Fall für ein Löschen und Neu-Einfügen (mit neuer ID)
> scheint mir zu sein, wenn das auch in der realen Welt der Fall ist:
> Wenn z.B. ein Gebäude abgerissen und neu erstellt wird, oder ein
> wichtiger Einzelbaum gefällt und neu gepflanzt wird.
> 
> Soeben realisiere ich, dass wenn Nodes (mit Tags) lagemässig
> verschoben werden, ein neuer Node mit neuer ID und neuen Koordinaten
> und den "geretteten" Tags erzeugt wird (zumindest in JOSM), während
> dessen alte Koordinaten als "normaler Way-Node zurückbleiben. Das ist
> aber kein logisch zwingender Grund, sondern technischer Mangel.

Dieses Problem lässt sich umgehen, wenn man nicht mit der Version des
Weges arbeitet, sondern zusätzlich mit einem Datum.

Ein way X lässt sich zu jedem Zeitpunkt und immer gleich aus OSM (und
der OSM-Historie) extrahieren.
Dieses Objekt(mit Datum) ist stabil. Diese Information ließen sich
cachen und bei Bedarf gegen die Objekte mit aktuellerem Datum
abgleichen.

Wie kommt man an das Objekt mit ObjektID+Datum?
--> alle referenzierten Objekte mit dem entsprechenden Datum ermitteln.
Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr
aufwändig.

Vor einigen Jahren habe ich mal einen Prototypen geschrieben, der über
die API aus der OSM-DB ein Objekt zu jedem Zeitpunkt ermitteln kann:
Beschreibung:
http://www.h-renrew.de/h/osm/tools/osmhistory.html
Quelltext:
https://github.com/werner2101/python-osm

Anmerkungen:
* Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die  
  Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden.
* Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction
  Bot verändert wurden.

Grüße
Werner



___
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??

[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. http://de.wikipedia.org/wiki/Rhein
> > s. http://de.wikipedia.org/wiki/Deutschland
> >
> > Damit können die geographischen Objekte aus OSM in der Karte in
> > Wikipedia dargestellt werden.

> Den Ansatz andersherum gibt es aber auch, und der wäre genausogut 
> machbar, ohne kuriose Relationen wie "Denkmalgeschützte Häuser in 
> Buxtehude" anlegen zu müssen.
> Der würde auf Seiten von Wikipedia eine Auswertung erfordern, was 
> ebensogut machbar ist.

Ja, WIWOSM zeigt meines Wissens nach alles in der Wiki-Seite an, was
entsprechend vertagged ist.

Es ist egal ob:
  * 1 Relation erstellt wird mit dem Wikipedia Tag
  * alle Einzelelemente mit Wikipeda-Tags versehen werden

Das Ergebnis ist dasselbe.

Dein Vergleich mit den Denkmalgeschützten Häusern hinkt. Sofern die
Denkmäler wichtig sind und eine eigene Wikipedia Seite haben, dann kann
man den entsprechenden Häusern jeweils ihren eigenen Wikipedia-Link
verpassen.

s. Eifelturm

> >>> Der Artikel in WP hat aber durchaus seine Berechtigung (finde ich). Dazu
> >>> gehört dann aber eben ein "[highway=motorway][ref=A*][bbox=...] als Link
> >>> hin.
> >> Für Bundesstraßen wäre es eher [highway=primary][ref=B*][bbox=...] aber
> >> auch das funktioniert nicht korrekt. Für die meisten Artikel in der
> >> Wikipedia kann man keine sinnvolle Koordinate angeben. Das schließt
> >> aber nicht aus, dass es für einige Artikel sinnvolle Links in beide
> >> Richtungen gibt.

> > Hier stellt sich mir nur die Frage, was sich leichter und zuverlässiger
> > verwalten läßt. Eine Relation mit Wikipedia tag oder ein komplexer
> > Ausdruck. Die Bundesstraßen enthalten auch highway=motorway Segmente.

> Wenn aber ein OSM-Mapper die Relation löscht und neu anlegt, kann nach 
> ID auch nicht mehr gefunden werden - schon bricht das Konstrukt zusammen.
> Das neu anlegen gleichbedeutender Relationen passiert aber und ist in 
> OSM auch nicht geächtet oder irgendwie unüblich.

WIWOSM verwendet keine IDs sondern die Wikipedia tags bzw. Interwiki
links. Das Konstrukt funktioniert, solange sich die Bedeutung der
Wikipedia-Seite nicht verändert.

> >>>> Das gleiche gilt natürlich auch für andere lineare Objekte wie Flüsse/
> >>>> Bäche.
> >>> Oberlauf des Rheins, Unterlauf des Rheins, Rhein - wie viele Objekte
> >>> willst du denn explizit formulieren? Oder dann doch wieder nur "Rhein"?
> >> Einen Fluss "Rhein" kenne ich, einen Fluss "Oberlauf des Rhein" nicht.
> >> Die Relation Rhein gibt es schon [1]. Ich erkenne auch hier kein
> >> Problem.
> > Hier kann man sich ja an der Wikipedia orientierten. Dort wird nur der
> > Rhein aufgeführt, also sind die Unterabschnitte nicht so wichtig.
> > s. http://de.wikipedia.org/wiki/Rhein

> Jetzt die Relevanzkriterien der Wikipedia auf OSM zu ziehen, halte ich 
> für falsch.
> Dann sind also Deines Erachtens Relationen anzulegen für:
> * http://de.wikipedia.org/wiki/Liste_von_Fl%C3%BCssen_in_Deutschland - 
> wohlgemerkt "eine Auswahl von"!!!
> * 
> http://de.wikipedia.org/wiki/Denkmalgesch%C3%BCtzte_Objekte_im_Okres_Brezno
> 

Nein, beides sind keine geographischen Objekte, sondern
Listen/Sammlungen/Collection.

Diesen Seiten kann man ebensowenig ein OSM-Objekt zuweisen wie den
begriffen "Goethe", "Mathematik", "Universum", "Metzger", "Bäcker", 


> Sorry, aber da hinkt diese Forderung meines Erachtens sehr stark.
> 
> Wenn aber dafür komplexere Query-Links gebraucht werden, dann kann man 
> das auch für die vermeintlich einfachen Fälle umsetzen.

Der vermeintlich einfache Fall ist, dass sich die Elemente, die zu einer
Wikipediaseite gehören eindeutig identifizieren lassen.

z.B. mit einem eindeutigen wikipedia tag --> das gibts ja schon.

Die Auswertung macht ja schon WIWOSM.

Grüße
Werner


___
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??

[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 der Wikipediaartikel überhaupt von osm aus verlinkt werden
> > sollte, und nicht über eine Art XAPI/Overpass-Query, das ist eine andere
> > GEschichte. IMHO gehört der Link eher in die Wikipedia als in die OSM,
> > weil die ganz andere Objekte enthält als OSM enthalten sollte.

> Der Sinn von Wikipedialinks ist ein anderes Thema, aber wikipedia und
> url/website-Tags werden verwendet.

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. http://de.wikipedia.org/wiki/Deutschland

Damit können die geographischen Objekte aus OSM in der Karte in
Wikipedia dargestellt werden.


> > "Deutsche
> > Bundesstraßen" ist kein OSM-Objekt, sondern eine Sammlung von Objekten.
> +1

+1

> > Der Artikel in WP hat aber durchaus seine Berechtigung (finde ich). Dazu
> > gehört dann aber eben ein "[highway=motorway][ref=A*][bbox=...] als Link
> > hin.
> Für Bundesstraßen wäre es eher [highway=primary][ref=B*][bbox=...] aber
> auch das funktioniert nicht korrekt. Für die meisten Artikel in der
> Wikipedia kann man keine sinnvolle Koordinate angeben. Das schließt
> aber nicht aus, dass es für einige Artikel sinnvolle Links in beide
> Richtungen gibt.

Hier stellt sich mir nur die Frage, was sich leichter und zuverlässiger
verwalten läßt. Eine Relation mit Wikipedia tag oder ein komplexer
Ausdruck. Die Bundesstraßen enthalten auch highway=motorway Segmente.

> >> Das gleiche gilt natürlich auch für andere lineare Objekte wie Flüsse/
> >> Bäche.
> > Oberlauf des Rheins, Unterlauf des Rheins, Rhein - wie viele Objekte
> > willst du denn explizit formulieren? Oder dann doch wieder nur "Rhein"?
> Einen Fluss "Rhein" kenne ich, einen Fluss "Oberlauf des Rhein" nicht.
> Die Relation Rhein gibt es schon [1]. Ich erkenne auch hier kein
> Problem.

Hier kann man sich ja an der Wikipedia orientierten. Dort wird nur der
Rhein aufgeführt, also sind die Unterabschnitte nicht so wichtig.
s. http://de.wikipedia.org/wiki/Rhein

> [1] http://www.osm.org/browse/relation/123924
[2] http://wiki.openstreetmap.org/wiki/WIWOSM


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

Re: [Talk-de] Changeset #10280168 reverten?!

[Werner Hoch]

Hallo,

Am Donnerstag, den 12.01.2012, 00:33 +0100 schrieb Frederik Ramm:
> On 01/11/2012 11:38 PM, Holger Blum wrote:
> >> ich bin der Meinung, der folgende changeset sollte zurückgesetzt werden:
> >> http://www.openstreetmap.org/browse/changeset/10280168
> >
> > Oberförster... :-(
> >
> >> Die falsche Änderung wurde jetzt schon zum zweiten mal gemacht, wie man
> >> an diesem Objekt sehen kann:
> >> http://www.openstreetmap.org/browse/way/53565780/history
> >
> > Das betrifft nicht nur dieses Changeset sondern einige andere auch, wie
> > z.B. 10296167 bei mir um's Eck. Seit Jahren immer wieder der gleiche Mist.
> 
> Der hat offenbar bei hunderten von Ways ein motorroad=yes wieder 
> hinzugefuegt, das von anderen zuvor entfernt worden war. Wer ist denn im 
> Recht? Ist das Stueck B31, das Du oben zitierst, Kraftfahrstrasse oder 
> nicht?

Das Stück ist keine Kraftfahrstraße.

Die Straße war bis vor kurzem auch auf kompletter Länge zwischen Lindau
und Meersburg korrekt getaggt (ich fahre da öfters lang).

Wobei die B31 mal eben eine Kraftfahrstraße ist und mal eine einfache
Bundesstraße. Das wechselt immer mal wieder.

Grüße
Werner


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

[Talk-de] Changeset #10280168 reverten?!

[Werner Hoch]

Hallo,

ich bin der Meinung, der folgende changeset sollte zurückgesetzt werden:
http://www.openstreetmap.org/browse/changeset/10280168

Die falsche Änderung wurde jetzt schon zum zweiten mal gemacht, wie man
an diesem Objekt sehen kann:
http://www.openstreetmap.org/browse/way/53565780/history


Grüße
Werner (werner2101)


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

Re: [Talk-de] warum verliert der Rhein sein Wasser?

[Werner Hoch]

Hallo,
Am Sonntag, den 08.01.2012, 11:57 +0100 schrieb Schorschi:
> da hat auch schon jemand um Hilfe gebeten:
> 
> http://www.openstreetmap.org/browse/changeset/10325594
> 
> kann das evtl. mit den Lücken und/oder der Reihenfolge der Elemente in
> 
> http://www.openstreetmap.org/browse/relation/1706129

Der Rhein hatte hier einige lücken, ich hab das mal gefixed.

Gruß
Werner


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

Re: [Talk-de] Aktive Mapper

[Werner Hoch]

Hallo Markus,

Am Freitag, den 16.12.2011, 12:23 +0100 schrieb Markus:
> Unsere Statistik zählt "über 500'000 Benutzer".
> 
> Aber das sind m.W. nur diejenigen, die einen Account angemeldet haben.
> Das sagt noch nichts über deren Aktivität aus.
> 
> Interessant wäre, wieviele "mitmachen", wieviele Mapper wir sind...

Ich werte hin und wieder den planet und Deutschland aus:
http://www.h-renrew.de/h/osm/osmchecks/03_Statistik/planet/statistic.html
http://www.h-renrew.de/h/osm/osmchecks/03_Statistik/de/statistic.html

In den Auswertungen sind nur die Daten enthalten, die jeweils aktuell
sind.
Mit den Cumulierten Verteilungsstatistiken kann man nette Aussagen
treffen.
* 90% aller Relationen wurden zuletzt von 2000 Mappern editiert.
* 99% aller Wege/Knoten wurden zuletzt von 2 Mappern editiert.


Grüße
Werner


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

Re: [Talk-de] Download von Relationen als KML/KMZ/GPX?

[Werner Hoch]

Hallo,

Am Freitag, den 16.12.2011, 17:21 +0100 schrieb Uwe R. Kunzmann:
> ich hatte vor längerer Zeit bereits einmal das Thema Relation Analyzer 
> angesprochen. Hier konnte man früher ein KMZ-File oder/und GPX-Daten 
> herunterladen - wenngleich auch über den Umweg der Anzeige der Daten bei 
> GoogleMaps. Leider geht das derzeit nicht mehr aus dem Relation Analyzer 
> - obwohl dieser für mich immer noch ein sehr gutes Tool darstellt.
> Frage: Gibt es derzeit eine Möglichkeit, ein KML oder KMZ von einer 
> Relation aus OSM zu exportieren? Leider habe ich bei der Suche keine 
> Möglichkeit gefunden...
> Schon mal vielen Dank vorab!!

Vor längerer Zeit habe ich dazu mal das Tool relation2gpx.py
geschrieben.
Es ist in Bestandteil von https://github.com/werner2101/python-osm
und benötigt neben dem sript tools/relations2gpx.py noch die Basisklasse
src/osm/pyosm.py.

Ich verwende das Tool, damit ich einfach ein paar Wanderwege auf einer
Karte darstellen kann:
http://www.h-renrew.de/h/osm/karten/wanderwege.html

Das Tool sortiert die Wege nicht und kann Relationen auch nicht rekursiv
auflösen.

Grüße
Werner



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

Re: [Talk-de] Kachelnummer

[Werner Hoch]

On Dienstag, 30. August 2011, Wolfgang Wienke wrote:
> Funktioniert bestimmt ganz einfach, nur ich finde es nicht:
> Wie/ Wo bekomme ich zu einen bestimmten GPS-Position/ einem
> bestimmten Ort die Nummer der zugehörigen Kachel der Karte?

http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

Grüße
Werner

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

Re: [Talk-de] Eine Insel im Fluss [Reparaturanfrage]

[Werner Hoch]

Hallo,

On Freitag, 21. Januar 2011, André Reichelt wrote:
> Könnte sich bitte jemand dieser Stelle hier zuwenden: Die Inseln
> werden nicht gerendert obwohl ich nach meinem Kenntnisstand alles
> korrekt gemacht habe. Dem Flusslauf nach Norden folgend ist noch so
> eine Insel.

An der Stelle lagen 3 riverbank multipolygone übereinander, wobei jedes 
eine andere Insel als inner-Rolle hatte. Die outer-Rolle war bei allen 
gleich.

Ich  habe 2 Mutlipolygone gelöscht und die anderen beiden Inseln dem 
verbleibenden polygon hinzugefügt.
Zusätzlich war noch ein Tag am inner-Element ebenfalls riverbank.

Sollte jetzt hoffentlich i.O. sein.

MfG
Werner

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

Re: [Talk-de] Aktion 11 - Verbindungsprobleme in Afrika

[Werner Hoch]

Hallo Gary68,

nachdem die Aktion fast abgeschlossen ist habe ich noch ein paar 
Anmerkungen/Verbesserungswünsche. Eventuell kannst du ja die ein oder 
andere Idee umsetzen:

1. geographische Sortierung der Fehler

Die Sortierung der Fehler hat  folgende Vorteile:
* naheliegene oder übereinanderliegende Fehler können gefixed werden 
ohne das die Region neu über das Remote-Plugin neu geladen werden muss.

* naheliegend Fehler werden liegen in einem Bearbeitungsblock. Damit 
wird die Wahrscheinlichkeit von Konflikten bei der Bearbeitung stark 
reduziert.

* jede Fehlerposition (auch mit vielen Fehlern) wird nur von einem User 
bearbeitet. Gegen Ende der Aktion waren fast 50% aller Fehler bereits 
von anderen behoben worden

* die Korrekturen erzeugen kleinere Changeset-BBoxes
Ohne Sortierung ist auch bei nur wenigen Korrekturen pro Changeset ein 
riesiges Gebiet betroffen.

Hier ein paar Fehler aus C53 die nahezu an derselben Stelle liegen:

ChkTouch - 
90606799/76371634 one way nearly hits another
ChkTouch - 
90606799/76371634 one way nearly hits another
ChkTouch - 
90606810/76371634 one way nearly hits another



ChkTouch - 
30762155/23085585 one way nearly hits another
ChkTouch - 
30762155/31130705 one way nearly hits another
ChkTouch - 
23085585/31130705 one way nearly hits another


Dieser Fehler ist sogar viermal identisch aufgeführt:

ChkTouch - 44584139/44584147 
one way nearly hits another


denkbare Sortiermethoden:
* lat oder lon sortieren
* Sortieren in Streifen:
  round(lat) als erstes Kriterium; lon als zweites
* Mäanderförmig: 
   wie zuvor nur dass jeder zweite Streifen in umgekehrter 
   Richtung sortiert wird.  [1]
* Traveling Salesman ;-)


2. Description Attribut im GPX-File mit Fehlernummer
In C53 wird diese Beschriftung verwendet:
ChkTouch - 88274564/12335472 one way nearly hits another

Die Beschriftungsbestandteile "ChkTouch - " und " one way nearly hits 
another" sind bei allen Fehlern gleich -- und damit überflüssig.

Mein Vorschlag wäre also:
[Fehlernummer] - 88274564/12335472

Damit wäre es auch einfacher den "richtigen" Fehler zu identifizieren 
wenn in einem Gebiet mehrere Fehler sind.

In Kombination mit der geographischen Sortierung können die Fehler sehr 
viel effizienter bearbeitet werden. (mindestens 30%)


[1] Vergleichsfunktion für Mäandersortierung (python)
Meine Streifen sind aufgrund des factor=5 nur 0,2 Grad breit.
---
def cmp_maeander(a,b):
"""
compare function for meander sort
when the nodes are fixed in this order, the changsets will be small
"""
ax, ay = a
bx, by = b
factor = 5

cmp_row = cmp(int(factor*float(ay)), int(factor*float(by)))
if cmp_row == 0:
direction = (int(factor*float(by)) % 2) * 2-1
return direction * cmp(float(ax), float(bx))
else:
return cmp_row


Grüße
Werner (werner2101)

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

Re: [Talk-de] Weg zur Nutzung von OSM-Daten

[Werner Hoch]

Hallo Marten,

On Sonntag, 12. Dezember 2010, Marten Karl wrote:
> Nun, meinen Kleinkram schreibe ich zumeist mit Python, da stehen mir
> auch entsprechende Tools direkt zur Verfügung. Allerdings habe ich
> hier bisher sehr erfolgreich das ElementTree-Modell verwendet. Das
> lädt aber den ganzen Baum in den Speicher. Im Falle einer einzelnen
> extrahierten Relation ist das möglich, aber eine Kiste bei der das
> mit europe.osm funktioniert steht mir leider nicht zur Verfügung.

Da du python verwendest, dann kannst du dir auch mal meine tools auf 
github ansehen: https://github.com/werner2101/python-osm

Mit dem skript src/osmdb.py kannst du über eine API auf Objekte in 
einer osm-Datei zugreifen. Die Größe der OSM-Datei ist egal, da die 
Objekte über eine binäre Suche lokalisiert werden.

Beispiel: Server mit einer (unkomprimierten) osm-Datei starten:
  src/osmdb.py --server=1234 osm_files/bw.osm
Relation vom server localhost abfragen:
  wget -OLK_RV.sm 
http://localhost:1234/relations?relations=62570\&mode=recursive

Die Abfrage von localhost kannst du auch mit python (urllib,...) oder 
aus dem Browser machen.

Mit dem skript tool/relation2gpx.py kannst du aus einer Relation eine 
gpx-Datei erzeugen. Die Way-Elemente werden allerdings als einzelne gpx 
track-Segmente abgespeichert.

Grüße
Werner

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

Re: [Talk-de] xybot kann sich nicht zwischen Schweiz und Deutschland entscheiden

[Werner Hoch]

Hallo Florian,

On Samstag, 27. November 2010, Florian Gross wrote:
> Am Freitag 26 November 2010, 20:53:34 glaubte Werner Hoch zu wissen:
> > Ein Fundstück zum Schmunzeln:
> > http://www.openstreetmap.org/browse/relation/1279148/history
> 
> Es gibt noch weitere solche Straßen. Nur daß bei denen die
> Versionsnummer teilweise 3 oder sogar schon vierstellig ist und
> der xybot für eine große Zahl der Änderungen verantwortlich ist.

Also vierstellige Versionsnummern kommen wirklich selten vor:
http://www.h-renrew.de/h/osm/osmchecks/03_Statistik/planet/statistic.html
(s. zweite Diagrammzeile)

Meiner Ansicht nach werden die wirklich großen Versionsnummern von 
Potlach im Live-Modus verursacht.

z.B. bei dieser Relation sind die ersten 185 Versionen an 2 Tagen entstanden.
Insgesamt hat die Relation 222 Versionen.

http://www.openstreetmap.org/browse/relation/451726
http://osm.virtuelle-loipe.de/history/?type=relation&ref=451726

> Ich finde das nicht mehr zum schmunzeln, teilweise wird es
> praktisch unmöglich, Änderungen nachzuvollziehen, die nicht von dem
> Bot kommen.

Grüße
Werner

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

[Talk-de] xybot kann sich nicht zwischen Schweiz und Deutschland entscheiden

[Werner Hoch]

Ein Fundstück zum Schmunzeln:
http://www.openstreetmap.org/browse/relation/1279148/history

Grüße
Werner

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

Re: [Talk-de] OSM Statistik gesucht - Editierfrequenz von Tags

[Werner Hoch]

On Freitag, 8. Oktober 2010, Christoph Wagner wrote:
> Am 07.10.2010 22:19, schrieb Jochen Topf:
> > On Wed, Oct 06, 2010 at 03:43:29PM +0200, Christoph Wagner wrote:
> >> Wie häufig werden bereits existierende Informationen wieder
> >> verändert?
> > 
> > Nodes haben im Durchschnitt ca. 1.5 Versionen, Ways ca. 1.7 und
> > Relations ca. 3.5.

Das gilt für den planet, die Werte sind regional sehr unterschiedlich.
Deutschland hat z.B.
Nodes=1,8  Ways=2,5  Relations=7,6

Meine Statistiken:
Deutschland:
http://www.h-renrew.de/h/osm/osmchecks/03_Statistik/de/statistic.html
Planet:
http://www.h-
renrew.de/h/osm/osmchecks/03_Statistik/planet/statistic.html

Für eine ausführliche Auswertung müsste man sicher auch noch alle 
Objekte betrachten die gelöscht worden sind.

Eine einfachere Auswertung ohne history wäre:
Wie häufig wurde ein Objekt geändert, das aktuell ein tag "x=y" trägt?
Bei nodes zusätzlich:
Wie häufig wurde ein Objekt geändert, das kein tag hat?

Grüße
Werner

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

Re: [Talk-de] Relation runterladen?

[Werner Hoch]

Hallo Rainer,

On Mittwoch, 6. Oktober 2010, Rainer Kluge wrote:
> Am 05.10.2010 19:16, schrieb Carsten Gerlach:
> > Lässt sich das so erweitern, daß man als Quelle eine lokale
> > osm-Datei (z.B. germany.osm) verwenden kann, aus der die Relation
> > extrahiert wird?
> 
> Das wäre machbar aber äußerst ineffizient. Die osm-Dateien sind reine
> Textdateien im XML-Format. Will man die Wege und Knoten einer
> Relation aus einer solchen Datei auslesen, dann muss man die
> komplette Datei lesen.

Nein. Geht man davon aus, dass die Objekte in der osm-Datei sortiert 
sind, dann kann man per binärer Suche die richtigen Objekte raussuchen.
 
> Ein XML-Parser, den ich für die sauberste Lösung halte, stößt da
> schon bei Bundesland-Dateien an Speichergrenzen, von der Rechenzeit
> ganz zu schweigen. Dieses Verfahren habe ich probeweise
> implementiert, und es funktioniert bei kleinen osm-Dateien für ein
> Gebiet mit etwa 20x20 km Seitenlänge gut. Aber schon bei der
> baden-wuerttemberg.osm.bz2 bekomme ich einen out-of-memory-Fehler.

Das ist nur der Fall wenn du versuchst ein ganzes XML-File im Speicher 
zu halten. Mit einem Streaming-Parser muss man nur die nötigsten Infos 
im Speicher halten.
 
> Als Alternative könnten die Daten mit dem Perl-Modul OSM::osm
> ausgelesen werden. Da die Knoten, Wege und Relationen in dieser
> Reihenfolge in der osm-Datei liegen, müsste die Datei dreimal
> durgegangen werden, einmal, um die Relation(en) zu finden, dann die
> zugehörigen Wege und zuletzt die zugehörigen Knoten. Das wäre wohl
> speichermäßig unproblematisch aber ebenfalls sehr zeitaufwendig.
> Ausserdem müsste ich die gesamte Programmlogik ändern.

Hier wäre wie vorher beschrieben ein Programm toll, das einen Stream in 
umgekehrter Reihenfolge erzeugt (Relationen, Ways, Nodes).

Grüße
Werner

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

Re: [Talk-de] Relation runterladen?

[Werner Hoch]

On Dienstag, 5. Oktober 2010, Carsten Gerlach wrote:
> Am Montag 04 Oktober 2010 schrieb Rainer Kluge:
> > In einer Zeit, als der Realtion Analyzer extrem langsam war, habe
> > ich mal ein Perl-Skript gebastelt, welches zu einer Relation-Id
> > den GPX-Track erzeugt.
> 
> Tolle Sache, gefällt mir, vorallem das verschachtelte Relationen
> komplett runtergeladen werden. :-)
> 
> Lässt sich das so erweitern, daß man als Quelle eine lokale osm-Datei
> (z.B. germany.osm) verwenden kann, aus der die Relation extrahiert
> wird?

Vor einiger Zeit gabs dazu mal einen Thread:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg71643.html
(lokaler Webserver, der OSM-ähnliche API-Zugriffe auf eine lokale OSM-
Datei zulässt). Der Webserver 

Im Angebot habe ich nur den Zugriff auf einzelne OSM-Objekte, keinen 
rekursiver Zugriff auf Objekte, wie für komplette Relationen 
erforderlich wäre.

Den Zugriff auf unkomprimierte osm-Dateien wollte ich auch mal einbauen, 
Im Moment würde mir das aber nichts bringen, weil ich nicht genug 
Plattenplatz für einen unkomprimierten planet habe.
 
> Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei
> ensteht.
> 
> Wäre super wenn das umsetzbar wäre. :-)

Hier sollte man den umgekehrten weg gehen. Relation zuerst aus der OSM-
Datei extrahieren und dann in GPX umwandeln.


Weitere Idee:
Ein Tool, dass die OSM-Datei in umgekehrter Form direkt aus einer bz2-
Datei streamt. (Relationen, Ways, Nodes)

Den Stream kann man dann mit einem Streaming-Parser (SAX) 
weiterverarbeiten ohne das man massenhaft Speicher benötigt.
Für alle Probleme bei denen man zuerst die Relationen benötigt muss man 
die Datei nur noch einmal parsen.

Link zu meinem Repo:
http://github.com/werner2101/python-osm

Grüße
Werner

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

Re: [Talk-de] (Perl)-Tool für die Relationsauflist ung

[Werner Hoch]

Hallo Jan,

On Samstag, 25. September 2010, Jan Tappenbeck wrote:
> Am 25.09.2010 08:35, schrieb Gary68:
> > http://wiki.openstreetmap.org/wiki/Relation_lists

Die hierarchischen Listen hier [1] mache ich mit einem python-skript 
[2], in die auch eine Filterung eingebaut werden kann [3].

Damit kann man nach belieben die OSM-Objekte vorfiltern bevor man die 
OSM-Objekte oder die Tags zu listen oder html-Ausgabe weiterverarbeitet.

Ergebnisse sehen z.B. so aus:
http://www.h-
renrew.de/h/osm/osmchecks/02_Relationstypen/planet_street.html

Hier wurden alle Relationen ausgefiltert, die etwas mit street, 
related_street, associatedStreet,  zu tun haben.

> > On Fri, 2010-09-24 at 21:49 +0200, o...@tappenbeck.net wrote:
> >> immer wieder kommt es vor das man nur mal eben die Namen aller
> >> Wegerelationen oder Gemeinde-Borders brauch. Dann mal eben
> >> auflisten und schon kommt man schneller ans Ziel.
> >> 
> >> Weiß einer von Euch ob soetwas irgendwo verfügbar ist ??

[...]
 
> aber damit kann ich vermutlich keine vorfilterung nach site,
> multipolygon, wanderweg, icw, vornehmen?

s. oben

Grüße
Werner

[1] http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/index.html

[2] http://github.com/werner2101/python-osm

[3] Filterfunktion für street-ähnliche relationen:

def street_relations_filter(object):
streetset = set(['street', 'relatedStreet', 'associatedStreet', 
'address', 'street_number'])
if type(object) == pyosm.Node:
return False
elif type(object) == pyosm.Way:
return False
elif type(object) == pyosm.Relation:
k = set(object.tags.keys())
if k & streetset:
return True
v = set(object.tags.values())
if v & streetset:
return True
return False
return True


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

Re: [Talk-de] Fragen zu einer Wanderrelation

[Werner Hoch]

Hallo Nop,

On Samstag, 28. August 2010, NopMap wrote:
> Generell ist die Mehrheit der Wanderrouten mit route=foot getaggt und
> dementsprechend mache ich es auch so. Bei der Auswertung gibt es
> keinen Unterschied.

Die Mehrheit ist mit route=hiking gemappt
route --> hiking: 9600 mal
route --> foot: 4800 mal

hiking wird ungefähr doppelt so häufig verwendet wie foot.

http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet.html

Grüsse
Werner


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

Re: [Talk-de] seek (perl) in osm dateien

[Werner Hoch]

Hallo gerhard,

On Dienstag, 27. Juli 2010, Gary68 wrote:
> mir war so, als hätte mal jemand ein paar routinen geschrieben, um
> mit einem file handle schnell an bestimmte stellen in osm files zu
> gelangen. also zum start der ways oder dem start der relations im
> speziellen. hat jemand einen tip, wo?

Ich hab nur python im Angebot:
http://github.com/werner2101/python-osm

Das Skript src/bz2osmdb.py kann direkt bz2-komprimierte osmfiles lesen.
Die Suche von Objekten erfogt über binäre Suche des richtigen bz2-blocks 
gefolgt von einer linearen Suche des richtigen Objektes.

Im Moment verwende ich das Skript praktisch nur zum abschneiden 
der Relation von OSM-Dumps.

Es hat noch einen server modus, mit dem lassen sich einzelen 
osm-objekte auslesen:

  python-osm> src/bz2osmdb.py --server= 
../../osm_files/planet-recoded.osm.bz2

Die Indizierung der bz2-Block dauert beim Start ungefähr 2 Minuten.

Danach kann man über die http-Requests die objekte abrufen:
   http://localhost:/ways?ways=27789814,27789843,28072063,27788612


Der Code ist nicht sonderlich gut getestet.

Der bz2-Zugriff auf die planet-files geht nur mit recomprimierten
planet-files.  (s. issue: http://bugs.python.org/issue1625)

Grüße
Werner


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

Re: [Talk-de] Jogging-Rundstrecken

[Werner Hoch]

Hallo Thomas

On Mittwoch, 9. Juni 2010, Thomas Ineichen wrote:
> > hast du dich gerade als Freiwilliger gemeldet, der das genaue
> > Tagging für Trimm-Dich-Pfade ausarbeiten will?
> 
> *grummel* ;)
> http://wiki.openstreetmap.org/wiki/Tag:route%3Dfitness_trail

;-)

Ich hab mal die Diskussionsseite erweitert:
http://wiki.openstreetmap.org/wiki/Talk:Tag:route%3Dfitness_trail

> > Wie die einzelne Station zu taggen ist muss aber auch noch
> > definiert werden.
> > Auf http://wiki.openstreetmap.org/wiki/Key:sport sehe ich spontan
> > kein passendes Tag für einen Trimmdich-Pfad-Station.
> > sport=gymnastic und sport=misc scheint mir nicht ganz passend.
> > Wie wär's mit sport=fitness_trail_station? Oder ist dieser Tag-Wert
> > zu lang?
> 
> Oder sport=exercise?

Hört sich auch gut an, ich frage mich nur ob exercise eindeutig genug 
ist.
 
> > Viele Trimmdichpfade verstecken sich derzeit noch unter type=route
> > route=foot.
> 
> Oder route=nordic_walking.
 
> > Welche Routen soll den das denn das Tag running beschreiben?
> > Trimmdichpfade? Oder Marathonstrecken? Hier gibts auch noch
> > permanent ausgeschilderte Halbmarathonstrecken.
> 
> Auf  Trimm-Dich-Pfaden  gibt's  doch  auch  Übungen? (Die Firma
>  Müller lässt  die  Bewegung übrigens gerade wieder aufleben:
>  www.trimmy.de ).
> 
> Ein  typisches  running-Beispiel  wäre  für  mich  die  Finnenbahn 
>  im Irchelpark:
> http://www.hotel-coronado.ch/www.hotel-coronado.ch/upload/textbild/Ir
> chelpark.jpg
> 
> (ca. 1 km lang, Holzschnitzel, keine Spaziergänger erlaubt)
> 
> Aber  auch  die ausgeschilderte Halbmarathon-Strecke oder ähnliches
>  wo man 'nur' rennt.

diese Marathonstrecken könnte man auch als Unterklasse von running 
taggen:
type=route
route=running
running=[marathon, half-marathon]

> Natürlich  kann  man  eine Fitness-Trail-Strecke auch rennen, ohne
>  die Übungen  zu  machen und daher wäre auch eine Relation mit
>  type=running und  additional_exercises=yes  möglich.  Zumindest hier
>  in der Schweiz sind  sie allerdings so verbreitet, dass ein eigener
>  Type mMn gerecht- fertigt ist.

Yup. Hier befindet sich auch in jedem zweiten Wald ein Trimmdichpfad.

Grüsse
Werner

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

Re: [Talk-de] Jogging-Rundstrecken

[Werner Hoch]

Hallo Thomas,

hast du dich gerade als Freiwilliger gemeldet, der das genaue Tagging 
für Trimm-Dich-Pfade ausarbeiten will?

On Dienstag, 8. Juni 2010, Thomas Ineichen wrote:
> > Also Trimm-dich-Pfade gibt es noch, von einem zumindest weiss ich
> > das ganz sicher. Allerdings macht der nicht mehr unbedingt den
> > gepflegtesten Eindruck.
> 
> Ja, ein paar wenige findet man hier:
> http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de/de1f1af31
> 383c2c2.html

Zu allen kommt man über die Einstiegsseite:
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/index.html
 
> > wohl aber nicht die Strecke das entscheidende (so lang ist der
> > nicht, gerade mal einige hundert Meter), sondern interessanter
> > waeren die einzelnen Stationen. Gibt es dafuer eine ueblich
> > Erfassung?
> 
> Hier wird als Rolle stop_ empfohlen:
> http://wiki.openstreetmap.org/wiki/EN:Switzerland/Parcoursvita
> (Den Link hatte ich vorhin vergessen.)

Die Mischung von Rolle und Nummer finde ich nicht gut.
 
> Manche Relationen verwenden aber auch 'station':
> http://www.openstreetmap.org/browse/relation/285910

In dieser Relation ist die Nummer als ref= Tag auf dem Knoten der 
einzelnen Station.
Wie die einzelne Station zu taggen ist muss aber auch noch definiert 
werden.
Auf http://wiki.openstreetmap.org/wiki/Key:sport sehe ich spontan kein 
passendes Tag für einen Trimmdich-Pfad-Station.
sport=gymnastic und sport=misc scheint mir nicht ganz passend.
Wie wär's mit sport=fitness_trail_station? Oder ist dieser Tag-Wert zu 
lang?

> [Es  läuft  ja  meistens  so  -  solange  etwas  nicht gerendert
>  wird, entwickelt sich auch kein einheitliches Tagging-Schema.]

Das kann sich schnell ändern, wenn ein Taggingschema mal sauber 
definiert ist, dann wird es auch zum Taggen verwendet.
Und wenn es verwendet wird, dann wird es auch irgendwann gerendert oder 
jemand macht eine Spezialkarte.

Viele Trimmdichpfade verstecken sich derzeit noch unter type=route 
route=foot.

>  Momentan läuft gerade ein Render-Durchgang, bei dem auch
>  route=running gezeichnet  wird.  Die Stationen kommen dann in einem
>  nächsten Schritt drann.

Welche Routen soll den das denn das Tag running beschreiben?
Trimmdichpfade? Oder Marathonstrecken? Hier gibts auch noch permanent 
ausgeschilderte Halbmarathonstrecken.

Grüße
Werner


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

[Talk-de] Tag-Auswertung für Relationen

[Werner Hoch]

Hallo allerseits,

für alle, die noch nicht genug von den Tag-Statistiken haben, hier meine 
Auswertung der Relationstags.

http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/index.html

Die Auswertung wurde für verschiedene Regionen gemacht.
Eine Auswertung besteht aus einer kurzen Statistik, einer Textdatei mit 
selten verwendeten Relation und einer Tabelle.

In einer Zeile sind jeweils alle Relationen zusammengefasst, die sich 
ausgehend vom type-Tag hierarchisch zusammengliedern lassen.

z.B. hier die Seite von Thüringen:
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de_th.html


Die erste Spalte der Tabelle enthält jeweils einen Link zu einer zweiten 
Auswertung. Hier werden alle weiteren Tags dieser Zeile zunächst als 
Statistik und anschließend in einer Tabelle dargestellt.

z.B. alle Wanderwege mit type=route, route=hiking:
http://www.h-
renrew.de/h/osm/osmchecks/02_Relationstypen/de_th/e7fb5f3115ae14bd.html


Verwendung der Textdateien:
Die Textdateien mit seltenen Relationen oder ohne type-Tag 
(rare_relations.txt) eignen sich für die Weiterverwendung in einer 
Tabellenkalkulation (oocalc, excel, ...).
In oocalc verwende ich mehrere Makros mit denen ich aus einer markierten 
Zelle die Relationen entweder mit josm laden kann, oder aber auf die 
browse Seite von openstreetmap.org springen kann. Somit kann man schnell 
die Fehler in den Relationen reparieren und ggf. die Fehlerursache in 
der object history ermitteln.

Die häufigsten Fehler sind:
* Tipfehler in den Tags (multipoligon, multipolgyon, ...)
* Tag type=multipolygon fehlt
* Tag type=restriction fehlt
* leere Relationen (ohne Member)
* Relation mit einem Member ohne jegliche Tags
* Relation mit einzelnem Way- oder Node-Tag.
  (hier kann man davon ausgehen, dass das Tag eigentlich dem Object
   gehört)

Die Auswertungen von Deutschland will ich vorerst einmal pro Woche 
aktualisieren. Die Auswertung des planets eher seltener. Die anderen 
Länder nur sporadisch.

Grüße
Werner (werner2101)

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

Re: [Talk-de] Wiki: Skipisten - Langlaufloipe

[Werner Hoch]

Hallo Markus,

On Sonntag, 14. Februar 2010, Markus wrote:
> Wie kann ich die Attribute von einer Relation auf eine andere kopieren?

geht wie bei Ways und Nodes:
* Relation aus der Relationsliste auswählen (Button oder Doppelklick)
* Kopieren
* zweite Relation aus der Relationsliste auswählen
* Merkmale einfügen

Grüße
Werner

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

Re: [Talk-de] ref-Tags in Relationen und Wegsegmenten

[Werner Hoch]

Hallo Simon,

On Freitag, 12. Februar 2010, Simon Kokolakis wrote:
> gibt es irgendeinen Grund warum man die ref-Tags der einzelnen 
> Wegsegmente zusätzlich zum ref-Eintrag in der Relation beibehält?
> Die Unfähigkeit mancher Renderer dies korrekt darzustellen sehe ich 
> nicht als Grund.

Die Frage habe ich irgendwann im Frühjahr letzten Jahres 
auch gestellt. Damals war ich noch der Meinung, dass die refs 
an den Wegen unnötig wären.

Mittlerweile bin ich eher für doppelte ref Tags. Damit
lässt sich die Konsistenz der Relationen überprüfen.
Für Baden-Württemberg habe ich hier eine halbwegs
aktuelle Auswertung der Referenztags:
http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/relationenindex.html

Grüße
Werner

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

Re: [Talk-de] Auswertung von Relationstags

[Werner Hoch]

Hi,

die Links zu den Auswertungen haben sich geändert und alle Links müssten
jetzt funktionieren.

On Sonntag, 17. Januar 2010, Werner Hoch wrote:
> Die Auswertung habe ich für verschiedene Gebiete laufen lassen:
> Baden-Württemberg: (von heute)
> http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de_bw_index.html

http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de_bw.html
 
> Deutschland: (von gestern)
> http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de_index.html

http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de.html

> Planet: (latest)
> http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet_index.html

http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet.html

Grüsse
Werner

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

Re: [Talk-de] Relationen aus osm-Dateien herausfiltern

[Werner Hoch]

Hallo Steffen,

On Dienstag, 19. Januar 2010, Steffen Wolf wrote:
> > Werner Hoch wrote:
> >> Derzeit verwende ich folgenden Workaround:
> >> 
> >> bzip2 -dc bw.osm.bz2 | head -n 3 > bw_relations.osm
> >> bzip2 -dc bw.osm.bz2 | grep -A 10 "> bw_relations.osm
> >> 
> 
> bzcat bw.osm.bz2 | sed -n -e '1,3p' -e '/bw_relations.osm
> 
> -n: gib nix aus
> -e: was folgt ist Befehl und nicht Datei
>   1,3p: gib Zeilen 1-3 aus
> /suche/,$p: gib ab Suchergebnis bis letzter Zeile alles aus
> '': die bash zerpflueckt sonst das $

Cool, danke.

Ich habe mal grep und sed verglichen:
wer...@linux-m82i:~/osm> time bzcat bw.osm.bz2 | grep -A 10 "> 
/dev/null
real0m55.945s
user0m50.408s
sys 0m5.564s

wer...@linux-m82i:~/osm> time bzcat bw.osm.bz2 | sed -n -e '1,3p' -e 
'/> /dev/null
real1m33.072s
user1m48.933s
sys 0m5.316s

sed ist deutlich langsamer.

> Der Speicherverbrauch scheint sich im Rahmen zu halten, also
> Groessenordnung eine Zeile.

Das war zu erwarten.

Grüße
Werner

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

Re: [Talk-de] Relationen aus osm-Dateien herausfiltern

[Werner Hoch]

On Sonntag, 17. Januar 2010, Sven Geggus wrote:
> Frederik Ramm  wrote:
> 
> > Eine krude Form mit "sed" ginge so:
> > 
> > bzcat bw.osm.bz2 | sed -e "1,/ bla.osm
> > 
> > wobei Dir das die allererste "relation"-Zeile verschluckt, und ich bin 
> > nicht sed-Wizard genug, um es besser zu koennen ;-)
> 
> Das kann man doch viel schöner mit xmlstarlet machen. Einfach nodes
> und ways rauslöschen:
> 
> xmlstarlet ed -d "//node" -d "//way" foo.osm

Genau der Befehl ging bei mir nicht. Das Programm hat nur 
meinen Speicher vollgeschrieben.

Grüße
Werner



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

[Talk-de] Relationen aus osm-Dateien herausfiltern

[Werner Hoch]

Hi,

für meine Relationsauswertung muss ich die Relationen aus
den osm-Dateien herausfiltern.

Derzeit verwende ich folgenden Workaround:

bzip2 -dc bw.osm.bz2 | head -n 3 > bw_relations.osm
bzip2 -dc bw.osm.bz2 | grep -A 10 "> bw_relations.osm


Getestet habe ich auch die --tag-filter Funktion von osmosis, 
aber ich bekomme nur eine Fehlermeldung:
-
> osmosis --read-xml file=bw.osm.bz2 --tag-filter reject-ways --tag-filter 
> reject-nodes --write-xml file=rel.osm
17.01.2010 13:53:51 org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.32
17.01.2010 13:53:53 org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
17.01.2010 13:53:53 org.openstreetmap.osmosis.core.Osmosis main
SCHWERWIEGEND: Execution aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Task type tag-filter 
doesn't exist.
at 
org.openstreetmap.osmosis.core.pipeline.common.TaskManagerFactoryRegister.getInstance(TaskManagerFactoryRegister.java:60)
at 
org.openstreetmap.osmosis.core.pipeline.common.Pipeline.buildTasks(Pipeline.java:50)
at 
org.openstreetmap.osmosis.core.pipeline.common.Pipeline.prepare(Pipeline.java:112)
at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:79)
at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30)
-
Die tag-filter aktion müsste lt. Dokumentation funktionieren:
http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--tag-filter_.28--tf.29

Ist in mein Kommando fehlerhaft?


Getestet habe ich dann noch xmlstartlet http://xmlstar.sourceforge.net/.
> bzip2 -dc bw.osm.bz2 | xml ed -d "//node" -d "//way" >out.osm
Das Programm benötigt aber zuviel Speicher.


Hat jemand eine Idee, wie die Filterung einfacher erfolgen kann?

Oder hat jemand zufällig die Daten der Datenbanktabelle
"current_relation_tags" oder einen planet-Auszug der nur die Relationen enthält?

Grüße
Werner

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

[Talk-de] Auswertung von Relationstags

[Werner Hoch]

Hi,

ich habe mir ein Script für die Auswertung von Relations tags geschrieben.
Die Auswertung soll ähnlich wie tagwatch die verwendeten Tags auflisten.

Die tags wurden hierarchisch sortiert:
   type=enforcement, enforcement=maxspeed, maxspeed=50
wird vereinfacht geschrieben zu:
   
enforcement --> maxspeed --> 50


Die Auswertung habe ich für verschiedene Gebiete laufen lassen:
Baden-Württemberg: (von heute)
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de_bw_index.html
(die Links auf der Seite funktionieren nicht)

Deutschland: (von gestern)
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/de_index.html
Von dieser Seite aus können Tabellen weiteren Auswertungen
und der Auflistung der Relationen der Kategorie aufgerufen werden.

Planet: (latest)
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet_index.html
(die Links auf der Seite funktionieren nicht)

Die Farben der Seiten teilweise mit Hilfe dieser Wiki-Seite ermittelt:
http://wiki.openstreetmap.org/wiki/Relations

Die Zuordnung ist nicht komplett und erst ein Anfang.

Mit Hilfe der Auswertung können auch Tippfehler, ... in den Tags
gefunden und manuell korrigiert werden.

Die Auswertung von Deutschland will ich einmal pro Woche aktualisieren.

Bei breiterem Interesse müsste die Auswertung zu einem anderen WebHoster
verschoben werden.

Grüße
Werner

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

Re: [Talk-de] Probleme mit SPLITTER

[Werner Hoch]

Hallo,

On Samstag, 9. Januar 2010, Jan Tappenbeck wrote:
> Kann mir einer die Meldung erklären bzw. hat einer etwas
>  vergleichbares feststellen können - Lösungansatz ?

Ich hab keine direkten Probleme, im Ausschnitt von Baden-Württemberg [1] 
sind seit heute aber ein paar Relationen mit mehreren Versionen 
enthalten.


17324085:  
17324086-
17324087-
17324088-
17324089-
17324090-
[...]
17324902:  
17324903-
17324904-
17324905-
17324906-
17324907-
[...]
17325719:  
17325720-
17325721-
17325722-
17325723-
--

hier sind also 3 Versionen einer derselben Relation enthalten.

Relation 61680 ist sogar in 6 Versionen in der Datei enthalten.
---
17383925:  
17383926-
17383927-
17383928-
17383929-
[..]
17384010:  
17384011-
17384012-
17384013-
--

[1] http://download.geofabrik.de/osm/europe/germany/baden-
wuerttemberg.osm.bz2

Grüße
Werner

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

Re: [Talk-de] Relationen in Baden-Württemberg aufr äumen?

[Werner Hoch]

On Dienstag, 5. Januar 2010, SLXViper wrote:
> Werner Hoch schrieb:
> > Die type-Tags halte ich allein deshalb für enorm wichtig, damit man
> > das taggingschema herausfinden kann.
> 
> Stimmt eigentlich. Ich hab die jetzt mal ergänzt und vereinheitlicht.
> Villingen und Umland bis Furtwangen und das Urachtal sollten sauber
>  sein. Vorerst hab ich mal type=public_transport für alle
>  "Oxomoa-Relationen" benutzt. Die Linien und Linienvarianten haben
>  jetzt zusätzlich public_transport=line bzw. line_variant.

Coole Sache. Das hat die Zahl der Relationen ohne type-Tags von 230 auf 
84 reduziert.

Ich hab jetzt mal Oxomoa kontaktiert, und warte mal auf seine Antwort.

Meine Mail an Oxoma:

Hallo Oxomoa,

in deinen Konzepten zum public_transport-Tagging wird das type-Tag
von Relationen nicht vorgegeben. Dies führt in der Praxis zu einem sehr
unterschiedlichen Tagging der public_transport Relationen.

Könntest du für die Relationen rund um public_transport eine Empfehlung
für das type-Tag abgeben?

Die Vorgabe (oder Empfehlung) würde das Mapping von neuen Relationen 
vereinfachen
und die bestehenden Relationen könnten entsprechend vereinheitlicht 
werden.


Mögliche type-Tags wären IHMO:
type=public_transport für alle Relationstypen (stop_area, 
stop_area_group, line, line_variant)
Dies würde zu folgender Hierarchie führen:
public_transport:
  stop_area
  stop_area_group
  line:
bus
tram
...
  line_variant
???

Eine Buslinie würde man dann mit folgenden Tags mappen:
  type=public_transport, public_transport=line, line=bus

Alternativ könnte für line eine separate Gruppe gebildet werden:
public_transport:
  stop_area
  stop_area_group
  line_variant
???
line:
  bus
  tram
  ...

Eine Buslinie würde man dann mit folgenden Tags mappen:
  type=line, line=bus


Ich habe mal die Tags für Baden-Württemberg ausgewertet. Diese 
Auswertung
wurde durchgeführt nachdem Mapper SLXViper bereits viele Relationen 
korrigiert hat:

Filtertag: "type=public_transport" Statistiktag: public_transport
   806 stop_area 
81 stop_area_group   
24 line_variant  
12 line  
 7   
 1 stop_site 
 1 network

Das bereits häufig verwendete type=public_transport tag führt bis auf 
wenige Ausnahmen
zu einem sehr sauberen tagging.

Sieht man sich die umgekehrte Auswertung an, so wird public_transport 
mit vielen 
verschiedenen type-Tags verwendet. Die Haltestellen (stop_area und 
stop_area_group)
werden noch zu häufig ohne type-Tag bzw. mit type-Tag site gemappt.

Filtertag: "public_transport=..*" Statistiktag: type
   925 public_transport 
26 site 
24  
 3 public_transport_stop
 2 collection   
 2 line 
 1 network  
 1 public_transport_stop_group


Beim Tagging der Linien ist das Tagging noch uneinheitlicher.
Während die das type=line zu einer sehr schönen line=Verkehrsmittel 
führt, ...
 
Filtertag: "type=line" Statistiktag: line
60 bus
 3 subway
 2 rail
 2 light_rail

führt die Auswertung in Gegenrichtung zu einer sehr unterschiedlichen
Verwendung des type-Tags.

Filtertag: "line=..*" Statistiktag: type
67 line
55 public_transport
47 route
40
 2 site

Diskussion auf talk-de:
http://lists.openstreetmap.org/pipermail/talk-de/2010-
January/060958.html



Grüße
Werner

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

Re: [Talk-de] Relationen in Baden-Württemberg aufr äumen?

[Werner Hoch]

Hallo,

On Montag, 4. Januar 2010, SLXViper wrote:
> Werner Hoch schrieb:
> > Inzwischen existieren viele Relationen ohne type-Tag. 
> > Diverse Relationen aus dem ÖPNV-Bereich könnten ein wenig Pflege vertragen.
> >   
> Allerdings. Oft auch "inhaltlicher" Art... Mithilfe der öpnvkarte sieht
> man das auch recht leicht, bspw. an leeren Popups beim Klick auf eine
> Haltestelle. Der OSM inspector ist da auch hilfreich.
> 
> > Gibts Bedenken gegen eine Aufräumaktion oder würde gar jemand mithelfen.
> > Hier eine Liste mit verschiedenen Bereichen, die verbessert werden könnten.
> 
> Zu ergänzen wären die, die noch komplett fehlen - je nach Gegend findet
> man fast keine einzige Haltestelle und wenn, dann öfters ohne Namen, was
> nicht gerade hilfreich ist. Daher gibt's dort eben auch keine Linien...
> 
> > 1. ÖPNV-Routen um Karlsruhe
> > 
> > einige Routen haben kein type-Tag und verwenden line=[bus,tram, ..]
> > --> Ergänzung von type=route, route=[bus,tram,...], das line Tag könnte 
> > IHMO entfallen.
> > s. auch http://wiki.openstreetmap.org/wiki/Public_transport
> >   
> Löschen würde ich definitiv nichts. type=route halte ich für überflüssig
> eine solche Redundanz könnte irreführend sein - so weiß man sofort, dass
> das Oxomoa-Schema zum Einsatz kam, welches sich deutlich vom bisherigen
> Bus-Schema unterscheidet. Bspw. wird empfohlen, die Haltestellen _neben_
> die Straße zu setzen, nach Oxomoa braucht man die gar nicht mehr,
> sondern nur noch stop_position _auf_ der Straße und platform daneben.

Mist. Ich habe nicht gesehen, das diese line=xxx zum Oxomoa-Schema gehören.
Damit entfällt hier das "Korrigieren" natürlich.
Trotzem sollte man sich überlegen welche type-Tags diese Relationen erhalten
sollen. (inclusive der Verlinkung auf der Relations Seite:
http://wiki.openstreetmap.org/wiki/Relations)

> > 2. Bus-Routen um Villingen Schweningen
> > --
> > gleiches Problem wie in Karlsruhe
> 
> Die wurden eben frisch nach Oxomoa-Schema angelegt, nachdem die meisten
> Haltestellen in Villingen vorhanden waren und ich die restlichen gezielt
> ergänzen konnte. type= muss man in der Tat noch vereinheitlichen,
> anfangs habe ich versucht, über type= etwas Ordnung zu schaffen, hatte
> allerdings keinen wirklichen Erfolg im Hinblick auf bessere
> Handhabbarkeit in josm und habe das daher erstmal komplett weggelassen.

Die type-Tags halte ich allein deshalb für enorm wichtig, damit man das 
taggingschema herausfinden kann.
 
> > 3. public_transport Relationen
> > ---
> > Viele public_transport=stop_area, public_transport=stop_area_group haben 
> > kein type-Tag.
> > Andere haben ein type=site, type=public_transport_stop, 
> > type=public_transport_stop_group tag.
> > --> ggf. Vereinheitlichung auf type=public_transport
> >
> > Auf der Seite von Oxomoa wird das type-Tag für stop_area_group 
> > und stop_area Relationen nicht erwähnt:
> > http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema
> > Das type=public_transport wird aber bereits häufig verwendet.
> 
> type=public_transport wäre eine Möglichkeit. Aber braucht man das denn
> wirklich?

Ja.

> Es ist doch eigentlich offensichtlich, was die Relation darstellt.

Nein. Das type-Tag macht es erst offensichtlich. ... ein fehlendes type-Tag
ist auch der einfachste Indikator, dass beim Tagging etwas schiefgelaufen ist.
(deshalb habe ich den Thread angefangen =:-> ).

Ich schreibe Oxomoa noch eine Mail und frage ihn, ob er für sein 
Schema type-Tags vorgesehen hat oder ob er welche empfehlen will.

> Mir fehlt eher eine Möglichkeit, Linien und Linien-Varianten zu
> unterscheiden, da wäre ein public_transport=line bzw. line_variant
> sinnvoll - auf jeden Fall für die menschlichen Benutzer...
> (type=public_transport,) public_transport=line/line_variant, line=bus,
> bus=urban würde sogar ins bisherige "Tag-Verkettungs-Schema" passen.

Soweit ich das Schema verstanden haben soll genau das durch das hierarchische
line,line_variant Relations-Modell möglich sein.

Grüsse
Werner

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

[Talk-de] Relationen in Baden-Württemberg aufr äumen?

[Werner Hoch]

Hallo allerseits,

ich würde gerne mal die Relationen in Baden-Württemberg ein wenig aufräumen.

Inzwischen existieren viele Relationen ohne type-Tag. 
Diverse Relationen aus dem ÖPNV-Bereich könnten ein wenig Pflege vertragen.

Gibts Bedenken gegen eine Aufräumaktion oder würde gar jemand mithelfen.
Hier eine Liste mit verschiedenen Bereichen, die verbessert werden könnten.

1. ÖPNV-Routen um Karlsruhe

einige Routen haben kein type-Tag und verwenden line=[bus,tram, ..]
--> Ergänzung von type=route, route=[bus,tram,...], das line Tag könnte IHMO 
entfallen.
s. auch http://wiki.openstreetmap.org/wiki/Public_transport

2. Bus-Routen um Villingen Schweningen
--
gleiches Problem wie in Karlsruhe

3. public_transport Relationen
---
Viele public_transport=stop_area, public_transport=stop_area_group haben kein 
type-Tag.
Andere haben ein type=site, type=public_transport_stop, 
type=public_transport_stop_group tag.
--> ggf. Vereinheitlichung auf type=public_transport

Auf der Seite von Oxomoa wird das type-Tag für stop_area_group 
und stop_area Relationen nicht erwähnt:
http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema
Das type=public_transport wird aber bereits häufig verwendet.


Weitere Hilfmittel:
Tabelle mit allen Relation (ca. 9500) aus Baden-Württemberg 
mit den wichtigsten Tags des ÖPNV
http://www.h-renrew.de/h/osm/osmchecks/00_Listen/bw_publictransport.ods

Statistik und Auflistung "seltsamer" Relationen:
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/bw_relationtypes.html

Grüße
Werner

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

[Talk-de] OpenOffice Calc makros für OSM

[Werner Hoch]

Hallo allerseits,

ich hab mir zwei kleine Makros gemacht mit denen man aus ooCalc heraus 
Relationen in JOSM laden oder im Browser ansehen kann:

-
sub osm_browse_relation
' browse the relation with the id of the selected cell
oDoc = thisComponent
oCell=oDoc.getCurrentSelection()
if HasUnoInterfaces(oCell, "com.sun.star.table.XCell") then
url =  "http://www.openstreetmap.org/browse/relation/"; + 
oCell.value
shell("/usr/bin/firefox/ " + url)
end if
end sub

sub josm_load_relation
' load relation with the id of the selected cell
oDoc = thisComponent
oCell = oDoc.getCurrentSelection()
if HasUnoInterfaces(oCell, "com.sun.star.table.XCell") then
josm_url = "http://localhost:8111/import?url=";
osm_api =  "http://www.openstreetmap.org/api/0.6/";
url = josm_url + osm_api + "relation/" + oCell.value + "/full"
shell("/usr/bin/wget -O/dev/null " + url)
end if
end sub
-

Die Makros sind nicht besonders schön. Vieleicht findet sich ja jemand der 
etwas mehr Ahnung von der Makro-Programmierung hat.

Verwendung:
* Zelle mit der Relations-ID makrieren.
* eines der Makro ausführen (ggf. über eine Schaltfläche oder Tastenkürzel)

Für Ways, Nodes, ... muss nur die URL geändert werden.

Grüße
Werner (werner2101)

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

Re: [Talk-de] Entwurf: ältere Versionsstände ü ber die OSM-API abfragen

[Werner Hoch]

Hallo Frederik,

On Mittwoch, 30. Dezember 2009, Frederik Ramm wrote:
> Werner Hoch wrote:
> > ich habe ein Tool geschrieben mit dem man osm-Objekte zu jedem
> > beliebigen Datum herunterladen kann.
> > Die heruntergeladenen Daten kann man für die Fehlersuche und
> > -behebung verwenden oder einfach nur zum Spaß die Veränderung
> > komplexerer Relationen untersuchen (z.B. der Mappingfortschritt von
> > Wanderrouten, ...)
> 
> Etwas aehnliches kann seit einigen Wochen auch die
>  XAPI-Schnittstelle. Details hier (und in den Folge-Artikeln):
> 
> http://lists.openstreetmap.org/pipermail/dev/2009-December/017896.htm
> l

Danke für den Link, da war wohl jemand etwas schneller ;-).
Ich werde die XAPI demnächst mal testen.
 
> Ich hab das nicht ausprobiert, aber zumindest auf dem Papier hat die
> XAPI den Vorteil, dass sie auf Basis des "history planet" arbeitet
>  und daher keine API-Requests nach hinten durchfuehren muss, die
>  Daten liegen einfach vor.

Ja, das Problem mit den vielen API-Calls kann nur auf dem Server 
vermieden werden. Mein Skript habe ich deshalb auch nur für kürzere 
Relationen und Wege verwendet.

Grüße
Werner

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

[Talk-de] Entwurf: ältere Versionsstände ü ber die OSM-API abfragen

[Werner Hoch]

Hallo allerseits,

ich habe ein Tool geschrieben mit dem man osm-Objekte zu jedem 
beliebigen Datum herunterladen kann.
Die heruntergeladenen Daten kann man für die Fehlersuche und -behebung 
verwenden oder einfach nur zum Spaß die Veränderung komplexerer 
Relationen untersuchen (z.B. der Mappingfortschritt von Wanderrouten, 
...)

längere Beschreibung (englisch):
http://www.h-renrew.de/h/osm/tools/osmhistory.html

Quelltext-Repository auf github:
http://github.com/werner2101/python-osm
bzw. das eigentliche script:
http://github.com/werner2101/python-osm/blob/master/tools/osmhistory.py

Das Tool ist nur ein Prototyp und noch nicht sonderlich ausgereift. 
Außerdem ist Tool sehr langsam (viele API-Aufrufe).
Falls Interesse besteht:
* würde ich den bestehenden Quelltext noch optimieren
  (deutliche Reduktion der erforderlichen API-Aufrufe)
* und einen kompletten Entwurf für die Umsetzung des Tools in der 
  als OSM-API schreiben.

Besteht Interesse an einem solchen Tool?

Kommentare, Ideen?

Grüße
Werner (werner2101)

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

Re: [Talk-de] Problem gelöst (was: gelöschtes Element fehlt beim Zugriff über die API)

[Werner Hoch]

Hallo Peter und alle anderen,

Hab gerade die Lösung gefunden.

On Dienstag, 22. Dezember 2009, Peter Körner wrote:
> > Nein, ich will keine unnötigen Daten herunterladen. Also auf gar
> > keinen Fall die komplette history eines Objekts.
> 
> Schön, dass du das willst - die API kanns aber nicht. Du kannst dir
> jederzeit den API-Code schnappen und eine entsprechende Erweiteung
> schreiben. Wenn du den Patch auf die dev Liste schickst und er nichts
> kaputt macht, wird er mit großer wahrscheinlichkeit auch angewendet.

Das gelöschte Element kann bereits mit einem API-Kommando 
heruntergeladen werden.
Man muss nur das "ways"-Kommando benutzen
http://www.openstreetmap.org/api/0.6/ways?ways=26802382
dann erhält man die neueste Version des gelöschten Objektes.

Das "way" kommando liefert wie schon vorher festgestellt wurde 410 -
GONE.
http://www.openstreetmap.org/api/0.6/way/26802382

Soweit ich den Quelltext verstanden habe müsste es auch mit nodes und 
relations funktionieren.
http://svn.openstreetmap.org/sites/rails_port/app/controllers/

Grüsse und Frohe Weihnachten
Werner


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

Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

Hallo Peter,

On Mittwoch, 23. Dezember 2009, Peter Körner wrote:
> >> Nein, ich will keine unnötigen Daten herunterladen.
> >>
> >> Also auf gar keinen Fall die komplette history eines Objekts.
> >
> > Schön, dass du das willst - die API kanns aber nicht.
> 
> Spräche etwas dagegen, bei einem Request auf ein gelöschtes Objekt
>  [1] *sowohl* einen "410 Gone" header *als auch* den XML-Body der
>  lösch-Version [2] zurück zu geben?

Hört sich gut an, aber ich weiß nicht ob die verschiedenen Tools (wget, 
curl, firefox, ...) den Text noch herunterladen, wenn der Status bereits 
410 lautet.
Programmiert man ein eigenes Tool, dann sollte es kein Problem sein.

Eine andere Möglichkeit wäre die Erweiterung der Versionsangabe des 
history Kommandos [2].
Mit negativen Versionsnummern könnte man die Historie von hinten 
durchnummerieren.

z.B.
http://www.openstreetmap.org/api/0.6/way/26802382/-1
--> die neueste Version von way 26802382
http://www.openstreetmap.org/api/0.6/way/26802382/-2
--> die zweitneueste Version von way 26802382
...

Ist die negative Version zu groß, dann würde man 404 zurückgeben.

Anmerkung:
Die negative Indizierung wird z.B. bei der Skriptsprache python 
verwendet, bei der Listenelemente von hinten durchgezählt werden.
 
> [1] http://www.openstreetmap.org/api/0.6/way/26802382
> [2] http://www.openstreetmap.org/api/0.6/way/26802382/10

Grüsse
Werner

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

Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

Hallo, 

On Sonntag, 20. Dezember 2009, Frederik Ramm wrote:
> Werner Hoch wrote:
> > Sieht man sich die Spezifikation V0.6 an, dann ist von der 410 bei
> > diesem Kommando und einem gelöschten Objekt nichts zu lesen.
> >
> > Version: GET /api/0.6/[node|way|relation]/#id/#version
> 
> Der 410 kommt nur beim GET ohne Versionsangabe und bedeutet: "Von
>  diesem Objekt gab es mal eine gueltige Version, aber die wurde
>  geloescht". Einen 404 gibt es, wenn Du ein Objekt anfragst, das nie
>  existiert hat.
> 
> Beim GET mit Versionsangabe kann es einen 410 logischerweise nicht
>  geben ("die Version gab es mal, aber sie wurde geloescht") - es gibt
>  entweder einen 404 ("diese Version oder dieses Objekt gibts nicht
>  und gab es nie"), oder die Version kommt zurueck - falls sie
>  geloescht ist, mit einem "visible=false".
> 
> > Entweder ist die Beschreibung nicht ganz vollständig oder der
> > Server liefert die falsche Antwort.
> 
> Soweit ich sehen kann, sind Beschreibung sowie Verhalten des Servers
> korrekt (oder stimmen zumindest ueberein ;-)

Ja, du hast recht. Aber dann habe ich ja zumindest die Möglichkeit über 
die API eine gelöschte Version herunterzuladen. Auch wenn ich erst über 
das Webfrontend die Versionsnummer herausfinden muss.

Das vereinfacht mein Problem wieder um ein kleines bisschen.

Grüsse
Werner

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

Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

On Samstag, 19. Dezember 2009, Frederik Ramm wrote:
> hy-soft wrote:
> > Zugegeben dann bekommt man HTML statt XML
> 
> Genau.
> 
> > aber fast jede
> > Programmiersprache bietet heutzutage auch die Moeglichkeit HTML zu
> > parsen oder eben den HTML-Output anzuzeigen.
> > (Ich habe da jetzt keine fuenf Minuten gebraucht um zu
> > verifizieren, dass es geht)
> 
> Bei der API gibt es seitens OpenStreetMap das implizite Versprechen,
> dass das nicht so mir-nichts, dir-nichts geaendert wird - wenn, dann
> gibt es vorher ausreichend Ankuendigung und eine genaue Spezifikation
> der neuen XML-Struktur und so weiter.

Sieht man sich die Spezifikation V0.6 an, dann ist von der 410 bei 
diesem Kommando und einem gelöschten Objekt nichts zu lesen.

---
Version: GET /api/0.6/[node|way|relation]/#id/#version
Retrieves a specific version of the element. 
Error codes
HTTP status code 404 (Not Found) 
When no element with the given id could be found
---
http://wiki.openstreetmap.org/wiki/API_v0.6#Version:_GET_.2Fapi.2F0.6.2F.5Bnode.7Cway.7Crelation.5D.2F.23id.2F.23version

Entweder ist die Beschreibung nicht ganz vollständig oder der Server 
liefert die falsche Antwort.

> Bei der Webseite koennen sich Aufbau und Inhalt jederzeit aendern,
>  und es waere toericht, seine Software auf irgendwelche Annahmen
>  bezueglich der HTML-Inhalte der Webseite zu stuetzen.

Yup.

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

Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

On Freitag, 18. Dezember 2009, hy-soft wrote:
> Werner Hoch wrote:
> > Ich will mir ein Skript schreiben mit dem ich einen Weg oder eine
> > Relation zu einem bestimmten Datum herunterladen kann.
> > z.B. einen Tag vor der Löschung, ...
> 
> Und das Objekt selbst (ID) ist bekannt?

Ja, die Objekt ID ist bekannt.


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

Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

hy-soft  wrote:
> Werner Hoch wrote:
> > hy-soft  wrote:
> >> Werner Hoch wrote:
> >>> Ich will mir ein Skript schreiben mit dem ich einen Weg oder eine 
> >>> Relation zu einem bestimmten Datum herunterladen kann.
> >>> z.B. einen Tag vor der Löschung, ...
> >> Und das Objekt selbst (ID) ist bekannt?
> >>
> > Ja die Objekt ID ist bekannt.
> 
> http://api.openstreetmap.org/api/0.6/[node|way|relation]/#id/history
> Dann das vorletzte Element nehmen, bzw. die Versionsnummer des
> vorletzten Elements 'merken' - das letzte Elt. ist der Loescheintrag.
> 
> Dann:
> http://api.openstreetmap.org/api/api/0.6/[node|way|relation]/#id/#version

Diese Version ist auch in der history enthalten und müsste nicht mehr 
heruntergeladen werden.
 
> Damit solltest Du das bekommen was Du haben willst.

Nein, ich will keine unnötigen Daten herunterladen. Also auf gar keinen Fall 
die komplette history eines Objekts.

Sofern sich das gelöschte Objekt nicht über die API ermitteln lässt werde ich 
folgenden workaround verwenden:

Immer dann wenn das aktuelle Objekt (über die API) nicht mehr vorhanden ist, 
dann frage ich das Objekt über das Webfrontend ab und generiere mir daraus das 
aktuelle (gelöschte) Objekt.

Grüsse
Werner


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

Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

hy-soft  wrote:
> Werner Hoch wrote:
> > Ich will mir ein Skript schreiben mit dem ich einen Weg oder eine 
> > Relation zu einem bestimmten Datum herunterladen kann.
> > z.B. einen Tag vor der Löschung, ...
> 
> Und das Objekt selbst (ID) ist bekannt?
> 
Ja die Objekt ID ist bekannt.

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

Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

Hallo Matthias,

On Freitag, 18. Dezember 2009, Matthias Versen wrote:
> > ich habe versucht die XML-Version eines gelöschen Elementes
> > herunterzuladen. Aber zu sehen bekomme ich nichts.
>
> Ist ja auch logsich, es ist gelöscht und es gibt nichts mehr zu
> sehen.

Übers Webfrontend kann ich noch auf die gelöschte Version zugreifen.
Die Information ist also immer noch da.

> > Gibt es eine andere Möglichkeit über die api auf ein gelöschtes
> > Objekt zuzugreifen?
>
> WO nichts ist da kann man auch nichts runterladen.
> Aber Du kannst eine alte Version herunterladen :
> http://www.openstreetmap.org/api/0.6/way/26802382/9
>
> das ist Version9, wo das Objekt noch nicht gelöscht war.

Woher soll ich wissen welche Version die vorletzte ist und wann die 
Löschung stattgefunden hat?

Grüsse
Werner

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

Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

Hallo Bernd,

On Freitag, 18. Dezember 2009, Bernd Wurst wrote:
> > Gibt es eine andere Möglichkeit über die api auf ein gelöschtes
> > Objekt zuzugreifen?
> > Die gesamte Historie eines Objektes will ich nicht herunterladen.
>
> Musst du aber.
> Eine Löschung ist eine "neue Version" des Objekts mit "visible=false"
> im XML. In dieser neuesten Version fehlen dann auch alle Tags.

Das ist ok. Mich interessieren dieselben infos, die ich auch übers 
Webfrontend sehe.

> d.h. was dich vermutlich interessiert ist die zweitneueste Version,
> nämlich die letzte "mit Sinn". Und die ist in der History drin.

Ja, mich wird meistens die zweitneueste interessieren. Dazu benötige ich 
aber die Versionsnummer der neuesten, gelöschten Version.

> http://www.openstreetmap.org/api/0.6/way/26802382/history
>
> > Ich bin an der Versionsnummer und dem Löschdatum des gelöschten
> > Objektes interessiert.
>
> Das steht in dem XML ganz unten.

Das habe ich gesehen. Ich will aber nicht eine ganze Historie 
runterladen, nur um an das Löschdatum und die Versionsnummer zu kommen.

Bei Objekten mit sehr vielen Versionen dauert das u.U. zu lange.
ggf. könnte ich durch bisecting solange die Versionen durchprobieren, 
bis ich die richtige Version gefunden habe. Das wäre aber eher 
subobtimal.

Ich will mir ein Skript schreiben mit dem ich einen Weg oder eine 
Relation zu einem bestimmten Datum herunterladen kann.
z.B. einen Tag vor der Löschung, ...

Grüsse
Werner

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

[Talk-de] gelöschtes Element fehlt beim Zugriff über die API

[Werner Hoch]

Hi,

ich habe versucht die XML-Version eines gelöschen Elementes 
herunterzuladen. Aber zu sehen bekomme ich nichts.

z.B. Dieser Weg in der Webansicht
http://www.openstreetmap.org/browse/way/26802382

Bzw. über die API:
http://www.openstreetmap.org/api/0.6/way/26802382

Oder mit wget über die API:

~> wget http://www.openstreetmap.org/api/0.6/way/26802382
--2009-12-18 17:12:33--  
http://www.openstreetmap.org/api/0.6/way/26802382
Auflösen des Hostnamen »www.openstreetmap.org« 128.40.168.98
Verbindungsaufbau zu www.openstreetmap.org|128.40.168.98|:80... 
verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 410 Gone
2009-12-18 17:12:33 FEHLER 410: Gone.


Gibt es eine andere Möglichkeit über die api auf ein gelöschtes Objekt 
zuzugreifen? 
Die gesamte Historie eines Objektes will ich nicht herunterladen.

Ich bin an der Versionsnummer und dem Löschdatum des gelöschten Objektes 
interessiert.

Grüße
Werner

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

Re: [Talk-de] polygon aus koordinaten erstellen/benutzen

[Werner Hoch]

Hallo Fabian,

On Freitag, 4. Dezember 2009, Fabian wrote:
> wuerde gerne einen Landkreis naeher untersuchen und ihn dazu aus dem
> Germanmap Datensatz extrahieren. 

Das geht mit osmosis und der --bounding-polygon option. [1]

> Ist es moeglich bei vorhandene 
> polygone in dem fall Landkreisgrenzenn an die Koordinaten zu kommen?

Falls du die Grenzrelation kennst, dann kannst du dir aus der Relation 
eine osmosis polygon Datei erstellen. [2] [3]

Wenn du nur eine Grenze brauchst, dann kann ich dir auch schnell mal 
eine entsprechende Datei machen.

Grüsse
Werner (werner2101)

[1] 
http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--bounding-polygon_.28--bp.29
[2] 
http://wiki.openstreetmap.org/wiki/Osmosis/Polygon_Filter_File_Format
--> osm2poly.pl
[3] http://github.com/werner2101/python-osm
--> src/multipolygon.py

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

Re: [Talk-de] is_in Tagging: Vereinheitlichung der Bezeichungen von Regierungsbezirken und Landkreisen

[Werner Hoch]

On Sonntag, 22. November 2009, Florian Lohoff wrote:
> On Sun, Nov 22, 2009 at 12:54:35PM +0100, Werner Hoch wrote:
> > Die Vorteile der Kurzform:
> >   * sie ist kürzer
> >   * openGeoDB verwendet auch die Kurzform
> >   * die Kurzform wird derzeit häufiger verwendet [1]
>
> In NRW defintiv nicht - Da habe ich fast alles konvertiert. Mitunter
> auch weil eben die entsprechenden namen einen place mit dem selben
> namen adressieren sollten.

In Baden-Württemberg wird die Kurzform in 70-80% der Fälle verwendet.

> D.h. mein is_in abgleich testet auch das eben die Bestandteile des
> is_in Pfades ebenfalls als place node existieren. D.h. wenn es einen
> is_in mit
>
> "Gütersloh, Kreis Gütersloh, Regierungsbezirk Detmold,
> Nordrhein-Westfalen ..."
>
> gibt sollte es entsprechend auch place nodes mit diesen Name geben.
> Ist dem nicht so findet sich ein bug in der "autobug" karte (Nicht
> schoen aber funktioniert)

[...]

> > [1] http://autobug.osm.lab.rfc822.org/lists/hierarchy.html
>
> Yep - Da kann man schoen jeweils die hierachie sehen ... Wer noch
> andere auswertung oder listen/darstellungen moechte - nur her damit.
> Das habe ich damals gebaut um trees/leaves zu finden die halt
> systematisch falsch sind.

Meine Auswertung habe ich gemacht um places mit wikipedia Listen 
abzugleichen. Die is_in Checks sind nur ein Nebenprodukt:
http://www.h-renrew.de/h/osm/osmchecks/04_Orte/Ergebnis/index.html

Ich prüfe dabei die vorhandenen places gegen die Grenzrelation des
jeweiligen Gebietes. Ein place mit korrektem is_in Tag, das im falschen 
Gebiet liegt wird damit auch erkannt (manchmal fehlen nur ein paar 
Meter).
Die places habe ich mit osmosis aus dem Baden-Württemberg dump 
herausgefiltert. Den anschließenden polygontest mache ich mit einem 
python script.

> Dann habe ich mir die place nodes via script und api geholte und via
> josm korrigiert und hochgeladen - Damit muss ich nicht ganz NRW laden
> sondern konnte mir nur die place nodes zu gemuete fuehren.

Hab ich in meinem Landkreis auch so gemacht.

Grüsse
Werner

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

Re: [Talk-de] is_in Tagging: Vereinheitlichung der Bezeichungen von Regierungsbezirken und Landkreisen

[Werner Hoch]

On Sonntag, 22. November 2009, Frederik Ramm wrote:
> Werner Hoch wrote:
> > das is_in tag von Orten (place) wird mehr oder weniger willkürlich
> > von bots und usern gesetzt. Das führt natürlich nicht zu einem
> > einheitlichen Schema und das hin und her taggen ist lästig.
>
> Ich rate daher jedem davon ab, is_in ueberhaupt zu verwenden, und
> wenn, dann *ausschliesslich* mit einem Gemeindenamen, niemals aber
> mit einer hierarchischen Liste. Denn die Information, dass Gemeinde X
> sich in Landkreis Y und dieser sich in Bundesland Z befindet, muss
> nun wirklich nicht hundertfach in unserer Datenbank stehen.
>
> > 5. Bereinigung der is_in Tags mit einer Aktion, mit einem Bot,
> >oder durch lokale Mapper
>
> Also wenn ich mich jemals entschliessen sollte, is_in zu bereinigen,
> dann wuerde diese Bereiningung in seiner Entfernung bestehen ;-)

Das wäre auch eine saubere Lösung.
Wenigstens einheitlich.

Grüße
Werner


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

Re: [Talk-de] is_in Tagging: Vereinheitlichung der Bezeichungen von Regierungsbezirken und Landkreisen

[Werner Hoch]

On Sonntag, 22. November 2009, Florian Gross wrote:
> Am So November 22 2009 glaubte Werner Hoch zu wissen:
> > Beispiel Kurzform:
> > ..,Landkreis Ravensburg,Regierungsbezirk
> > Tübingen,Baden-Württemberg,. Beispiel Langform:
> > ..,Ravensburg,Tübingen,Baden-Württemberg,
>
> Sicher?

Nein, genau anders herum. Aarrgghh.

Werner


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

[Talk-de] is_in Tagging: Vereinheitlichung der Bezeichungen von Regierungsbezirken und Landkreisen

[Werner Hoch]

Hallo allerseits,

das is_in tag von Orten (place) wird mehr oder weniger willkürlich von 
bots und usern gesetzt. Das führt natürlich nicht zu einem 
einheitlichen Schema und das hin und her taggen ist lästig.

Im Wiki habe ich noch kein Seite gefunden, die den Sollzustand der is_in 
Tags für Deutschland genau beschreibt.
Hier die englische Seite: http://wiki.openstreetmap.org/wiki/Key:is_in

Deshalb habe ich mal eine grobe Struktur für die Festlegung des Taggings 
in Deutschland erstellt:
http://wiki.openstreetmap.org/wiki/DE:Is_in

Die Bundesländer sind einheitlich benannt. Unterhalb der Bundesländer, 
bei den Regierungsbezirken und den Landkreisen sind die Bezeichnungen 
noch zu unterschiedlich.

Regierungsbezirke und Landkreise können entweder in der Langform mit 
Verwaltungsform oder in Kurzform ohne Verwaltungseinheit angegeben 
werden.
Beispiel Kurzform:
..,Landkreis Ravensburg,Regierungsbezirk Tübingen,Baden-Württemberg,.
Beispiel Langform:
..,Ravensburg,Tübingen,Baden-Württemberg,


Die Vorteile der Kurzform:
  * sie ist kürzer
  * openGeoDB verwendet auch die Kurzform
  * die Kurzform wird derzeit häufiger verwendet [1]
 
Die Vorteile der Langform:
  * die is_in tags sind selbsterklärend weil die Bedeutung jedes
Abschnittes einigermaßen eindeutig ist.
  ..,Landkreis Ravensburg,Regierungsbezirk Tübingen,..
Bei der Kurzform ist dies nicht so einfach, weil die
Einzelbestandteile mehrere Bedeutungen haben können
  ..,Ravensburg,Tübingen,Baden-Württemberg,.. 
oder weil die Einzelbestandteile gleich sind.
  ...,Stuttgart,Stuttgart,Stuttgart,Baden-Württemberg,...
  * die is_in tags können bei Bedarf durch Entfernen der 
Verwaltungsform automatisch gekürzt werden. Eine Verlängerung
der Tags von der Kurz- auf die Langform ist nicht möglich.


Erstmal würde mich interessieren ob es noch weitere Argumente für die 
Lang- bzw. Kurzform gibt.

Dann könnte man darüber abstimmen und eine Bereinigung nach diesem 
Ablauf durchführen:

1. Diskussion (Auf der Liste oder im Wiki?)
2. Abstimmung (Kurz- oder Lang) (???)
3. Dokumentation des Abstimmungsergebnisses
   (http://wiki.openstreetmap.org/wiki/DE:Is_in)
4. Eintragen der endgültigen Bezeichnungen in das Wiki
5. Bereinigung der is_in Tags mit einer Aktion, mit einem Bot,
   oder durch lokale Mapper
  
[1] http://autobug.osm.lab.rfc822.org/lists/hierarchy.html

Grüße
Werner (werner2101)

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

Re: [Talk-de] Stuttgart - keine Radwege in der Autostadt ?

[Werner Hoch]

On Montag, 26. Oktober 2009, qbert biker wrote:
>  Original-Nachricht 
>
> > Datum: Mon, 26 Oct 2009 01:50:31 +0100
> > Von: Thomas Wedekind 
> > An: talk-de@openstreetmap.org
> > Betreff: [Talk-de]  Stuttgart - keine Radwege in der Autostadt ?
> >
> > Eine Wikiseite besagt, dass man dann nach der
> > tatsächlichen Bedeutung taggen soll, oder? Den letzten Fall habe
> > ich gerade vor Augen, aber noch nicht angefasst.
>
> Grundsaetzlich verweisen (fast?) alle abgeleiteten Seiten
> auf die engl. Mapfeatures, so dass die eigentlich die
> 'letzte Instanz' fuer die Entscheidung sein sollten.
>
> http://wiki.openstreetmap.org/wiki/Map_Features
>
> Ich fuer meinen Teil habe diese Texte immer so interpretiert,
> dass die administrative Einteilung nur ein Hilfskonstrukt
> ist, um ein erstes Raster zu definieren.

Ich bin mittlerweile auf diese Beschreibung umgestiegen:
http://wiki.openstreetmap.org/wiki/DE:Road_Signs

Der Unterschied zwischen den Beschreibungen trägt natürlich nicht 
unbedingt zur Vereinheitlichung beim Mapping bei.

> Ist natuerlich nur meine ganz persoenliche Sicht der Dinge
> als Anwernder.

Meine auch
Werner

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

Re: [Talk-de] Deutschlandgrenze Relation 62781 beschäd igt

[Werner Hoch]

Danke.

On Mittwoch, 21. Oktober 2009, Florian Lohoff wrote:
> On Mon, Oct 19, 2009 at 10:37:27PM +0200, Werner Hoch wrote:
> > Kann jemand von den Experten die Fehler bitte beheben?
>
> Okay - habe auch so 2-3 Versuche gebraucht - Halb Ruegen fehlte und
> irgendwie scheint die haelfte der Deutschen kueste noch zusaetzlich
> ways ohne tags zu haben - die waren stellenweise anhand der
> wirklichen Kuestenlinie in der relation. Ausserdem war bei Flensburg
> ein way nicht gesplittet d.h. ein "schniepel" zu viel in der
> relation.
>
> http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?rel
>ationId=62781
>
> Sagt das jetzt alle ways "closed (self contained)" sind - Damit
> sollte die relation in ordnung sein - Das ganze ist aber nicht
> durch eine Aktion beschaedigt worden sondern wie es scheint
> ueber diverseste aktionen nach und nach degeneriert ...

;-)


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

Re: [Talk-de] Wanderwege-Overlay jetzt weltweit verf ügbar

[Werner Hoch]

Hallo Sarah,

On Mittwoch, 21. Oktober 2009, Sarah Hoffmann wrote:
> wie einige vielleicht mitbekommen haben, stelle ich eine Karte mit
> Wanderwegen der Schweiz zur Verfügung. Nach einigem Umbau des
> Renderings ist diese Karte ab sofort weltweit verfügbar:
>
> http://osm.lonvia.de/world_hiking.html

Super Darstellung.

> Die Implementierung des osmc:symbol-Tags ist noch nicht ganz
> vollständig, und die Interpretation von ref-Tags folgt in den
> nächsten Tagen. Dazu eine Frage: wäre es nicht sinnvoll die Liste der
> möglichen Werte des osmc_symbol-Tags ins Wiki zu verlegen, damit
> Leute neue Werte einfacher beschreiben können?

> Die einzelnen Wegefarben wie im osmc:symbol-Tag beschrieben zu
> rendern, ist in einem Overlay leider nicht möglich, weil die Zahl der
> verwendbaren Farben begrenzt ist. Es gibt daher nur eine
> Unterscheidung nach network-Typ.

Könntest du nicht die Symbole vom Wiki aus dem wiki:symbol Tag 
verwenden?

Hier z.B. die Symbole der Wanderwege im Bodenseekreis:
http://wiki.openstreetmap.org/wiki/Bodenseekreis#Rad-_und_Wanderwege

Grüße
Werner (werner2101)


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

[Talk-de] Deutschlandgrenze Relation 62781 besch ädigt

[Werner Hoch]

Hallo Experten,

die Relationen der Deutschlandgrenze 62781 ist vor einiger Zeit 
beschädigt worden.
Die Relation hat keine Tags mehr (auch kein type=multipolygon).

Die Tags sind zwischen der Version:
http://api.openstreetmap.org/api/0.6/relation/62781/442
und der Version:
http://api.openstreetmap.org/api/0.6/relation/62781/443
In Changeset 2745883 verschwunden.

Das multipolygon hat auch ein paar Lücken in der Hauptgrenze im Süden 
von Bayern und an der Ostsee.

Kann jemand von den Experten die Fehler bitte beheben?

Link:
http://wiki.openstreetmap.org/wiki/DE:Grenze

Grüße
Werner

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

Re: [Talk-de] Statusseite der Landesstraßen in Baden-W ürttemberg neu angelegt

[Werner Hoch]

On Freitag, 16. Oktober 2009, FlaBot wrote:
> Naja man könnte eine Liste mit Referenzen machen die man als zuletzt
> validiert mit Datum versieht .. oder ?

Zunächst müssen die Relationen erstmalig überprüft werden.
Trägt man bei der Überprüfung das Datum mit ein. So kann man jederzeit 
(ggf. mit etwas Aufwand) zu diesem Stand zurück.

Ich hab mal die ersten beiden Straßen abgehakt:
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Landesstraßen/Baden-Württemberg_2#L_300_-_L_349

Für die Status-Tabellen gibts doch inzwischen genügend Vorbilder:
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bundesstra%C3%9Fen
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Landesstraßen/Bayern

Grüße
Werner




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

Re: [Talk-de] Statusseite der Landesstraßen in Baden-W ürttemberg neu angelegt

[Werner Hoch]

Hallo Dirk,

On Freitag, 16. Oktober 2009, FlaBot wrote:
> Super Aktion 
> ... aber kann man sowas nicht über eine Datenbank laufen lassen ?
> Tabellen konnte man so dynamisch erzeugen. Den Datenbankinhalt
> wöchentlich per Dump updaten ..

Die Tabellen kann ich jederzeit automatisch neu erzeugen:
http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/relationenindex.html

Hier die ganze Wikitabelle der Landesstraßen:
http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/wiki_Landesstrassen.txt
und einem Test der Relationen:
http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/Refcheck_Landesstrassen.html

Leider nützt das ganze nicht viel. Die Straßen müssen von einem Mapper 
auch kontrolliert und hin und wieder korrigiert werden.

Grüße
Werner

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

[Talk-de] Statusseite der Landesstraßen in Baden -Württemberg neu angelegt

[Werner Hoch]

Hallo,

die bisherige Statusseite für die Landesstraßen in Baden-Württemberg war 
zu groß und konnte schon seit längerem nicht mehr editiert werden.
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Landesstraßen/Baden-Württemberg

Ich habe die Status-Tabellen auf 6 Unterseiten verteilt.
Die eingetragenen Relationen wurden aus dem Baden-Württemberg Dump 
extrahiert.

Viel Spaß beim Kontrollieren der Straßen.

Grüsse
Werner (werner2101)

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

Re: [Talk-de] Einzeichnen von "speziellen" Bereichen in Karten

[Werner Hoch]

On Freitag, 16. Oktober 2009, Peter Staab wrote:
> Liebe Mailingslistenleser,
>
> Welche Möglichkeiten bestehen in OSM um spezielle Flächen, wie z.B.
> Parplätze einzuzeichnen? In den Beispieldaten die ich bis jetzt
> finden konnte waren Parkplätze immer mit einem "P" eingezeichnet.
> Aber es war keine Fläche definiert. Geht das irgednwie?

Ja. Das Tag amenity=parking muss dann an eine Fläche anstatt an einen 
Punkt angehängt werden.
http://wiki.openstreetmap.org/wiki/Parking

> Wie kann man Parkflächen weiters annotieren, also z.B. "Nur für
> Kunden", "Kurzparkzone", "Gebührenpflichtig", etc.? - geht dies nur
> über das "notes" Feld?

"Gebührenpflichtig" --> fee=yes
"Kurzparkzone" ???
"Nur für Kunden" --> eventl. mit access tags
http://wiki.openstreetmap.org/wiki/Access

Grüsse
Werner


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

Re: [Talk-de] Checks für Kreisstraßen in Baden-W ürttemberg

[Werner Hoch]

Hallo Marcus,

On Donnerstag, 17. September 2009, marcus.wolsc...@googlemail.com wrote:
> On Thu, 17 Sep 2009 12:34:18 +0200, Werner Hoch  
wrote:
> http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/relationenind
>ex.html
>
> Achtung, ich sehe gerade auf
> http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/relationenind
>ex.html dass du für Landesstrassen den regulären Ausdruck "L .*" hast.
>
> In einigen Bundesländern fangen die nicht mit L an sondern anders.
> Habe ich bei den Vorbereitungen zum TMC-import herausgefunden.
> http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/automatic_i
>mport
>
> "L[0-9]*",
> "S[0-9]*",
> "K [A-Z]*[0-9]*" ([A-Z]*[0-9]*=licence plate),
> "G[A-Zo0-9 ]*"

Meine Checks sind nur für Baden-Württemberg. Die Auswertungen zu den 
Landesstraßen kann man nur mit Vorsicht verwenden, weil hin und wieder 
noch Straßensegmente aus anderen Bundesländern im Baden-Württemberg 
dump sind.

Grüße
Werner

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

Re: [Talk-de] Checks für Kreisstraßen in Baden-W ürttemberg

[Werner Hoch]

Hallo Bernd,

On Mittwoch, 16. September 2009, Bernd Wurst wrote:
> Kannst du Bezeichnungen, die als Ref vorkommen und keine Relation
> haben, da auch irgendwie aufführen?

Ich habe mal die Wege die noch keine Relation haben mit aufgenommen.
http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/relationenindex.html

Die Daten sind leider noch von gestern. Heute gabs kein neues dump file:
http://download.geofabrik.de/osm/europe/germany/

Grüße
Werner

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

[Talk-de] Checks für Kreisstraßen in Baden-W ürttemberg

[Werner Hoch]

Hallo Allerseits,

vor einiger Zeit habe ich Skript geschrieben, das die Relation und 
Referenzbezeichnungen von Kreisstraßen in Baden-Württemberg auswertet.

Das Ergebnis habe ich hier mal hochgeladen:
http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/relationenindex.html

Die Tabelle enthält für jeden Landkreis 2 Dateien. 

Eine Tabelle im Wiki-Format. Die Tabelle kann als Ausgangspunkt für eine 
QA-Rubrik für Kreisstraßen verwendet werden. Im Bodenseekreis sieht die 
Tabelle derzeit so aus:
http://wiki.openstreetmap.org/wiki/Bodenseekreis#Kreisstra.C3.9Fen

Die zweite Datei listet für die vorhandenen Relationen mögliche Fehler 
auf. (Bei Landkreisen ohne Kreisstraßenrelationen ist die Fehlertabelle 
leer)
Hier z.B. das Ergebnis des Hohelohe-Kreises.
http://www.h-renrew.de/h/osm/osmchecks/01_Relationstest/Refcheck_Hohenlohekreis.html

In der ersten Spalte ist die Referenz und die Relationsnummer 
aufgeführt.
Die zweite Spalte listet alle Wege, die in der Relation enthalten sind, 
aber keine passende Referenzbezeichnung im Weg tragen.
Die dritte Spalte listet alle Wege die ein übereinstimmendes ref=* Tag 
haben aber nicht in der Relation enthalten sind.
Die letzte Spalte listet die Wege die in der Relation mehrfach 
vorkommen.

Doppelte Wege in Relationen sind fast immer Fehler. Bei den anderen 
Spalten sollten die Relationen oder Wege geprüft werden.

Viel Spaß damit
Werner (werner2101)

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

Re: [Talk-de] "unofficial path"??

[Werner Hoch]

On Montag, 14. September 2009, malenki wrote:
> Werner Hoch schrieb:
> >http://www.openstreetmap.org/browse/way/37574858/history
>
> Leicht OT:
> Dort sehe ich ein created_by-Tag - wird das von Potlatch im Gegensatz
> zu JOSM nicht automatisch entfernt?

Der User dobi verwendet JOSM. (s. Changeset)

Mir wäre es auch noch nicht aufgefallen, daß JOSM die created_by tags 
entfernt. Zumindest ältere Versionen von JOSM nicht.

Grüße
Werner

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

Re: [Talk-de] "unofficial path"??

[Werner Hoch]

On Sonntag, 13. September 2009, Jörk wrote:
> Claudius schrieb:
> > Potentiell reden wir aneinander vorbei. Hast du bitte einen
> > Kartenlink zu einem Beispielausschnitt oder einen Link zur Seite
> > mit Informationen zu einem betroffenen Weg? Eventuell wurde ja nur
> > die Übersetzung im Editor geändert und am Tagging hat sich nichts
> > geändert.

> der Begriff steht in den presets von Potlatch 1.2a. Z.B. bei diesem
> Weg 37574858

In der history, also in der Datenbank von OSM steht immer nur 
highway=path siehe:

http://www.openstreetmap.org/browse/way/37574858/history

Gruß
Werner

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

Re: [Talk-de] Wanderweg-Relation

[Werner Hoch]

Hallo Markus,

On Sonntag, 13. September 2009, Markus wrote:
> ich war mal wieder wandern und habe einen Weg eingetragen.
> Den will ich nun als Relation bezeichnen: 240937
> Aber der Relation Analyzer sagt, dass da ein Teilstück fehlt.
>
> Also versuche ich, dieses fehlende Teilstück zu idenfifizieren,
> um es dann zu ergänzen.
>
> Aber wie geht das?

Bei kleinen Routen am besten indem du die Relation markierst und 
schrittweise den Weg verfolgst.

Bei deiner Route würde ich auf die beiden unclassified Straßen zwischen 
Frohnhof und Steinensittenbach tippen. (27845453, 27845454)

> Im Wiki finde ich auch nach längerem Suchen nichts.
> Mit JOSM Remote Control wird ein grösserer Kartenausschnitt gezeigt,
> aber dort ist kein Wegstück markiert, weder das fehlende, noch
> diejenigen davor und danach, noch die Relation.

Ich glaube, es wird hier die Lücke zwischen den Wegstücken 
heruntergeladen. Die Wege mußt du selber identifizieren.

> Und wenn ich das Segment davor anklicke, wird dieses in einer
> Minikarte angezeigt, aber ich erkenne nicht, was genau gemeint ist.
> Nun habe ich mal probeweise ein Stück eingefügt, von dem ich denke,
> dass es vielleicht der Übeltäter sein könnte, aber nun zeigt der
> Analyser /zwei/ fehlende Wegstücke statt einem.

In diesem Zustand hat deine Route östlich von Steinensittenbach mehrere 
Äste. der Track 38095911 geht nach norden weiter und der track 31964784 
geht nach südosten weiter.

> Nun verstehe ich gar nichts mehr: wenn ich das falsche, also ein
> schon vorhandenes eingetragen hätte, dann müsste doch JOSM irgendwie
> schimpfen? und der Analyser müsste ein doppeltes Wegstück anzeigen?

Der Analyzer ist auch verwirt, weil er eine durchgehende Route 
sucht ;-).

HTH
Werner

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

Re: [Talk-de] Fehler in Website finden

[Werner Hoch]

On Montag, 7. September 2009, Markus wrote:
> Wer kann helfen:
>
> In www.lau-net.de/baerlocher/osm/Simmelsdorf.html
> wird der Layer "Essen und Trinken" nicht angezeigt.
>
> Ich suche seit Tagen den Fehler und finde ihn nicht.
> Und morgen sollte ich die Seite präsentieren...


Firefox sagt, dass die Zeile 92 des html-files nicht i.O. ist.
Dort versucht du die Essen.gpx Datei zu laden.

Die gpx-Datei Essen.gpx ist kaputt:

wer...@linux-m82i:~/osm/src> xmllint Essen.gpx
Essen.gpx:92: parser error : Opening and ending tag mismatch: desc line 
89 and wpt

  ^
Essen.gpx:103: parser error : Opening and ending tag mismatch: wpt line 
86 and gpx

  ^
Essen.gpx:104: parser error : Premature end of data in tag gpx line 2

^
--

HTH
Werner

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

Re: [Talk-de] Aktion 04 - D/A/CH Touch checks für mot orway, trunk etc.

[Werner Hoch]

On Samstag, 5. September 2009, Gary68 wrote:
> das josm gebiet habe ich nun geviertelt, wird beim nächsten lauf also
> besser sein.
>
> einen versionskonflikt habe ich bei noch keiner aktion erlebt. aber
> auch das sollte besser werden mit kleineren flächen.

kleinere Flächen bringen nichts, wenn dann von den Usern die gleichen 
Wege editiert werden.

Ich hab mal nach doppelten Fehlern gesucht bzw. nach Wegen, die in 
mehreren Fehlern vorkommen.  (c53_austria.htm)

1. Doppelte Wege
src> grep way c53_austria.htm | sort |uniq -c |sort -n

--
...
  7 http://www.openstreetmap.org/browse/way/30380249/history";>30380249
  8 http://www.openstreetmap.org/browse/way/26652421/history";>26652421
  8 http://www.openstreetmap.org/browse/way/30041835/history";>30041835
 10 http://www.openstreetmap.org/browse/way/26311270/history";>26311270
 10 http://www.openstreetmap.org/browse/way/26710677/history";>26710677
 18 http://www.openstreetmap.org/browse/way/37876147/history";>37876147
--

Der letzte Weg ist in 18 Fehler involviert:
30,173,265,275,326,358,383,414,468, ...


Ähnliches gilt für die dargestellten Kacheln (tiles):
src> grep img c53_austria.htm | sort |uniq -c |sort -n   

---

  6 http://tah.openstreetmap.org/Tiles/tile/16/35294/22716.png";>
  6 http://tah.openstreetmap.org/Tiles/tile/16/35404/22746.png";>
  6 http://tah.openstreetmap.org/Tiles/tile/16/35733/22712.png";>
  6 http://tah.openstreetmap.org/Tiles/tile/16/35815/22675.png";>
 10 http://tah.openstreetmap.org/Tiles/tile/16/35649/22624.png";>
---

In der letzten Kachel sind insgesamt 10 Fehler:
99,207,222,258,262,282,402,458,633,824


Diese Fehler sind über viele Fehlerblöcke verstreut. Konflikte beim 
editieren lassen sich also kaum vermeiden.

Würde man die Fehler sortieren, dann könnte man ähnliche Fehler schon an 
der dargestelten Kachel erkennen und ähnliche Fehler wären nur auf 1 
oder 2 Fehlerblöcke verteilt.

Grüße
Werner (werner2101)


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

Re: [Talk-de] Aktion 04 - D/A/CH Touch checks für mot orway, trunk etc.

[Werner Hoch]

Hallo Gerhard,

On Samstag, 5. September 2009, Gary68 wrote:
> wenn du etwas sortiertest haben möchtest, dann nimm bitte die gpx
> files und lade sie in josm. bei einer aktion wird man sich dabei
> sicherlich in die quere kommen, aber ich stelle ja jede woche alle
> reports frisch bereit. die kannst du alle benutzen. 

Es geht ja gerade um die Aktionen.

> ps: ist nicht so 
> einfach, eine soche 2d-sortierung in einer 1d-liste sinnvoll
> hinzubekommen!

Eine 1d-Sortierung in Längsrichtung des jeweiligen Gebietes würde schon 
reichen.
Eine 2d-Sortierung könnte mäanderförmig sein:
http://www.h-renrew.de/misc/2009/osm/maeander.png
python skript mit Compare-Funktion s. Anhang

> wenn dir die changesets zu groß werden, dann speichere doch einfach
> nach jedem edit?

Um die BBOX klein zu bekommen müsste jeder nach jedem Edit speichern.#
Der Changeset (Anzahl der Änderungen) ist auch bei 10 Fehlerkorrekturen
nicht wirklich groß.

> das josm gebiet habe ich nun geviertelt, wird beim nächsten lauf also
> besser sein.

Danke.

> einen versionskonflikt habe ich bei noch keiner aktion erlebt. aber
> auch das sollte besser werden mit kleineren flächen.

Hatte ich gestern. 

Ich habe den Eindruck dass Fehler mehrfach in der Auflistung sind, wenn 
drei und mehr Wege nahe beieinanderliegen.

Grüsse
Werner
#!/usr/bin/python

import numpy, pylab


def cmp_maeander(a,b):
ax, ay = a
bx, by = b
factor = 5

cmp_row = cmp(int(factor*ay), int(factor*by))
if cmp_row == 0:
direction = (int(factor*by) % 2) * 2-1
return direction * cmp(ax, bx)
else:
return cmp_row




x = numpy.random.rand(200)
y = numpy.random.rand(200)

xy = zip(x,y)
xy.sort(cmp_maeander)

sx = [ p[0] for p in xy ]
sy = [ p[1] for p in xy ]

pylab.plot(sx,sy,'r-o',label='Maeander_Sortierung', linewidth=3)
pylab.legend()
pylab.show()
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Aktion 04 - D/A/CH Touch checks für mot orway, trunk etc.

[Werner Hoch]

Hallo Gerhard,

On Freitag, 4. September 2009, Gary68 wrote:
> http://wiki.openstreetmap.org/wiki/DE:Aktionen/Aktion_04

Ich habe zum ersten mal bei einer deiner Korrektur-Aktionen mitgemacht 
und hätte noch kleine Verbesserungswünsche.

1. Fehlerliste geographisch sortieren
z.B. von Nord-Süd oder West-Ost, oder irgendwie gekachelt
Ich würde mir davon zwei Vorteile versprechen.
* die Changesets hätten eine kleinere BBOX und würden auf 
  weniger History-Seiten erscheinen
* sind zwei Fehler doppelt vorhanden, oder nahegelegen, so
  gäbe es seltener Versionskonflikte mit anderen Mappern

2. Der Link "Local JOSM" sollte kleinere Flächen herunterladen.
Die Flächen sind bei Fehleren in den Städten zu groß Teilweise wurden 
mehr als 100k Daten heruntergeladen, das dauert dann zu lange.
100x100m müsste eigentlich für die Fehlerkorrektur ausreichend sein.

Ich habe den Link nicht verwendet, sondern immer nur die zwei Wege 
heruntergeladen (kleines Skript) und zusätzliche manuell eine kleine 
Fläche um die Fehlerstelle (JOSM).

Grüße
Werner (werner2101)

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

Re: [Talk-de] Relationen überwechen

[Werner Hoch]

On Montag, 17. August 2009, Falk Zscheile wrote:
> gibt es eine Möglichkeit Relationen bzw. die an ihnen vorgenommenen
> Änderungen automatisch zu überwachen? Es scheint ja doch hin und
> wieder vorzukommen, dass etwas aus Versehen gelöscht wird. Je später
> so etwas entdeckt wird, um so komplizierter ist ja die
> Wiederherstellung. Es gibt da schon einige Relationen, die mir sehr
> am Herzen liegen :-)

Relationen hin und wieder herunterladen und lokal in eine 
Versionsverwaltung (z.B. git, mercurial) einchecken. Damit kannst du 
einfach die Änderungen nachverfolgen, oder versehentliche Änderungen 
entdecken.

Die Überwachung lässt sich gut automatisieren und ist für nahezu alles 
verwendbar. z.B. wiki-Seiten, generierten Indexlisten von Straßen, 
Grenzen, generierte Fehlerlisten, ...

Grüße
Werner




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

Re: [Talk-de] OSB (neu) API und deren Belastbarkeit

[Werner Hoch]

On Montag, 17. August 2009, Gary G: wrote:
> mal ein gedankenspiel.
>
> 1.)
> also würde ich erst mal 20.000 bugs hochladen, die ich z.B. im text
> mit einem code versehe, sodass ich sie nächste woche wiederfinde. 2.)
> dann würden alle die bugs sehen und könnten damit arbeiten.
> 3.)
> eine woche später müsste ich alle (noch offenen) bugs identifizieren
> (am code) und einzeln löschen. 4.)
> upload aller neu gerechneten fehler etc.
>
> also, was sagt osb (neu) zu 40.000 api calls? wie schnell kann sowas
> gehen? verträgt der server das?
>
> sonstige meinungen?

Ich wäre nicht begeistert davon. Damit würde man die Fehler die von 
Personen geschrieben wurden mit Fehler-Reports von einen Skript 
mischen.

Könntest du deine Fehler nicht bei keepright.at einfügen?

Grüße
Werner (werner2101)

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

Re: [Talk-de] Doppelte Wege - Untersuchung

[Werner Hoch]

On Montag, 17. August 2009, Andre Hinrichs wrote:
> Am Montag, den 17.08.2009, 11:31 +0200 schrieb Steffen Wolf:
> > Was Euch noch fehlt, und da weiss ich auch keinen rechten Weg, ist
> > die Moeglichkeit, die Beseitigungen einzutragen, d.h. die GPX-Datei
> > zu kuerzen.

Nicht notwendig.

> Ich denke, es reicht, wenn Du die Generierung der Datei
> automatisieren kannst und dann tagesaktuell hältst.

Hoffentlich tauchen die Fehler nicht in so großer Zahl auf, daß das 
notwendig wird. Einmal im Monat ein Update würde IMHO reichen.

> Für diejenigen, die die Fehler bearbeiten und JOSM verwenden, gibt es
> ein schönes Plugin, welches GPX-Dateien bearbeiten kann.

Dieses Plugin habe ich auch verwendet. Zusätzlich habe ich immer die 
Grenzrelation eines Landkreises eingeblendet, sodaß ich immer einen 
kleineren Rahmen um ein Teilgebiet hatte.

Grüße
Werner

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

Re: [Talk-de] Aktion 01 - Ergebnis

[Werner Hoch]

Hallo FlaBot,

On Sonntag, 16. August 2009, FlaBot wrote:
> Man könnte gerade mit BW weitermachen !

Wenn du Lust hast kannst du dich mal an dieser Liste austoben:
http://www.h-renrew.de/h/osm/osmchecks/bad_relations.html

Die Liste enthält die Relationen aus Baden-Württemberg ohne type tag 
oder mit einem eher seltenen type-tag.

Sind viele Relationen aus dem Karlsruher und Stuttgarter ÖPNV dabei.
Aber auch völlig missglückte Relationen, bei denen man nicht weiß was 
gemeint sein soll.

viel Spaß
Werner (werner2101)


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

Re: [Talk-de] Doppelte Wege - Untersuchung

[Werner Hoch]

Hallo Steffen,

On Dienstag, 11. August 2009, Steffen Wolf wrote:
> Ich bereite mal eine GPX-Datei fuer ganz Deutschland vor, mit Wegen
> mit mehr als 4 gemeinsamen Knoten. Damit koennte man in JOSM schnell
> die Fehler entfernen. Ich halt mich aber lieber mit Aenderungen
> mangels Ortskenntnis zurueck.
>
>  http://www.unix-ag.uni-kl.de/~stw/germany-5.gpx

Ich bin die Fehler in Baden-Württemberg durchgegangen und habe die 
meisten auch behoben. Fehler bei denen Ortskenntnis erforderlich ist 
habe ich nicht korrigiert.

Besteht die Möglichkeit nur die Punkte in das GPX-File aufzunehmen, die 
an den doppelten Wegen beteiligt sind?
Ich musste bei manchen Wegen ein Weilchen suchen, bis ich die Doppelung 
gefunden hatte.
Beispiel:
  Weg1: abcdefghijklmnopq
  Weg2: abc
  Weg3: mno
Im GPX-File sollten nur die Wegpunkte abc und mno auftauchen.

Grüsse
Werner (werner2101)
http://www.openstreetmap.org/user/werner2101/edits









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

Re: [Talk-de] Openstreetbugs

[Werner Hoch]

On Montag, 3. August 2009, Martin Koppenhoefer wrote:
> Am 3. August 2009 14:48 schrieb Werner König 
:
> > für Oberkirch bekomme ich hier einen Hinweis "lots of unconnected
> > junctions ... Slow Rider, was ist speziell damit gemeint, was ist
> > falsch.
>
> damit ist gemeint, dass jemand einfach mal Wege gemalt hat, ohne dass
> diese an den (fast)-Berührungspunkten als gemeinsame Nodes=verbunden
> ausgeführt wären. Damit funktioniert an diesen Stellen kein Routing.

Bei diesen Fehlern ist es IMHO sinnvoller hin und wieder auf keepright 
nachzusehen anstatt den BugTracker zu verwenden.

http://keepright.ipax.at/report_map.php?zoom=14&lat=48.53&lon=8.08

Gruß Werner

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

[Talk-de] wiki kaum editierbar (timeout)

[Werner Hoch]

Hallo,

Kann es sein dass das wiki kaum mehr zu editieren ist?

Versuche immer mal wieder diese Seite zu editieren:
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Landesstraßen/Baden-Württemberg

Erhalte aber dauern nur timeout Fehler:

Fatal error: Maximum execution time of 30 seconds exceeded 
in /var/www/wiki.openstreetmap.org/extensions/ConfirmEdit/ConfirmEdit_body.php 
on line 319

Fatal error: Maximum execution time of 30 seconds exceeded 
in /var/www/wiki.openstreetmap.org/includes/Hooks.php on line 40

Fatal error: Maximum execution time of 30 seconds exceeded 
in /var/www/wiki.openstreetmap.org/includes/parser/Parser.php on line 
4965
-

Liegt das Problem eher an der speziellen Seite, oder ist der Server ein 
wenig überlastet?

Grüsse
Werner (werner2101)

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

Re: [Talk-de] Realtion Analyzer, Wanderweg

[Werner Hoch]

On Montag, 1. Juni 2009, Markus wrote:
> Habe gestern eine Relation (Wanderweg) eingegeben,
> aber der Relation Analyzer findet sie nicht.
>
> Im JOSM wird sie angezeigt (Jura-Höhenweg, Nr. 150262)

Sehe den weg im Relation Analyzer
http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=150262

Und im Routen Manager:
http://osm.cdauth.de/route-manager/relation.php?id=150262

MfG
Werner


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

Re: [Talk-de] route=road-Relationen und ref=

[Werner Hoch]

Hallo UncleOwen,

On Mittwoch, 27. Mai 2009, UncleOwen wrote:
> Gestern hab ich dann von den beteiligten Wegen das ref="Ring 1"
> entfernt (stand eh nur an der Hälfte des Ringes). Leider zeigen jetzt
> Mapnik und Osmarender gar nichts mehr an :( Werden Relationen mit
> type=route, route=road wirklich (auf den "Haupt"karten) nicht
> gerendert, oder hab ich was falsch gemacht? Wenn es wirklich nicht
> gerendert wird: Ist das geplant?

Hatte vor einiger zeit dasselbe Problem. Hier die Mail bzw. der Thread 
zum Thema:
http://lists.openstreetmap.org/pipermail/talk-de/2009-May/044859.html
http://lists.openstreetmap.org/pipermail/talk-de/2009-May/thread.html#44859

Grüsse
Werner

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

[Talk-de] Landesstraßen in Baden-Württemberg

[Werner Hoch]

Hallo Leute,

in den letzten 2 Wochen entstand eine Statusseite über die Landesstraßen 
in Baden Württemberg:
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Landesstraßen/Baden-Württemberg

Mit Skripts wurden die Relationen aus dem Baden-Württembergischen 
Auszugs des Worldfiles herausgefiltert und als Wiki-Tabellen 
formatiert. Die Tabellen sind natürlich noch nicht komplett.

Ich hoffe, dass auf der Seite, ähnlich wie auf der Bundesstraßenseite 
[1], die Infos über die Landesstraßen gesammelt werden können und mit 
der Zeit die Straßen in BW komplettiert werden können.

Feedback und rege Beteiligung sind natürlich erwünscht.

Für den Bodenseekreis und den Landkreis Ravensburg habe ich ähnliche 
Tabellen für die Kreisstraßen auf den Seiten der Landkreise angelegt.
http://wiki.openstreetmap.org/wiki/Bodenseekreis
http://wiki.openstreetmap.org/wiki/Landkreis_Ravensburg


[1] http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bundesstraßen

Grüße
Werner (werner2101)
PS: Danke an dmuecke, der einen Teil der Arbeit gemacht hat.

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