Re: [Talk-de] Voting zu use_sidepath läuft
Vielleicht sollte ich meine Meinung etwas ausführlicher begründen. Ich verstehe, das das gerade das Fahrradrouting mit dem Tag deutlich verbessert werden kann. Ausserdem ist bicycle=designated ja in einem anderen Talk noch als unscharf dargestellt, was aber nicht dazu führen sollte, ein zweites Tag einzuführen um die Schärfe des ersten zu verbessern. Dennoch halte ich es für ein maschinenlösbares Problem aus bicycle=designated (Mit Schild) und der Benutzungspflicht abzuleiten, dass eine Strasse durch Fahrräder nicht befahren werden darf. Das das eventuell nicht in einem Smartphone gelöst werden kann, heisst ja nicht, das die Arbeit an 2.000 Mapper gegeben werden muss, um die Basisdaten anzureichern. Was spricht dagegen, unsere Daten in einer abgeleiteten Version fürs Routing zur Verfügung zu stellen. Citylimit, Radwegbenutzung, detaillierte Abbiegevorschriften, alles was Router glücklich macht, könnte in diesen Daten drin sein. Skobbler rechnet die Basisdaten auch routing tauglich um, bevor sie das in das Handy schicken. Heraus käme z.B. eine modifizierte Overpass, die entsprechend maschinell gesetzte Tags verbreitet. Und wenn wir feststellen, das es für die Router besser ist, die Maxheight von einer Brücke an bestimmte Strassen zu vererben, um das LKW Routing zu verbessern, kann das da auch gemacht werden. Wir halten unser Datenmodell sauber, beschäftigen und die Mapper müssen nicht 10-20% der Strassen mit einem Zusatztag versehen, die Anreicherung würde sogar direkt QA Ergebnisse liefern. Den Beweis, das das Problem maschinenlösbar ist, kann ich leider nicht persönlich antreten (mein C++ ist zu lange her), aber vielleicht liest ja jemand mit, der Bachelorarbeiten vergiibt :-) Christoph Am 10.05.2014 um 07:55 schrieb Christoph thefive@gmail.com: Ich dachte das implitize 50 wäre maxspeed =citylimit Ich mappe innerorts die 50 nur bei Schildern mit 50. Sent from my iDingens Am 10.05.2014 um 00:39 schrieb Alexander Heinlein alexander.heinl...@web.de: On Fri, May 09, 2014 at 10:23:08PM +0200, Christoph (TheFive@OSM) wrote: Am 09.05.2014 um 21:31 schrieb Masi Master masi-mas...@gmx.de: Die blauen Radweg-Schilder geben normale Beschränkungen wieder und gelten für Radweg UND Fahrbahn, also sollte auch beides getaggt werden. Hat erstmal nix mit dem Routing zu tun. bicycle=designated ist zu schwammig formuliert. In Deutschland, aber vor allem weltweit. Das Andere ist, dass das Bevorzugen von bicycle=designated-Radwegen nicht funktioniert. Der Radweg kann länger als die Fahrbahn sein und wird teils deswegen nicht bevorzugt. Oder es wird nur auf Radwegen geroutet. Außerdem funktioniert kürzeste Route (nach StVO) nicht, bei unterschiedlicher Gewichtung. Sorry, das sind Implementierungsdetails für mich. Bevorzugung ist eine Möglichkeit ein Benutzungsbebot abzubilden. Schon sprachlich (ohne Implementierungsdetails) merkt man, das ein gebot und eine Bevorzugung andere Schwerpunkte haben, das also nicht klappen kann. Für mich ist das sich aus einem gemappten Schild abgeleitete Benutzungsverbot auf einer Parallelstrasse nicht on the ground, sondern in the law, gehört daher nicht in OSM. Ich denke nicht dass man von einem Router erwarten kann sämtliche Sonderregeln aller Länder dieser Welt zu kennen. Das implizite maxspeed=50 innerorts taggen wir doch auch explizit. Daher finde ich die Idee mit use_sidepath gut. Es macht komplizierte Heuristiken in Routern, die sowieso nie immer das richtige Ergebnis liefern können, unnötig und ist für Mapper on the ground auch ziemlich einfach überprüfbar. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting zu use_sidepath läuft
maxspeed = 50 wäre auch falsch. Die implizite Geschwindigkeitsbegrenzung innerorts gilt nämlich nur für Kraftfahrzeuge, die explizite allerdings für alle Fahrzeuge. Daher ist es wichtig, dass man zwischen beiden unterscheiden kann. Ähnlich sollte man zwischen man zwischen einer Benutzungspflicht des Radweges und einem Benutzungsverbot der Fahrbahn unterscheiden. Ist der Radweg nicht benutzbar (zu eng für das eigene Fahrrad, zugeparkt, zugestellt, etc.) oder führt nicht in die gewünschte Richtung (z.B. beim Linksabbiegen oder bei Radwegen, die im weiteren Verlauf nicht mehr fahrbahnbegleitend geführt werden), so darf natürlich auch mit dem Rad die Fahrbahn benutzt werden. Bei einem expliziten Benutzungsverbot auf der Fahrbahn wäre dies nicht mehr möglich. Am 10.05.2014 07:55, schrieb Christoph: Ich dachte das implitize 50 wäre maxspeed =citylimit Ich mappe innerorts die 50 nur bei Schildern mit 50. Sent from my iDingens Am 10.05.2014 um 00:39 schrieb Alexander Heinlein alexander.heinl...@web.de: On Fri, May 09, 2014 at 10:23:08PM +0200, Christoph (TheFive@OSM) wrote: Am 09.05.2014 um 21:31 schrieb Masi Master masi-mas...@gmx.de: Die blauen Radweg-Schilder geben normale Beschränkungen wieder und gelten für Radweg UND Fahrbahn, also sollte auch beides getaggt werden. Hat erstmal nix mit dem Routing zu tun. bicycle=designated ist zu schwammig formuliert. In Deutschland, aber vor allem weltweit. Das Andere ist, dass das Bevorzugen von bicycle=designated-Radwegen nicht funktioniert. Der Radweg kann länger als die Fahrbahn sein und wird teils deswegen nicht bevorzugt. Oder es wird nur auf Radwegen geroutet. Außerdem funktioniert kürzeste Route (nach StVO) nicht, bei unterschiedlicher Gewichtung. Sorry, das sind Implementierungsdetails für mich. Bevorzugung ist eine Möglichkeit ein Benutzungsbebot abzubilden. Schon sprachlich (ohne Implementierungsdetails) merkt man, das ein gebot und eine Bevorzugung andere Schwerpunkte haben, das also nicht klappen kann. Für mich ist das sich aus einem gemappten Schild abgeleitete Benutzungsverbot auf einer Parallelstrasse nicht on the ground, sondern in the law, gehört daher nicht in OSM. Ich denke nicht dass man von einem Router erwarten kann sämtliche Sonderregeln aller Länder dieser Welt zu kennen. Das implizite maxspeed=50 innerorts taggen wir doch auch explizit. Daher finde ich die Idee mit use_sidepath gut. Es macht komplizierte Heuristiken in Routern, die sowieso nie immer das richtige Ergebnis liefern können, unnötig und ist für Mapper on the ground auch ziemlich einfach überprüfbar. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting zu use_sidepath läuft
Das zugeparkt Thema halte ich hier für falsch, das wollen doch nich auch noch mappen. Das Routingvorschläge manchmal durch das normale leben überholt werden, ist wohl so. Ich war auch schon mal polizeilich angeordneter Geisterfahrer. Ein nicht benutzbarer Radweg darf natürlich auch erfasst werden, auch wenn die Radfahrer da unterschiedliche Massstäbe anlegen. Das sind aber auch Sonderfälle, die wir aus der Diskussion raushalten sollten. Das das Proposal ohne Richtungsangabe auskommt, habe ich dort schon auf der Diskussionsseite angemerkt. Christoph Sent from my iDingens Am 10.05.2014 um 10:20 schrieb Steffen van Bergerem svberge...@online.de: maxspeed = 50 wäre auch falsch. Die implizite Geschwindigkeitsbegrenzung innerorts gilt nämlich nur für Kraftfahrzeuge, die explizite allerdings für alle Fahrzeuge. Daher ist es wichtig, dass man zwischen beiden unterscheiden kann. Ähnlich sollte man zwischen man zwischen einer Benutzungspflicht des Radweges und einem Benutzungsverbot der Fahrbahn unterscheiden. Ist der Radweg nicht benutzbar (zu eng für das eigene Fahrrad, zugeparkt, zugestellt, etc.) oder führt nicht in die gewünschte Richtung (z.B. beim Linksabbiegen oder bei Radwegen, die im weiteren Verlauf nicht mehr fahrbahnbegleitend geführt werden), so darf natürlich auch mit dem Rad die Fahrbahn benutzt werden. Bei einem expliziten Benutzungsverbot auf der Fahrbahn wäre dies nicht mehr möglich. Am 10.05.2014 07:55, schrieb Christoph: Ich dachte das implitize 50 wäre maxspeed =citylimit Ich mappe innerorts die 50 nur bei Schildern mit 50. Sent from my iDingens Am 10.05.2014 um 00:39 schrieb Alexander Heinlein alexander.heinl...@web.de: On Fri, May 09, 2014 at 10:23:08PM +0200, Christoph (TheFive@OSM) wrote: Am 09.05.2014 um 21:31 schrieb Masi Master masi-mas...@gmx.de: Die blauen Radweg-Schilder geben normale Beschränkungen wieder und gelten für Radweg UND Fahrbahn, also sollte auch beides getaggt werden. Hat erstmal nix mit dem Routing zu tun. bicycle=designated ist zu schwammig formuliert. In Deutschland, aber vor allem weltweit. Das Andere ist, dass das Bevorzugen von bicycle=designated-Radwegen nicht funktioniert. Der Radweg kann länger als die Fahrbahn sein und wird teils deswegen nicht bevorzugt. Oder es wird nur auf Radwegen geroutet. Außerdem funktioniert kürzeste Route (nach StVO) nicht, bei unterschiedlicher Gewichtung. Sorry, das sind Implementierungsdetails für mich. Bevorzugung ist eine Möglichkeit ein Benutzungsbebot abzubilden. Schon sprachlich (ohne Implementierungsdetails) merkt man, das ein gebot und eine Bevorzugung andere Schwerpunkte haben, das also nicht klappen kann. Für mich ist das sich aus einem gemappten Schild abgeleitete Benutzungsverbot auf einer Parallelstrasse nicht on the ground, sondern in the law, gehört daher nicht in OSM. Ich denke nicht dass man von einem Router erwarten kann sämtliche Sonderregeln aller Länder dieser Welt zu kennen. Das implizite maxspeed=50 innerorts taggen wir doch auch explizit. Daher finde ich die Idee mit use_sidepath gut. Es macht komplizierte Heuristiken in Routern, die sowieso nie immer das richtige Ergebnis liefern können, unnötig und ist für Mapper on the ground auch ziemlich einfach überprüfbar. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting zu use_sidepath läuft
Anscheinend habe ich mich in meiner Mail missverständlich ausgedrückt. Ich wollte nicht aussagen, dass zugeparkte oder nicht benutzbare Radwege besonders getaggt werden müssen. Ich wollte lediglich begründen, warum bicycle=no ohne entsprechendes explizites Verbot nicht sinnvoll ist, da dieser Vorschlag ebenfalls erwähnt wurde. Gruß Steffen Am 10.05.2014 10:41, schrieb Christoph: Das zugeparkt Thema halte ich hier für falsch, das wollen doch nich auch noch mappen. Das Routingvorschläge manchmal durch das normale leben überholt werden, ist wohl so. Ich war auch schon mal polizeilich angeordneter Geisterfahrer. Ein nicht benutzbarer Radweg darf natürlich auch erfasst werden, auch wenn die Radfahrer da unterschiedliche Massstäbe anlegen. Das sind aber auch Sonderfälle, die wir aus der Diskussion raushalten sollten. Das das Proposal ohne Richtungsangabe auskommt, habe ich dort schon auf der Diskussionsseite angemerkt. Christoph Sent from my iDingens Am 10.05.2014 um 10:20 schrieb Steffen van Bergerem svberge...@online.de: maxspeed = 50 wäre auch falsch. Die implizite Geschwindigkeitsbegrenzung innerorts gilt nämlich nur für Kraftfahrzeuge, die explizite allerdings für alle Fahrzeuge. Daher ist es wichtig, dass man zwischen beiden unterscheiden kann. Ähnlich sollte man zwischen man zwischen einer Benutzungspflicht des Radweges und einem Benutzungsverbot der Fahrbahn unterscheiden. Ist der Radweg nicht benutzbar (zu eng für das eigene Fahrrad, zugeparkt, zugestellt, etc.) oder führt nicht in die gewünschte Richtung (z.B. beim Linksabbiegen oder bei Radwegen, die im weiteren Verlauf nicht mehr fahrbahnbegleitend geführt werden), so darf natürlich auch mit dem Rad die Fahrbahn benutzt werden. Bei einem expliziten Benutzungsverbot auf der Fahrbahn wäre dies nicht mehr möglich. Am 10.05.2014 07:55, schrieb Christoph: Ich dachte das implitize 50 wäre maxspeed =citylimit Ich mappe innerorts die 50 nur bei Schildern mit 50. Sent from my iDingens Am 10.05.2014 um 00:39 schrieb Alexander Heinlein alexander.heinl...@web.de: On Fri, May 09, 2014 at 10:23:08PM +0200, Christoph (TheFive@OSM) wrote: Am 09.05.2014 um 21:31 schrieb Masi Master masi-mas...@gmx.de: Die blauen Radweg-Schilder geben normale Beschränkungen wieder und gelten für Radweg UND Fahrbahn, also sollte auch beides getaggt werden. Hat erstmal nix mit dem Routing zu tun. bicycle=designated ist zu schwammig formuliert. In Deutschland, aber vor allem weltweit. Das Andere ist, dass das Bevorzugen von bicycle=designated-Radwegen nicht funktioniert. Der Radweg kann länger als die Fahrbahn sein und wird teils deswegen nicht bevorzugt. Oder es wird nur auf Radwegen geroutet. Außerdem funktioniert kürzeste Route (nach StVO) nicht, bei unterschiedlicher Gewichtung. Sorry, das sind Implementierungsdetails für mich. Bevorzugung ist eine Möglichkeit ein Benutzungsbebot abzubilden. Schon sprachlich (ohne Implementierungsdetails) merkt man, das ein gebot und eine Bevorzugung andere Schwerpunkte haben, das also nicht klappen kann. Für mich ist das sich aus einem gemappten Schild abgeleitete Benutzungsverbot auf einer Parallelstrasse nicht on the ground, sondern in the law, gehört daher nicht in OSM. Ich denke nicht dass man von einem Router erwarten kann sämtliche Sonderregeln aller Länder dieser Welt zu kennen. Das implizite maxspeed=50 innerorts taggen wir doch auch explizit. Daher finde ich die Idee mit use_sidepath gut. Es macht komplizierte Heuristiken in Routern, die sowieso nie immer das richtige Ergebnis liefern können, unnötig und ist für Mapper on the ground auch ziemlich einfach überprüfbar. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting zu use_sidepath läuft
On Sat, May 10, 2014 at 08:30:36AM +0200, Christoph (TheFive@OSM) wrote: Was spricht dagegen, unsere Daten in einer abgeleiteten Version fürs Routing zur Verfügung zu stellen. Citylimit, Radwegbenutzung, detaillierte Abbiegevorschriften, alles was Router glücklich macht, könnte in diesen Daten drin sein. Skobbler rechnet die Basisdaten auch routing tauglich um, bevor sie das in das Handy schicken. Heraus käme z.B. eine modifizierte Overpass, die entsprechend maschinell gesetzte Tags verbreitet. Und wenn wir feststellen, das es für die Router besser ist, die Maxheight von einer Brücke an bestimmte Strassen zu vererben, um das LKW Routing zu verbessern, kann das da auch gemacht werden. Vieles: - Das weltweite vorverarbeiten dieser Daten ist entsprechend ressourcenintensiv (Rechenpower, Speicherplatz, Traffic) - Man kann diese Routingdaten vermutlich nicht tagesaktuell anbieten - Jemand müsste so einen komplexen Algorithmus überhaupt erst mal implementieren und ständig pflegen - Sowohl der allgemeine Mapper als auch die Entwickler von Endanwendungen haben dadurch keine direkte Möglichkeit mehr, Routingfehler zu korrigieren, die aufrgrund von Bugs in dieser Vorverarbeitung entstanden sind. Es entsteht eine Zwischenschicht, die untransparent ist und das Debugging unglaublich erschwert. - Router, die zusätzlich zur Berechnung der Strecke auch eine Karte anzeigen wollen, müssen sich zusätzlich zu diesen vorverarbeiteten Daten auch den Planet besorgen. Im schlimmsten Fall passt auch dann die Routen- darstellung mit der restlichen Kartendarstellung nicht mehr überein, weil beide Datensätze nicht auf dem gleichen Stand sind. Klar hat es auch Vorteile einen zentralen Algorithmus zu haben, den nicht jeder Router neu implementieren muss. Den sollte man aber besser als eine Bibliothek bereitstellen, und nicht als vorverarbeitenden Datensatz. Ich dachte das implitize 50 wäre maxspeed =citylimit Ich mappe innerorts die 50 nur bei Schildern mit 50. maxspeed=citylimit gibt es nicht. Du meinst anscheinend maxspeed=50 und source:maxspeed=DE:urban. Auch da wird das implizite maxspeed explizit getaggt. Oder dachtest du an maxspeed=DE:urban? Das gibt es nur 219 mal und ist laut Wiki nur in Rumänien verbreitet (da natürlich nicht mit DE :)), sollte daher nicht verwendet werden. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation Harz (Mittelgebirge)
Am 10. Mai 2014 02:39 schrieb Frederik Ramm frede...@remote.org: Für uns ist es wichtig, dass im Zweifel jemand hingehen und die Sache verifizieren kann. Wie soll das gehen mit dem Harz? Da es sich beim Harz um ein Mittelgebirge handelt wird ein Mapper vor Ort wohl zumindest verifizieren können, dass da Berge stehen. Zieht man dann noch Höhendaten hinzu und liest die Definition von Mittelgebirgen auf Wikipedia dann kann selbst ich als Nicht-Geologe einigermaßen abschätzen wo ca. die Grenzen des Harz verlaufen. Nur weil etwas schwierig zu verifizieren ist kann das doch kein Grund sein, es nicht einzutragen. Manchmal muss man sich halt auch auf Experten verlassen die mehr Ahnung von der Materie haben. Wem die Grenzen zu ungenau sind der muss sie ja nicht nutzen. Einen Nutzen hat die Erfassung solcher Regionen durchaus, sei es für Karten, aber z.B. auch TMC hat Codes für Regionen, Unwetterwarnungen für bestimmte Regionen, ... Gruß Archer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting zu use_sidepath läuft
Hallo Alex, Streckenweise gebe ich Dir recht, einige Argumente klingen so, als ob ein gewissen Mr. Coast sie vor 10 Jahren auch gehört hat. Wir kloppen uns hier doch permanent über redundante Tags: addr:city ja nein… Adresse im POI oder im Gebäude oder in beides… Ich glaube, das es sinnvoll sein kann gewünschte Redundanzen zentral zur Verfügung zu stellen, die Entwickler dürfen die Algorithmen zur Ermittlung auch gerne so implementieren, das sie client und serverseitig nutzbar sind. Open Source wäre auch nicht schlecht :-) Am 10.05.2014 um 11:39 schrieb Alexander Heinlein alexander.heinl...@web.de: On Sat, May 10, 2014 at 08:30:36AM +0200, Christoph (TheFive@OSM) wrote: Was spricht dagegen, unsere Daten in einer abgeleiteten Version fürs Routing zur Verfügung zu stellen. Citylimit, Radwegbenutzung, detaillierte Abbiegevorschriften, alles was Router glücklich macht, könnte in diesen Daten drin sein. Skobbler rechnet die Basisdaten auch routing tauglich um, bevor sie das in das Handy schicken. Heraus käme z.B. eine modifizierte Overpass, die entsprechend maschinell gesetzte Tags verbreitet. Und wenn wir feststellen, das es für die Router besser ist, die Maxheight von einer Brücke an bestimmte Strassen zu vererben, um das LKW Routing zu verbessern, kann das da auch gemacht werden. Vieles: - Das weltweite vorverarbeiten dieser Daten ist entsprechend ressourcenintensiv (Rechenpower, Speicherplatz, Traffic) wenn ich mir die Overpass API anschaue, scheint das nicht unlösbar zu sein. - Man kann diese Routingdaten vermutlich nicht tagesaktuell anbieten Ja. Ist das schlimm ? Früher haben die Kartenupdates auch Tage gebraucht. Heute nicht mehr. - Jemand müsste so einen komplexen Algorithmus überhaupt erst mal implementieren und ständig pflegen Korrekt, die Alternative in dem konkreten Fall wäre, das jemand (viele) den komplexen Algorithmus von Hand ausführen und partiell nachtaggen. das wird NIE vollständig werden. Da ist mir einmal kräftiger Gehirnschmalz mit vollständig und konsistenem Ergebnis lieber. - Sowohl der allgemeine Mapper als auch die Entwickler von Endanwendungen haben dadurch keine direkte Möglichkeit mehr, Routingfehler zu korrigieren, die aufrgrund von Bugs in dieser Vorverarbeitung entstanden sind. Es entsteht eine Zwischenschicht, die untransparent ist und das Debugging unglaublich erschwert. ?? Wir sind ein OpenSource Projekt, ich kann auch keinen Kartenstil machen. Trotzdem ist das Ergebnis der Renderer Zeichner und unserer Arbeit super. Fehler im Renderer kann ich melden und sie werden gefixt. Das ist Arbeitsteilung und für mich kein Problem. Ich kann umschulen und mich am Renderer Projekt beteiligen. Die komplexe Materie OSM beherrschen wir nur, weil wir arbeitsteilig arbeiten. Benutzt jemand jetzt die Overpass hat er das gleiche Problem, im Falle von Fehlern in der Software. - Router, die zusätzlich zur Berechnung der Strecke auch eine Karte anzeigen wollen, müssen sich zusätzlich zu diesen vorverarbeiteten Daten auch den Planet besorgen. Im schlimmsten Fall passt auch dann die Routen- darstellung mit der restlichen Kartendarstellung nicht mehr überein, weil beide Datensätze nicht auf dem gleichen Stand sind. Ja, halte ich für vernachlässigbar. Löscht jemand zur Zeit 500 Strassen in Bremen, so wird der Router im schlimmsten Fall gar nicht mehr Bescheid wissen. (Real existierendes Beispiel) Klar hat es auch Vorteile einen zentralen Algorithmus zu haben, den nicht jeder Router neu implementieren muss. Den sollte man aber besser als eine Bibliothek bereitstellen, und nicht als vorverarbeitenden Datensatz. Ich dachte das implitize 50 wäre maxspeed =citylimit Ich mappe innerorts die 50 nur bei Schildern mit 50. maxspeed=citylimit gibt es nicht. Du meinst anscheinend maxspeed=50 und source:maxspeed=DE:urban. Auch da wird das implizite maxspeed explizit getaggt. Oder dachtest du an maxspeed=DE:urban? Das gibt es nur 219 mal und ist laut Wiki nur in Rumänien verbreitet (da natürlich nicht mit DE :)), sollte daher nicht verwendet werden. Danke, dann wurde das so gelöst, klingt auch bessern. im wesentlichen plädiere ich auch nur dafür, die Aufnahme redundanter Tags nach Möglichkeit zu vermeiden. Und wollte eine (nicht die ultimative) Lösung vorschlagen, die durchaus nachvollziehbaren Probleme der Router zu lösen. Die Technik wird sich schneller weiterentwickeln, als wir das überflüssige Tagging wieder loswerden. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
On Saturday 10 May 2014, Archer wrote: Da es sich beim Harz um ein Mittelgebirge handelt wird ein Mapper vor Ort wohl zumindest verifizieren können, dass da Berge stehen. Zieht man dann noch Höhendaten hinzu und liest die Definition von Mittelgebirgen auf Wikipedia dann kann selbst ich als Nicht-Geologe einigermaßen abschätzen wo ca. die Grenzen des Harz verlaufen. Nur weil etwas schwierig zu verifizieren ist kann das doch kein Grund sein, es nicht einzutragen. Umgekehrt herum wird ein Schuh draus - nur weil etwas unzweifelhaft existiert bedeutet das noch lange nicht, das man es sinnvoll in OSM erfassen kann. Der Punkt hier ist, dass die einzige Möglichkeit, so etwas derzeit in OSM einzutragen, mittels eines Polygons ist - welches selbst dann, wenn man es nur 'ungefähr' einzeichnet mit großen Abständen zwischen den Nodes immer eine scharfe Grenze beschreibt und diese ist nicht verifizierbar. Das ist keine Frage von fehlender Fachkenntnis oder Aufwand bei der Ermittlung sondern liegt in der grundsätzlichen Natur der Sache, der Harz hat keine scharfe Grenze egal ob man ihn als geologische, topographische oder naturräumliche Einheit betrachtet. Es wären durchaus Methoden denkbar, solche Strukturen in OSM zu erfassen, beispielsweise könnte man einen Relationstyp vereinbaren, der einen inneren und einen äußeren Perimeter enthält. Der innere Perimeter wäre dadurch definiert, das alles innerhalb dessen unbestritten zur beschriebenen Region gehört und der äußere Perimeter würde festlegen, das alles außerhalb dessen unbestritten nicht dazu gehört. Der Raum zwischen den beiden Grenzen würde also gewissermaßen das Streuband aller Meinungen zur Abgrenzung des Gebietes darstellen. Die Frage ist allerdings natürlich, ob so etwas praktisch handhabbar ist - sowohl in der Erfassung als auch in der Auswertung. Und für die beiden Perimeter gäbe es individuell immer noch das Problem der Überprüfbarkeit, das würde durch eine solche Konstruktion zwar entschärft aber nicht wirklich gelöst. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
Am 10. Mai 2014 12:59 schrieb Christoph Hormann chris_horm...@gmx.de: On Saturday 10 May 2014, Archer wrote: Da es sich beim Harz um ein Mittelgebirge handelt wird ein Mapper vor Ort wohl zumindest verifizieren können, dass da Berge stehen. Zieht man dann noch Höhendaten hinzu und liest die Definition von Mittelgebirgen auf Wikipedia dann kann selbst ich als Nicht-Geologe einigermaßen abschätzen wo ca. die Grenzen des Harz verlaufen. Nur weil etwas schwierig zu verifizieren ist kann das doch kein Grund sein, es nicht einzutragen. Umgekehrt herum wird ein Schuh draus - nur weil etwas unzweifelhaft existiert bedeutet das noch lange nicht, das man es sinnvoll in OSM erfassen kann. Der Punkt hier ist, dass die einzige Möglichkeit, so etwas derzeit in OSM einzutragen, mittels eines Polygons ist - welches selbst dann, wenn man es nur 'ungefähr' einzeichnet mit großen Abständen zwischen den Nodes immer eine scharfe Grenze beschreibt und diese ist nicht verifizierbar. Das ist keine Frage von fehlender Fachkenntnis oder Aufwand bei der Ermittlung sondern liegt in der grundsätzlichen Natur der Sache, der Harz hat keine scharfe Grenze egal ob man ihn als geologische, topographische oder naturräumliche Einheit betrachtet. Es wären durchaus Methoden denkbar, solche Strukturen in OSM zu erfassen, beispielsweise könnte man einen Relationstyp vereinbaren, der einen inneren und einen äußeren Perimeter enthält. Der innere Perimeter wäre dadurch definiert, das alles innerhalb dessen unbestritten zur beschriebenen Region gehört und der äußere Perimeter würde festlegen, das alles außerhalb dessen unbestritten nicht dazu gehört. Der Raum zwischen den beiden Grenzen würde also gewissermaßen das Streuband aller Meinungen zur Abgrenzung des Gebietes darstellen. Die Frage ist allerdings natürlich, ob so etwas praktisch handhabbar ist - sowohl in der Erfassung als auch in der Auswertung. Und für die beiden Perimeter gäbe es individuell immer noch das Problem der Überprüfbarkeit, das würde durch eine solche Konstruktion zwar entschärft aber nicht wirklich gelöst. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de Unscharfe Grenzen kommen doch in der Natur relativ häufig vor, z.B. die Waldgrenze/Baumgrenze. Erfasst werden Wälder in OSM trotzdem als Polygone. Irgendwo muss man halt einfach eine Grenze ziehen, auch wenn diese unter Umständen nicht optimal ist. Eine Lösung mit innerer und äußerer Perimeter hätte aber natürlich mehr Charme. Gruß Archer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 9. Mai 2014 19:08 schrieb Hubert sg.fo...@gmx.de: die Grüne Box hab ich nicht gesehen. Müsste aufjedenfall mal überarbeitet werden. Ob vorgesehe, gewidmet oder ausgeschildert eingesetzt werden soll, hängt davon ab, was man unter designated versteht. Ich verstehe darunter alle ausgeschilderten Wege (Blaue VZ 237,240,241 oder eventuell sogar Radroutenschilder) aber auch rechte nichtbenutzungpflichtige Radwege (ohne jegliche Beschilderung). Daher empfinde ich verpflichtend auf den Fall als Falsch und ausgeschildert dementsprechend auch nicht passend. designated=value ist, wenn ich das richtig sehe nichts anderes und allgemein gebräuchliche Kurzform von access=designated, designated=value. Wir verwenden aber immer nur bicycle=designated und foot=designated Wie so oft bei OSM passt key=designated natürlich nicht bruchfrei zu access=value, wie es sonst verwendet wird. Sind auch Fälle denkbar wie: access=all, designated=[bestimmtes Fahrzeug]? bicycle=designated und foot=designated wird insbesondere im Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt es aber eigentlich access=designated, designated=bicycle, designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen sind. Alles höchst unbefriedigend, höchst unbefriedigend ... Oder gelingt es jemandem von euch designated und access in ein logisches und für OSM konsistentes Schema zu bringen? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting zu use_sidepath läuft
Christoph (TheFive@OSM) schrieb: Nach meiner Information ist in Deutschland ein ausgezeichneter Radweg benutztungspflichtig. Die Verkehrszeichen 237, 240, und 241 geben eine Benutzungspflicht an. In allen anderen Fällen gilt, dass der Radweg benutzt werden DARF, wenn er vorhanden ist, und auf der Fahrbahn gefahren werden MUSS, wenn kein Radweg vorhanden ist. Benutzungspflichtige Radwege muss man NICHT benutzen, wenn sie nicht Straßenbegleitend sind, wenn sie nicht benutzbar sind, oder wenn sie unzumutbar sind. Straßenbegleitend sind Radwege dann, wenn sie im Mittel nicht mehr als 5 Meter von der Hauptfahrbahn entfernt sind. Wenn ein Radweg nicht dieselben Vorfahrtsregeln wie die Kfz-Fahrbahn hat, gilt er ebenfalls nicht als Straßenbegleitend, und muss nicht genutzt werden. Unbenutzbar sind Radwege, die zugeparkt oder verstellt sind, oder wenn sie als Fußweg missbraucht werden, keinen Winterdienst erhalten haben, obwohl die Fahrbahn aber geräumt wurde, oder sonstwie blockiert sind. In solchen Fällen darf Abschnittsweise auf die Fahrbahn, aber nicht auf den Gehweg ausgewichen werden. Unzumutbare Radwege sind Radwege, die zum Beispiel alle paar Meter unter die Kategorie „Unbenutzbar“ fallen, stark beschädigt sind, starke Verschmutzung aufweisen, oder es gefährlicher ist, sie zu benutzen, statt auf der Fahrbahn zu fahren (bei Sturm unter stark schwankenden Ästen hinzurch, z.B.). Des weiteren gibt es Radfahrstreifen, die durch Zeichen 295 (breite, durchgezogene Linie) von der Fahrbahn abgegrenzt sind. Wenn sie zudem benutzbar und zumutbar (s.o.) sind, sind sie ebenfalls benutzungspflichtig. Seitenstreifen (Zeichen 295, durchgezogene Linie) dürfen benutzt werden, müssen es aber nicht, wenn sie nicht durch ein Schild als Radfahrstreifen ausgewiesen sind. Ebenfalls dürfen Radfahrer auf dem Seitenstreifen keine Fußgänger behindern, und sie müssen ihn sich mit anderen langsamen Fahrzeugen, sowie parkenden und haltenden Fahrzeugen teilen. Freigegebene Gehwege (Zeichen 239 in Kombination mit Zeichen 1022-10) DÜRFEN verwendet werden, aber nur in Schrittgeschwindigkeit, MÜSSEN es aber nicht. Fußgänger haben immer Vorrang. Die Situation ist doch mit bicycle = designated ordentlich gemappt.. Offensichtlich: Nein. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2014-05-10T13:46:22+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Falk Zscheile schrieb: bicycle=designated und foot=designated wird insbesondere im Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt es aber eigentlich access=designated, designated=bicycle, designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen sind. Zumindest beim Zeichen 241 gilt es eben nicht, da es sich hier rechtlich um zwei direkt nebeneinanderliegende Wege handelt, einen für Fußgänger, und einen für Radfahrer. Streng genommen müssten also zwei Wege gemappt werden, einen mit „access=designated, designated=bicycle“, und einen mit „access=designated, designated=foot“ … Wobei die diversen Sonderfälle und Ausnahmen von der Benutzungspflicht hier noch gar nicht berücksichtigt sind … Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2014-05-10T14:13:24+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Hey, das wird schwierig. Besonders in Hinblick auf backward-capability. Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu highway=footway + footway=sidewalk/crossing. Von der Key:bicycle-Seite steht zu der Werten nur: For values see access=*. (Wäre übrigens ein Grund bicycle=use_sidepath nicht zu erlauben) Gruß Hubert Am 10. Mai 2014 13:51 schrieb Falk Zscheile falk.zsche...@gmail.com: Am 9. Mai 2014 19:08 schrieb Hubert sg.fo...@gmx.de: die Grüne Box hab ich nicht gesehen. Müsste aufjedenfall mal überarbeitet werden. Ob vorgesehe, gewidmet oder ausgeschildert eingesetzt werden soll, hängt davon ab, was man unter designated versteht. Ich verstehe darunter alle ausgeschilderten Wege (Blaue VZ 237,240,241 oder eventuell sogar Radroutenschilder) aber auch rechte nichtbenutzungpflichtige Radwege (ohne jegliche Beschilderung). Daher empfinde ich verpflichtend auf den Fall als Falsch und ausgeschildert dementsprechend auch nicht passend. designated=value ist, wenn ich das richtig sehe nichts anderes und allgemein gebräuchliche Kurzform von access=designated, designated=value. Wir verwenden aber immer nur bicycle=designated und foot=designated Wie so oft bei OSM passt key=designated natürlich nicht bruchfrei zu access=value, wie es sonst verwendet wird. Sind auch Fälle denkbar wie: access=all, designated=[bestimmtes Fahrzeug]? bicycle=designated und foot=designated wird insbesondere im Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt es aber eigentlich access=designated, designated=bicycle, designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen sind. Alles höchst unbefriedigend, höchst unbefriedigend ... Oder gelingt es jemandem von euch designated und access in ein logisches und für OSM konsistentes Schema zu bringen? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting zu use_sidepath läuft
Moin, Am Freitag, den 09.05.2014, 21:31 +0200 schrieb Masi Master: Die blauen Radweg-Schilder geben normale Beschränkungen wieder und gelten für Radweg UND Fahrbahn, also sollte auch beides getaggt werden. Hat erstmal nix mit dem Routing zu tun. bicycle=designated ist zu schwammig formuliert. In Deutschland, aber vor allem weltweit. Das Andere ist, dass das Bevorzugen von bicycle=designated-Radwegen nicht funktioniert. Der Radweg kann länger als die Fahrbahn sein und wird teils deswegen nicht bevorzugt. Oder es wird nur auf Radwegen geroutet. Außerdem funktioniert kürzeste Route (nach StVO) nicht, bei unterschiedlicher Gewichtung. Also wenn ich mit dem Fahrrad fahre, dann brauche ich ein Navi nur für die grobe Richtung und nicht um mir zu zeigen ob ich einen Fahrradweg oder eine Straße benutzten darf oder nicht. Dafür habe ich zwei Augen, die Ihre Signale an mein Gehirn weiterleiten und dort viel besser als in einem Navi verarbeitet werden. Dann passiert es auch nicht wie der Frau aus Belgien, die ins Nachbardorf wollte und auf dem Balkan ankam, weil das Navi sie so geschickt hat. Am 09.05.2014, 06:51 Uhr, schrieb Christoph (TheFive@OSM) thefive@gmail.com: Nach meiner Information ist in Deutschland ein ausgezeichneter Radweg benutztungspflichtig. Ist das nicht aber mappen für die Router ? Die Situation ist doch mit bicycle = designated ordentlich gemappt.. +1 Und demnächst werden dann bestimmt noch Regeln für Routing von Bussen, LKW, PKW, Fußgängern und und und gemappt. [...] Schönes Wochenende Jörg -- Jörg Frings-Fürst OSM privat D-54526 Landscheid GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Full GPG key: hkp://pool.sks-keyservers.net CAcert Serialnr.: 0D:9A:23 SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E http://cacert.org signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 10. Mai 2014 14:17 schrieb Dirk Sohler s...@0x7be.de: Falk Zscheile schrieb: bicycle=designated und foot=designated wird insbesondere im Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt es aber eigentlich access=designated, designated=bicycle, designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen sind. Zumindest beim Zeichen 241 gilt es eben nicht, da es sich hier rechtlich um zwei direkt nebeneinanderliegende Wege handelt, einen für Fußgänger, und einen für Radfahrer. Streng genommen müssten also zwei Wege gemappt werden, einen mit „access=designated, designated=bicycle“, und einen mit „access=designated, designated=foot“ … Wobei die diversen Sonderfälle und Ausnahmen von der Benutzungspflicht hier noch gar nicht berücksichtigt sind … Also ich habe mich gerade auf der osm-mv liste in Bezug auf Autostraßen aufklären lassen, dass bei Straßen/Wegen die physische Beschaffenheit gemappt wird, also ein geteerter Weg, und nicht die rechtliche Beschaffenheit, eine Spur für Fahrräder und eine Spur für Fußgänger. Im Endeffekt sind es auch mehrere Informationen, die wir getrennt erfassen sollten: 1. der Weg als physische Einheit, 2. ggf. die Aufteilung des Weges in einzelne Spuren, 3. die Benutzungsbedingungen für den Weg bzw. die Fahrspuren. 1. wäre highway=path 2. wäre segregated=yes 3. wäre die access/designated-Problematik Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 10. Mai 2014 14:23 schrieb Hubert sg.fo...@gmx.de: das wird schwierig. Besonders in Hinblick auf backward-capability. Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu highway=footway + footway=sidewalk/crossing. Von der Key:bicycle-Seite steht zu der Werten nur: For values see access=*. Naja, so lange für backward die gleichen access-Bedingungen gelten wie für forward ist es kein Problem, sonst schon ... (Wäre übrigens ein Grund bicycle=use_sidepath nicht zu erlauben) Da bin ich mir nicht sicher. Ohne das Proposal vollständig verstanden zu haben, wäre die Information von bicycle=use_sidepath doch (aus dem Blickwinkel von access) etwa: für die Straße an der das Tag hängt: access:bicycle=no und bicycle=use_sidepath die Zusatzinformation, dass es einen parallel verlaufenden Weg gibt, den der Fahrradfahrer benutzen kann/soll/darf, oder? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
On 2014-05-9 16:33, Manuel Reimer wrote: On 05/09/2014 04:20 PM, Martin Koppenhoefer wrote: wieso ist das egal? Wenn ein Datentyp nicht geeignet ist, die Welt so zu beschreiben wie sie ist, dann sollte man es auch nicht damit machen... Warum sollte das nicht gehen? Die Grenzlinie wird einfach so gelegt wie es derjenige, der es einträgt, für richtig hält. Wenn das nicht passt kann das ja jederzeit noch korrigiert werden. Oder habe ich dich jetzt falsch verstanden? Es geht um die Tags die beschreiben, welche Art von Grenze es ist. Was eine sinnvolle Beschreibung des Grenzverlaufs angeht, habe ich lokal schon mal was aus den jetztigen Sachen angelegt. Allerdings ist das richtige Tagging noch unklar. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 10. Mai 2014 15:42 schrieb falk.zsche...@gmail.com: Am 10. Mai 2014 14:23 schrieb Hubert sg.fo...@gmx.de: das wird schwierig. Besonders in Hinblick auf backward-capability. Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu highway=footway + footway=sidewalk/crossing. Von der Key:bicycle-Seite steht zu der Werten nur: For values see access=*. Naja, so lange für backward die gleichen access-Bedingungen gelten wie für forward ist es kein Problem, sonst schon ... Ich glaub, da hast du mich missverstanden, oder ich dich gerade. Mit backward-capability meinte ich nicht in Bezug auf die Fahrtrichtung der Straße sondern in Hinblick auf schon in den Daten vorhandene Tags. (Wäre übrigens ein Grund bicycle=use_sidepath nicht zu erlauben) Da bin ich mir nicht sicher. Ohne das Proposal vollständig verstanden zu haben, wäre die Information von bicycle=use_sidepath doch (aus dem Blickwinkel von access) etwa: für die Straße an der das Tag hängt: access:bicycle=no und bicycle=use_sidepath die Zusatzinformation, dass es einen parallel verlaufenden Weg gibt, den der Fahrradfahrer benutzen kann/soll/darf, oder? Gruß Falk Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
Hallo, ich habe in Thüringen schon für einige Gebiete type=multipolygon + boundary=usage genutzt. Beispiel: http://www.openstreetmap.org/relation/3681432 Gruß Bastian (BBO) -- View this message in context: http://gis.19327.n5.nabble.com/Relation-Harz-Mittelgebirge-tp5805709p5805848.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
On 2014-05-10 11:47, Archer wrote: Am 10. Mai 2014 02:39 schrieb Frederik Ramm frede...@remote.org: Für uns ist es wichtig, dass im Zweifel jemand hingehen und die Sache verifizieren kann. Wie soll das gehen mit dem Harz? Da es sich beim Harz um ein Mittelgebirge handelt wird ein Mapper vor Ort wohl zumindest verifizieren können, dass da Berge stehen. Zieht man dann noch Höhendaten hinzu und liest die Definition von Mittelgebirgen auf Wikipedia dann kann selbst ich als Nicht-Geologe einigermaßen abschätzen wo ca. die Grenzen des Harz verlaufen. Also ich bin vor Ort und eine einigermaßen verlässliche Abgrenzung ist auf jeden Fall möglich und die Idee es nicht zu erfassen weil es nicht auf den cm genau abzugrenzen ist. Es existiert und Menschen suchen danach in Karten und damit sollte es auch in OSM abgebildet werden. Ich werde mich mal in der Bücherei nach Infos umschauen und mir was überlegen. Nur weil etwas schwierig zu verifizieren ist kann das doch kein Grund sein, es nicht einzutragen. Manchmal muss man sich halt auch auf Experten verlassen die mehr Ahnung von der Materie haben. Wem die Grenzen zu ungenau sind der muss sie ja nicht nutzen. Einen Nutzen hat die Erfassung solcher Regionen durchaus, sei es für Karten, aber z.B. auch TMC hat Codes für Regionen, Unwetterwarnungen für bestimmte Regionen, ... +1 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Harz (Mittelgebirge)
Es gibt ein Proposal für das Mappen von Gebirgen: http://wiki.openstreetmap.org/wiki/Proposed_features/Mountains Der Harz ist wohl ein Massiv laut Wikipedia: https://de.wikipedia.org/wiki/Gebirge#Gebirgsformen Den Harz könnte man also laut diesem Proposal mit natural=massif taggen. Oder du hälst dich an das Tagging, das in den Alpen angewandt wird mit region:type=mountain_area siehe z.B.: https://www.openstreetmap.org/relation/2127484 Es gab schon eine längere Diskussion zum Tagging von Gebirgen im Forum dazu: http://forum.openstreetmap.org/viewtopic.php?id=16094 Am 10. Mai 2014 16:09 schrieb Thorsten Alge li...@thorsten-alge.de: On 2014-05-9 16:33, Manuel Reimer wrote: On 05/09/2014 04:20 PM, Martin Koppenhoefer wrote: wieso ist das egal? Wenn ein Datentyp nicht geeignet ist, die Welt so zu beschreiben wie sie ist, dann sollte man es auch nicht damit machen... Warum sollte das nicht gehen? Die Grenzlinie wird einfach so gelegt wie es derjenige, der es einträgt, für richtig hält. Wenn das nicht passt kann das ja jederzeit noch korrigiert werden. Oder habe ich dich jetzt falsch verstanden? Es geht um die Tags die beschreiben, welche Art von Grenze es ist. Was eine sinnvolle Beschreibung des Grenzverlaufs angeht, habe ich lokal schon mal was aus den jetztigen Sachen angelegt. Allerdings ist das richtige Tagging noch unklar. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM Tag-Template ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, ich mappe neben Adressen auch Anzahl Etagen. Kann man JOSM irgendwie bei bringen, der aktuellen Auswahl building:levels=1 mit Taste 1, usw... zu adden? Gruß Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTbj3rAAoJEIhNWXvfzcR1vvkH/2VN8y1NavPzzqLc49mlkG9/ uoDocrm8tLtAYMkvBL2r/czsTfacXVqq21XhRrrfooUiyKU+Qr1/N+DPyK9gBHwe UK+g8DUKdJECgDRsKdMxr7I/cp1lOMow/jwhk1VPcUrWMhhcRLeZB8jLRjFdeFBo vwmTo+HwSHwXGnzVOv1a2BmIcQfCDn0Yt45Fn7Ph3Koj2cO67u+Je1pTAl4fdp3g JUx37z4E0JSDZyrF7tFnTPEx4u+heAewBRzZ9Pa2T16G06SINXO7+SB3Byik1Hm9 V3bGRlgR2qE+K0WCS3zWWP+bkyPC9kf+fFepSHQGsko8WsQe1mAZ26NxyybdXEk= =uE5u -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 10. Mai 2014 16:11 schrieb Hubert sg.fo...@gmx.de: Am 10. Mai 2014 15:42 schrieb falk.zsche...@gmail.com: Am 10. Mai 2014 14:23 schrieb Hubert sg.fo...@gmx.de: das wird schwierig. Besonders in Hinblick auf backward-capability. Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu highway=footway + footway=sidewalk/crossing. Von der Key:bicycle-Seite steht zu der Werten nur: For values see access=*. Naja, so lange für backward die gleichen access-Bedingungen gelten wie für forward ist es kein Problem, sonst schon ... Ich glaub, da hast du mich missverstanden, oder ich dich gerade. Mit backward-capability meinte ich nicht in Bezug auf die Fahrtrichtung der Straße sondern in Hinblick auf schon in den Daten vorhandene Tags. In der Tat. Habe ich. Aber das Problem haben wir bei OSM immer, wenn sich etwas entwickelt. Und das sich nichts mehr entwickelt, das wollen wir ja auch nicht, denn perfekt ist unser Datenschema, wie mein Beispiel zeigt, noch lange nicht. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Falk Zscheile schrieb: […] dass bei Straßen/Wegen die physische Beschaffenheit gemappt wird, also ein geteerter Weg, und nicht die rechtliche Beschaffenheit, eine Spur für Fahrräder und eine Spur für Fußgänger. Wie würde dann das hier gemappt werden? (Bild aus der Google-Suche.) http://img836.imageshack.us/img836/1209/wftj.jpg Links: Geteerter Zwei-Richtungs-Radweg Rechts: Fußweg mit Beton-Bodenplatten Sowohl rechtlich als auch von der Beschaffenheit her unterschiedlich. Und schließlich gibt es hier sogar drei Spuren (für Fahrrad-Router sicher nicht ganz irrelevant, dass der Radweg in beide Richtungen befahren werden darf). Nun ist so ein Luxusradweg natürlich nicht üblich, aber gerade hier in Hamburg gibt es häufig – unabhängig der Benutzungspflicht – die Situation, dass der Radweg geteert ist, und der Fußweg aus Beton-Bodenplatten besteht … Und das habe ich bisher noch nirgends derart erfasst gesehen. -- Local time :: Ortszeit :: DE-HH 2014-05-10T23:46:40+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
