Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie
Am 22.10.18 um 17:33 schrieb Frederik Ramm: 1. Du kannst eine Straße quer durch einen Wald malen. 2. Du kannst den Wald auch entlang der Straße - mit Verkleben - in zwei Teile teilen. Das verleitet dazu, diese analog auch auf auch Straßen am Waldrand anzuwenden und dort die Straße mit dem Wald und der angrenzenden Wiese zu zu verkleben. Will man dem Verkleben Einhalt gebieten dann müsste die Regel konsequenterweise so lauten: 2. Du kannst den Wald auch entlang der Straße in zwei Teile teilen. Teile dabei nicht am Weg auf sondern auf einer Seite der Straße am Waldrand. Das erleichtert es, später einmal die Fläche von Straße, Seitenstreifen und Straßengraben zu mappen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gehweg kurzes Stück nicht straßenbegleitend, oder path ohne Widmung?
Am 26.04.2018 um 08:03 schrieb Florian Lohoff: > Aber da die durchfahrt zwischen der Figaro und Fideliostraße mit dem Rad > zu verbieten fühlt sich genauso kaputt an. Das Tagging in OSM kann und soll das Radfahren auf solch einem Weg weder verbieten noch erlauben sondern die Realität abbilden. Die Realität ist, dass es sich hier um einen Gehweg handelt, dessen Befahren gemäß StVO nicht erlaubt ist. Diese Situation wird korrekt durch highway=footway oder highway=path + bicycle=no beschrieben. Dass man den Weg mit dem Fahrrad als Abkürzung nutzen kann, durch Absteigen und Schieben oder kurzzeitiges Ausblenden der StVO, ist für den Auswerter der Daten an der Kürze der Verbindung und dem Fehlen besonderer Hindernisse erkennbar. Man kann solche Stellen daher auf Karten, falls gewünscht, entsprechend darstellen und Router sollten in der Lage sein, bei entsprechender Konfiguration darüber zu routen. Das gilt im Übrigen auch für Stellen, wo die rechtliche Situation eindeutig ist, aber der gesunde Menschenverstand zu einer abweichenden Praxis führt, z.B. solche Verbindungswege zwischen der Fahrbahn und einem nichtbegleitenden Radweg: https://www.mapillary.com/map/im/fXZ1I2q_2cGPuBP3lrGM3w https://www.openstreetmap.org/way/25277428 Der war übrigens auch mal auf bicycle=yes getaggt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] routing.openstreetmap.de
Am 31.12.2017 um 18:58 schrieb René Kirchhoff: > Danke ich habe den Weg entsprechend geändert. > Es ist verwirrend, dass einige router hindurch navigieren und andere nicht. > dabei ist die stvo für alle die gleiche... > es funktioniert z.b. mit graphhopper und brouter... Das Fazit dieses Threads ist doch, dass der Weg mit dem ursprünglichen Attributen für Fußgänger nur freigegeben ist, wenn diese sich dort zu landwirtschaftlichen Zwecken aufhalten. Graphhopper und BRouter werten die access-Attribute in diesem Fall falsch aus oder sind bewusst großzügig im Sinne von: wenn der Bauer dort zu Fuß durch darf, dann wird man es einem Wanderer wohl kaum verwehren. In der Praxis könnte dort ein Schild "Durchgang verboten, frei für landwirtschaftl. Zwecke" stehen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin gmapsupp.img funktioniert nicht mehr mit qlandkartegt / qmapshack
Hallo Andreas, ich habe mir die Karte heruntergeladen und kann sie mit einem aktuellen QMapShack (1.9.1post) unter Debian Testing öffnen. Grüße Rainer Am 27.10.2017 um 22:51 schrieb Andreas Tille: > Hi Moritz, > > On Thu, Oct 26, 2017 at 11:26:05AM +0200, Moritz wrote: >> kannst du mir die img files zukommen lassen, dann kann ich mal bei mir mit >> qmapshack schauen (1.9.1) ob's tut. > > http://fam-tille.de/tmp/osm/gmapsupp.img > > (Bitte gib mir kurz Bescheid, wenn Du es heruntergeladen hast - der Server > hat nicht mehr so sehr viel Platz ...) > >> Habe qmapshack zuletzt im Sommer mit Openmtb Karten genutzt. >> >> Alternativ könntest du dir img-Files von extract.bbbike.org runterladen. >> >> Ich habe es gerade mit dieser Karte[1] und qmapshack probiert (falls sie >> nicht mehr verfügbar ist, dann hier[2] neu bauen). >> >> Dann würdest du erstmal sehen, obs an dir oder den Karten liegt. >> >>> Was kann ich tun, um eine Tour zu planen und eine GPX-Ausgabe >>> zu bekommen (es müssen nun nicht notwendig diese Programme sein, >>> aber die Web-Routenplaner, die dann auf eine APP aufsetzen >>> nützen mir nichts). >> >> Ich nutze inzwischen recht häufig brouter-web [3]. Da fällt dann ein GPX >> raus, was sich einfach auf den Garmin übertragen lässt. > > Danke für die hilfreichen Tips, die ich mir bei Gelegenheit ansehen > werde. > > Viele Grüße > >Andreas. > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Namens-Tags in Polen
Am 25.10.2017 um 16:31 schrieb Stefan Kopetzky: > Zudem, gerade bei OSMand, wird in der deutschen Sprachversion immer > name:de verwendet, verwirrt, das den jeweiligen User nicht nur in Polen. Man kann Osmand auch so konfigurieren, dass die lokalen Namen angezeigt werden, also der Wert von name=*. Allerdings wirkt das nicht bei der Übersichtskarte, also in den niedrigen Zoomstufen. > Das Problem hat OSMand nicht nur in Polen, sondern etwa auch in anderen > Teilen Osteuropas (Ukraine, Ungarn, Rumänien), wo einige großflächig die > deutschsprachingen Bezeichnungen aus der Österr.-Ung.-Monarchie > eingepflegt haben und die dort in der Praxis wenig bis gar keine > Anwendung finden. Auch in Frankreich hat mal ein Mapper heute völlig unübliche deutschsprachige Bezeichnungen eingepflegt, z.B. Bisanz (Besançon) und Tolosen (Toulouse). Ich habe diese Bezeichnungen in old_name:de verschoben. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Technische Frage ÖPNV-Karte / Mapnik-Karte
Eine strikt nach dem V2-Schema erfasste Haltestelle wird auf der Standard-Karte im Carto-Stil auf osm.org nur unvollständig gerendert. Insbesondere wird der Name der Haltestelle nicht angezeigt. Deshalb lassen viele Mapper neben den V2-konformen Objekten noch ein highway=bus_stop stehen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routen planen
Hallo Sebastian, ich plane meine Radtouren überwiegend mit QMapShack (QMS) lokal unter Linux. QMS hat die Routino-Routingmaschine integriert mit einem recht guten Fahrradrouting. QMS hat auch eine Datenbank integriert, in der man seine Tracks ablegen und verwalten kann. Der Hauptnachteil von Routino und vieler anderer Router ist, dass das Höhenprofil nicht berücksichtigt wird. Daher nutze ich bei Touren in bergigem Gelände ergänzend den BRouter Web client [1]. BRouter ist speziell auf das Routing für Radfahrer ausgelegt. Beim Profil "trekking" sucht BRouter einen Kompromiss zwischen Entfernung und Höhenmetern, d.h. es wird eine gerngfügig längere Strecke in Kauf genommen, wenn dadurch Höhenmeter gespart werden. Manchmal nutze ich auch cycle.travel [2]. Dort kann man das Routing nicht parametrisieren, es ist aber für Radwandern und Radreisen sehr gut geeignet und berücksichtigt meines Wissens auch das Höhenprofil. Ein weiterer Vorteil ist die Möglichkeit von einem Punkt auf der Strecke direkt nach Streetview zu wechseln. Das Ergebnis der Planung kann man bei allen diesen Tools in einer GPX-Datei speichern, die man dann auf das Smartphone überträgt. Beide Tools arbeiten mit OSM-Daten. Wenn du weitere Fragen hast, würde ich dir empfehlen, diese in einem Radfahrer-Forum zu stellen, etwa hier [3] oder hier [4]. Dort werden solche Themen häufig und ausführlich diskutiert. Grüße Rainer [1] http://brouter.de/brouter-web/ [2] http://cycle.travel/map [3] http://radreise-forum.de [4] http://www.radforum.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwendung von Markenlogos in Karten?
Hallo Sven, auf der Karte der französischen OSM-Community werden die Logos der SNCF, der Post und einiger anderer Firmen gerendert [1]. Dem ging eine Diskussion auf der französischen mailingliste voraus [2], in der es aber weniger um rechtliche Aspekte als um die Opportunität von Logos auf der Karte ging. Der Konsens war dann wohl, dass man das nur bei quasi öffentlichen Diensten wie Post und öffentlichem Transportwesen machen sollte. Gruß Rainer [1] http://tile.openstreetmap.fr/?zoom=17=48.83993=2.36354=B000FF [2] http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.fr/57626 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben
Am 05.06.2016 um 18:04 schrieb Joerg Fischer: rainerU wrote: mit dem UniRS-Renderer einen highway=path bicycle=designated mit einer gestrichelten grünen Linie dar. Mit dem Standard-Renderer Spannende Sache. Bei mir (osmand aus dem Playstore, V 2.3.5) stellt UniRS _alle_ Pfade, egal ob bicycle=designated dran hängt oder nicht, als schwarze Pünktchenlinie dar. Auch wenn das hier jetzt ziemlich off-topic wird: zum einen habe ich mich vertan, Path mit bicycle=designated wird gestrichelt blau-lila dargestellt, Path ohne bicycle=designated in grün gestrichelt. Zum anderen hängt die Darstellung vom gewählten Modus ab. Meine Aussage bezieht sich auf den Fahrradmodus. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben
Am 05.06.2016 um 16:55 schrieb Joerg Fischer: rainerU wrote: z.B. rot dargestellt auf anderen Karten grün. Auch Navigationsprogramme wie OsmAnd und BRouter machen das so. Osmand? Definitiv: Nein. Osmand stellt Pfade als schwarze Strichlinie dar, egal ob da ein cycleway=designated dran hängt. Um cycleway=designated ging es bisher nicht. Bei mir stellt OsmAnd mit dem UniRS-Renderer einen highway=path bicycle=designated mit einer gestrichelten grünen Linie dar. Mit dem Standard-Renderer sogar als blaue gestrichelte Linie. Und soweit ich das beurteilen kann, behandelt der Router solche Wege wie highway=cycleway. Aber, wie bereits gesagt, ist dies kein Argument dafür, Radwege als path + designated zu mappen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben
Am 05.06.2016 um 08:55 schrieb Joerg Fischer: Das ist nicht das primäre Problem. Auf meine Frage ob es denn irgendeine Anwendung gibt die das dann als blauen Radweg zeigt kam keine Antwort. Weil du die Frage auf die blaue Darstellung reduziert hast. Anwendungen, welche mit bicycle=designated getaggte Wege zwar nicht blau darstellen aber als Radweg behandeln, gibt es eine ganze Reihe, z.B. mit mkgmap erstellte Karten für Garmin-Geräte. Meist werden bei diesen Karten die path/designated-Wege mit den Cycleways in einer Wegeklasse zusammengefasst. Das Navi-Gerät berücksichtigt diese Wege dann vorrangig beim Fahrradrouting. Die Darstellung ist je nach Karte und Gerätetyp unterschiedlich, auf der Openfietsmap werden sie z.B. rot dargestellt auf anderen Karten grün. Auch Navigationsprogramme wie OsmAnd und BRouter machen das so. Ein Argument für das path-Tagging ist das natürlich nicht, denn diese Anwendungen werten ja auch highway=cycleway aus, und meist auch bicycle=designated an anderen Highway-Typen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben
Am 30.05.2016 um 23:57 schrieb Joachim: Folgende Einträge: * Keine Beschilderung - Radweg ohne Benutzungspflicht: * Keine Beschilderung - Getrennter Fuß- und Radweg ohne Benutzungspflicht * Zeichen 1022-10 - Radweg ohne Benutzungspflicht ... bekommen cycleway:right:bicycle=yes in cycleway:right:bicycle=designated geändert. Wenn ich den Vorschlag richtig interpretiere, dann würde sich ein baulich nicht abgesetzter Radweg mit Zeichen 237, 240 oder 241 von einem nicht beschilderten nur noch durch das cycleway:right:traffic_sign=* unterscheiden. Da bicycle=designated Standard für cycleway=* ist wird das entsprechende Tag entfernt. Dann sollte man konsequenterweise das auch bei den nicht baulich getrennten Radwegen mit Zeichen 237, 240 oder 241 machen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:name multilanguage nach browsereinstellung anzeigen
Am 07.02.2016 um 12:15 schrieb chris66: Die Multi Language Map macht es so: http://mlm.jochentopf.com/ bei mir funktioniert sie allerdings zur Zeit nicht mehr richtig. Funktioniert schon, aber das Rendern der Label-Layer ist sehr langsam. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM bei der Kantonspolizei Aargau
Heute morgen im ARD Morgenmagazin in einer Reportage der moma-Reporter zu sehen(bei 02:15), eine Anwendung mit OSM-Mapnik-Karten: http://mediathek.daserste.de/Morgenmagazin/moma-Reporter-Mit-Precops-gegen-Krimina/Das-Erste/Video?documentId=29567638topRessortbcastId=435054 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage zu Kleben von Landnutzungsflächen an Straßen (bis 11.8.)
Am 12.07.2015 um 14:58 schrieb Michael Reichert: Es wäre mir recht, wenn ihr euch die Umfrage anschauen würdet, bevor ihr dazu etwas schreibt. Geht das Wohngebiet bis zur Fahrbahnmitte, oder hört es da auf, wo es es vor Ort aufhört ist NICHT MEHR die Fragestellung! Die Formulierung besagt jetzt explizit, dass die Landuses beim Kleben und beim Verbinden in der Straßenmitte bis zur Straßenmitte reichen. Deswegen kann jemand, der Kleben oder Verbinden in der Straßenmitte so interpretiert, dass die von der Straße eingenommene Fläche nicht zu den darunterliegenden Landuses gehört, die Landuses also bis zum Straßenrand gehen, nicht an der Umfrage teilnehmen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene OSM-Karte mit Overpass
Am 10.05.2015 um 14:06 schrieb Markus: Vielleicht können wir ja zusammen das OL-HowTo http://wiki.openstreetmap.org/wiki/DE:Karte_in_Webseite_einbinden so ergänzen, dass der Benutzer mit einer Overpass-Abfrage einen individuellen Layer hinzufügen kann :-) Die Idee ist gut, aber das sollte jemand machen, der sich gut mit Openlayers auskennt. Ich habe mir meine Layer-Definition aus verschiedenen Beispielen zusammen gestöpselt ohne alles zu verstehen, nach dem Motto Hauptsache es funktioniert. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene OSM-Karte mit Overpass
Hallo Markus,
Am 09.05.2015 um 20:38 schrieb Markus:
Nun suche ich dort noch das Howto zum Ausführen einer Overpass-Abfrage
und Einbinden der Ergebnisse in die Karte.
Ich habe auch nach so etwas gesucht, aber für OpenLayers kein HowTo
gefunden. Anhand diversen Einzelinformationen habe ich es dann doch
geschafft. Entscheidend war, dass die Daten nicht als JSON sondern im
OSM-XML-Format abgerufen werden. Den OL-Layer erzeuge ich so:
var layer = new OpenLayers.Layer.Vector(layername, {
protocol: new OpenLayers.Protocol.HTTP({
url:
'http://overpass-api.de/api/interpreter?data=[timeout:25];(node[amenity=bicycle_parking](42.327,1.72,42.942,3.26););out
body;;out skel qt;',
format: new OpenLayers.Format.OSM({ignoreExtraDims: true}),
projection: new OpenLayers.Projection(EPSG:4326)
}),
strategies: [new OpenLayers.Strategy.Fixed()],
projection: map.displayProjection,
extractAttributes: true,
styleMap: new OpenLayers.StyleMap({
default: new OpenLayers.Style({
externalGraphic: icon,
graphicWidth:21,
graphicHeight:25,
graphicXOffset:-10,
graphicYOffset:-25 ,
graphicZIndex: 1
},
OpenLayers.Feature.Vector.style[default])
}),
});
Ich halte allerdings auch die von Benjamin angesprochene Lösung mit Cron
für sinnvoll. In diesem Fall ersetzt man den Url der Overpass-Abfrage
mit dem Url der per Cron erzeugten Datei.
Grüße
Rainer
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Drupal - Karte einbinden
Hallo, Am 01.08.2014 07:48, schrieb Markus: hier gibt es eine Doku, wie man Karten in Drupal einbindenn kann: http://wiki.openseamap.org/wiki/De:OpenSeaMap_in_Website#Drupal En Benutzer meldet, dass das nicht funktioniere... Vielleicht kann das jemand prüfen/verbessern? Ich nutze das Modul MappingKit seit langem unter Drupal 6, Beispiel: [1]. Das Modul funktioniert unter Drupal 6 sehr gut, man kann zwischen einigen vordefinierten Tile-Servern wählen (osm.org, Google Maps/Satellite) und GPX-Tracks und -Waypoints anzeigen. Für einfache Anwendungsfälle ist es ausreichend und auch einfach zu bedienen. Leider wird das Modul nicht mehr gepflegt und es ist daher auch nicht für die aktuelle Drupal-Version 7 verfügbar. Grüße Rainer [1] http://blog.velocarte66.fr/de/node/295 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Changesetkommentare [war: Re: Erfahrungen mit dem Benutzer HoloDuke? (Vandalismus?)]
Hallo, Am 13.06.2014 20:09, schrieb Droelfzehn (aka Michael): Hm, da könnte man z.B. Gebäude und/oder Tags und Wege eingepflegt/geändert schreiben. Der Mehrwert so eines Kommentars ist nahe Null. Wenn ich auch nur einen flüchtigen Blick auf den Changeset werfe, weiß ich das auch. Ich halte Kommentare grundsätzlich für sinnvoll, aber bei solchen Misch-Changesets habe ich auch ein Problem, mir was aussagekräftiges aus den Fingern zu saugen. Wenn ich aus der Stadt zurückkomme und eine Access Restriction, ein Stück Radweg, ein Geschäft und ein Restaurant erfasse, dann schreib ich dann halt rein Miscellaneous contributions after site survey. Sagt zwar nicht viel aber alle sind zufrieden. Grüße Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Saisonabhängiges Kartenrendering (war Re: Markierungen auf Sportplätzen)
Am 07.06.2014 09:24, schrieb Christoph (TheFive@OSM): Parlaments und Regierungsgebäude mit der aktuellen Parteienfarbe einfärben. Ebbe und Flut zeitnah rendern Die erwarteten Schneemengen (auf highways) in höheren Regionen rendern, so dass die Durchfahrtsbreiten gleich aktuell sind. Schulgebäude in den Ferien anders darstellen… Nicht zu vergessen: die Belegung von Parkplätzen. Im Ernst: alles, was ohne zusätzliche Daten in der Datenbank, die dort nichts zu suchen haben, machbar ist, ist ok. Die Alpen von Dezember bis März ab 1200m weiß darstellen, warum nicht und irgendwo habe ich mal gelesen, dass so etwas schon gemacht wird. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad-Wander-Skate-Routen
Guten Morgen, Ich sehe das auch so, dass ein Tagging-Schema möglichst einfach und auch vom Durchschnittsmapper handhabbar sein soll. Mein Vorschlag würde es erst mal ermöglichen, den im UP aufgeworfenen Fall mit einer einzigen Relation und ohne Semikolon-Attribute zu erfassen. Das ist eine große Vereinfachung gegenüber dem hier auch schon gebrachten Vorschlag, mehrerer Relationen anzulegen. Die Praxis zeigt, dass viele Mapper mit Wegen, die zu mehreren Relationen gehören überfordert sind. Und wenn der Verlauf für die verschiedenen Nutzungsarten nicht deckungsgleich ist, kommt man um eine komplexe Lösung nicht herum, zumindest kann ich hier bislang keinen einfachen Ansatz erkennen. Oder man lebt mit der bei den Voies Vertes/Vias Verdes derzeit praktizierten Lösung: bicycle-Route und access-Tags für die anderen Nutzungsarten an den Wegen. Grüße Rainer Am 25.05.2014 01:25, schrieb Henning Scholland: Hallo, in der IT-Theorie magst du recht haben, dass dies eine saubere Variante ist, die Redundanz verhindert. OSM ist aber deutlich mehr als IT-Theorie. Menschen müssen die Routen warten können. Menschen müssen entscheiden können, was zu tun ist, wenn sie den Weg bearbeiten wollen. All das wird komplexer. Der typische Mapper hat keine Lust sich ewig einzulesen, bis er seine Info richtig in OSM platzieren kann. Entweder er versteht es gleich oder er lässt es. Relationen sind da ohnehin schon etwas abstrakt. Komplexe Relationskonstrukte blicken teilweise erfahrene Mapper nicht. Das Problem siehst du beim ÖPNV-Schema. Es hat einen Grund, warum sich nur sehr wenige damit befassen. Die Auswertung wird auch komplexer. Einen Vorteil neben der Redundanz sehe ich nicht und da würde ich die einfachere Datenstruktur in jedem Fall bevorzugen. Denn das braucht es, um es vielen zu ermöglichen daran mitzuwirken und das macht OSM letztlich aus. Henning Am 24.05.2014 12:30, schrieb rainerU: Wenn man die Situation über mehrere Relationen lösen will, und wahrscheinlich ist das der einzige Weg mit den heute verfügbaren Mitteln, dann sollte man Redundanz vermeiden und Abschnitte mit einheitlicher Nutzung auch nur einmal erfassen. Das könnte dann z.B. so aussehen: Pro einheitlich genutztem Abschnitt eine Relation mit route=multi_usage nutzungsart=[yes|no] mit nutzungsart=bicycle|hiking|inline_skates... und eine Super-Relation ebenfalls vom Typ multi_usage Grüße Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad-Wander-Skate-Routen
Am 25.05.2014 12:38, schrieb Martin Koppenhoefer: Am 25/mag/2014 um 08:06 schrieb rainerU ra...@sfr.fr: Oder man lebt mit der bei den Voies Vertes/Vias Verdes derzeit praktizierten Lösung: bicycle-Route und access-Tags für die anderen Nutzungsarten an den Wegen. Das ist keine Lösung für das beschriebene Problem sondern sind schlicht noch unvollständige Daten, d.h. es fehlen da noch die Wanderrouten. ...und die Skaterrouten und die Reiterrouten. Das kann doch nicht die Lösung für eine kombinierte Wander-, Radwander-, Skating- und Reiter-Route sein. Mehr Redundanz geht kaum. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad-Wander-Skate-Routen
Am 23.05.2014 08:15, schrieb Henning Scholland: Die Semikolon-Variante finde ich auch nur bedingt gut. Es bleibt ja letztlich nicht bei dem einen Semikolon. Bei network tritt das gleiche auf. Zumal man den Ansatz komplett vergessen kann, wenn sich die Wege unterscheiden. Mal muss der Radfahrer auf die Straße, mal darf der Reiter nicht über die Brücke. Bei den Vias Verdes in Spanien und den Voies Vertes in Frankreich ist das der Normalfall. Beide sind grundsätzlich für Fußgänger, Radfahrer, Skater und Reiter bestimmt, aber nicht alle Abschnitte sind für jede Nutzergruppe freigegeben bzw. verlaufen unterschiedlich für die Nutzergruppen. Die meisten dieser Routen sind derzeit als bicycle getaggt und die zugrundeliegenden Wege mit access-Tags versehen. Wenn man die Situation über mehrere Relationen lösen will, und wahrscheinlich ist das der einzige Weg mit den heute verfügbaren Mitteln, dann sollte man Redundanz vermeiden und Abschnitte mit einheitlicher Nutzung auch nur einmal erfassen. Das könnte dann z.B. so aussehen: Pro einheitlich genutztem Abschnitt eine Relation mit route=multi_usage nutzungsart=[yes|no] mit nutzungsart=bicycle|hiking|inline_skates... und eine Super-Relation ebenfalls vom Typ multi_usage Grüße Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Land- UND Forstwirtschaflticher Verkehr
Am 16.12.2013 12:04, schrieb Florian Lohoff: On Sun, Dec 15, 2013 at 09:53:40PM +0100, Mark Obrembalski wrote: Wer im forstlichen Zusammenhang aber tatsächlich ein Navi gut gebrauchen kann, ist der Lastwagenfahrer, der irgendwo Holz aufladen soll. Im Gegensatz zum Forstarbeiter fährt der nämlich heute ganz woanders hin als gestern und kennt sich im jeweiligen Wald drum nicht so gut aus. Den interessiert aber ein access= wenig da er vom Eigentümer beauftragt worden ist. Das ist das was ich sage. Es geht nicht darum, was wen interessiert, sondern darum, die tatsächliche Situation abzubilden. Und da ist nun mal motor_vehicle=no nicht dasselbe wie access=agricultural. Es ist ja schön das wir der Deutschen gründlichkeit genüge tun jeden Kieselstein einzutragen. Mit deutscher Gründlichkeit hat das nichts zu tun, das wird von den Mappern in anderen Ländern genau so gemacht. Ich sehe den nutzen bei solchen dingen nicht und sehe eher die Gefahr das wir einen großen Haufen Daten ansammeln den hinterher keiner mehr Pflegt. Ob man motor_vehicle=no taggt oder access=agricultural macht von der Datenmenge her gesehen keinen Unterschied. Persöhnlich bin ich an Beschilderung für LKW interessiert, d.h. Achslast, zGG, Brückenhöhe etc. Mich persönlich interessiert dies überhaupt nicht. Trotzdem ist es sinnvoll, diese Informationen zu erfassen. Ich rendere eine Fahrradkarte, auf der ich Wege, auf denen landwirschaftlicher Verkehr zugelassen ist, anders darstelle als solche, auf denen jeglicher motorisierter Verkehr verboten ist. Für die Familie, die mit kleinen Kindern auf dem Fahrrad unterwegs ist, kann das ein wichtiges Kriterium bei der Streckenwahl sein. Dafür brauche ich access=agricultural. Das Ziel von OpenStreetMap ist ja nicht die Befriedigung persönlicher Bedürfnisse sondern die Realität möglichst präzise abzubilden, so dass damit jeder seine persönlichen Bedürfnisse befriedigen kann. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Land- UND Forstwirtschaflticher Verkehr
Am 16.12.2013 12:59, schrieb Bernd Wurst: Aber dass ein Weg im Wald oder über freies Feld die LuF-Nutzung nicht erlaubt, ist jetzt nicht grade geläufig. Oder irre ich mich da. Hast du da ein Beispiel? Bitte: https://maps.google.com/?ll=42.763303,2.987165spn=0.011311,0.050082t=mz=15layer=ccbll=42.763316,2.987144panoid=-1dgQfxcOWuQQeedgfAINgcbp=13,45,,0,0 Übersetung der Aufschrift: Verboten für motorisierte Fahrzeuge aller Art. Natürlich kann die Schranke vom Servicepersonal geöffnet werden und natürlich dürfen die mit Servicefahrzeugen reinfahren. Aber das ist etwas anderes, als wenn ich zur Erntezeit mit regem Verkehr von Traktoren, Pkws und Erntemaschinen aller Art rechnen muss. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitreise ins 4. Jahrhundert oder was?
Am 16.12.2013 14:40, schrieb Jörg Frings-Fürst: Genau der Gegensatz dazu war die kürzliche Diskussion über die Angabe ob zum Zeitpunkt x in einem POI laktosefreie Lebensmittel angeboten wurden. Diese Angaben wurden eingetragen. Das ist ja noch harmlos. Es soll sogar mal einer einen Holzstapel und die Kennzeichen an seinen privaten Parkplätzen gemappt haben... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Land- UND Forstwirtschaflticher Verkehr
Am 16.12.2013 17:24, schrieb Jörg Frings-Fürst: Das was bemängele steht genau in dem Absatz über meinem Satz. Für die Familie, die mit kleinen Kindern auf dem Fahrrad unterwegs ist, kann das ein wichtiges Kriterium bei der Streckenwahl sein. Viel schlimmer ist, wiederum IMHO, sich auf eine Karte zu verlassen, die suggeriert das auf einem nicht entsprechend getaggtem Weg kein landwirtschaftlicher Verkehr unterwegs ist. Die Karte suggeriert nichts, sie kennzeichnet Wege gemäß den access-Tags und zwar - Wege, die für den allgemeinen Verkehr gesperrt aber für bestimmte Nutzergruppen freigegeben sind: Anlieger, land- und forstwirtschaftlichen Verkehr, ÖPNV - Wege, die für den gesamten motorisierten Verkehr gesperrt sind. Das ist auch in der Legende der Karte so beschrieben. Es liegt am Nutzer der Karte, ob er sich darauf verläßt, dass sich die Verkehrsteilnehmer an diese Beschränkungen halten. Und was ist mit den landwirtschaftlichen Wegen an denen die Zeichen 1026-36 - 1026-38 einfach fehlen? Sollen die Landwirte dort dann zu Ihrem Acker fliegen? Das muss der Landwirt mit seinem Gewissen, den örtlichen Organen der Staatsmacht und seinem Geldbeutel ausmachen, hat aber mit der Diskussion hier nichts zu tun. Ich persönlich halte eine Auswertung die darauf aufsetzt das ein Wert nicht getaggt ist für gefährlich und nicht sinnvoll. Meine Auswertung setzt nicht auf das Nichtvorhandensein von Tags sondern macht genau das Gegenteil: nur Wege, die explizite access-Tags tragen, werden markiert. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] route=proposed bei Relationen
Hallo, Es geht um die Frage, wie man geplante oder im Bau befindliche Wanderwege und Radwanderwege taggt. In diesem Thread [1] kam der Vorschlag: type=route route=proposed|construction proposed=bicycle Ich habe dieses Schema inzwischen bei einigen Radwanderwegen angewandt, z.B. hier: [2]. Das ist bisher auf keinen Widerstand gestoßen. Ich habe diesen Vorschlag auch in Diskussion auf der französischen Liste und in Mailkontakten mit Mappern von Radwanderwegen propagiert, auch hier kam bisher kein Einwand. Nach einem Mailkontakt mit Andy Allen werden so getaggte Routen auf der OpenCycleMap farblich wie die mit route=bicycle + state=proposed getaggten dargestellt. Der Vorschlag betrifft natürlich nicht nur Rad- und anderer Wanderwege sondern alle Relationen vom Typ route. Ich frage mich nun, wie ich vorgehen soll/muss, um dieses Taggingschema offiziell zu machen: einfach den Wiki-Eintrag ändern, einen Beitrag auf tagging-Liste verfassen oder gar ein Proposal-Verfahren anstossen? Gruß Rainer [1] https://lists.openstreetmap.org/pipermail/talk-de/2013-April/101630.html [2] http://www.openstreetmap.org/relation/3264259 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] route=proposed bei Relationen
Am 14.12.2013 11:11, schrieb chris66: Am 14.12.2013 11:07, schrieb rainerU: Ich frage mich nun, wie ich vorgehen soll/muss, um dieses Taggingschema offiziell zu machen: einfach den Wiki-Eintrag ändern, einen Beitrag auf tagging-Liste verfassen oder gar ein Proposal-Verfahren anstossen? Im Prinzip: Ja, letzteres. ;-) Das habe ich befürchtet, ist auch ok so. Dann setze ich das mal auf die Liste der guten Vorsätze für das neue Jahr. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] route=proposed bei Relationen
Am 14.12.2013 20:03, schrieb Volker Schmidt: Wenn ich Taginfo richtig interpretiere gibt es bereits 1373 state=proposed in Relationen. Die 1373 beziehen sich auf Relationen, Nodes und Ways, was aber keinen großen Unterschied macht, da state nahezu ausschließlich bei Relationen verwendet wird. Ich kann auch mit state=* leben, aber dann sollte dieses Attribut im Wiki beschrieben werden. Warum wird ein neues tagging benoetigt? Damit geplante oder im Bau befindliche Routen auf dieselbe Weise getaggt werden wie Straßen: Straßen: highway=proposed|construction + proposed/construction=highway_type Routen: route=proposed|construction + proposed/construction=route_type state=proposed wird derzeit von vielen Anwendungen und Renderern nicht ausgewertet. Zum Beispiel werden so getaggte Routen auf waymarkedtrails.org wie existierende Routen angezeigt. Die Umstellung auf meinen Vorschlag hätte den Nebeneffekt, dass solche Anwendungen die proposed/construction-Routen erst mal ignorieren und sie dann hoffentlich irgendwann korrekt behandeln würden. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetMap und Bürgerbus
Am 27.11.2013 09:22, schrieb Volker Schmidt: Ich weiss nicht, wie weit das uebertragbar ist, aber fuer Rad-Routen, die geplant aber noch nicht ausgeschildert sind, habe ich in der relation state=proposed verwendet. Der wichtigste renderer fuer Radkarten, Opencyclemap, stellt diese Routen gestrichelt dar. Beispiel: relation 1742549 Weiss nicht, ob das einfach uebertragbar ist. Es gab hier vor einiger Zeit einen Thread zum Thema geplanter Fahrradrouten [1]. Der schlüssigste Vorschlag war seinerzeit an das Taggen geplanter Strassen angelehnt: type=route route=[proposed|construction] proposed=bicycle Der Vorteil dieser Lösung ist, dass sie auch für anderer Routentypen angewendet werden kann. Grüße Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarten von Russland
Am 06.11.2013 19:36, schrieb Subidux: Vielleicht weiß ja jemand wo man solche Karten her bekommt, oder ob es einen Anbieter giebt, der OSM-Karten druckt oder wie man das möglichst einfach, im Maststab 1:125000, selber machen kann. Der User JBacc hat einen Topo-Stil für Maperitive entwickelt, der allerdings auf 1:25.000 optimiert ist: http://wiki.openstreetmap.org/wiki/User:JBacc ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Hallo, Am 07.11.2013 09:28, schrieb Georg Feddern: Natürlich _kann_ es auch mit einem Polygon und entsprechender Vorverarbeitung (übertragen der Information auf den way) funktionieren. Aber praktische Erfahrungen belegen derzeit eher das Gegenteil: Während solch eine programmtechnische Vorverarbeitung noch in den Sternen steht, funktioniert es bereits da, wo die Vorverarbeitung bereits vom Mapper vorgenommen wurde. Das steht nicht in den Sternen sondern ist mit einfachen Mitteln zu bewerkstelligen, vorausgesetzt man verwendet eine spatiale Datenbank wie PostGIS. Das Problem ist, dass diese Möglichkeit beim Erstellen der Kartendaten für die Navi-Applikationen nicht genutzt wird. Das ist verständlich, man kann nicht jedem Nutzer von mkgmap oder mapcreator die Installation von PostGis zumuten. Man sollte mal über eine API nachdenken, die einem diesen Schritt abnimmt, d.h. im vorliegenden Fall die Information liegt im innerorts-Polygon auf alle Objekt innerhalb des Polygons überträgt. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege taggen, Lübecker Methode
Am 30.10.2013 13:29, schrieb Wolfgang Hinsch: Am Dienstag, den 29.10.2013, 11:04 +0100 schrieb rainerU: - Das Schema macht Redundanz zum Prinzip. Wenn cycleway:right und cycleway:left vorhanden sind, braucht es nicht noch cycleway=both. Redundanz schadet nichts, aber man sollte sie nicht obligatorisch machen. Das riecht förmlich nach Taggen für eine Anwendung. Das wurde so auch nicht benutzt. cycleway:both ersetzt cycleway:left + cycleway:right, ist also das Gegenteil von Redundanz. Wenn die Wege auf beiden Seiten gleich sind, wird both benutzt. Das entspricht damit dem cycleway=*. Wenn deine Darstellung zuträfe, dann müsste man den Wiki-Eintrag entsprechend korrigieren. Dort wird die Key/Value-Kombination cycleway=both beschrieben, der Key cycleway:both kommt dort nicht vor. Ich denke aber, dass der Wiki-Eintrag die Lübecker Mapping-Praxis beschreibt, wie das erstbeste Beispiel zeigt: Way: Kanalstraße (134808713) Jeu de données : 5e095df7 Modifié à : 2012-05-28T05:35:41Z Modifié par : user_5359 (5359) Version : 3 Dans le groupe de modifications : 11722589 Attributs : cycleway:left:smoothness=excellent is_in:city=Lübeck highway=secondary cycleway:right=lane * cycleway=both cycleway:right:surface=asphalt cycleway:left:oneway=yes source:maxspeed=DE:urban zone:traffic=DE:urban cycleway:left=lane ref=K 16 traffic=low postal_code=23552 name=Kanalstraße cycleway:right:bicycle=designated cycleway:right:smoothness=excellent cycleway:left:bicycle=designated maxspeed=50 is_in:country_code=DE cycleway:right:oneway=yes cycleway:left:surface=asphalt Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege taggen, Lübecker Methode
Hallo, Am 29.10.2013 00:19, schrieb Wolfgang Hinsch: cycleway=track ist unbrauchbar, da in ~50% der Fälle der Radweg nicht auf beiden Seiten gleich ist. Das ist aus meiner Sicht nicht das Thema dieses Threads. Mit dem eingeführten und im Wiki [1] dokumentierten Tagging-Schema können die Wege auf beiden Seiten einer Straße durchaus differenziert getaggt werden. Was an diesem Lübecker Schema aufstößt ist - Das cycleway-Attribut wird umdefiniert. Standardmäßig wird dort der Typ des Radwegs angegeben, in Lübeck wird dort angegeben, auf welcher Seite der Straße ein Radweg oder -streifen verläuft. - Das Schema macht Redundanz zum Prinzip. Wenn cycleway:right und cycleway:left vorhanden sind, braucht es nicht noch cycleway=both. Redundanz schadet nichts, aber man sollte sie nicht obligatorisch machen. Das riecht förmlich nach Taggen für eine Anwendung. - cycleway=no und oneway=no sind zwar überflüssig, werden aber wohl zur Fortschritts-/Vollständigkeitskontrolle beim Mappen genutzt. Dafür gibt es durchaus plausible Argumente wie die immer mal wiederkehrenden Diskussionen zu oneway=no zeigen. - Ein neuer Wert cycleway=sidepath wird eingeführt. Vermutlich will man damit Radwege kennzeichnen, die zwar baulich mit der Strasse verbunden sind, aber als separater highway=cycleway|track erfasst sind. Das erscheint durchaus sinnvoll, hätte aber diskutiert werden müssen. Letztlich bleibt als klarer und gravierender Verstoß gegen die bisherige Praxis das Umdefinieren des Attributs cycleway. Der ganze Wust an redundanten Daten ist zwar ärgerlich aber anwendungstechnisch nicht schädlich. Dass ausgerechnet eine Radfahrorganisation mit Server- und Netzressourcen so verschwenderisch umgeht, verwundert mich allerdings. Ich plädiere dafür, die Daten zu bereinigen: - cycleway=both|left|right wird gelöscht, wenn entsprechende cycleway:left und cycleway:right vorhanden sind. - optional: cycleway:left=value und cycleway:right=value werden durch cycleway=value ersetzt. Ich bin auch gern bereit, den Machern der Lübecker Radkarte zu zeigen, wie man in PostGis bzw. QGis aus cycleway=value ein cycleway:left=value und cycleway:right=value macht, vorausgesetzt sie stellen ihre Skripts und Styles unter eine offene Lizenz. Gruß Rainer [1] http://wiki.openstreetmap.org/wiki/DE:Key:cycleway ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dann trag sie doch ein Du Depp
Hallo, Am 17.10.2013 08:58, schrieb Frederik Ramm: in Eisenach herrscht ein relativ rauher Umgangston in den Notes: Besonders bedauerlich finde ich, dass der Betreffende zwar offenbar ein Mapper ist, aber seinen Kommentar anonym abgibt. Auch wenn es bei derart ruppigen Zeitgenossen nichts bringt, wäre ein deutlicher Hinweis darauf, ob man eine Note oder einen Kommentar anonym oder unter seinem OSM-Account erstellt nützlich, z.B. Du erstellst diesen Hinweis unter deinem OSM-Account bzw. Du erstellst diesen Hinweis anonym. Falls du einen OSM-Account besitzst, melde dich bitte an und erstelle dann den Hinweis. Würden alle Mapper konsequent ihren OSM-Account für die Notes nutzen, dann könnte man unterschiedliche Auffassungen privat ausdiskutieren. Offensichtlich haben viele auch noch nicht verstanden, dass die Notes sowohl für aktive Mapper als auch für Nicht-Mapper genutzt werden. Missverständlich ist in diesem Zusammenhang die Formulierung im Popup Andere Mapper werden sich dann um die Erledigung kümmern, die impliziert, dass es sich um ein Werkzeug zur Kommunikation von Mapper zu Mapper handelt, mal ganz abgesehen davon, dass ein Nicht-Mapper wahrscheinlich gar nicht weiß, was ein Mapper ist. Ideal wäre es, wenn es auch für den Nicht-Mapper eine Möglichkeit gäbe, ein Pseudonym und eine Mailadresse anzugeben, unter der er erreichbar ist, natürlich ohne öffentliche Sichtbarkeit der Mailadresse. Ob und wie so etwas technisch machbar wäre, ist mir allerdings unklar. Grüße Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgesprochener Import?
Am 16.10.2013 13:44, schrieb Sven Geggus: Die OSM Daten als solche stehen unter ODBL. Wenn zu importierende Daten nicht unter ODBL weitergegeben werden dürfen (auch ohne source=irgendwas tag), dann können wir diese nicht importieren. Ist das so schwer verständlich? Verständlich ist das schon, aber nicht ganz korrekt. Laut Contributor Terms stimmt jeder Mapper zu, dass seine Daten unter der ODbL oder einer anderen freien und offenen Lizenz, für die sich mindestens 2/3 der aktiven Mapper entscheiden, veröffentlicht werden. Wenn du also fremde Daten einträgst, genügt nicht dass diese unter ODbL stehen, der Datenspender muss auch damit einverstanden sein, dass seine Daten zukünftig unter einer anderen freien und offenen Lizenz veröffentlicht werden. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Am 15.10.2013 09:57, schrieb Bernd Raichle: Was fuer die Fahrrad-Navigation jetzt noch sinnvoll waere, waere eine Abstufung der Wege, wie es aehnlich auch fuer die Strassen gibt (highway=motorway, trunk, primary, secondary, ...). Wobei es hier sinnvoller waere, ein Fahrradweg-Hierarchie-Attribut gesondert vom highway-Attribut zu fuehren. Man kann beide Einstufungen nicht von einander trennen. Sieht man von Straßen ab, die mit Radspur, Radweg o.ä. versehen sind, dann ist eine Straße je höher sie für den motorisierten Verkehr eingestuft ist um so ungeeigneter für den Radverkehr. Was fehlt ist eine Unterteilung von Residential und Unclassified in je zwei Unterkategorien, nach baulicher Gestaltung und Verkehrskommen. Das könnte ähnlich wie mit Tracktype gemacht werden. Ja, ich weiß, das Tracktype subjektiv ist, aber was ist an der Unterscheidung zwischen Primary, Secondary und Tertiary objektiv? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Am 13.10.2013 18:01, schrieb fly: Nein, für so ein Netzt reicht ein simpler Tag an den Wegen. Welches simple Tag könnte das denn sein? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Am 13.10.2013 08:39, schrieb Martin Koppenhoefer: Am 13/ott/2013 um 07:43 schrieb rainerU ra...@sfr.fr: Wie könnte denn ein einfaches Tagging im vorliegenden Fall aussehen? s.o. im Thread, lcn=yes bzw. rcn=yes bzw. ncn=yes Das kann man dort machen, wo es eine klar definierte Hierarchie von landesweitem Netz und regionalen und lokalen Netzen gibt wie z.B. in der Schweiz. Da weiß dann jeder Mapper und jede Anwendung, was mit ncn, rcn und lcn gemeint ist und es sind keine weiteren Tags erforderlich. Beim gegenwärtigen Stand der Dingen in den meisten Ländern ist es aus meiner Sicht sinnvoll und notwendig, auch zu Taggen, um welches Netz es geht. Das könnte man auch an den einzelnen Wegen taggen, z.B. mit lcn:ref, wenn es dafür ein einheitliches Schema gäbe. Derzeit sehe ich aber nur die von dir vorgeschlagene Lösung ein note=Radstreckennetz der Stadt A anzubringen, und das ist ohne Relation doch zuviel der Redundanz. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo, Es geht mir um Strecken, die mit Radwegweisern [1] ausgeschildert sind, und zwar nur um solche, die nicht mit einer Nummer oder einem Namen versehen sind. Für das Rendern von Radkarten und Routing-Anwendungen wäre es nützlich, wenn die damit ausgeschilderten Strecken identifizierbar wären. Ich habe aber weder im Wiki noch auf den Listen dazu einen Vorschlag gefunden. Mit guidepost können zwar die Schilder selbst erfasst werden, das ist aber für einen Renderer oder Router nicht bzw. nicht mit vernünftigem Aufwand auswertbar. Ich sehe zwei Möglichkeiten, solche Strecken zu erfassen: - als Routen-Relation, route=bicycle, network=lcn, mit jeweils einer Relation für einen einheitlichen Zuständigkeitsbereich, name=Radstreckennetz des Landkreises X - mit einem Attribut an allen betroffenen Wegen, z.B. bicycle:signposted=yes oder bicycle:signposted=Radstreckennetz des Landkreises X Die erste Lösung hat den Nachteil, dass man einen Namen erfinden muss, wenn das ausgeschilderte Netz keinen hat. Der zweite Vorschlag hat den Nachteil, dass man zusätzliche Informationen an allen betroffenen Wegen anbringen müsste. Somit spricht alles für die Umsetzung als Routen-Relation mit den vorhandenen Tags. Ist das schon irgend wo umgesetzt worden oder gibt es andere Lösungen und Vorschläge ? Gruß Rainer [1] http://commons.wikimedia.org/wiki/File:20110630Radwegweiser_Hockenheim.jpg [2] https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Am 12.10.2013 11:38, schrieb Martin Koppenhoefer: ich würde diese Routenrelations-Variante verwenden, allerdings je eine Route pro Strecke, nicht pro Landkreis. Wie kommst Du auf die Landkreise, steht das so irgendwo im Wiki? Die so ausgeschilderten Wege lassen sich meist nicht zu durchgehende Strecken zusammenfassen. Es handelt sich um ein Netz, das an jeder Kreuzung entsprechend den von dort erreichbaren Zielen und Zwischenzielen beschildert ist. Ein fiktives Beispiel: Im Umland steht ein Schild A-Stadt, das wiederholt sich bis zum Stadtrand, dort findet man dann Zentrum, Stadion und A-Stadt Nord, und wenn man näher an das Stadtzentrum kommt Münster, Rathaus und Theater. In der anderen Richtung sind die Teilstrecken wiederum ganz anders Ausgeschildert. Landkreis uns Stadt habe ich nur als Beispiel genannt, mein Vorschlag ist, das Netz nach der Verwaltungseinheit zu benennen, welche die Beschilderung plant und umsetzt. Die erste Lösung hat den Nachteil, dass man einen Namen erfinden muss, wenn das ausgeschilderte Netz keinen hat. nö, muss man überhaupt nicht. Wenn es keinen Namen gibt trägt man einfach keinen ein. Ggf. macht aber ein tag note oder description (bzw. note:de / description:de) Sinn, um die Route einfacher zu identifizieren beim Mappen (z.B. im Editor). Daran dachte ich auch. Ich befürchte nur, dass Renderer und Applikationen einen Namen erwarten. Aber das kann man ja ändern. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] db-Tabelle per Kartenausschnitt filtern
Am 10.10.2013 00:13, schrieb tshrub: Die Liste enthält immer nur Orte des Kartenausschnitts. Im Detail hängt die Lösung sehr stark von den von dir eingesetzten Tools ab. Wenn du die Karte mit OpenLayers realisierst, dann kannst du im Javascript jederzeit die Bbox des aktuellen Kartenausschnitts abfagen, z.B. mit map.getExtent. Dies Information muss man dann eben an den serverseitigen Teil der Anwendung übergeben, z.B. über ein location.replace. Im Kartenausschnitt sieht man Pins bzw. Cluster-Ikons, ggf. mit Trefferzahl, falls die Häufung zu groß ist. Bei Openlayers erzeugt man dafür einen Marker-Layer, an den man eine Datenstruktur mit den Koordinaten und Eigenschaften der Marker bindet. Ausch das ist wieder mehr eine Frage der Kommunikation zwischen clientseitigem Javascript und serverseitigem Datenzugriff, also kein OSM-Thema. Kann mir da jemand Suchworte und Quellen zu guten Tutorials, Scripts etc. sagen? Das ist erst sinnvoll, wenn du dich zwischen Openlayers und Leaflet entschieden hast. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezialgebiet Fahrrad-Mapping
Hallo Wolfgang,
ich rendere eine regionale Fahrradkarte [1] und habe mich daher mit dem Thema
Radverkehrsnetz in OSM zwangsläufig befasst. Weitgehend unproblematisch
bezügliche Erfassen und Auswerten sind aus meiner Sicht Verkehrswege, die per
rechtlicher Regelung für Radfahrer freigegeben, vorgeschriebenen oder gesperrt
sind, sowie die ausgeschilderten, nummerierten oder benannten Radwanderwege.
Keinen Konsens und somit Diskussionsbedarf gibt es für
- Routen, die nur als Empfehlung existieren ('nicht sichtbare Daten'). Ich sehe
aber durchaus eine Chance, dass solche Daten in OSM akzeptiert werden, wenn sie
ausreichend dokumentiert und publiziert sind.
- Routen die zwar durch spezielle Fahrrad-Wegweiser gekennzeichnet sind, aber
keine Routennummer oder -kennung enthalten und aus denen sich auch keine Routen
konstruieren lassen.
- Klassifizierung von Straßen und Wegen entsprechend ihrer Eignung für
Radfahrer. Versuche, dieses Thema mit tracktype, smoothness, bicyle:scale,
class:bicycle oder diesem Vorschlag [2] zu lösen, scheitern daran, dass es sich
dabei immer um individuelle Einschätzungen handelt. Was bei tracktype, wo
objektive Kriterien wie der Belagtyp mit herangezogen werden, noch einigermaßen
funktioniert, versagt spätestens bei Kriterien wie Gefährlichkeit und
Komfort. Sinnvoller ist es, objektive Attribute wie Belagtyp und Straßenbreite
flächendeckend zu erfassen.
Gruß
Rainer
[1] http://velocarte66.fr/
[2] https://wiki.openstreetmap.org/wiki/Cycle_Hierarchy
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und drink:soy_milk
Am 08.08.2013 00:32, schrieb Dirk Sohler: Henning Scholland schrieb: ...und diverse Supermarktketten mit der Info zu bestücken, dass es dort lactosefreie Produkte gibt ist jetzt sinnvoller? Solange Sojamilch noch nicht Standard ist, wie Bargeldzahlung, ja. Aber wenn schon, dann ordentlich, so, dass der Nutzer auch etwas davon hat. Ich bin laktose-intolerant und auf laktosefreie Produkte angewiesen. Die bloße Information, dass es in einem Café oder einem Laden Sojamilch gibt hilft mir aber wenig. Es gibt sie in Bio-Qualität oder nicht, letztere garantiert ohne genmanipulierte Zutaten oder nicht. Und da ich mich nicht von Milch alleine ernähre, suche ich auch nach Bezugsquellen für Joghurt, Gebäck und andere Produkte auf Sojabasis. Das Sojamilch-Tag hilft mir daher nicht und ich denke, den Veganern geht es ebenso. Es ist somit ein weiteres der vielen Tags, die dort, wo sie angebracht sind, meist korrekt sind, bei vielen POIs, wo sie hingehören, nicht vorhanden sind, daher von geringem Nutzen sind aber auch niemanden stören. Mich beeindruckt die Energie und der Aufwand, den einzelne Mapper treiben, um ein solches Attribut einzuführen und zu erfassen. Leider endet das in den meisten Fällen in einem unvollständigen und nicht aktuellem Datenbestand, der nicht nutzbar ist und allenfalls als Beispiel dafür dienen kann, was man mit OSM alles Tolles machen kann bzw. könnte. Selbst lebenswichtige Einrichtungen wie Defibrillatoren, die zweifellos in die OSM-DB gehören, sind lückenhaft erfasst und somit derzeit nicht nutzbar. Ich habe im Notfall nämlich nichts davon, wenn ich zum 20km entfernten Defibrillator gebracht werde, weil der um die Ecke nicht in OSM gemappt ist. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autokennzeichen
Hallo, Am 08.08.2013 22:00, schrieb Sarah Hoffmann: für Nominatim hat jemand den Featurewunsch geäussert, dass es doch die Suche nach deutschen Autokennzeichen unterstützen möge (siehe https://trac.openstreetmap.org/ticket/4936). Finde ich jetzt keine schlechte Idee, weil die Kennzeichen ja im Prinzip als ref für die Kreise dienen. Ich halte die Verwendung von Kürzeln für Verwaltungseinheiten grundsätzlich für eine gute Idee. In den USA sind zweistellige Buchstabencodes für die Bundesstaaten üblich, in Frankreich zweistellige Nummern für die Departements. In beiden Fällen handelt es sich um offizielle Kürzel für die Verwaltungseinheiten, die in OSM an als ref an den Grenzrelationen getaggt sind. Es geht um eine überschaubare Anzahl von Kürzeln, 50 bzw. 101, die im Alltag in vielen Zusammenhängen verwendet werden. Jeder weiß, dass mit Greenwood (MS) das Greenwood in Mississippi bzw. mit Bages (11) Bages im Departement Aude gemeint ist und nicht eine der namensgleichen Gemeinden im Land. Es ist daher auch üblich bei der Ortssuche in Formularen das Kürzel der Verwaltungseinheit zur geografischen Eingrenzung anzugeben. Meines Wissens funktioniert das auch in Nominatim. In Deutschland, wo es 295 Landreise gibt, ist die Situation etwas anders. Die Autokennzeichen werden meines Wissens offiziell ausschließlich für diesen Zweck verwendet. Kaum jemand kann sich 295 Autokennzeichen merken und es ist auch nicht üblich, das Autokennzeichen als zusätzliche Information zum Ortsnamen zu verwenden, zumindest habe ich es noch nie gesehen, dass jemand Erbach (ERB) und Erbach (UL) zur Abgrenzung benutzt. Die Bedenken wegen der Mehrdeutigkeit teile ich nicht. Auch wenn man sein Kennzeichen beim Umzug behalten kann, bleibt die Zuordnung Gemeinde zu Kennzeichen bestehen. Und dort, wo in einer Gemeinde mehrere Kfz-Kennzeichen möglich sind, könnte man diese ja beide in dem noch zu definierenden Attribut eintragen und bei der Suche auch beide auswerten. Ich halte das Ganze für eine nice-to-have-Funktion mit geringem praktischen Nutzen. Kann nichts schaden, bringt aber außer vermutlich heißen Diskussionen über das Tagging nicht viel. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und drink:soy_milk
Am 07.08.2013 19:21, schrieb Dirk Sohler: Cola gibt es überall, genau so, wie man wohl überall mittels Bargeld zahlen kann. Wohingegen es Sojamilch oder andere Produkte nicht überall gibt, und man auch nicht überall mit der Geldkarte zahlen kann. Kommt wohl immer drauf an, was gemeinhin als „Selbstverstandlich“ angesehen wird. Es geht weniger darum, ob es sich um eine nützliche Information handelt oder ob Cola im Supermarkt und Schnitzel im Restaurant mit deutscher Küche als Default gilt, sondern darum, ob dies eine Information ist, die in einer geografische Datenbank ihren Platz hat. Ich halte die Unterbringung in einer externen Datenbank im Interesse der Zielgruppen solcher Informationen für sinnvoller. Ich finde es z.B. effizienter, in einer externen DB die Information In allen Aldi-Süd-Märkten gibt es Bio-Soja-Milch Natur/Schoko/Vanille im 1l-Tetrapak abzuspeichern als an jedem Aldi-Süd-Markt in OSM ein Sojamilch-tag anzuhängen. Es stört mich aber auch nicht weiter, wenn es in OSM getaggt wird. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki und drink:soy_milk
Am 06.08.2013 18:39, schrieb Henning Scholland: Für mich gehört sowas genauso wenig in die OSM-DB wie die Info, dass es im Restaurant um die Ecke Pommes mit Schnitzel gibt oder im Aldi Cola und Salami. Das ist eher ein Fall für externe DB und overpassID auf das OSM-Objekt. +1, und das gilt für fast alle Tags, die an POIs vom Typ Shop und Restaurant hängen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellungsfehler im Rendering. Wie Fehler melden?
Am 05.08.2013 06:50, schrieb Manuel Reimer: Woran liegt es? Kann man den Fehler irgendwo melden? Das ist ein Effekt, der beim Erzeugen von Kacheln mit Mapnik an Kachelgrenzen auftreten kann. Vereinfacht ausgedrückt rendert Mapnik jede Kachel für sich und mit den Daten des von der Kachel abgedeckten Bereichs. Hier geht es um zwei Kacheln: http://tile.openstreetmap.org/18/138103/88950.png http://tile.openstreetmap.org/18/138104/88950.png Auf der ersten Kachel hat die Straße kein Label, also ist Platz für das Label des POI. Auf der zweiten Kachel ist die Straße beschriftet und da Straßenlabels höhere Priorität haben als POI-Labels, wird das POI-Label nicht gerendert. Dieser Effekts kann nicht völlig verhindert werden, aber es gibt Möglichkeiten, sein Auftreten zu reduzieren, z.B. durch das Verwenden von Metatiles. Ich gehe aber davon aus, dass diese Möglichkeiten bei der Generierung der Tiles für openstreetmap.org schon effizient genutzt werden. Fehler kann man auf https://trac.openstreetmap.org/ melden. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellungsfehler im Rendering. Wie Fehler melden?
Am 06.08.2013 01:38, schrieb Tirkon: Möglicherweise gibt es von Zeit zu Zeit eine Art Rundumschlag beim Rendern. Es könnte mit der Umstellung auf CartoCss[1] zusammenhängen, die am Wochenende erfolgt ist. Das Restaurant wurde schon am 30.07.13 gemappt. Es wäre daher interessant zu wissen, ob das Rendering-Problem bereits vor der Umstellung existierte. Ich würde es auf jeden Fall im Trac melden. [1] http://lists.openstreetmap.org/pipermail/talk/2013-August/067802.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?
Am 29.07.2013 10:34, schrieb Kai Krueger: Bis es entweder zu spaet ist, oder es sich hoffentlich herausgestellt hat das es nur die Sorgen ein paar paranoider Spinner waren... ;-) Mapper, die einen von deinem abweichenden Standpunkt zum Datenschutz vertreten, als paranoide Spinner zu bezeichnen, entspricht nicht dem Umgang, den ich bisher bei OSM erlebt habe. Der Smiley ändert da nichts daran. Ich hoffe du stellst das klar. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?
Am 28.07.2013 00:56, schrieb Kai Krueger: Markus-2 wrote * OSMbook: ja es gibt Strömungen in der OSM community die gerne aus OSM eine social media Platform machen würden Wer will das? und warum? Es wollen viele. Unter anderem auch einige die an der Webseite entwickeln. Insofern werden in Zukunft sicherlich auch einige weitere Aenderungen in der Richtung einzug erhalten. Diese Bestrebungen, die im Thread zur Gamification angesprochen wurden, waren der Auslöser der Diskussionen über Privacy, nicht die Auswertungen von Pascal Neis, die nur als Beispiel dafür, was machbar ist, erwähnt wurden. Es erlaubt Mappern sich zu thematischen Gruppen zusammen zu schliessen und dann sich leichter ueber ihre Interessen auszutauschen. Zum Beispiel koennen sich in so einer Gruppe alle Freunde des oeffentlichen Verkehrs zusammen schliessen und Aktionen planen wie sie den OePNV besser in OSM erfassen koennten. Oder ueber das beste Tagging schema streiten. Man kann sich aber auch zu eine Gruppe des lokalen Stammtisches zusammen schliesen oder eben auch zu jedem anderen Thema das einem Interessiert. Heute können und tun das solche Gruppen indem sie eine Mailingliste anlegen oder einen eigenen Bereich in einem Forum. Lokale Mailingslists gibt es und es spricht nichts dagegen eine Liste zum Thema öffentlicher Verkehr anzulegen, wenn es sie nicht schon gibt. Durch die Integration von Soacial-media-Funktionen in die Hauptseite kommt ein neuer Aspekt hinzu, den man zumindest erwähnen sollte. Auf einer Liste kann man ohne Bezug zum OSM-Account auftreten, bei dem Social Media Zeugs, wenn ich es richtig verstanden habe, würde man unter seinem OSM-Usernamen arbeiten. Damit entfällt die Möglichkeit, seine Mapping-Aktivitäten und daraus ableitbare Informationen von seinen Diskussionsbeiträgen zu entkoppeln. Diese Entkopplung ist für die Privacy von Bedeutung, da man in den Diskussionen zwangsläufig oder auch gewollt auf Dauer nicht anonym bleibt. Wer also will dass die Daten, die er zum Projekt beiträgt, nicht seiner Identität zugeordnet werden können, sollte sich an den zukünftigen Social-Media-Funktionen nicht beteiligen. Allerdings ist es eben wichtig, das es freiwillig ist und das man daran nicht mit machen muss wenn man nicht will. Ganz so einfach ist es nicht. Ich will schon, aber nicht auf einer Social-Media-Plattform. Irgendwann werden aber die Mailinglisten und Foren aussterben und der auf Privacy achtende Mapper hat keine Plattform mehr, auf der er sich mit der Community austauschen kann. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?
Hallo Markus, Am 28.07.2013 10:47, schrieb Markus: Damit entfällt die Möglichkeit, seine Mapping-Aktivitäten und daraus ableitbare Informationen von seinen Diskussionsbeiträgen zu entkoppeln. :-( Entsprechend notwendig ist eine klare Möglichkeit, sich frei entscheiden zu können zwischen: - ja, ich will meine Personen-Daten freigeben - nein, ich will nicht, dass meine Personen-Daten mit meinen Geo-Daten verknüpft werden. Ich bin mir nicht sicher, dass du meinen Beitrag richtig interpretierst. Ich halte die derzeitige Losung zwar nicht für ideal, aber unter den gegebenen Randbedingungen für akzeptabel. Ich möchte weder auf die Historie der Elemente mit Usernamen noch auf diverse userbezogene Auswertungen verzichten. Ideal wäre es, wenn sowohl die Verknüpfung der Daten mit den Usernamen als auch die daraus abgeleiteten Auswertungen nur für eingeloggte User sichtbar wären, aber das ist nicht praktikabel. Erst durch die Social-Media-Funktionen kommt eine andere Qualität ins Spiel, da solche Funktionen ja nur einen Sinn geben, wenn die hinter dem Usernamen stehende Person nicht mehr anonym ist. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import von unklaren Daten geht weiter bitte sofort stoppen
Hallo Hennig, Am 25.07.2013 23:29, schrieb Henning Scholland: ich habe eben kurz mit Frederik Rücksprache gehalten und derzeit sind wir beide derzeit der Ansicht, dass es sich hier nicht unbedingt um einen Fall für die DWG handelt, sondern besser unter den Mappern geklärt werden sollte. Ich denke auch, dass die Verhältnismäßigkeit der Mittel eingehalten werden sollte und direkter Kontakt besser ist als langes Hin- und Her auf der Liste. Ich halte im konkreten Fall ein moderates Eingreifen der DWG durchaus für angebracht, wenn es darum geht die Einhaltung der Import Guidelines durchzusetzen. Das ist erstens ein kritisches Thema, da es um Lizenzangelegenheiten geht und außerdem kennt sich da der gemeine Mapper meist nicht so gut aus. Wenn ich die Wiki-Seite sehe, die die Firma inzwischen angelegt hat, dann komme ich mir als einer, der für einem weit weniger kritischen Import einen eigenen Account angelegt hat und in Josm ständig zwischen diesem und meinem üblichen Account hin und herswitcht, schon etwas veräppelt vor: Accounts, die *möglicherweise* an diesem Import arbeiten, kein Wort geschweige denn ein Nachweis zur rechtlichen Grundlage für die Nutzung der Daten, usw. Ich finde die Aktion ansonsten für begrüßenswert und unterstützungswürdig. Gruß Rainer ___ 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 24.07.2013 03:27, schrieb Tirkon: Hier kommt nun ein Problem zu Tage. Unsere Daten sind unter der freien Lizenz ODbL verfügbar. http://opendatacommons.org/licenses/odbl/ Damit das so bleibt, müsste das auch für die von Euch eingepflegten Daten gelten. Streng genommen reicht eine Zustimmung zur Nutzung dr Daten unter der ODbL nicht aus. In Punkt 3 der Contributor Terms heißt es: ...or such other free and open licence (for example, http://www.opendefinition.org/okd/) as may from time to time be chosen by a vote of the OSMF membership and approved by at least a 2/3 majority vote of active contributors. Der Verkehrsbetrieb oder -verbund muss also auch damit einverstanden sein, dass seine Daten nach einem eventuellen Wechsel zu einer anderen freien und offenen Lizenz weiter in der OSM-Datenbank bleiben dürfen. Auf der sicheren Seite ist man, wenn man das Einverständnis des Datenlieferanten hat, dass OSM die Daten unter den Bedingungen der CT nutzen darf. Da man dieses Einverständis so explizit meist nicht bekommt, halte ich die Verfolgbarkeit der Daten für besonders wichtig. So kann man sie später notfalls wieder löschen, wenn sich herausstellt, dass das alles nicht so gemeint war. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo, Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Tracy (taoxue) Inhaltlich kann und will ich nichts beitragen, aber aus meiner Sicht fällt das Eintragen dieser Daten unter die Import Guidelines [1]. Deshalb, aber auch wenn man das nicht so sieht, wäre es sinnvoll, die Änderungen an der OSM-Datenbank unter einem (oder mehreren) dafür vorgesehenen Account zu machen, dessen Bezeichnung zum Ausdruck bringt, worum es geht, mit einer kurzen Beschreibung des Projekts in der Profilbeschreibung und ggf. einer Wiki-Seite. Das würde Mappern, die auf eure Changes stoßen, ungemein helfen und auch manche etwas ungehalten wirkende Beiträge auf der Liste verhindern. Gruß Rainer [1] http://wiki.openstreetmap.org/wiki/Import/Guidelines ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 5 Jahre OSM - eine persönliche Bilanz
Hallo, Am 17.07.2013 18:01, schrieb Tirkon: Joachim Topf hat eine multilinguale OSM Karte in 280 (Sprach-) Versionen mit moderatem Traffic für Wikipedia entwickelt, die dort derzeit implementiert wird. Ich nutze selbst Jochens Kacheln vom Toolserver (nach Absprache mit Tim Alder) für eine Spezialkarte. Mich interessiert, wie du das mit dem moderaten Traffic meinst. Der Traffic pro Abruf sollte doch derselbe sein wie bei den Kacheln von openoffice.org. Oder meinst du damit, dass derzeit der Traffic durch Abrufe moderat ist? Wenn sich diese dort bewährt, spekuliere ich mit ihr als Werkzeug-Grundlage darauf, Spezialkarten auf Basis dieses Konzepts billiger ausliefern zu können. Das Problem der Last auf den Server wird dadurch doch eher noch verschärft, Derzeit verteilt sich der Traffic auf die diversen Server der Spezialkarten. Wenn diese alle die Kacheln vom Toolserver, oder einem anderen Server, auf dem diese dann liegen, dann sehe ich da keine keine Verbesserung. Ansonsten sehe ich das Thema des Zugangs zu den Anwendungen ähnlich wie Stephan. Ich habe in den letzten Monaten viel Werbung für OSM in Gruppen gemacht, die sich mit ganz anderen Dingen befassen (Linux, Radfahren, Verwaltung). Die Leute sind anfangs sehr interessiert und auch bereit OSM statt Google zu nutzen, aber am Ende steht dann die Frage nach einer POI-Karte, einer Routing-Anwendung und der Möglichkeit einen Marker zu setzen und den Link darauf zu verschicken. Wenn man dann drei verschiedene Seiten für jeden dieser Bedarfe aufzählt, dann ist für die meisten das Thema gegessen. Hinzu kommt, dass keine dieser Seiten, die Erwartungshaltung an Bedienungsfreundlich des Nicht-Mappers erfüllt. Das ist keine Kritik an den Leuten, die diese Seiten machen. Es ist vielmehr eine Frage der Bündelung der technischen Kompetenz und der finanziellen Mittel. Linux hat aus meiner Sicht auch erst den Durchbruch in der Breite geschafft, als Canonical Ubuntu herausbrachte. Dieser Schritt steht bei OSM noch aus und wenn wir den in den nächsten ein bis zwei Jahren nicht schaffen, dann sehe ich die Zukunft des Projekts pessimistisch. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 5 Jahre OSM - eine persönliche Bilanz -MLM
Hallo, Am 18.07.2013 20:07, schrieb Kolossos: Verwirrung: Jochen-Kacheln kommen nicht vom Toolserver sondern vom Fossgis-Server, der verträgt aber auch was. Was sind Kacheln von openoffice.org? Ich denke das war ein Tippfehler. Ja, ich habe da ein paar Dinge durcheinander gebracht. Ich nutze die Tiles vom Toolserver und es sollte natürlich openstreetmap.org heißen. Sorry. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 5 Jahre OSM - eine persönliche Bilanz
Am 18.07.2013 20:58, schrieb Tirkon: Wenn ich es richtig verstanden habe, kann die Hintergrundkarte lokal gecached werden, womit sie für verschiedene darüber gelayerte Darstellungen nur einmal für einen gewissen Zeitraum übertragen werden müsste. Korrigiere mich, wenn ich falsch liege. Dazu kann ich nichts sagen, ich kenne mich da leider zu wenig aus. Wenn ich mir aber den Verkehr während dem Zoomen und Bewegen in einer Slippy Map anschaue, habe ich den Eindruck, dass da nicht allzuviel Kacheln gecacht werden (Firefox 10). Darf man fragen, welche Spezialkarten Du aus Jochens Kacheln erstellst? Das ist eine Karte, die für die OSM-Community in Perpignan gemacht habe [1]. Es ist der Prototyp einer Karte, die später einmal auf einer Webseite openstreetmap.cat präsentiert werden soll. Auf der Karte werden im französischen Katalonien die Toponyme in katalanisch oder zweisprachig angezeigt, soweit vorhanden. Das ließ sich mit der Multilingualen Karte von Jochen Topf nicht machen. Das kommt zum einen daher, dass im spanischen Teil Kataloniens die katalanischen Namen überwiegend nur im name-Tag nicht aber als name:ca erfasst sind. Und zum anderen rendert Jochen die Namen nach einer einheitlichen Regel für die gesamte Karte. Damit ist es z.B. nicht möglich, den katalanischen Namen anzuzeigen und falls dieser nicht vorhanden ist, als Rückfall den französischen Namen, jedoch nur in Frankreich, oder eine zweisprachige Anzeige in Frankreich zu machen, in Spanien aber nicht. Momentan funktioniert leider nur das katalanische Overlay, die beide anderen kommen morgen wieder. Auch OSM-Mapper ohne Programmierkenntnisse wünschen sich so ein OSM Maps im Sinne von Gebt uns unsere Daten zurück. Wenn Du hier aber von drei Seiten sprichst, kennst Du http://maps.skobbler.de/ und http://open.mapquest.com/ noch nicht, die aber leider auch Wehrmutstropfen aufweisen. Die Patzer wären sicherlich schnell dingfest gemacht, wenn die beiden Anbieter Kontakt zur Community pflegen würden. Ich weiß aber nicht, ob die zu Grunde liegende Software frei und offen ist. Vor kurzem gab es auf der talk-Liste einen langen Thread zu dem Thema der Karten und Anwendungen auf openstreetmap.org. Da hat Greg Knisely von Mapquest angeboten, deren Routingservice zu integrieren [2]. Gruß Rainer [1] http://osmcat.velocarte66.fr/ [2] http://lists.openstreetmap.org/pipermail/talk/2013-July/067488.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Hallo, Am 15.07.2013 00:02, schrieb Frederik Ramm: On 14.07.2013 15:59, rainerU wrote: Letztlich ist die Frage, ob die Auswertung der OSM-Daten einschließlich der Metadaten zu statistischen Zwecken und zur Erstellung eines Aktivitätsprofils und die Veröffentlichung der Ergebnisse durch die ODbL gedeckt ist. Ich habe da erhebliche Zweifel. Ich nicht. Die benoetigten Daten stecken in jedem Planetfile drin, das komplette Planetfile steht unter einer freien Lizenz, und so ein Profil ist letztlich ein verhaeltnismaessig einfacher Algorithmus. Die Zahl meiner Notes, meiner GPX-Tracks und meiner Changesets steckt im Plantefile? Ich gebe zu, noch nie mit einem Planetfile gearbeitete zu haben sondern immer nur mit euren Extrakten, wo das alles nicht drin ist, aber es würde mich doch sehr wundern. Die Veroeffentlichung nicht nur der Datensubstanz, sondern auch der Information, *wer* die Daten wann beigetragen hat, ist meiner Ansicht nach jedoch essentiell fuer die Zusammenarbeit im Projekt. Eine Auswertung der Verteilung der Changesets über die Wochentage und Tagesstunden ist dafür völlig überflüssig. Auch ein Ranking braucht es dafür nicht und Fleißbildchen, ehrenzeichen und Generalssterne (Badges) schon gar nicht. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Hallo Pascal, Meinen Beiträge waren weder als Kritik an deinen Auswertungen noch als Aufforderung, etwas raus zu nehmen, gedacht. Ich nutze deine Auswertungen regelmäßig, um einen Mapper besser einordnen zu können, um Mapper in meiner Gegend ausfindig zu machen oder um mir einen Überblick über meine eigenen Aktivitäten zu verschaffen. Die Diskussion hier ist nur hoch gekommen, weil offenbar der Wunsch nach weitergehenden Auswertungen besteht, z.B. nach Objektkategorien wie Strassenlaternen und Adressen. Und bevor ich demnächst einen Badge in Gold als fleißigster Mapper von Puffs oder Hundekottütenspendern bekomme, hätte ich schon erst mal den rechtlichen Rahmen geklärt bekommen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Am 15.07.2013 11:03, schrieb Simon Poole: Nur als Hinweise, macht man sich ein Konto hats es an promintenter Stelle ein Link auf http://wiki.openstreetmap.org/wiki/Privacy_Policy (das wie immer in OSM eher zuviel als zuwenig Information hat). Könnt man noch expliziter machen, aber es hat jeder die Möglichkeit es zu lesen. Dort steht nur, was veröffentlicht wird, nicht was Dritte damit machen dürfen. Würde man die selbe Logik auf die geografischen Daten anwenden, dann hieße das: Contributions werden über das API und das Planetfile öffentlich verfügbar gemacht, und somit kann jeder damit anfangen was er will. Wozu dann eine ODbL? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Am 15.07.2013 12:53, schrieb Ronnie Soak: In der ODbL steht eben genau, was dritte damit machen dürfen. Und da steht: sie dürfen alles damit machen, solange sie die Attribution und ggfs. die Lizenz zur Weitergabe einhalten. Welche Definition fehlt dir jetzt? Ob die Usernamen, die aus technischen und administrativen Gründen in der Datenbank stehen, auch unter die ODbL fallen. Und falls ja, ob ich durch die Annahme der Contributor Terms der OSMF das Recht hierzu eingeräumt habe. Ich erwarte hier auf der Liste dazu keine Antwort, dazu sind detaillierte juristische Kenntnisse erforderlich, über die wohl kaum jemand hier verfügt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Am 15.07.2013 13:30, schrieb Ronnie Soak: Aus den CT: [...] contributing data and/or any other content (collectively, “Contents”) to the geo-database of the OpenStreetMap project [...] 'and/or any other content' ist für mich als Laien eine Umschreibung für Alles. Also erstreckt sich für mich die CT auf alles, was ich zur DB hinzufüge. Und da ein Jurist den Unterschied zwischen Content und Metadaten ohnehin nie verstehen wird, ist alles klar. Danke. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Hallo Peter, Am 15.07.2013 18:35, schrieb Peter Wendorff: - Zu rainerU lässt sich mit großer Wahrscheinlichkeit der Provider bestimmen. Ich wollte eigentlich nichts mehr in diesem Thread schreiben, nachdem Hartmut Holzgraefe am Ende seines Postings besser als ich es könnte zum Ausdruck gebracht hat, worum es worum es mir geht: http://lists.openstreetmap.org/pipermail/talk-de/2013-July/103426.html Aber wo du mich jetzt erwähnst: Meinen Provider und damit mein Wohnland kannst du aus meiner Mailadresse ablesen. Ich habe auch eine deutsche Mailadresse, aber ich verwende bewusst diese, um damit einen Hinweis auf meinen Aufenthalt zu geben. Ich habe hier auch schon einen Link auf eine von mir betriebene Homepage gepostet und somit kann jeder meine Identität herausbekommen. Zusätzlich gebe ich hier meinen OSM-Usernamen an, was ich für ein Gebot der Höflichkeit halte. Wenn ich einen Kurzurlaub mache, dann mappe ich unmittelbar nach der Rückkehr was mir unterwegs untergekommen ist und lade meist auch einen Track dazu hoch. Jeder, den es interessiert, kann also herausbekommen, wo ich mein Wochenende verbracht habe. Das waren jetzt 2 Minuten Suche insgesamt - per Hand und nur aufgrund der Namen in den Mailinglisten. Mir ist nicht klar, was du damit ausdrücken möchtest. Doch wohl nicht, dass man hier nur dann als Beschwerdeführer ins Sachen Datenschutz auftreten darf, wenn man dies unter völliger Anonymität macht. Oder etwa, dass ich über Dinge rede, von den ich keinen Schimmer habe? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treppen und Räder (steps access)
Hallo Ralf, Am 14.07.2013 00:46, schrieb RalfGesellensetter: heute haben wir eine kleine Radtour unternommen, bei der wir (2 Erw. 2 Kinder) uns von OSM-Daten (gespeichert auf einem routingfähigen eTrex Legend Hcx im Bike-Modus) durch die (vermeintlich) vertraute Umgebung lotsen ließen. Man muss bei der Bewertung des Routings berücksichtigen, dass das Garmin-Gerät nicht mit den originalen OSM-Daten arbeitet. Vielmehr werden die OSM-Daten mit mkgmap in das Garmin-Format umgesetzt. Die Abbildung der OSM-Objekte und ihrer Eigenschaften auf Garmin-Objekte ist daher von Karte zu Karte unterschiedlich und es geht bei der Umsetzung immer Information verloren. Interessant wäre daher, welche Karte du auf dem Etrex verwendest. Am 14.07.2013 00:46, schrieb RalfGesellensetter: Im Alltag gibt es aber Abkürzungen, die so attraktiv sind, dass 2-3 Stufen die meisten Radler nicht abhalten würden - und Radsportler würden ihr Rad gerne auch 10-15 Stufen tragen, wenn sie dadurch die Bundesstraße oder einen Umweg umgehen könnten. Da die Garmin-Software, zumindest die des Etrex, nur ein Routing-Profil für Fahrradfahrer kennt, nutzen manche aus OSM-Daten generierten Garmin-Karten, z.B. die Openmtbmap, das Routing-Profil Auto / Motorrad für solche Zwecke. Dabei wird dann z.B. bei Einbahnstraßen in beiden Richtung geroutet. Ob dabei auch über Treppen geroutet wird, weiß ich nicht, aber es wäre machbar. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Am 14.07.2013 15:14, schrieb Frederik Ramm: Hi, On 14.07.2013 00:28, Dirk Sohler wrote: Ich hoffe, dass du eine Opt-out-Option einbaust, so können immerhin diejenigen, die davon Kenntnis erlangen, was du mit ihren Daten machst, und die das nicht möchten, verhindern, dass diese Daten ohne weiteres von jedermann mittels Suchmaske abgegriffen werden können. Diese Person hat der Nutzung ihrer Daten durch HDYC widersprochen. Um die Daten dieser Person dennoch anzuzeigen, gib auf einem geeigneten Linuxrechner die folgenden Befehle ein ... Nicht alles, was technisch machbar ist, ist rechtlich erlaubt und/oder moralisch vertretbar. Dass man meinen Mailverkehr ausspionieren kann und ich das auch weiß, berechtigt niemanden dazu, es zu tun und Statistiken darüber ins Internet zu stellen. Letztlich ist die Frage, ob die Auswertung der OSM-Daten einschließlich der Metadaten zu statistischen Zwecken und zur Erstellung eines Aktivitätsprofils und die Veröffentlichung der Ergebnisse durch die ODbL gedeckt ist. Ich habe da erhebliche Zweifel. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Am 14.07.2013 15:49, schrieb Ronnie Soak: Was habt ihr eigentlich immer mit Datenzusammenführung? Die Daten liegen doch in genau einer DB? Eine Datenzusammenführung liegt z.B. dann vor, wenn Informationen aus dem Userprofil auf openstreetmap.org mit den Informationen aus der Datenbank zusammengeführt würden, z.B. der geografische Standort, die Freunde etc. Bisher habe ich gesehen, dass in HDYC die Anzahl der Notes und die Zahl der GPS-Tracks aufführt, die sicher nicht aus der Datenbank stammen. Das ist schon grenzwertig. Ich muss aber gestehen, dass ich bisher davon ausgegangen bin, dass derartige Informationen nur von eingeloggten Usern gesehen werden können. Und wieso sind das Bewegungsprofile? Für die Hälfte meiner Edits hab ich mich nur leicht drehend im Bürostuhl bewegt. Die andere Hälfte an Edits hat zeitlich nur eine sehr wage Korrelation mit meinem Aufenthaltsort. Und keiner weiß, welcher Edit zu welcher Hälfte gehört. Nun ja, wenn sich jemand meine Heatmap, meine HDYC-Auswertung und Who's around me? anschaut, dann ist es für ihn ein Leichtes Rückschlüsse auf meinen Wohnort zu ziehen. Und wenn ich heute einen Changeset mit dem Kommentar site survey with GPS device mache, dann kannst du davon ausgehen, dass ich in den letzten drei Tagen an den Orten war, wo ich Änderungen gemacht habe. Mich juckt das wenig, aber das gilt nicht für jeden und bei mir auch nicht immer. Das nimmt mir eher die Lust am Mappen als es ein Badge kompensieren könnte. Gruß rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo, Am 07.07.2013 16:57, schrieb Eckhart Wörner: Abgesehen davon kann ich mir nicht vorstellen, dass Mentz Daten ihrer Kunden in OSM einpflegt, ohne die Kunden vorher um Erlaubnis zu fragen. Kann ich mir auch nicht vorstellen. Die Frage ist, ob sich diese Kunden über die Tragweite ihrer Zustimmung im Klaren sind. Wenn ebendiese Kunden ihre Daten bisher nicht unter mit den Contributor Terms kompatiblen Bedingungen bereit gestellt haben, dann ist es legitim daran zu zweifeln, ob ihnen klar ist, dass sie das jetzt auf dem Umweg über die Firma Mentz tun. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprache des Namens Fehler in Kort.
Hallo, Am 24.06.2013 09:03, schrieb Jo: Ich wohne in Belgien. Es ist natürlich noch etwas komplexer als dann mussen beide Sprachen angezeigt werden. 1. haben wir 3 offizielle Sprachen: nl, fr, de 2. Im norten nl, im süden fr, im osten de und in Brüssel fr-nl/nl-fr. In manche Fazilitätgemeinde nl-fr, in andere fr-nl. In der Schweiz passiert warscheinlich etwas ähnliches. Ich würde Name ersetzen mit Referenzen zu ISO Abkürzungen, z.B.: name:nl=Brussel name:de=Brüssel name:fr=Bruxelles name:en=Brussels name=fr - nl Dieser Vorschlag geht in die richtige Richtung, aber IMHO nicht weit genug. Use Cases, die damit nicht umgesetzt werden können: - Anzeige der Toponyme in der/den Amtssprache(n), also: Deutsch und Italienisch in Südtirol, Französisch und Niederländisch in Brüssel, Französisch in Wallonien, Niederländisch in Flandern, Katalanisch und Kastilisch in Katalonien. Während dies in manchen mehrsprachigen Regionen schon im name-Tag umgesetzt ist, hat man anderswo einen anderen Weg gewählt, z.B. in Katalonien: name=Girona, name:es=Gerona. - Anzeige der Toponyme in der Regionalsprache, also: Bretonisch in der Bretagne, Katalanisch in Katalonien (ausser im Val d'Aran, dort Aranesisch), Valencia, den Balearen, in Andorra und dem katalanischsprachigen Teil Frankreichs,... - Anzeige der Toponyme auf Deutsch sofern es sich um heutige oder historische Endonyme handelt, also: Königsberg, Straßburg, Bozen, Laibach Damit auch diese Use Cases abgedeckt werden können, werden für jeden mit name:xx erfassten Namen zusätzlich folgende Informationen benötigt: - es handelt sich um die Bezeichnung in einer vor Ort üblichen Sprache (Endonym) oder um eine Fremdbezeichnung (Exonym) - bei Endonymen: Amtssprache oder nicht, Regionalsprache oder Landessprache, historisch (Königsberg) oder zeitgenössisch (Kaliningrad) Derartige Informationen sollten sinnvollerweise nicht für jedes einzelne Objekt erfasst werden sondern zentral für die betroffene boundary-Relation bzw. gesonderte Relationen für Sprachgebiete. Das Thema ist recht komplex, teilweise auch politisch sensibel, so dass ich mich inzwischen frage, ob man es in einer geografischen Datenbank wie OSM befriedigend abbilden kann. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wir sind doch nicht bei Wikipedia-de
Am 31.05.2013 12:30, schrieb Tobias Conradi: Die von Frederik Ramm aufgestellten unrichtigen Behauptungen und die Ausschmückungen seiner Email mit unverschaemt usw. waren in der Tat sehr lehrreich. Ich kann dir nur empfehlen, Frederiks Beitrag nochmals in aller Ruhe und unvoreingenommen durchzulesen. Für mich als Außenstehendem wird dort alles sachlich und verständlich dargelegt: Um dir zu helfen, hat Sven einen Sandbox-Account für dich eingerichtet. Das macht er nur in Einzelfällen. Es ist kein Service, den er generell und jedem anbietet. Du hast im Wiki beschrieben, wie du zu diesem Sandbox-Account gekommen bist. Entweder hast du das für dich als persönliche Notiz gemacht, dann gehört es nicht in den Wiki. Oder aber das war von dir als Anleitung für Jedermann gedacht, dann gehört es nicht ins Wiki, weil das Einrichten eines Sandbox-Accounts kein Service ist, den Sven für Jedermann anbietet. Ergo gehört die Anleitung in jedem Fall gelöscht. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 15:26, schrieb Wolfgang Hinsch: Am Mittwoch, den 29.05.2013, 12:52 +0200 schrieb Peter Wendorff: Am 29.05.2013 10:05, schrieb Wolfgang Hinsch: Wenn das normalerweise egal ist, nur für offizielle Drucke der offiziellen Farben nicht - dann nimmt man für diese offiziellen Drucke auch offizielle Daten, also ist OSM normalerweise aus dem Spiel. Und für eine Übersicht klappert man xx Unternehmen an, fragt nach Farben, die man sonst sofort verwenden könnte. Spätestens nach der 100. Anfrage fragen sich bestimmt einige, ob die bei OSM noch gesund sind. Haben eine Datenbank und fragen ständig nach... Es wäre sinnvoll, mal zu erklären, wozu das Erfassen der exakten Farben dienen soll, bevor man festlegt, in welcher Form man sie abspeichert. So wie ich es verstanden habe, geht es um Farben, welche von den Verkehrsbetrieben auf ihren Linienplänen verwendet werden, nicht aber um Farbcodes für die Linien, im Sinne von Linie 21 = die lilablassblaue Linie. Wenn ich damit richtig liege, dann würde es sich nur ein gestalterisches Mittel diese farbcodes Somit geht es darum, dass auf OSM-basierten Karten dieselben Farben verwendet werden wie auf dem Linienplan des jeweiligen Verkehrsbetriebs. Man nimmt damit dem Renderer die Mühe ab, bei einer Vielzahl von Linien einigermaßen unterscheidbare Farben auszuwählen. Das ist ganzs praktisch, aber mappen wir für den Renderer? Ein weiteres Ziel könnte sein, dass der Nutzer auf der OSM-Karte dieselben Farben wiederfindet wie auf der BVG-Karte. So ganz erschließt sich mir der Nutzen davon allerdings nicht. Schließlich werden die Farbcodes ja nicht auf den Fahrzeugen verwendet, und selbst wenn, dann wäre der Wiedererkennungsgrad sehr gering, da sich z.B. in Berlin manche der Farben nur im direkten Vergleich unterscheiden lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 16:48, schrieb Wolfgang Hinsch: Am Mittwoch, den 29.05.2013, 16:42 +0200 schrieb RainerU: Ein weiteres Ziel könnte sein, dass der Nutzer auf der OSM-Karte dieselben Farben wiederfindet wie auf der BVG-Karte. Vergiss in diesem Zusammenhang die OSM-Karte aus dem Web. Um die geht es mir überhaupt nicht. Dafür reicht der RGB-Wert immer aus. Aber es gibt noch viele Welten neben der Karte. Mit der OSM-Karte ist natürlich jede auf der Basis der OSM-Daten erzeugte Karte gemeint, das kann auch ein schematisierter Linienplan sein, oder auch eine Anwendung bei der der aktuelle Standort des Fahrzeugs in der entsprechenden Farbe angezeigt wird (was noch nicht mal die Verkehrsbetriebe in ihren RBLs machen). Letztendlich geht es dabei immer darum, eine mit einer Linie assoziierte Information in genau der Farbe darzustellen, die auch der Verkehrsbetrieb in seinen Veröffentlichungen benutzt. Mir fehlt noch der Anwendungsfall, wo das sinnvoll oder notwendig ist. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 30.05.2013 04:01, schrieb Tobias Conradi: 2013/5/29 RainerU ra...@sfr.fr: Letztendlich geht es dabei immer darum, eine mit einer Linie assoziierte Information in genau der Farbe darzustellen, die auch der Verkehrsbetrieb in seinen Veröffentlichungen benutzt. Mir fehlt noch der Anwendungsfall, wo das sinnvoll oder notwendig ist. Z.B. einen Stadtplan herausgeben, auf dem die U-Bahnlinien in der Linienfarbe dargestellt sind. Meine Frage ist: warum ist es sinnvoll/notwendig auf einem derartigen Plan die Linien genau in derselben Farbe darzustellen, wie das der Verkehrsbetrieb auf seinen eigenen Plänen macht? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Export-Funktion
Am 28.05.2013 16:23, schrieb Peter Wendorff: Gibt es mittlerweile den Mapnik-Style als Carto-Stildefinition? Dann kann man eventuell ein How-To schreiben, das Tilemill benutzt. Den Stil gibt es, er funktioniert gut und das Ergebnis ist vom Mapnik-Style nicht zu unterscheiden: https://github.com/gravitystorm/openstreetmap-carto Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ist der ID Editor reif für osm.org?
Hallo, Am 17.05.2013 02:08, schrieb Tirkon: Nachdem in einem anderen Posting über die gravierenden Mängel von ID gesprochen wird, möchte ich hier die Frage stellen, ob der Editor wirklich reif für osm.org ist? Möglicherweise werden die folgenden Fragen etwas provokativ erscheinen. Aber sie stellen sich eben, wenn man an die Zukunft von OSM denkt. Wenn man an die Zukunft von OSM denkt, dann sollte man grundsätzliche Überlegungen über Sinn, Zweck und Funktionsumfang des Online-Editors auf der Projektseite anstellen. Ist es sinnvoll und notwendig, auf der Einstiegseite einen Editor anzubieten, der jedem Neuling unbegrenzten Zugriff auf die Daten bietet? Das hat ja nicht nur den Nachteil, dass Neueinsteiger ungewollt und unbewusst Strukturen zerstören können. Für mindestens genauso gravierend halte ich es, dass Leute, welche die Mächtigkeit des Tools und die damit verbundenen Risiken erkennen, es aus Vorsicht lieber sein lassen und somit den Einstieg in OSM verpassen. Ein failsafe-Editor mit eingeschränkter Funktion wäre an dieser Stelle besser angebracht. Für alle anderen kann man ja an anderer Stelle eine Vollversion mit entsprechend deutlichen Warnhinweisen bereit stellen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building=yes vs. building=residential
Am 14.05.2013 10:02, schrieb Martin Koppenhoefer: bitte nicht die Bedeutung von building umdefinieren, die Nutzung ergibt sich aus anderen tags (wobei der Typ sich schon nach der geplanten Nutzung richtet, d.h. es gibt einen Zusammenhang). Dann sollte man das im Wiki auch klar zum Ausdruck bringen bzw. gerade ziehen. Dort sind für building=* u.a. die Werte hotel, commercial, industrial, school, university aufgeführt. Damit wird aus meiner Sicht ganz klar die Nutzung und nicht die Gebäudeart beschrieben. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building=yes vs. building=residential
Am 15.05.2013 11:52, schrieb Martin Koppenhoefer: Von daher ist residential auch nicht falsch (Wohngebäude ist in der Tat ein Gebäudetyp), aber eher als vorläufiger Wert zu sehen, und wer sich gut in seinem Gebiet auskennt, der mappt (m.E.) besser gleich eine oder 2 Stufen genauer. Für mich sind Gebäudetypen: Reihenhaus, freistehendes zweistöckiges Gebäude mit Flachdach, Industriehalle, mehrgeschossiges Gebäude mit mehreren getrennten Nutzungsbereichen pro Etage, mehrgeschossiges Gebäude mit durchgehender Nutzung pro Etage, schloßartiges historisches Gebäude usw. Alle diese Gebäudetypen können genutzt werden: zu Wohnzwecken, gewerblich, industriell, als Schule, als Kindergarten,... Die derzeitige Definition von building=* vermischt das alles. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapper-Treffen
Hallo Thorsten, Am 06.05.2013 00:40, schrieb Thorsten Alge: Gibt es da was um auf einfache Weise eine Liste solcher Nutzer auf die diese Kriterien zutreffen zu bekommen und allen eine Nachricht über die OSM-Seite zuzuschicken? Da über OSM keine Mails an eine Verteilerliste möglich ist, ist es sinnvoll und notwendig, die Zahl der Adressaten zu beschränken. Man kommt daher, selbst wenn es eine automatische erstellte Liste gäbe, nicht umhin, händisch zu selektieren. Es gibt Bots, User die landes- oder weltweit bestimmte Themen mappen, User, die mal in der Gegend aktiv waren und inzwischen weggezogen sind, User, die ihren Schwerpunkt anderswo haben, aber regelmässig Urlaub in deiner Gegend machen,... Als ich das gemacht habe, habe ich mich auf die Informationen von itoworld.com [1] gestützt: Anzeige der OSM Sessions, Kopie in Tabellenkalkulationsprogramm, händische Auswertung nach Anzahl der Changesets und Datum, Herausfiltern der Bots. Auch [2] kann hilfreich sein. Ergänzend kann man das Treffen ja hier auf der Liste und im Forum ankündigen. Gruß Rainer [1] http://www.itoworld.com/product/osm [2] http://resultmaps.neis-one.org/oooc ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landessprachen, Regionalsprachen,
Hallo Simon, Am 28.04.2013 15:42, schrieb Simon Poole: Die Annahme ist schon mal falsch. Es gibt Gemeinden die echt zweisprachig sind. Ja, das ist mir schon klar, spätestens seit ich mich vor langen Jahren mal in Biel verfahren habe und die befragten Passanten mir mal auf Deutsch mal auf Französisch geantwortet haben. Ich würde in solchen Fällen beide gesprochenen Sprachen im Place oder an der Boundary der Gemeinde eintragen, je nach rechtlicher Lage als Amtssprache oder als gesprochenen Sprache. Mir ging es um Sprachgebiete, deren Ausdehnung mit keiner in der admin_level-Hierarchie entsprechenden Einheit übereinstimmt und die sich auch nicht aus solchen Einheiten zusammensetzen. Das würde bedeuten, dass die Sprachgrenze innerhalb der untersten Verwaltungsebene verläuft. Solche Fälle sehe, zumindest was amtlich anerkannte Sprachen anbelangt, nicht. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Landessprachen, Regionalsprachen,
Hallo, Meine Fragen stehen im Zusammenhang mit einem Projekt einer regionalen Karte für Katalonien, aber das Thema betrifft eine Vielzahl von Ländern und Regionen. Wahrscheinlich wäre das auch ein Thema für die Tagging-Liste, aber ich versuche es erst mal hier vorzuklären. Das Ziel ist es, die Toponyme in einer bestimmten Sprache, in meinem Fall Katalanisch, anzuzeigen mit Rückfall auf die bzw. eine offizielle Sprache, typografisch als solche erkennbar, wenn kein Name-Attribut für die gewünschte Sprache vorhanden ist. In einem weiteren Layer sollen die Toponyme in der/den jeweiligen lokalen Sprache(n) angezeigt werden. Um die Aufgabenstellung allgemein, d.h. losgelöst von der konkreten Situation in einer Region lösen zu können, bräuchte man folgende Informationen: - die offizielle(n) Sprache(n) einer administrativen Einheit. - die Grenzen offiziell anerkannter Sprachgebiete, sofern diese nicht mit einem über admin_level abgebildeten Gebiet identisch sind. - die Grenzen von faktischen und/oder historischen Sprachgebieten, wie z.B. Katalanisch in Frankreich. - die Sprache, in der das name-Attribut eines Objekts erfasst ist. Auf das Erfassen der Grenzen von Sprachgebieten kann man verzichten, wenn man davon ausgeht, dass es immer eine kleinsten Verwaltungseinheit (Gemeinde) gibt, in der eine einheitliche Sprachregelung gilt, und man die Sprach-Tags an diese Einheiten hängt. Bei den name-tags sollte man dazu übergehen, systematisch neben name=wert auch zusätzlich name:sprache=wert zu taggen, auch in einsprachigen Gebieten. Amtsprachen kann man mit language=* im boundary- oder place-Objekt taggen, anerkannte oder faktische Sprachen mit eigenen Tags, z.B. spoken_language. Ich habe dafür aber keine Beispiele gefunden. Gibt es einen Vorschlag oder eine eingeführte Praxis? language=* wird laut Taginfo nur 86 mal verwendet. Ich erinnere mich, dass das Thema schon diskutiert wurde, kann mich aber an keinen abschließenden Konsens erinnern und habe auch im Wiki nichts dazu gefunden. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verwenden der Tiles von toolserver.org
Hallo, Ich möchte Tiles von toolserver.org, speziell www.toolserver.org/tiles/osm-no-labels, auf einer Webssite verwenden (als OpenLayers-Layer). Kennt jemand die Nutzungsbedingungen für diese Tiles bzw. einen Ansprechpartner, mit dem man die Nutzung abklären kann? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rechtschreibung und Zeichensetzung in den Karten
Hallo, Am 22.04.2013 19:42, schrieb Martin Trautmann: On 13-04-22 18:02, Andreas Schmidt wrote: Aber - da ich ja wohl der Urheber der ganzen Diskussion war - ich finde inzwischen, dass ich einen Kindergarten namens Kita „Villa Kunterbunt“ als Kita Villa Kunterbunt eintragen sollte. Nö, als name=Villa Kunterbunt amenity=kindergarten Ich unterstelle mal, dass Kita hier eine Abkürzung für Tageseinrichtung für Kinder ist, ein in Deutschland auf Länderebene gesetzlich geregelter Typ von Einrichtungen mit ganz bestimmten Eigenschaftenund Anforderungen. Nach meinem Verständnis wird aber amenity=kindergarten nicht ausschließlich für Einrichtungen verwendet, die diesen Anforderungen entsprechen. Auch ein nur halbtags betreuender Waldkindergarten würde so getaggt. Lässt man also Tageseinrichtung für Kinder weg, geht Information verloren. Die Lösung ist entweder name=Tageseinrichtung für Kinder Villa Kunterbunt short_name=Villa Kunterbunt amenity=kindergarten oder besser name=Villa Kunterbunt amenity=kindergarten kindergarten:DE=Tageseinrichtung für Kinder Zu bevorzugen wäre die zweite Variante, da diese besser für maschinelle Auswertung geeignet ist. Das gilt im übrigen auch für Einrichtungen vom Typ amenity=school. Nach deinem Vorschlag müsste eine Gesamtschule Am Wiesenrand mit name=Am Wiesenrand amenit=school getaggt werden, womit klar wird, dass da etwas fehlt, z.B. ein: school:DE=Gesamtschule Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Am 20.04.2013 11:05, schrieb Volker Schmidt: state=proposed Siehe: https://wiki.openstreetmap.org/wiki/Cycle_routes Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Hallo Henning, Am 20.04.2013 11:34, schrieb Henning Scholland: Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. So wird es sein. Warum auch? Wer rechnet damit, dass wenn einer route=bicycle und network=*cn setzt, dann noch ein weiteres Tag kommt, dass sagt: Ätsch, aber erst in x Jahren? Wenn die Route noch keine Radroute ist, dann ist das Setzen von route=bicycle falsch. Anlass meiner Frage ist die im Radreise Fernradler Forum hochgekommene Kritik an der OpenCycleMap [1], die speziell in Frankreich viele Radwanderwege anzeigt, die nur in der Planung existieren. Ich halte es nicht für sinnvoll, die entsprechenden Relationen zu löschen. Das würde die dortige Community auch nicht akzeptieren. In einigen Fällen sind die Wege bereits in der Realisierung, z.B. der Abschnitt am Canal du Midi im Département Aude. Da ist es nicht sinnvoll, die Relation jetzt zu löschen und in ein paar Monaten wieder neu anzulegen. Wie bei Straßen kann es auch interessant sein den Planungsstand zu erfassen. Und es wäre auch unfair den Mappern gegenüber, die sich viel Mühe gemacht haben. Ich werde wohl den Vorschlag state=proposed zu verwenden. Schön wäre wenn Waymarkedtrails dieses Attribut auch auswerten und die Routen gestrichelt oder auf andere Weise erkennbar anzeigen würde. Gruß Rainer [1] http://radreise-forum.de/topics/930026/Neues_aus_dem_Radreise_Wiki#Post930026 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Da hab ich ja nichts gegen, dass die dargestellt werden. Auch das es sinnvoll für die Radler sein kann bestreite ich nicht. Ich finde es nur schlecht, wenn man als Auswerter zig Tags zusätzlich abfragen muss, um tatsächlich existierende Objekte zu finden. Das steigert nicht gerade die Lust unsere Daten zu nutzen. Da gebe ich dir grundsätzlich Recht. Aber wer die Lust nicht schon verloren hat, wenn er aus den access-Tags ermitteln will, ob ein Weg für Radfahrer zugelassen ist, der die schafft auch noch das eine oder andere Tag an Route-Relationen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] proposed/construction bei Relationen
Hallo, Bei Straßen, die geplant oder im Bau sind, setzt man proposed=highway_type bzw, construction=highway_type anstelle des highway-Attributes. Wie macht man das bei Relationen, z.B. einem geplanten Radwanderweg? proposed=bicycle anstelle von route=bicycle? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarten mit Hillshade/ Hillcolour
Am 08.03.2013 21:38, schrieb Martin Simon: Dann öffne man diese mit JOSM und schließe um die Kanten der Kachel herum die Höhenlinien zu Flächen zusammen (immer so, dass ein Schnitt durch das gelände auf der jeweiligen Höhe diese Flächen ergeben würde). Dann braucht man noch eine TYP-Datei, die zu jeder Höhenstufe eine Farbe enthält. Ich habe mir mehr Farben erschummelt, indem ich teilweise transparente Flächen definiert habe, die Teile der darunter liegenden Farbe durchscheinen liessen. Super Idee! Kann man die TYP-Datei bekommen? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mustertext für Datenspende
Hallo, ich bin auf der Suche nach einer Formulierung, mit welcher eine Gemeinde dem Projekt OSM die Nutzung von georeferenzierten Daten erlaubt. Gibt es dafür Bespiele? Eine Suche in den Archiven und im Wiki hat leider nichts ergeben. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mustertext für Datenspende
Hallo Joachim, Am 04.03.2013 18:45, schrieb Joachim Kast: in welchem Bundesland bzw. Staat möchtest Du die Anfragen stellen? Es geht um Frankreich. Über die französische Community habe ich zwar ein paar nützliche Tipps zum Thema Opendata bekommen, aber eben keinen Textvorschlag für eine derartige Vereinbarung. Der Vorschlag auf der Wiki-Seite zum Datenimport[1] ist mir zu knapp: The #ORGANISATION# has no objections to geodata derived in part from #DATASET# being incorporated into the OpenStreetMap project geodata database and released under a free and open license Ich stelle mir noch ein paar Sätze darüber, was mit der Datenbank gemacht werden kann/darf, und zum Thema Attribution vor. Welche georeferenzierten Daten? Georeferenziert war nicht ganz korrekt von mir. Es geht um eine Straßenliste mit den Straßennamen auf Französisch und Katalanisch. Über die bereits vollständig erfassten französischen Straßennamen können wir damit den OSM-Objekten die katalanischen Namen zuweisen. Gruß Rainer [1] http://wiki.openstreetmap.org/wiki/Import/GettingPermission ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mustertext für Datenspende
Hallo Joachim, Am 04.03.2013 23:14, schrieb Joachim Kast: Sind in Perpignan zweisprachige Straßenschilder montiert? Ja, und es ist auch schon einiges erfasst worden [1]. Ich denke, im konkreten Fall werden wir die Daten ohne große Probleme bekommen. Ich habe das Thema nur deshalb so hoch aufgehängt, weil es eventuell der Einstieg in ein umfangreicheres Programm der Datenüberlassung sein könnte. In Frankreich sind der Staat und einige Städte beim Thema Open Data ja schon recht weit. So stellt z.B. die Stadt Montpellier Geodaten zu Themen wie Radwege und Behindertenparkplätze unter LO/OL-Lizenz zur Verfügung. Das Ziel der lokalen OSM-Gruppe ist es, auch die hiesigen Behörden in diese Richtung zu bewegen. Grüße Rainer [1] http://mlm.jochentopf.com/?zoom=17lat=42.69931lon=2.89611layers=B0Tlang=ca [2] http://opendata.montpelliernumerique.fr/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen weicher Kriterien bei Radwegen
Am 13.12.2012 15:35, schrieb Henning Scholland: Ich stelle mir hier und auch bei den Parkern eher eine Lösung vor, die den Radfahrer primär warnt, dass er hier vorsichtig sein muss und damit rechnen sollte, dass er den Radweg mit nicht Radfahrern Teilen muss. Genau das ist der Punkt um den es mir im UP ging, und dafür suche ich ein geeignetes Tag. foot=permissive würde im Fall der Fußgänger auf dem Radweg zwar die Radfahrer zufriedenstellen, aber den Fußgängern eine Nutzungserlaubnis anzeigen, die tatsächlich nicht existiert. Wenn man die Zahl der Keys in Grenzen halten will, dann käme foot=accepted, foot=customary, foot=inofficial oder ähnliches in Frage. Anders herum könnte man solche Situationen mit nuisance=parked_cars, disturbance=pedestrians kennzeichnen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taggen weicher Kriterien bei Radwegen
hallo, Im Zusammenhang mit der Erstellung einer lokalen Fahrradkarte stellt sich die Frage, ob es eine Möglichkeit gibt, Radwege und Radstreifen neben der auf der legalen Situation basierenden Attribute auch mit einer nutzerorientierten Klassifizierung zu versehen. Hintergrund ist der Wunsch, auf der Karte Wege, die zwar denselben Nutzungsver- und geboten unterliegen, aber auf Grund der Umstände für den Nutzer von ganz unterschiedlicher Qualität sind, optisch unterscheiden zu können. Ein Beispiel hierfür ist ein dedizierter Radweg (Zeichen 237), der aber aufgrund seiner Bauweise und Lage stark von Fußgängern frequentiert wird. Oder ein Radstreifen, der de facto seine Funktion nicht erfüllt, da die Markierung am Boden kaum erkennbar ist. Oder ein Radstreifen, dessen Benutzung wegen mangelnder Breite und/oder starken Lkw-Verkehrs für bestimmte Nutzergruppen unzumutbar ist. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen weicher Kriterien bei Radwegen
Am 12/12/2012 13:46 schrieb Frederik Ramm: Eher nein, weil solche Klassifizierungen in aller Regel subjektiv sind und daher nicht unserem Wunsch nach Ueberpruefbarkeit durch Dritte standhalten. Grundsätzlich sehe ich das auch so und versuche daher auch, subjektive Daten nach Möglichkeit extern zu halten. Das ist z.B. bei Gefahrenpunkten mit geringem Aufwand für die Umsetzung und Pflege zu machen. Bei den Radwegen und -spuren scheidet solch eine Lösung aus, da ich auf jeden Fall die Topologie und die Standardattribute aus OSM verwenden will. Erst recht gilt das, wenn man die Radfahreignung sämtlicher Verkehrswege darstellen möchte. Und wie ausgiebige Diskussionen, z.B. [1], gezeigt haben, gibt es keine einfach handzuhabende Lösung, um OSM-Objekte mit anwendungspezifischen, extern gehaltenen Daten zu verknüpfen. Die Radfahreignung aus Zusatztags wie surface, width, smoothness usw. abzuleiten, halte ich für nicht praktikabel. Zum einen ist ein flächendeckende Versorgung mit diesen Tags in absehbarer Zeit nicht zu erwarten. Zum anderen ist eine programmtechnische Auswertung dieser Tags, die alle möglichen Kombinationen abdeckt, kaum möglich. Ein class:bicycle mit mit vier bis sechs Stufen und einer Kategorisierung mittels objektiver Kriterien, wie Breite, Belag, Steigung, Fahrzeugfrequenz, ähnlich wie das bei sac-scale, mtb:scale und tracktype gemacht wurde, wäre aus meiner Sicht eine pragmatische Lösung. Leider erfüllt der Vorschlag im Wiki diese Anforderungen auch nicht ansatzweise. In meinem Fall kann ich mich auf eine Klassifizierung der örtlichen Radfahrorganisation stützen. Entweder erfinde ich dafür ein spezielles Tag oder ich bilde das auf class:bicycle ab. Gruß Rainer [1] http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.de/96029 [2] http://wiki.openstreetmap.org/wiki/Class:bicycle ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen weicher Kriterien bei Radwegen
Hallo Hennig, Am 12.12.2012 16:51, schrieb Henning Scholland: Das simpelste Beispiel ist tracktype. Die Werte werden genutzt, wie es dem Mapper gerne passt. Mal ist eine ebene Schotterpiste grade1, mal eine holprigere Asphaltpiste grade2 usw. Im wiki steht als Definition nur der Grad der Befestigung, nicht ob der Weg eben ist oder nicht. Meine Erfahrung in der Praxis ist gerade gegenteilig. Als Track getaggte Wege werden in der Regel nur für land- und forstwirtschaftlichen Verkehr genutzt. Grade1-Tracks sind in Mitteleuropa in der Regel asphaltiert, Grade2-Tracks haben zumindest bei trockenem Wetter eine Oberfläche, die bequem mit 32er-Reifen befahren werden kann. Die Begründung: surface, smoothness und width gibt es nicht flächendeckend, dann nehmen ich halt class:bicycle finde ich recht merkwürdig. Das ist um den Faktor 100 weniger verbreitet als smoothness, bei surface ist es Faktor 5000. Wie schon die Werte horrible und unpassable zeigen, ist smoothness ein extrem subjektives Attribut. Wahrscheinlich ist es genau deshalb auch so weit verbreitet. Laut Wiki entspricht smoothness=good (thin_wheels) racing bike. Was bitte sind thin wheels? Ich fahre mit Rennrad und 25er-Reifen schon mal über nicht-asphaltierte Wege, soll ich die also mit smoothness=good taggen? Wenn nicht, dann frage ich mich, wie sieht ein Weg aus, der mit dem Rennrad befahrbar ist, also smoothness=good, aber nicht mit dem Skateboard (erfordert excellent)? Aber wie gesagt, ich finde class:bicycle auch nicht optimal und einen key scale:adfc_ortsgruppe_hitertupfingen ist auch nicht viel besser. Aber ich sehe nach wie vor keine andere Möglichkeit, nicht messbare Informationen wie Radweg ständig zugeparkt mit OSM-Daten zu verknüpfen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
