Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Alexander, Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner: Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche neuen Erkenntnisse? • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen • zusätzliche amenities: opening_hours? Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki Nicht-Streitpunkt public_transport name/ref
Am Mon, 22 Jul 2013 02:20:25 +0200 schrieb Tirkon tirko...@yahoo.de: Bei Bahnsteigen mit Gleisen auf beiden Seiten wird nicht klar, auf welcher Seite der Fahrgast seine Bahn zu erwarten hat. In der betreffenden Variante unbenutzte Steige kommen ja nicht in die Relation. Die Values für Komplettheit müssten noch einen Wert für fraglich zulassen, möglicherweise ?. Das ist der Default. Aber vielleicht sollte ich einen expliziten Wert vorsehen. To be able to map platform nodes with unknown properties, the tag public_transport=any_platform is added to the set of values. This tag corresponds to highway=bus_stop and alike even in the case of nodes. For ways and areas it's the same as public_transport=platform. Verstehe ich nicht. Was sagt public_transport=any_platform aus? Und zu welcher Menge von Werten wird das hinzugefügt. (eventuell Beispiel) Der Key public_transport kann doch nur einen Wert haben. Und wann wird stattdessen highway=bus_stop oder public_transport=platform getaggt. Was passiert dann mit der erwähnten Menge von Werten? Es sollen nicht mehrere Werte zum Key angegeben werden -- es gibt einen zusätzlichen Wert. Zur Menge der zulässigen Werte (platform, stop_position) wird also einer hinzugefügt. Dann haben wir (any_platform, platform, stop_position). Der Unterschied zwischen platform und any_platform ist, dass any_platform nichts über die Art des Steigs aussagt. Platform besagt ja laut Public Transport Proposal bei einem Node, dass dort kein Steig vorhanden ist. Man kann also zur Zeit die ganzen alten highway=bus_stop Nodes neben der Fahrbahn nicht durch ein public_transport=irgendwas ergänzen, da keine der bisherigen Möglichkeiten passt. Dann können die verarbeitenden Programme aber auch nicht umgestellt werden. pt2_subname A name as found on the splot ... Die Bedeutung der Vokabel splot konnte ich nicht ergründen. vor Ort. Man soll sich da nichts ausdenken, sondern nur nehmen was da vor Ort angegeben ist. pt2_subname=? value is unknown, but there is one pt2_subname omitted: unknown Wo ist der Unterschied zwischen den beiden Alternativen? Weiß ich beim der zweiten weder den Wert, noch dass ein Wert existiert? Genau. vehicle The vehicle kind(s) used. Vehicle macht mir etwas Bauchschmerzen, weil es von der Acess Wikiseite stammt, die ihrerseits inkonsistent ist. Geht aber vermutlich. Man könnte es umbenennen. Aber eigentlich definiert der Relationstyp die Bedeutung seiner Tags und was woanders ist, beißt sich damit nicht. Das ist eigentlich nicht anders als bei name. Da definiert der Objekttyp ja auch, was da benannt wird. *_exit_only and role : *_entry_only are not really useful as first and last stop markers and for intermediate stops they are not needed as time table routing doesn't use them. Hmm, man sollte aber schon wissen, dass man an einer Haltestelle nicht einsteigen kann - insbesondere wenn es nicht die letzte ist. Ja, da gibt es drei Fälle. 1.: Anfang und Ende der Linie. Das wird von vielen Mappern weggelassen, ist aber relevant bei Folgelinien Sie können sitzen bleiben, wir fahren weiter als 456. Das habe ich in follow_up_ref gesteckt. 2.: Reine Ausstiegshaltestellen. Da sollte es an der Haltestelle vermerkt sein. 3.: Restriktionen der Tickets. Bei Schlafwagen gilt oft die Regel, dass nur Übernachtungspassiere zugelassen sind. Bei allen Abend-Haltestellen darf man nur einsteigen und bei allen Morgenhaltestellen nur aussteigen. Das sind aber eigentlich Bestandteile des Fahrplans/Ticketverkaufs. Variants - Member roles haltvar bis part+ sind Rollen von ways der Route, halt sowie +halt sind Rollen von nodes der Haltestellen. Ist das richtig? Wenn ja, könnte das im Text - eventuell durch Überschriften - noch verdeutlichst werden. Also die Überschrift Member Roles ist ja da. Ich wollte die einzelnen Roles eigentlich deutlicher markieren (und in meinem LaTeX-Original hab ich das auch) durch glossarartige Einrückungen. Ich habe es aber nicht hinbekommen, dass da auch weitere Absätze mit eingerückt werden. Wenn mir da jemand sagen kann, wie das geht, dann mach ich das sofort. Ich fasse das Ganze für eine einfache Standard-Buslinie ohne Varianten in Kurzform zusammen. Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation: type=pt2, pt2=variant. Die beiden sich ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2, pt2=master. Richtig? Ja. Was mir unklar bleibt: Wie weiß man jetzt, wo ein Umsteigepunkt zu einer ebenso einfach gestrickten Linie besteht, wenn Du die stop_area abschaffst? Die stop_area existiert nach wie vor, an der hat sich nichts geändert. Sie wird aber nicht mehr von der Routen direkt gebraucht -- z.B. um Haltestellennamen zu ermitteln. Zuletzt: Was mir die größten Bauchschmerzen bereitet, ist das parallele Existieren derselben Linien in zwei Relationsmodellen. Das könnte für die Mapper
Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)
Hi, On Sun, Jul 21, 2013 at 02:42:14PM +0200, Tirkon wrote: Daraus ergibt sich, dass diese Fehlermeldungen auf den Meldeseiten verschimmeln, egal ob gefixt oder nicht. Diverse Leute haben sich bei mir darüber beschwert, dass sie Fehler eingetragen haben und sich nun niemand darum kümmere. Von daher hat sich mir der Sinn solcher Seiten - egal ob nun eine zentrale oder mehrere in Koexistenz - niemals erschlossen. Das ist erstmal richtig. Ich habe sowohl OSB wie auch Notes in meinen RSS Feeds so das ich zumindest anderer Leute Bugs mitbekomme. Ab und zu - bevorzugt an Regenreichen Tagen gehe ich dann mal alle Bugs durch und gucke mal ob die noch passen. Und meist sinds hinterher 20-30 Weniger. Zugegebenermassen sind im Kreis GT wohl die meisten Bugs von mir selber weil ich eben selber meine Arbeit auch noch damit Organisiere. D.h. bei Hausnummern wo ich mir dann nicht mehr sicher bin, oder welche die ich nicht habe oder power sub_stations die ich eintraege bei denen ich dann die ref nicht mehr parat habe setze ich mir selber Bugs. Die Schimmeln dann gerne mal rum. Finde ich aber gar nicht schlimm. Bugs die wirklich gar keinen Kontext haben d.h. ich ueberhaupt nicht weiss was gemeint ist oder quatsch drin steht die schliesse ich auch einfach mal. Gerade bei Skobbler gibt es im moment vermutlich 20-30 Bugs fuer das Teilstueck A33 zwischen Kreuz Bielefeld und Bielefeld Innenstadt, respektive Anschuss Ostwestfalendamm. Das zeugs war am Eröffnungstag eingetragen. Leider hampelt Skobbler teilweise noch mit Daten vor der Lizenzumstellung rum. Da habe ich aufgegeben irgendwas zu schliessen. Ich fände es wichtig das für das Notes die erstellung der RSS Feeds einfacher geht - Sich selber koordinaten suchen und eine URL handbasteln kann echt nicht wahr sein. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Alexander, Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. OSM kann wirklich sehr aktuell sein, aber bis die Informationen eines Wochenend-Ereignisses beim normalen Endanwender ankommen, ist es vermutlich schon längst wieder vorbei. Im schlimmsten Fall holt sich z.B. ein Navigationsprojekt genau an diesem Wochenende die Daten und berücksichtigt in den nächsten 3 Monaten die Straßensperrungen. Ein Festival-Gelände auf der grünen Wiese ist problemlos, aber innerhalb eines dicht gemappten Gebietes für ein Wochenende alles umzuschmeißen richtet bestimmt mehr Verwirrung an als dass es Nutzen bringt. Sowas sollte auf einem getrennten Datenbestand eingetragen und eine temporäre Veranstaltungskarte erstellt werden, die man sich auch schon einige Zeit im Voraus anschauen kann. Grüße Joachim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäudenummern auf Firmengelände
On Mon, Jul 22, 2013 at 06:45:16AM +0200, jotpe wrote: Hallo, wie taggt man eine interne Gebäudenummer eines größeren Firmenareals, die keine amtliche Hausnummer ist? Ich habe fuer solche fälle einfach ref genommen. Es ist ja eine referenznummer - Bezugssystem nicht geklärt :) flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Lokalisierung deutscher Kartenstil verbessert
On Sat, Jul 20, 2013 at 12:56:43PM +, Sven Geggus wrote: Jetzt bräuchte man nur noch eine passende Transliteration für diverse große nicht-lateinische Alphabete z.B. für russisch. http://translit.ru Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten exportieren
Hi, On Mon, Jul 22, 2013 at 09:26:44AM +0200, Hartmut Haase wrote: Hallo Liste, ich habe auf meinem Tablet die Navi-App von MapFactor installiert, der die Karten von OpenStreetMap benutzt. Aus irgendeinem Grund sind die Karten nicht aktuell. Ein Beispiel: In Sindelfingen, Carl-Loewe-Str. kennt der Navigator nur die Hausnummern 1 und 4, OpenStreetMap aber alle. Offensichtlich hat der Navigator eine alte Karte. Wie bekomme ich eine neue? MapFactor benutzt die Karten als mca-Dateien. Mapfactor im Menu unten auch Kartenmanager und dann Karten Herunterladen - wenn es aktuellere gibt sieht man das da. Mapfactor betreibt aber irgendeine aggregation von Hausnummern auf Straßenabschnitte und mapped die dann noch auf die Endpunkte. d.h. die Positionen der Adressen werden ein wenig verwaschen. Kann evtl auch da dran liegen da einige Adressen nicht auftauchen. Ich meine Mapfactor erzeugt so rund alle 4 Wochen die Karten. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)
On 22/lug/2013, at 08:54, Florian Lohoff f...@zz.de wrote: Gerade bei Skobbler gibt es im moment vermutlich 20-30 Bugs fuer das Teilstueck A33 zwischen Kreuz Bielefeld und Bielefeld Innenstadt, respektive Anschuss Ostwestfalendamm. Das zeugs war am Eröffnungstag eingetragen. Leider hampelt Skobbler teilweise noch mit Daten vor der Lizenzumstellung rum. Da habe ich aufgegeben irgendwas zu schliessen. +1, skobbler Bugmeldungen sind unbrauchbar weil die Daten viel zu alt sind. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Lokalisierung deutscher Kartenstil verbessert
Florian Lohoff f...@zz.de wrote: http://translit.ru Hm, ein Webdienst ist ja eher nicht das was ich brauche sondern eine funktion, die ich als stored procedure in PostgreSQL einbauen kann. Sven -- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. (Anselm Lingnau in de.comp.os.unix.discussion) /me ist giggls@ircnet, http://sven.gegg.us/ im WWW ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Radio Live Folge 19
Hi wir sind noch dabei die Folge zu produzieren. Da wir das alle Hobbymäßig machen und der Post-Production-Aufwand doch einigen Stunden Arbeit entspricht, braucht das ein paar Tage. Die Folge wird dann auf http://blog.openstreetmap.de/radio-osm/ auftauchen und auch hier auf der Mailingliste angekündigt. Lg, Peter Am 22.07.2013 06:48, schrieb jotpe: Hallo, wo kann man die Live-Folge nur 19 von letzter Woche hören? Gruß Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Lokalisierung deutscher Kartenstil verbessert
On Mon, Jul 22, 2013 at 08:47:16AM +, Sven Geggus wrote: Florian Lohoff f...@zz.de wrote: http://translit.ru Hm, ein Webdienst ist ja eher nicht das was ich brauche sondern eine funktion, die ich als stored procedure in PostgreSQL einbauen kann. Das stehen aber oben die im Russischen üblichen transliterationen drüber ... Флориан Логофф -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fahrradrouting mit OpenRouteService
Hallo, ORS hat immer noch altes Datenmaterial: OSM-Data for Routing: 29.10.12 Schade, alle relevanten Änderungen, gerade für Fahrradrouting kann man nicht testen. http://www.yournavigation.org/ ist aktueller und hat zumindest für Fahhrard zwei Optionen Shortest geht ganz gut. Fastest liefert seltsame Ergebnisse. Welches nehmt Ihr? -- mit freundlichen Grüßen Heinz signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Lokalisierung deutscher Kartenstil verbessert
On Mon, Jul 22, 2013 at 01:37:37PM +0200, Florian Lohoff wrote: On Mon, Jul 22, 2013 at 08:47:16AM +, Sven Geggus wrote: Florian Lohoff f...@zz.de wrote: http://translit.ru Hm, ein Webdienst ist ja eher nicht das was ich brauche sondern eine funktion, die ich als stored procedure in PostgreSQL einbauen kann. Das stehen aber oben die im Russischen üblichen transliterationen drüber ... Флориан Логофф http://postgres.cz/wiki/PostgreSQL_SQL_Tricks#from_Russian_alphabet_.28Cyrillic.29_to_ASCII Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)
Hallo Tirkon, ich habe vor geraumer Zeit auf http://stadtplan-ilmenau.de eine Schnittstelle zu OSB implementiert. Geplant war es schon lange, aber es gab einen inneren Konflikt. OSB bietet nicht wirklich eine SPAM-Abwehr und es ist fraglich wie gut die Nutzer solche Funktionen annehmen. Ersteres habe ich dadurch erschlagen, indem ich die Fehlermeldungen explizit nicht im Stadtplan integriert habe. Überrascht bin ich von den Rückmeldungen. Ursprünglich habe ich mit 10% verwertbaren Fehlerberichten gerechnet. Heraus kam, dass ca. die Hälfte aller Fehlermeldungen sinnvoll sind und so detailiert, dass man sie vom Sessel aus abarbeiten kann. Warum ich es implementiert habe: Ist ein Gebiet gemappt, gehe ich da nicht mehr hin. Ich rede jetzt nicht vom Feriendorf wo ich mal alles eingetragen habe, sondern von ganzen Stadtvierteln und Vororten meiner Stadt. Ilmenau ist zwar mit vielen Mappern gesegnet, aber die decken durch ihren Alltag, wenn es hoch kommt 20% der Stadt ab. Im restlichen Gebiet sind wir blind. Man könnte zwar alle x Jahre mal wieder einen Rundgang wagen, aber wer sagt, dass ich da auch jede Änderung mitbekomme. Mit den Nutzern des Stadtplans decken wir aber plötzlich ein viel größeres Gebiet ab. Man muss den Nutzern nur die Möglichkeit einräumen auf Unstimmigkeiten hinzuweisen. Mein Fazit: OSB ist vllt. für die Neumappung eines Gebietes nicht geeignet, dafür aber für die Wartung von Gebieten, wenn man den Nutzern eine einfache Möglichkeit einräumt. Andererseits sehe ich auch das Negativbeispiel. In jena gibt es viele Tickets. Teilweise sind diese seit Jahren offen. Sie beinhalten oft wichtige Hinweise, doch wenn es an aktiven Mappern mangelt, dann geht da nix voran. Daher bin ich sehr dankbar, dass viele Tickets der Stadtplannutzer auch von anderen Mappern abgearbeitet werden. Teilweise noch bevor ich sie sehe. just my 2 cents, Andreas On 07/21/2013 02:42 PM, Tirkon wrote: Moin, auf osm.org wurde ein Button zur Fehlermeldung eingefügt. Nach meinem Verständnis des im Folgenden beschriebenen OSM Workflows verstehe ich dessen Sinn nicht. Es gibt schon diverse Fehlermeldekarten z.B. von Skobbler, osmbugs und mehr. Ich finde dort meist Fehlermeldungen wie Straße fehlt, Häuser fehlen, dies ist eine Einbahnstraße, hier gilt Höchstgeschwindigkeit xy, so auch auf der neuen Add A Note Seite. Manchmal ist unverständlich, was bemängelt wird. Wenn sich ein OSMler in ein Gebiet begibt, um es mappen, dann erledigt er Dinge wie die aus den Fehlermeldungen ohnehin, sei es durch Gebäudeerfassung mit Hilfe von Bing oder Straßen- und Hausnummernerfassung etc vor Ort. Wer also macht sich die Arbeit zu ergründen, welche Bugmeldeseiten es derzeit gerade gibt und dann als Mehrarbeit nachzuschauen, ob man einen der gemeldeten Bugs erschlagen hat? Andererseits wird niemand zig Kilometer weit fahren, nur um einen Bug zu klären. Für den Preis muss doch schon ein größeres Gebiet flächendeckend herausspringen. Daraus ergibt sich, dass diese Fehlermeldungen auf den Meldeseiten verschimmeln, egal ob gefixt oder nicht. Diverse Leute haben sich bei mir darüber beschwert, dass sie Fehler eingetragen haben und sich nun niemand darum kümmere. Von daher hat sich mir der Sinn solcher Seiten - egal ob nun eine zentrale oder mehrere in Koexistenz - niemals erschlossen. Und von daher erschließt sich mir erst recht nicht, wieso man jetzt so etwas sogar auf der Hauptseite platziert. Nach dem oben beschriebenen Workflow bringen diese Meldungen rein gar nichts außer Frust für die Fehlermelder. Vielleicht ist aber Alles ganz anders. Dann wäre ich für eine Aufklärung recht dankbar, damit ich zukünftigen Beschwerdeführern eine bessere Antwort geben kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Andreas Neumann http://stadtplan-ilmenau.de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradrouting mit OpenRouteService
Heinz-Jürgen Oertel schrieb: http://www.yournavigation.org/ ist aktueller und hat zumindest für Fahhrard zwei Optionen Shortest geht ganz gut. Fastest liefert seltsame Ergebnisse. Welches nehmt Ihr? Aus diesem Grund YourNavigation und dort „Shortest“ :) -- Local time :: Ortszeit :: DE-HH 2013-07-22T15:23:07+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradrouting mit OpenRouteService
ich kannte http://www.yournavigation.org nicht. Ein kleiner Test macht mich stutzig. Padova - Vicenza (im Veneto, Italien) ergibt: 1) bicycle (routes) + fastest: die Route fuehrt ueber die Autobahn 2) bicyle + fastest: die Route fuehrt ueber Radwege und ausgewiesene, geplante Radrouten 3) bicylce + shortest: die Route fuehrt ueber die viel befahrene und meist radwegfreie Staatsstrasse Pass alles so nicht: (1) ist illegal (2) ist schoen, aber lang und langsam (3) ist die schnellste und kuerzeste Verbindung Volker (Padova, Italien) 2013/7/22 Heinz-Jürgen Oertel hj.oer...@t-online.de Hallo, ORS hat immer noch altes Datenmaterial: OSM-Data for Routing: 29.10.12 Schade, alle relevanten Änderungen, gerade für Fahrradrouting kann man nicht testen. http://www.yournavigation.org/ ist aktueller und hat zumindest für Fahhrard zwei Optionen Shortest geht ganz gut. Fastest liefert seltsame Ergebnisse. Welches nehmt Ihr? -- mit freundlichen Grüßen Heinz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postcode Map 2.0 freigeschaltet
Hej Walter, vielleicht solltest du noch irgendwo die URL bekanntgeben ;) Mit Screenshots aus dem Forum und Raten bin ich auf http://osm.wno-edv-service.de/plz/ gekommen. Ich hoffe das stimmt so. Jedenfalls vielen Dank für die Karte, die hat mir in München schon etliche Stellen zum Verbessern aufgezeigt. Viele Grüße ysae ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)
Am 21.07.2013 14:42, schrieb Tirkon: Hey auf osm.org wurde ein Button zur Fehlermeldung eingefügt. Nach meinem Verständnis des im Folgenden beschriebenen OSM Workflows verstehe ich dessen Sinn nicht. Es gibt schon diverse Fehlermeldekarten z.B. von Skobbler, osmbugs und mehr. Ich finde dort meist Fehlermeldungen wie Straße fehlt, Häuser fehlen, dies ist eine Einbahnstraße, hier gilt Höchstgeschwindigkeit xy, so auch auf der neuen Add A Note Seite. Manchmal ist unverständlich, was bemängelt wird. Wenn sich ein OSMler in ein Gebiet begibt, um es mappen, dann erledigt er Dinge wie die aus den Fehlermeldungen ohnehin, sei es durch Gebäudeerfassung mit Hilfe von Bing oder Straßen- und Hausnummernerfassung etc vor Ort. Wer also macht sich die Arbeit zu ergründen, welche Bugmeldeseiten es derzeit gerade gibt und dann als Mehrarbeit nachzuschauen, ob man einen der gemeldeten Bugs erschlagen hat? Andererseits wird niemand zig Kilometer weit fahren, nur um einen Bug zu klären. Für den Preis muss doch schon ein größeres Gebiet flächendeckend herausspringen. Daraus ergibt sich, dass diese Fehlermeldungen auf den Meldeseiten verschimmeln, egal ob gefixt oder nicht. Diverse Leute haben sich bei mir darüber beschwert, dass sie Fehler eingetragen haben und sich nun niemand darum kümmere. Von daher hat sich mir der Sinn solcher Seiten - egal ob nun eine zentrale oder mehrere in Koexistenz - niemals erschlossen. Und von daher erschließt sich mir erst recht nicht, wieso man jetzt so etwas sogar auf der Hauptseite platziert. Nach dem oben beschriebenen Workflow bringen diese Meldungen rein gar nichts außer Frust für die Fehlermelder. Vielleicht ist aber Alles ganz anders. Dann wäre ich für eine Aufklärung recht dankbar, damit ich zukünftigen Beschwerdeführern eine bessere Antwort geben kann. Ich glaube den Sinn hast Du mittlerweile vermittelt bekommen. Recht gebe ich Dir aber auch in Deiner Kritik. Es macht keinen Sinn sowas in zig Datenbanken mit jeweils separaten Tools zu bearbeiten. Irgendwo sollte es eine Verschmelzung geben. Die Information sollten verbessert werden und zB das Kartendaten Datum mitgeliefert werden. Wenn schon so prominent auf der Front-Seite platziert, dann bitte auch so in den Editoren. Last but not least, eine gute Dokumentation: Angefangen von jeweils einem positive/negative Beispiel erreichbar über eine zweite Schaltfläche bis hin zum Wiki und den Anfänger_innen-Seite. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradrouting mit OpenRouteService
Am 22.07.2013 15:42, schrieb Volker Schmidt: ich kannte http://www.yournavigation.org nicht. Ein kleiner Test macht mich stutzig. Padova - Vicenza (im Veneto, Italien) ergibt: 1) bicycle (routes) + fastest: die Route fuehrt ueber die Autobahn 2) bicyle + fastest: die Route fuehrt ueber Radwege und ausgewiesene, geplante Radrouten 3) bicylce + shortest: die Route fuehrt ueber die viel befahrene und meist radwegfreie Staatsstrasse Pass alles so nicht: (1) ist illegal (2) ist schoen, aber lang und langsam (3) ist die schnellste und kuerzeste Verbindung Gleiche Ergebnisse bei mir. Wobei (2) immer noch an einigen befahrenen Straßen mit Radweg entlang führt, anstatt die Seitenstraßen mit maxspeed 30 zu benutzen. Beim richtigen einordnen zum Linksabbiegen scheitert es auch. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 18.07.2013 16:28, schrieb Martin Koppenhoefer: Am 18. Juli 2013 16:23 schrieb Wilhelm Spickermann o...@spickermann-d.de: Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden. Darüber müsste man erstmal diskutieren, Hat sich das denn jetzt aufgeklärt oder geht das weiter ? wenn da keine bauliche Trennung da ist, dann sollte die Diskussion eigentlich schon gleich wieder zu Ende sein... Zumindest eine Diskussion hier im Vorraus hätte ich schon erwartet. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Liebe alle Das Thema temporäre Verkehrshindernisse (Fahrverbote, gesperrte Strassen) v.a. wegen Bauarbeiten oder Veranstaltungen interessiert mich auch. Ich habe es gerade diese Tage auf Talk-ch angeschnitten (Temporär gesperrte Strassen). Das Argument, dass veraltete Daten in offline Applikationen (Navis) landen können, ist oft zu hören. Doch ist das wirklich das einzige Argument gegen entsprechende Tags in OSM? Mir scheint das Argument etwas zu fürsorglich, denn einerseits könnten Importprogramme Baustellen herausfiltern und zweitens könnten Qualitätssicherungsprogramme veraltete Daten durchaus aufspüren. Ich hake hier bewusst nach, um die Möglichkeiten und Grenzen eines eigenen Projekts abzustecken. Die Idee diese Projekts ist, solche Informationen über eine Karte und ein Webservice/API zur Verfügung zu stellen. Zudem können Profis (= Bewilligungs-Behörden) wie auch Freiwillige (= Mapper) solche Daten erfassen. LG, Stefan Am 22. Juli 2013 08:57 schrieb Joachim Kast osm...@dd1gj.de: Hallo Alexander, Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. OSM kann wirklich sehr aktuell sein, aber bis die Informationen eines Wochenend-Ereignisses beim normalen Endanwender ankommen, ist es vermutlich schon längst wieder vorbei. Im schlimmsten Fall holt sich z.B. ein Navigationsprojekt genau an diesem Wochenende die Daten und berücksichtigt in den nächsten 3 Monaten die Straßensperrungen. Ein Festival-Gelände auf der grünen Wiese ist problemlos, aber innerhalb eines dicht gemappten Gebietes für ein Wochenende alles umzuschmeißen richtet bestimmt mehr Verwirrung an als dass es Nutzen bringt. Sowas sollte auf einem getrennten Datenbestand eingetragen und eine temporäre Veranstaltungskarte erstellt werden, die man sich auch schon einige Zeit im Voraus anschauen kann. Grüße Joachim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
On Mon, 22 Jul 2013, Stefan Keller wrote: Liebe alle Das Thema temporäre Verkehrshindernisse (Fahrverbote, gesperrte Strassen) v.a. wegen Bauarbeiten oder Veranstaltungen interessiert mich auch. Ich habe es gerade diese Tage auf Talk-ch angeschnitten (Temporär gesperrte Strassen). Das Argument, dass veraltete Daten in offline Applikationen (Navis) landen können, ist oft zu hören. Doch ist das wirklich das einzige Argument gegen entsprechende Tags in OSM? Mir scheint das Argument etwas zu fürsorglich, denn einerseits könnten Importprogramme Baustellen herausfiltern und zweitens könnten Qualitätssicherungsprogramme veraltete Daten durchaus aufspüren. Ich hake hier bewusst nach, um die Möglichkeiten und Grenzen eines eigenen Projekts abzustecken. Die Idee diese Projekts ist, solche Informationen über eine Karte und ein Webservice/API zur Verfügung zu stellen. Zudem können Profis (= Bewilligungs-Behörden) wie auch Freiwillige (= Mapper) solche Daten erfassen. Sehr schoen! Das beantwortet zwar noch immer nicht meine Frage, ob es da im Wiki bereits eine Diskussions-Seite gibt, aber vielleicht richte ich dann einfach eine ein. In meinem konkreten Fall war es so, dass die Stadt Landshut die OSM Karte auf ihrer Homepage verwendet, was sehr loeblich ist. Und zur Landshuter Hochzeit, die 4 Wochen dauert, gibt es ein extra Overlay mit weiteren Informationen, die nicht von OSM stammen. Recht nett gemacht: http://stadtplan.landshut.de/ Die berechtigte Kritik der Stadtverwaltung war, dass waehrend des Umzugs die doch recht dominant gerenderten Parkplaetze nicht zur Verfuegung stehen, waehrend die Besucher der freudigen Meinung sind, dass entlang des Festzugs beliebig viele Parkflaechen zur Verfuegung stehen. Chaos vorprogrammiert. Ich habe also pragmatischerweise fuer die 4 Wochen die Parklflaechen umgetagged. Das hat auch bei den OSM'lern hier bereits Kritik geschuert und das ist auch sicher keine Dauerloesung. Es gibt ja auch verschiedene Grade von Beeinflussung, sowohl was die gerenderte Karte betrifft, die ja immer aktuell ist, als auch die heruntergeladenen OSM Daten fuer offline routing. Eine Bruecke, die beispielsweise fuer ein halbes Jahr gesperrt ist, waere dem offline Routing vielleicht zuzumuten, eine gesperrte Strasse wegen 4 Wochen Veranstaltung eher nicht. Ein Festival auf einer Wiese, wo Buehnen und Campingflaechen eingezeichnet sind, stoeren beim offline Routing nicht, egal ob das Festival gerade stattfindet oder nicht. Usw. Diese verschiedenen Aspekte haette ich gerne mal gesammelt. A. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Radio Live Folge 19
Moin, Du meinst explizit die ungeschnittene Variante, oder? Ich hab es leider nicht aufgenommen. Besten Gruß Malte ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programm zur Überwachung von OSM-Relationen
Hallo Sebastian, Link zur Website: http://osmarelmon.won2.de/ ich glaube, dass der New Feeds-Feed kaputt ist oder evtl. nur die letzte neue Relation anzeigt oder ähnliches, ist das möglich? Ich sehe zumindest nur einen Feed (AVS hike routes) der hinzugefügt wurde. Auf der Webseite sind es aber eindeutig mehr ;) Und dann hab ich noch ein kleines Featurerequest für die Feeds selbst. Der Titel der Feeds ist ziemlich unaussagekräftig. Kann man die Änderungen evtl. etwas klassifizieren? Dass im Titel z.B. steht paar Knoten haben sich verändert oder ganz viel hat sich geändert oder ähnliches? Oder vielleicht einen Counter wieviel Änderungen es jeweils gab? Die Overpass-QL-Query ist da jedenfalls im Titel eher uninteressant finde ich. Die könnte man statt dessen als Link in die Feed-Beschreibung einbaun. Evtl. sogar direkt als Link auf Overpass-Turbo (falls das mit Turbo geht). Ansonsten: Nette Arbeit :) Gruß, Peda p.s. Feedback über ML, falls andere das selbe schreiben wollten ;) -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Am 22.07.2013 16:16, schrieb Stefan Keller: Das Argument, dass veraltete Daten in offline Applikationen (Navis) landen können, ist oft zu hören. Doch ist das wirklich das einzige Argument gegen entsprechende Tags in OSM? Mir scheint das Argument etwas zu fürsorglich, denn einerseits könnten Importprogramme Baustellen herausfiltern und zweitens könnten Qualitätssicherungsprogramme veraltete Daten durchaus aufspüren. Hallo, evtl. ist es nicht das einzige Argument, aber ein sehr wichtiges. Die Mapnikkarte ist die einzige Anwendung, die nahezu in Echtzeit die Daten anzeigt. Allerdings hat man von der Karte nicht viel. Einzig das access einiger Straßen dürfte ein paar rote Punkte auf die Karte zaubern. Alle anderen Anwendungen hinken der Echtzeit um einiges hinterher. So kann es dann sein, dass das Festival eine Woche später dargestellt wird oder einen Monat lang. Einen wirklichen Vorteil des Eintragens kurzfristiger Dinge sehe ich hier nicht. Tendenziell eher einen Nachteil. Aus Sicht des Konsumenten ist es auch nicht gerade sinnvoll. Der Veranstalter braucht die dann aktuellen Karten für Flyer etc. deutlich eher als Echtzeit. Ebenso die Anwohner, die lieber ein paar Tage eher wissen wollen, welche Straßen gesperrt werden etc. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postcode Map 2.0 freigeschaltet
Hi, On Sat, Jul 20, 2013 at 04:57:06AM -0700, Walter Nordmann wrote: Hi, da nicht jeder hier auch das Forum benutzt: Ich habe meine alte PLZ-Karte komplett überarbeitet und freigeschaltet. Nähere Infos: http://forum.openstreetmap.org/viewtopic.php?id=21827 Wir können selbstverständlich hier auf der Liste drüber diskutieren. Es werden bestimmt noch Kleinigkeiten unklar oder gar fehlerhaft sein. das das clipping der areas immer neu entsteht ist aehm - verwirrend ;) Bisher habe ich so Areas immer vorberechnet und dann immer ganze Areas/Hulls an den browser ausgeliefert so das das clipping im leaflet/openlayers stattfindet. Damit aendert sich die hull nicht beim verschieben (in der form). Ist natuerlich vom Update her komplizierter :) Ansonsten - schön - hab gleich ein paar Fehler beheben können. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)
Am 22.07.2013 09:55, schrieb Martin Koppenhoefer: On 22/lug/2013, at 08:54, Florian Lohoff f...@zz.de wrote: Gerade bei Skobbler gibt es im moment vermutlich 20-30 Bugs fuer das Teilstueck A33 zwischen Kreuz Bielefeld und Bielefeld Innenstadt, respektive Anschuss Ostwestfalendamm. Das zeugs war am Eröffnungstag eingetragen. Leider hampelt Skobbler teilweise noch mit Daten vor der Lizenzumstellung rum. Da habe ich aufgegeben irgendwas zu schliessen. +1, skobbler Bugmeldungen sind unbrauchbar weil die Daten viel zu alt sind. Dann ist vielleicht das Datum der Kartendaten wichtig und sollte beigefügt werden bzw ein Check der Software mit Hinweis auf Veränderungen in diesem Bereich. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Mon, 22 Jul 2013 16:43:25 +0200 schrieb fly lowfligh...@googlemail.com: Am 18. Juli 2013 16:23 schrieb Wilhelm Spickermann o...@spickermann-d.de: Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden. Darüber müsste man erstmal diskutieren, Hat sich das denn jetzt aufgeklärt oder geht das weiter ? Ich dachte, es hätte aufgehört, aber gerade kam die Änderungsmeldung zum Bahnhof Düsseldorf Flughafen rein. - die Bahnsteige wurden gesplittet. Darüber kann man streiten. - je zwei Hälften wurden zu stop_areas zusammengefasst. Das ist falsch. - der Name der Haltestelle Düsseldorf Flughafen wurde durch Bahnsteig n ersetzt. Ist falsch, steht aber so im Wiki. - Die einzige bisher von mir geprüfte Zuglinie hält jetzt an zwei Bahnsteighälften. Das ist falsch. Aber vielleicht kommt ja noch eine Änderung. Wilhelm PS: Ich habe zwei von den Leuten am Anfang (vor der ersten Mail hier) geholfen, das Splitting bzw. das Neuanlegen von Bahnsteigen richtig zu machen (obwohl ich eigentlich nichts vom Splitting halte). In einem Fall war das ziemlich viel Arbeit. Die Dialoge hatten eine angenehme Atmosphäre -- keiner hat aber was von dem Vorhaben verlauten lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programm zur Überwachung von OSM-Relationen
Hallo, On 07/22/2013 06:32 PM, Peter Barth wrote: ich glaube, dass der New Feeds-Feed kaputt ist oder evtl. nur die letzte neue Relation anzeigt oder ähnliches, ist das möglich? Ich sehe zumindest nur einen Feed (AVS hike routes) der hinzugefügt wurde. Auf der Webseite sind es aber eindeutig mehr ;) Ich hab heute ne neue Version vom Programm hochgeladen, deswegen wurde auch der News Feed resettet. Ich weiß jetz nur nicht ganz auf was du dich beziehst, weil bei mir im Standard (OSMarelmon) Feed gar nix angezeigt wird, außer dass der Server eben neu gestartet wurde. Und dann hab ich noch ein kleines Featurerequest für die Feeds selbst. Der Titel der Feeds ist ziemlich unaussagekräftig. Kann man die Änderungen evtl. etwas klassifizieren? Dass im Titel z.B. steht paar Knoten haben sich verändert oder ganz viel hat sich geändert oder ähnliches? Oder vielleicht einen Counter wieviel Änderungen es jeweils gab? Die Overpass-QL-Query ist da jedenfalls im Titel eher uninteressant finde ich. Die könnte man statt dessen als Link in die Feed-Beschreibung einbaun. Evtl. sogar direkt als Link auf Overpass-Turbo (falls das mit Turbo geht). Okay ja, guter Vorschlag, wusste selber nicht was ich reinschreiben sollte :D Grüße, Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programm zur Überwachung von OSM-Relationen
Am 22.07.2013 19:35, schrieb Sebastian Brunner: On 07/22/2013 06:32 PM, Peter Barth wrote: ich glaube, dass der New Feeds-Feed kaputt ist oder evtl. nur die letzte neue Relation anzeigt oder ähnliches, ist das möglich? Ich sehe zumindest nur einen Feed (AVS hike routes) der hinzugefügt wurde. Auf der Webseite sind es aber eindeutig mehr ;) Ich hab heute ne neue Version vom Programm hochgeladen, deswegen wurde auch der News Feed resettet. Ich weiß jetz nur nicht ganz auf was du dich beziehst, weil bei mir im Standard (OSMarelmon) Feed gar nix angezeigt wird, außer dass der Server eben neu gestartet wurde. Hallo, ich denke du solltest als erstes hier eine Routine einbauen, die die vorhandenen Daten speichert und nach einem Update zurückspielt. Wenn man nach jedem unvorhersehbarem Update alles neu machen muss, vergeht einem der Spaß recht schnell. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Am 22.07.2013 08:07, schrieb Eckhart Wörner: Hallo Alexander, Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner: Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche neuen Erkenntnisse? • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen • zusätzliche amenities: opening_hours? Eckhart Ich denke, es ging Alexander eher um die Frage, ob man die temporären Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen sollte. Es wäre zwar nett, wenn die Karte auch während des Ausnahmezustandes Stadtfest aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich. Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend eingerichtet wurden. Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie. Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann wochenlang mit diesen Sonder-Anpassungen herum. Auch andere Auszüge werden nicht täglich aktualisiert. Ich denke, die OSM-Datenbank sollte nur den Normalzustand wiedergeben und nicht den temporären Ausnahmezustand. Dies kann evtl. auf einer Webseite oder in Flyern durch Overlays dargestellt werden. -- Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo, evtl. ist es nicht das einzige Argument, aber ein sehr wichtiges. Die Mapnikkarte ist die einzige Anwendung, die nahezu in Echtzeit die Daten anzeigt. Allerdings hat man von der Karte nicht viel. Einzig das access einiger Straßen dürfte ein paar rote Punkte auf die Karte zaubern. Alle anderen Anwendungen hinken der Echtzeit um einiges hinterher. So kann es dann sein, dass das Festival eine Woche später dargestellt wird oder einen Monat lang. Einen wirklichen Vorteil des Eintragens kurzfristiger Dinge sehe ich hier nicht. Tendenziell eher einen Nachteil. Sehr gut zusammengefasst! Danke! Gruß Malte ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Routing Engine Graphhopper in Version 0.1 erschienen
Graphhopper ist eine neue, schnelle Routing Engine in Java, mit Daten auf OSM Basis. Das Open Source Projekt hat heute seine erste Version 0.1 released. Die Release Meldung findet sich hier: https://karussell.wordpress.com/category/graphhopper/ bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/Routing-Engine-Graphhopper-in-Version-0-1-erschienen-tp5770955.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Frank und Thorsten Vielleicht hast du beim Schreiben Thorsts Vorschlag noch nicht gesehen: Thorsten Kurz schrieb am 22. Juli 2013 19:25: Wäre es vielleicht möglich, das ganze in ein Tagging-Schema zu packen, das man im Zweifelsfall auch komplett ignorieren kann und immer noch etwas einigermassen sinnvolles erhält? Wie wäre es z.B., statt highway = construction construction = primary vielmehr highway = primary construction = yes zu verwenden? Mittlerweile ist mir klar geworden, dass z.B. der highway-Tag nur dem eigentlichen Attributieren der Strassenklasse vorbehalten sein soll. Ein Hin- und Zurückändern wäre falsch. Hingegen sind zusätzliche (optionale) Tags (construction=yes etc.) - wie von Thorsten vorgeschlagen - für mich eine durchaus gangbare Lösung. construction=yes deckt aber noch nicht alle Fälle ab - insbesondere nicht Veranstaltungen wie Alexanders Stadtfest! Wie wär's in diesem Falle mit: * traffic_obstruction=yes/no Am 22. Juli 2013 20:25 schrieb Frank fr...@fotodrachen.de: Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie. Der originale highway-Tag nicht; ein construction=yes schon. Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann wochenlang mit diesen Sonder-Anpassungen herum. Auch andere Auszüge werden nicht täglich aktualisiert. Solche zeitlich hinterherhinkenden Projekte sollten sich nicht beirren lassen von zusätzlichen Tags, die den letzten Sperrzustand kennzeichnen. Bei der Anwendung, die ich im Kopf habe - und die auch Alexander anspricht - ist die Information ja Tage, wenn nicht Wochen im Voraus bekannt mit offiziellem Start- und Enddatum. Dazu habe ich ursprünglich start_date / end_date vorgeschlagen. Ob die wirklich passend sind, bin ich mir auch nicht mehr sicher, denn diese Angaben beziehen sich auf die Existenz des Objekts und nicht auf Zusatzeigenschaften, auf die ich hinaus will. Besser so? * traffic_obstruction_start=Datum * traffic_obstruction_end=Datum Ich denke, die OSM-Datenbank sollte nur den Normalzustand wiedergeben und nicht den temporären Ausnahmezustand. Ich glaube mittlerweile, dass sich beide Zustände nicht stören müssen. Ich fasse zusammen: * Strassen-Tags (highway) bleiben unberührt * traffic_obstruction=yes/no -- Kennzeichnet eine Verkehrsbehinderung * traffic_obstruction_start=Datum-- Beginn Verkehrsbehinderung (falls bekannt) * traffic_obstruction_end=Datum -- Ende Verkehrsbehinderung (falls bekannt) * emergency=yes/no -- Blaulich-KFz. können trotzdem durchfahren Dies kann evtl. auf einer Webseite oder in Flyern durch Overlays dargestellt werden. Damit kann ich auch leben. Wie gesagt, möchte ich die Möglichkeiten ausloten. LG, Stefan Am 22. Juli 2013 20:25 schrieb Frank fr...@fotodrachen.de: Am 22.07.2013 08:07, schrieb Eckhart Wörner: Hallo Alexander, Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner: Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche neuen Erkenntnisse? • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen • zusätzliche amenities: opening_hours? Eckhart Ich denke, es ging Alexander eher um die Frage, ob man die temporären Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen sollte. Es wäre zwar nett, wenn die Karte auch während des Ausnahmezustandes Stadtfest aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich. Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend eingerichtet wurden. Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie. Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann wochenlang mit diesen Sonder-Anpassungen herum. Auch andere Auszüge werden nicht täglich aktualisiert. Ich denke, die OSM-Datenbank sollte nur den Normalzustand wiedergeben und nicht den temporären Ausnahmezustand. Dies kann evtl. auf einer Webseite oder in Flyern durch Overlays dargestellt werden. -- Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Malte und Henning Falls ihr euch auf die Lösung mit dem Abändern bestender Tags bezieht, muss ich euch vollkommen Recht geben: highway=primary vorübergehend auf highway=construction zu wechseln macht keinen Sinn. Hingegen zeichnet sich eine bessere Lösung mit zusätlichen Tags ab, welche die Wirklichkeit besser abbilden: Vgl. die anderen Mails. LG, Stefan Am 22. Juli 2013 20:44 schrieb Malte Blättermann malte.blaetterm...@gmail.com: Am 22. Juli 2013 18:30 schrieb Henning Scholland o...@aighes.de: Hallo, evtl. ist es nicht das einzige Argument, aber ein sehr wichtiges. Die Mapnikkarte ist die einzige Anwendung, die nahezu in Echtzeit die Daten anzeigt. Allerdings hat man von der Karte nicht viel. Einzig das access einiger Straßen dürfte ein paar rote Punkte auf die Karte zaubern. Alle anderen Anwendungen hinken der Echtzeit um einiges hinterher. So kann es dann sein, dass das Festival eine Woche später dargestellt wird oder einen Monat lang. Einen wirklichen Vorteil des Eintragens kurzfristiger Dinge sehe ich hier nicht. Tendenziell eher einen Nachteil. Sehr gut zusammengefasst! Danke! Gruß Malte ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Am 22.07.2013 21:41, schrieb Stefan Keller: Hallo Malte und Henning Falls ihr euch auf die Lösung mit dem Abändern bestender Tags bezieht, muss ich euch vollkommen Recht geben: highway=primary vorübergehend auf highway=construction zu wechseln macht keinen Sinn. Hingegen zeichnet sich eine bessere Lösung mit zusätlichen Tags ab, welche die Wirklichkeit besser abbilden: Vgl. die anderen Mails. Hallo, ich antworte dir mal auf diese Mail. Ich halte es für vollkommen verkehrt, ein Objekt als X zu taggen, um dann im nächsten Tag zu sagen, es ist Y. Konkret meint das: highway=primary hat eine gewisse Bedeutung. Wenn das Objekt, was ich eintragen möchte aber gar nicht diese Eigenschaften hat, dann ist es auch falsch, dieses Tag zu verwenden. Es ist für jeden Auswerter ein leichtes, highway= construction und construction=primary genauso zu behandeln wie highway=primary. Bei der Sache der kurzfristigen Änderungen geht es nicht darum, wie man einen Renderer überlisten kann, sondern dass es aktuell (meiner Meinung nach) nicht sinnvoll ist, das zu erfassen, weil die meisten Auswertungen ohnehin nicht rechtzeitig die Darstellung ändern und wie bereits gesagt egtl. die Daten für die kurzfristige Änderung schon nutzbar sein müssen, bevor man sie in OSM live schalten kann. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Henning, Es geht nicht darum ein Objekt als X zu taggen, um dann im nächsten Tag zu sagen, es ist Y. Und es geht niemandem um den Renderer. Der aktuelle Vorschlag lautet: Ein highway=primary bleibt ein highway=primary. Es kann nun unbestrittenermassen vorkommen, dass eine Strasse zeitlich angekündigt und befristet für den Verkehr gesperrt ist. Das wird dann mit *zusätzlichen* Tags gekennzeichnet. Navi- und andere Projekte müssen (bzw. können und sollen) diese *zusätzlichen* Tags nicht auswerten. LG, Stefan Am 22. Juli 2013 22:01 schrieb Henning Scholland o...@aighes.de: Am 22.07.2013 21:41, schrieb Stefan Keller: Hallo Malte und Henning Falls ihr euch auf die Lösung mit dem Abändern bestender Tags bezieht, muss ich euch vollkommen Recht geben: highway=primary vorübergehend auf highway=construction zu wechseln macht keinen Sinn. Hingegen zeichnet sich eine bessere Lösung mit zusätlichen Tags ab, welche die Wirklichkeit besser abbilden: Vgl. die anderen Mails. Hallo, ich antworte dir mal auf diese Mail. Ich halte es für vollkommen verkehrt, ein Objekt als X zu taggen, um dann im nächsten Tag zu sagen, es ist Y. Konkret meint das: highway=primary hat eine gewisse Bedeutung. Wenn das Objekt, was ich eintragen möchte aber gar nicht diese Eigenschaften hat, dann ist es auch falsch, dieses Tag zu verwenden. Es ist für jeden Auswerter ein leichtes, highway= construction und construction=primary genauso zu behandeln wie highway=primary. Bei der Sache der kurzfristigen Änderungen geht es nicht darum, wie man einen Renderer überlisten kann, sondern dass es aktuell (meiner Meinung nach) nicht sinnvoll ist, das zu erfassen, weil die meisten Auswertungen ohnehin nicht rechtzeitig die Darstellung ändern und wie bereits gesagt egtl. die Daten für die kurzfristige Änderung schon nutzbar sein müssen, bevor man sie in OSM live schalten kann. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäudenummern auf Firmengelände
Hallo Johannes, jotpe schrieb: wie taggt man eine interne Gebäudenummer eines größeren Firmenareals, die keine amtliche Hausnummer ist? ich benutze für sowas den Key building:ref Grüße, Michael signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo, Am Montag, den 22.07.2013, 22:36 +0200 schrieb Stefan Keller: Hallo Henning, Es geht nicht darum ein Objekt als X zu taggen, um dann im nächsten Tag zu sagen, es ist Y. Und es geht niemandem um den Renderer. Der aktuelle Vorschlag lautet: Ein highway=primary bleibt ein highway=primary. Es kann nun unbestrittenermassen vorkommen, dass eine Strasse zeitlich angekündigt und befristet für den Verkehr gesperrt ist. Das wird dann mit *zusätzlichen* Tags gekennzeichnet. Navi- und andere Projekte müssen (bzw. können und sollen) diese *zusätzlichen* Tags nicht auswerten. Für diese temporären Umleitungen hat man doch die tmc-tags erfunden. Lasst die doch endlich mal funktionieren und lasst das Gebastel an den highways. Alles 1 Jahr - tmc Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Am 22.07.2013, 20:25 Uhr, schrieb Frank fr...@fotodrachen.de: Am 22.07.2013 08:07, schrieb Eckhart Wörner: Hallo Alexander, Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner: Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche neuen Erkenntnisse? • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen • zusätzliche amenities: opening_hours? Eckhart Ich denke, es ging Alexander eher um die Frage, ob man die temporären Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen sollte. Es wäre zwar nett, wenn die Karte auch während des Ausnahmezustandes Stadtfest aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich. Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend eingerichtet wurden. Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie. Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann wochenlang mit diesen Sonder-Anpassungen herum. Auch andere Auszüge werden nicht täglich aktualisiert. Ich denke, die OSM-Datenbank sollte nur den Normalzustand wiedergeben und nicht den temporären Ausnahmezustand. Dies kann evtl. auf einer Webseite oder in Flyern durch Overlays dargestellt werden. Das Problem ist doch, dass das zeitliche Sperren nicht funktioniert und zu lange in der Datenbank bestehen bleibt (oft wird die Sperrung vergessen aus OSM herauszunehmen) Angenommen eine Straße hat das Tagging motorcycle=no + mofa=yes. Nun kommt einer und will die Straße mit access=no sperren. Funktioniert natürlich nicht für Mofas und alle anderen (vorher überflüssigen) *=yes Tags werden zum Verhängnis. date_on date_off geht genausowenig, da nicht klar ist, auf welche Tags es sich bezieht. Eine mögliche Lösung ist eine Baustellen- oder Sperrungs-Relation, die alle access tags der Wege nicht beachtet und mit access=no überschreibt. Gleichzeitig kann die Relation weitere access tags aufnehmen, zB Freigabe für Fußgänger und Radfahrer, oder Freigabe für Anwohner. Bei der Relation MUSS aber mit angegeben werden, von wann - und noch wichtiger - BIS wann gesperrt ist. Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von Routern nicht mehr berücksichtigt werden und aufgrund des Datums können alle überfälligen Baustellen aus der Datenbank gelöscht werden. Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, versteht sich) Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. Falls das Enddatum unbekannt ist, sollte/muss eine Schätzung angegeben werden, damit die Mapper nach der Frist die Baustelle nochmal überprüfen/aktualisieren können. So, das war meine bisherige Überlegung. Aber vielleicht hat jemand noch einen besseren Vorschlag? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programm zur Überwachung von OSM-Relationen
Hallo, Henning Scholland schrieb: ich denke du solltest als erstes hier eine Routine einbauen, die die vorhandenen Daten speichert und nach einem Update zurückspielt. Wenn man nach jedem unvorhersehbarem Update alles neu machen muss, vergeht einem der Spaß recht schnell. was vermisst du denn? Soweit ich das beobachten konnte, ist seit dem Fauxpas beim aller ersten Update nichts mehr verschwunden. Es gibt lediglich Items mit dem Hinweis auf Server-Neustart. Die Feeds blieben aber erhalten, oder täusch ich mich?! Gruß, Peda -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Lieber Wolfgang Am 22. Juli 2013 23:59 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Für diese temporären Umleitungen hat man doch die tmc-tags erfunden. Lasst die doch endlich mal funktionieren und lasst das Gebastel an den highways. Alles 1 Jahr - tmc TMC scheint mind. innerhalb OSM tot zu sein. Vgl. [1]. Und so oder so, scheint mir TMC doch reichlich kompliziert, unzugänglich und daher ungeeignet für diese Zwecke hier. Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse, Landshut, mittels TMC für nächstes Wochenende sperren würde? LG, Stefan P.S. Bitte unterlasse herablassende Ausdrücke wie Gebastel. [1] http://wiki.openstreetmap.org/wiki/DE:TMC Am 22. Juli 2013 23:59 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Hallo, Am Montag, den 22.07.2013, 22:36 +0200 schrieb Stefan Keller: Hallo Henning, Es geht nicht darum ein Objekt als X zu taggen, um dann im nächsten Tag zu sagen, es ist Y. Und es geht niemandem um den Renderer. Der aktuelle Vorschlag lautet: Ein highway=primary bleibt ein highway=primary. Es kann nun unbestrittenermassen vorkommen, dass eine Strasse zeitlich angekündigt und befristet für den Verkehr gesperrt ist. Das wird dann mit *zusätzlichen* Tags gekennzeichnet. Navi- und andere Projekte müssen (bzw. können und sollen) diese *zusätzlichen* Tags nicht auswerten. Für diese temporären Umleitungen hat man doch die tmc-tags erfunden. Lasst die doch endlich mal funktionieren und lasst das Gebastel an den highways. Alles 1 Jahr - tmc Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Wilhelm Spickermann o...@spickermann-d.de wrote: Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden. Darüber müsste man erstmal diskutieren, Hat sich das denn jetzt aufgeklärt oder geht das weiter ? Ich dachte, es hätte aufgehört, aber gerade kam die Änderungsmeldung zum Bahnhof Düsseldorf Flughafen rein. - die Bahnsteige wurden gesplittet. Darüber kann man streiten. - je zwei Hälften wurden zu stop_areas zusammengefasst. Das ist falsch. - der Name der Haltestelle Düsseldorf Flughafen wurde durch Bahnsteig n ersetzt. Ist falsch, steht aber so im Wiki. - Die einzige bisher von mir geprüfte Zuglinie hält jetzt an zwei Bahnsteighälften. Das ist falsch. Aber vielleicht kommt ja noch eine Änderung. Nachdem wir hier kürzlich die Diskussion hatten, dass durch Doppelstreifen getrennte Richtungsfahrbahnen auf autobahnähnlichen Straßen wegen fehlender baulicher Trennung nicht zu einer Trennung auf OSM führen sollen, ist ein Splitten von Bahnsteighälften noch weniger berechtigt. Dort existiert im Unterschied zu den Straßen in der Realität weder eine Trennungslinie noch eine verbotene Zone noch ein Übergangsverbot. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Proposal
Hi, nach einer Diskussion im Forum (http://forum.openstreetmap.org/viewtopic.php?id=21908) habe ich die ursprünglich gestrichenen Segment-Relationen wieder eingebaut. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
