Re: [Talk-de] Maß für die Genauigkeit von Eigenbau-GPS-Geräten?
On 01.09.2020 09:37, Eifelhunde via Talk-de wrote: > was auch interessant ist, es gibt für GPS referenzsateliten die fest > über dem Horizont stehen, mein GPS kann die Empfangen und verarbeiten. > zeigt so praktisch beide Seiten einer Straße an. Für meine Anforderungen wäre SBAS/WAAN/EGNOS nicht relevant, da ich meine GPS Spuren in einem Land ziehe für die es kein Messnetzwerk mit Ionosphärenkorrektur gibt. Da wäre wichtig, dass der Logger entweder merkt, dass es für den Bereich keine Korrektur gibt und er es ignoriert, oder das ganze abschaltbar. Ich hatte irgendwo mal einen Vergleich gemacht was passiert wenn der Logger fälschlicherweise eine Korrektur in einem Gebiet anwendet für die es keine Daten gibt. Da kam es zu einem üblen Offset. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maß für die Genauigkeit von Eigenbau-GPS-Geräten?
Hallo Manuel, On 31.08.2020 16:30, Manuel Reimer wrote: > Was würdet ihr noch probieren um Performance zu vergleichen? Mal zu Fuß dicht an hohen Häuserwänden gehen. Die Hoffnung wäre, dass die Empfänger mit mehr Satelliten hier weniger problemen mit Reflektion haben. Da dürfte dann vermutlich auch die Antenne eine Rolle spielen. > Besteht grundsätzlich Interesse am Eigenbau von GPS-Empfängern? Da meine BT747 Sammlung auch irgendwann nicht mehr funktionieren wird und ich auch Bedenken habe mal noch Ersatz für die Akkus zu bekommen, besteht schon Grundsätzlich Interesse. Das große Problem wird der Preis werden. Diese ganzen kleinen Handlichen Logger hat man ja problemlos bei eBay für Preise zwischen 30 und 50 Euro bekommen, je nachdem ob gebraucht, oder neu. Wenn du selbst baust wirst du preislich vermutlich deutlich drüber liegen, oder? Und dann unterscheiden sich auch noch die Wünsche gewaltig. In den letzten Umfragen reichte die Spanne von "wasserdicht", über "mit Display" zu "Standard-Batterien", "externe Antenne" und Rohdatenaufzeichnung. Ich vermute auch dass man Anpassungen an der Firmware braucht. Zu Fuß reicht eine Aufzeichnung mit 1Hz super. Mit dem Auto könnte es ruhig etwas mehr sein. Und für fliegende Anwendungen sind wir eher im 10Hz Bereich. Dann musst du unterscheiden wie die Strategie ist um die Messwerte zu Glätten. Wenn du schnell Abbiegst, wie genau folgt der Logger dann der Spur? Ich glaube auf den Garmin Geräten hatte die Wahl des Fortbewegungsmodus das auch beeinflusst. Im "Kfz" Mode war der Nachlauf in die alte Richtung etwas größer. Klingt nach einem spannenden Projekt. Hast du auf einer Website/Blog noch mehr Details? Bilder, Materialliste, etc.. ? Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mediatek Logger (747) und GPS Datum Problem
Hallo, mit den Mediatek MT3329 basierten Loggern wurden Probleme bezüglich des GPS Datums nach dem GPS Week Rollover Anfang April gemeldet. Betrifft die Transystem iBlue 747/747 A+ Modelle sowie auch baugleiche von Blumax oder QStarz. Ich konnte bei einigen meiner Logger aus dem Archiv das Problem nachvollziehen. Hier in den Kommentaren gibt es den Anfang der Diskussion: https://www.technologyblog.de/2012/01/bt747-einstellungen-fur-i-blue-747a-gps-datenlogger/#comment-2493 Lösung war dann doch ganz einfach. Das Datum der RTC mit NMEA Befehl setzen, dann funktioniert es wieder. Hier die genau Erklärung: https://www.technologyblog.de/2019/05/gps-rollover-zerstoert-gps-logger/ Viel Spaß noch beim GPS Tracks aufzeichnen und nicht vergessen die auch sichtbar bei OSM hochzuladen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] POIs - Details - Gerichtsurteil
On 02.11.2018 07:03, sepp1...@posteo.de wrote: Irgendwann kommt irgendwer auf die Idee, einen Friedhof mit all seinen Gräbern und Grabsteininschriften als POI zu mappen, weil's geht - ich denke, irgendwo hörts ganz einfach auf. Gibt es das nicht auch schon in OSM? Taginfo listet etwas über 20.000 POI https://wiki.openstreetmap.org/wiki/Tag:cemetery%3Dgrave https://wiki.openstreetmap.org/wiki/Tag:historic%3Dtomb Wir müssen halt aufpassen, dass wir nicht einfach ein anderes Projekt kopieren, z.B.: https://www.findagrave.com/ Immerhin verwenden die OpenStreetMap als Karte... Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 10 EUR Bahnrabatt für Changelist reviews
Hallo, es gibt gerade wieder etwas Kritik an der Qualität mit der Facebook in Thailand das Mapping durchführt. unpassende Klassifizierung, nicht verbunden oder plötzlich endend, schlechte Geometrie oder was ganz anderes. Wir haben demnächst einen Konferenz-Call mit dem Facebook Team und würden da gerne noch etwas mehr Beispiele für schlechtes Mapping präsentieren. Vielleicht hilft das ja dabei dass Facebook ihr Mapper-Training etwas verbessert. Die verwendeten Accounts sind hier gelistet, sind aber recht leicht erkennbar, da nach Schema: VLD001, RVR001, jeweils mit anderen Nummern. https://wiki.openstreetmap.org/wiki/AI-Assisted_Road_Tracing Im Süden von Thailand sind die Edits sehr präsent, da es dort kaum andere Mapper gab. Bitte kommentiert schlechte Changes direkt in einem Changeset comment. Wäre nett wenn ihr mir dann auch einen Link schickt, dann habe ich das gleich griffbereit. Wir werden aber auf jeden Fall die letzten Comments der Facebook Mapper vor dem Meeting ansehen. Als kleines Dankeschön für die Unterstützung gibt es für die zwei schnellsten Rückmeldungen zu schlechten Edits jeweils einen 10 EUR Gutschein aus der ferrero-hinundweg.de Aktion mit dem man günstiger Bahnfahren kann. Vielen Dank schon mal für eure Hilfe, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Karte zur Geldautomatensuche finde.cash!
Hallo Nils, wie ist denn die Zuordnung zu den Bankverbünden realisiert? Die BW-Bank gehört zum Sparkassenverbund, das wird aber nur manchmal so angezeigt. Mein Eindruck ist, dass "LBBW" und "BW Bank" erkannt wird, "BW-Bank" aber nicht. Gruß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenschutz bei OSM - Schweiz
Hallo Markus, das von dir zitierte Dokument scheint auf OSM nur sehr begrenzt zuzutreffen. Es bezieht sich ja ausdrücklich auf GIS die personenbezogenen Daten sichtbar machen sollen. Als Beispiel ist eine Anwendung aufgeführt, die Alter und Einkommen der Bewohner eines Quartiers auswertet. Also so etwas wie das Geoscoring, das der Schufa nachgesagt wurde. Das was wir erfassen sind reine Geodaten ohne Personenbezug. Somit nicht zutreffend. Bleiben die Metadaten. Die sind aber nicht an eine Person gekoppelt, sondern an ein Pseudonym. Du hast weder eine technische, noch eine rechtliche Möglichkeit herauszufinden welcher Person ein Pseudonym zuzuordnen ist. Dass es Ausnahmen gibt in denen eine Person freiwillig eine Beziehung zu ihrem Pseudonym herstellt ist bei der großen Masse die Ausnahme und somit auch nicht relevant. Was sicher nützlich ist wäre ein deutlicher Hinweis bei der Anmeldung dass die Metadaten essentiell für das Funktionieren der Community sind und einsehbar sind. OSM ist aber bei weitem unkritischer als Internet Foren, bei denen ja auch das Datum und Uhrzeit angezeigt wird. Oder noch schlimmer Facebook, bei dem durch Einbeziehung der Freunde eine Person in der Regel identifizierbar ist. Stephan On June 13, 2017 6:20:22 AM GMT+02:00, Markus wrote: >Hallo Frederik, > >> Fürsorgepflicht gegenüber unseren Mappern >> vor möglichem Datenmissbrauch schützen > >Zufällig stosse ich auf ein Gutachten des Eidgenössischen Datenschutz >und Öffentlichkeitsbeauftagten der Schweiz. >https://www.edoeb.admin.ch/datenschutz/00628/00665/00681/index.html?lang=de > >Ich vermute, das hat tiefgreifende Auswirkungen auf unsere Arbeit... > >Der entscheidende Punkt: >*die Verknüpfung mit Personendaten begrenzen oder verunmöglichen* > >"begrenzen" meint: >"Frederik arbeitet mit" oder >"Frederik hat 2016 ##-tausend Punkte eingetragen" ist möglicherweise >ok, >"Frederik hat folgende Daten eingetragen" ist ohne seine explizite >Zustimmung nicht ok. > >> Jeder, der unser Planetfile runterlädt und verarbeitet, wird >> unwillkürlich zum Verarbeiter persönlicher Daten > >Ja, das Planetfile darf m.E. nur anonymisiert verbreitet werden. > >> * Wer sich drum kümmert, kann heute schon seine Daten in OSM >schützen, >> und die, denen das wichtig ist, die wissen meist auch, was sie machen >> müssen. > >Das ist nicht ausreichend. > >Erforderlich ist ein Opt-In-Verfahren, also eine ausdrückliche >qualifizierte Zustimmung zur nicht anonymisierten Datenerfassung, >bzw. der automatischen Ablehnung einer Nicht-Anonymisierung, wenn nicht >explizit zugestimmt wird. > >Ich vermute, eine solche Zustimmung würden nur wenige erteilen. >Es ist aus datenschutzrechtlicher Sicht sinnvoll, die Daten >grundsätzlich zu anonymisieren. > >Ein Zugriff auf die Verknüpfungstabelle wäre dann ausschliesslich der >DWG gestattet. Die Möglichkeit für Dritte muss technisch ausgeschlossen >sein. > >> * Egal, was wir tun oder nicht tun, wir sollten eventuell dafür >sorgen, >> dass neue Benutzer ganz genau wissen, was sie tun und was über sie >> später ermittelbar ist. > >Das ist sowohl für Daten in DE als auch in CH zwingend. > >> im deutschen Recht, der Datenschutz stärker als das Urherber- >> oder Datenbankschutzrecht oder irgendwelche Lizenztexte. > >Gilt auch für CH. > >Mit herzlichem Gruss, >Markus > >___ >Talk-de mailing list >Talk-de@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenedit bei living_street
Hier z.B.: wurde eine Tempo-30 Zone bei der sogar die Schilderart DE:274.1 (Tempo-30-Zone) katrografiert wurde zu maxspeed:walk https://www.openstreetmap.org/way/305956789/history Ist das Vandalismus Deutschlandweit? Mit freundlichen Grüßen Stephan aka smarties > Gesendet: Dienstag, 23. Mai 2017 um 11:05 Uhr > Von: smart...@gmx-topmail.de > An: talk-de@openstreetmap.org > Betreff: [Talk-de] Massenedit bei living_street > > Hallo, > > was sagt Ihr dazu das der User:Graf Westerholt in ganz Deutschland bei > mehreren zehntausenden living_street ein maxspeed:walk setzt, egal ob da > vorher ein maxspeed:30, 7 oder garnichts dranstand? Er ist da auch schon > reichlich mit anderen Usern zusammengestoßen und weigert sich sein tun > aufzugeben. Ca. 10% seiner Changesets wurden auch bereits komplett > zurückgesetzt, er macht aber munter weiter. > > Es gibt ein Proposal zu maxspeed:walk das allerdings 2008 (vor 9 Jahren) > nicht zu Ende geführt wurde (ja eigentlich noch nicht mal richtig angefangen > wurde). http://wiki.openstreetmap.org/wiki/Proposed_features/maxspeed_walk > > Ich habe Ihn angeschrieben, er meint jede Zahl wäre falsch und nur "walk" > wäre richtig und er höre nicht damit nicht auf. > > > https://www.openstreetmap.org/changeset/47980360 > https://www.openstreetmap.org/changeset/47980908 > https://www.openstreetmap.org/changeset/47980016 > https://www.openstreetmap.org/changeset/47978442 > https://www.openstreetmap.org/changeset/47977546 > > > > Mit freundlichen Grüßen > Stephan > aka smarties > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschwindigkeitsbegrenzungen protokollieren
Moin, Landstraße: Mit gelber Rundumleuchte und Warnblinker auf dem Auto am Schild stoppen und einen GPS Punkt setzen. Das ganze wird gleichzeitig mit dem Smartphone mit Scheibenhalterung gefilmt. So kann ich mit der Hand mein Garmin-GPS bedienen, was sogar erlaubt ist, und gleichzeitig auf dem Video sprechen das bei GPX-Punkt 81 ein Tempo 70 Schild ist. Daneben habe ich mein Tablet mit Scheibenhalterung um dabei auf der Osmand-Karte zu sehen wo ich gerade bin und wo ich schon war. Autobahn: Kontinuierlich 100 Kmh immer auf der rechten Spur damit ich gleichmäßig fahre. Dann das ganze mit dem Smartphone filmen und mit dem Garmin GPX-Punkte setzen. Wie oben, nur im vorbeifahren. Das klappt mit etwas Übung auf 10m genau. Tipp: Smartphones zeichnen max. 30 Minuten auf. Ich filme immer nur von einer zur nächsten Abfahrt, fahre runter und starte das Video neu. So kann man auch gleich alle Auf- und Abfahrten mappen. So kann man auch alle Fahrspuren, Schilder, Kilometersteine und Notruftelefone mappen. Mit freundlichen Grüßen Stephan aka smarties > Gesendet: Freitag, 19. Mai 2017 um 08:56 Uhr > Von: "Martin Trautmann" > An: "Openstreetmap allgemeines in Deutsch" > Betreff: [Talk-de] Geschwindigkeitsbegrenzungen protokollieren > > Hallo, > > wie schafft ihr es, die exakte Position von Geschwindigkeitsbegrenzungen > aufzuzeichnen und Änderungen einzupflegen? > > Ich muss gestehen, wenn ich selbst unterwegs bin, dann kann ich auf der > Autobahn nicht auch noch ein Gerät bedienen, um zu sagen: ab hier > Geschwindigkeitsbegrenzung von 80 km/h. > > Smartphone-Aufnahme mit GPS-Funktion klappt vermutlich nur, wenn ihr > wisst, dass gleich das Schild kommt und der Beifahrer aufnahmebereit > dasitzt. > > Und selbst bei Geschwindigkeiten unter 80 km/h komme ich mit einer > Aufzeichnung nicht mit - das klappt vermutlich nur mit ständig > mitlaufender Kamera vorne, die auch noch GPS mit aufzeichnen müsste? > > Wie macht ihr das? > > Schönen Gruß > Martin > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Technische Frage ÖPNV-Karte / Mapnik-Karte
Kannst du bitte einen Link zu so einer Stelle posten? Vielleicht auch den Node und die Tags um die es konkret geht? Updates können durchaus mal etwas länger brauchen aber mehrere Wochen klingt ungewöhnlich. On March 3, 2017 8:41:52 AM GMT+01:00, goegeo wrote: >Hallo Mitstreiter, > >ich bearbeite bereits seit einiger Zeit Busrouten und zugehörige >Infrastrukturen. Ich folge dabei dem PTv2-Schema. > >Mir war jetzt aufgefallen, dass viele Änderungen sowohl vom >Mapnik-Renderer, wie auch in der ÖPNV-Karte auch nach Wochen nicht in >der abgeänderten Form verarbeitet werden. Es sind immer noch die >früheren Bezeichnungen von Haltestellen (Name etc.) vorhanden. In >Teilen >sind auch gar keine Daten, obwohl von mir erfasst. Parallel sind >dieselben Daten aber in JOSM abrufbar. Bin ein wenig ratlos. > >Kann jemand weiterhelfen, woran es liegen könnte. Danke! > >___ >Talk-de mailing list >Talk-de@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Domain osm.solutions abzugeben
Hallo, könnte vielleicht für die OSM Freiberufler hier interessant sein. Ich habe die Domain "osm.solutions". Da ich mit OSM kein Geld verdiene ist mir die für den Einsatzzweck den ich dafür noch hätte zu teuer geworden. Ich finanziere ja schon jetzt recht viel aus eigener Tasche. Wer Interesse daran hat die Domain direkt zu übernehmen sollte sich die nächsten Tage mal bei mir melden. Eine finanzielle Anerkennung die den Betrieb meines Servers unterstützt sollte dann aber drin sein. Alternativ: einfach etwas warten und die Domain regulär registrieren in der Hoffnung dass niemand schneller ist. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:name multilanguage nach browsereinstellung anzeigen
On 06.02.2016 15:08, tshrub wrote: Wieso wird auf mapnik nicht "automatisch übersetzt", sprich: wenn die tags existieren name:de name:el name:en name:ar name:fr zeigt mein de:en:SeaMonkey z.B. in Arabien für mich nichts lesbares an. Weil das "default" Mapnik rendering für die Mapper da ist. Und die sind lokal und "on the ground". Sprich: die haben überhaupt kein Problem mit Arabisch weil Muttersprache. Wenn du eine Karte haben willst die Namen auch auf Englisch/romanisiert anzeigt dann musst du die einen passenden Kartenanbieter suchen. Nur wenn ich auf eine andere Karte wie "Verkehrskarte" umschalte, werden die key schön browserspez. extrahiert. Macht er bei mir nicht. Wird immer Englisch angezeigt. Denke daher, das ist einfach so ein Anbieter wie oben erwähnt. Da Andy aus UK stammt wäre das naheliegend. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscehr tileserver (was: HTTPS für openstreetmap.DE)
On February 1, 2016 10:55:51 AM GMT+01:00, Sven Geggus wrote: > >Ich habe den Rant bei Fefe über letsencrypt gelesen und war dann erst >mal >etwas desilusioniert. Wenn mir jemand ein howto für ein sauberes >automatisiertes setup von letsencrypt mit SANs zeigt ist das im Prinzip >kein >Problem das für den deutsche Tileserver aufzusetzen. Ich habe noch mehr als 60 Tage bis zum renewal, denke aber dass ich zwei vielversprechende Lösungen zum renewal gefunden habe. Bis zum Hack Weekend in Karlsruhe könnte ich das am laufen haben. Wenn du mit dabei bist und Lust hast können wir das dann zusammen anschauen... Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Private Schwimmmbecken
Ist dir wahrscheinlich schon klar, aber zur Klarstellung trotzdem. Du scheinst OSM als Karte zu sehen. Es ist aber sehr viel mehr. OSM ist eine Datenbank mit Geo Features. Das was einige aus den Daten machen ist dann eine Karte. In diesem Fall dann wohl Wheelmap. Wenn da was unsinniges drauf ist solltest du dich direkt an den Macher der Karte wenden... Stephan On November 29, 2015 6:28:18 PM GMT+07:00, Michael Reichert wrote: >Hallo Chris, > >Am 2015-11-29 um 12:20 schrieb chris66: >> Ja, was jemand auf seinem Privatgrundstück stehen hat, gehört IMHO >nicht >> auf eine öffentliche Karte. > >Ok, dann lass uns doch fast alle Gebäude in OSM löschen. ;-) > >Viele Grüße > >Michael > >-- >Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten >ausgenommen) >I prefer GPG encryption of emails. (does not apply on mailing lists) > > > > > >___ >Talk-de mailing list >Talk-de@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM bei Polizei?
Habe gerade kein so tolles Netz, aber ist der Fossgis als gemeinnützig anerkannt? Dann könnte er sich, bzw. OSM in die Bußgeldliste eintragen lassen. Dann können wir wirklich Spenden bekommen... Stephan On November 17, 2015 5:01:01 PM GMT+07:00, Andreas Schmidt wrote: >Internet ist ja auch Neuland. >Es ist übrigens die Bußgeldstelle. Ob man die um eine Spende für OSM >bitten könnte? So als pauschale Lizenzabgeltungsgebühr? :-) > >Am 17.11.2015 um 10:35 schrieb Hartmut Holzgraefe: >> On 17.11.2015 10:26, Andreas Schmidt wrote: >>> >https://www.polizei.rlp.de/internet/nav/092/09250455-9958-bb31-7a52-f616a313445c.htm >>> >>> >>> >>> Nutzt die Polizei dort eine OSM-Karte und ist dort keine >Urheber-Notiz >>> vorhanden? >> >> ja, sieht so aus. >> >> Sieht aber auch so aus als ob wer auch immer die Seite gestaltet hat >> auch von Web allgemein eher so wenig bis garkeine Ahnung hat? >> >> >> ___ >> Talk-de mailing list >> Talk-de@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-de > > > > > > >___ >Talk-de mailing list >Talk-de@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Notes API-Anfrage geht nicht vollständig
On 24.10.2015 23:02, Dietmar wrote: wget -O nodes.osn http://api.openstreetmap.org/api/0.6/notes?bbox=8.976,47.2701,13.8397,50.565&limit=2550&closed=-1 bringt nur 100 Notes (das ist default), also der limit-Parameter scheint nicht zu gehen. hatte das gerade ausprobiert: wget -O - "http://api.openstreetmap.org/api/0.6/notes?bbox=8.976,47.2701,13.8397,50.565&limit=2550&closed=-1"; | grep "--2015-10-25 00:14:44-- http://api.openstreetmap.org/api/0.6/notes?bbox=8.976,47.2701,13.8397,50.565&limit=2550&closed=-1 Resolving api.openstreetmap.org (api.openstreetmap.org)... 2001:630:12:500:21a:4bff:fea5:fd2a, 2001:630:12:500:219:bbff:fe39:3d9e, 2001:630:12:500:219:bbff:fe39:8aba, ... Connecting to api.openstreetmap.org (api.openstreetmap.org)|2001:630:12:500:21a:4bff:fea5:fd2a|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/xml] Saving to: `STDOUT' [ <=> ] 3,318,350 11.6M/s in 0.3s 2015-10-25 00:15:14 (11.6 MB/s) - written to stdout [3318350] 2550 Scheint wie erwartet zu funktionieren. vielleicht nur ein kurzer Schluckauf der API? Format kann ich aber auch nicht ändern. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Notes API-Anfrage geht nicht vollständig
On 24.10.2015 23:02, Dietmar wrote: Gemäß der Dokuangabe könnte man auch das Ausgabeformat, u.a. gpx auswählen, aber der Parameter ist nicht dokumentiert. Ein Versuch mit format=gpx war nicht erfolgreich. Kann mir jemand helfen? Ruby und Rails ist für mich immer irgendwie magie. Ich habe keine Idee wie die Parameter reinkommen. Ist einfach aller irgendwie magisch da. Vielleicht wirst du ja daraus schlau: https://github.com/openstreetmap/openstreetmap-website/blob/master/app/controllers/notes_controller.rb Es gibt zumindest eine Auswertung für Format: # Render the result respond_to do |format| format.rss format.xml format.json format.gpx end Und der Limit Parameter scheint auf geprüft und ausgewertet zu werden. Ob man dem ruby irgendwo sagen muss, dass er in der Funktion den Limit Parameter auch holt oder ob das mal wieder magisch passiert kann ich nicht sagen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit Bahnhofsmapping von MentzDV
Hallo Peda und andere, On 29.08.2015 21:36, Peter Barth wrote: vor ein paar Tagen wurde von Mentzdv in 3 Changesets unser Bahnhof "verschönert". da auf deiner eMail nicht mit drauf habe ich das ganze mal an Mentz weitergeleitet. Da noch Wochenende ist wird frühestens Montag Nachmittag eine Antwort kommen. Viele von den "Routinearbeiten" kann sicher auch ein mittelmäßig erfahrener Mapper remote erledigen. Ich denke wir brauchen aber einen Weg wie das lokale Wissen stärker berücksichtigt wird. Ob ein bezahlter Mapper eine veraltete Info einträgt oder ein Mapper vor Ort die Info nicht nachtpflegt macht im Ergebnis keinen Unterschied. Aber schlechter sollten die Daten hinterher nicht werden. Also richtige Infos dürfen nicht kaputtkorrigiert werden. Ich habe folgendes auch an Mentz geschickt, hoffe dass die Antwort öffentlich kommt. "Passiert euch ja immer wieder, dass eure Infos gegenüber den OSM Daten veraltet sind. Habt ihr mal überlegt wie sich das verbessern lässt? Ihr dürftet wohl umfangreichere Quellen haben, die OSM Daten stammen aber in der Regel aus Begehungen vor Ort und sind damit wohl auch aktueller. Habt ihr versucht die lokalen Mapper stärker einzubinden? Wie wäre es wenn ihr im Vorfeld einer Mapping-Aktion von Bahnhöfen die Mapper aus der OSM Datenbank anschreibt die in den letzten sagen wir mal 18 Monaten dort Objekte angefasst haben? Die Abfrage sollte sich aus Overpass bedienen lassen. Mal Roland fragen. Da könnt ihr dann schreiben was ihr vorhabt, welche Accounts voraussichtlich editieren werden und anbieten, dass die lokalen Mapper helfen. Das könnte eine Ortsbegehung sein, Beantwortung von Detailfragen oder ein Review der Änderungen." Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 20.08.2015 14:20, schrieb Christoph Hormann: natürlich (also waterway=river/stream und ggf. waterway=riverbank bzw. water=river für das Polygon): es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt. Der Nord-Ostsee-Kanal ersetzt die Eider zwischen Flemhuder See und Rendsburg. Er nimmt das Wasser der Obereider und aller ehemaligen Zuflüsse auf. Ist dieser Abschnitt ein natürliches Gewässer? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 21.08.2015 00:28, schrieb Christoph Hormann: On Thursday 20 August 2015, Stephan Wolff wrote: >> Welche kleinen Wasserläufe dieses Gebiets sind natürlich? http://www.openstreetmap.org/#map=13/54.3349/9.4072 Dort ist das eigentlich relativ einfach, denn die meisten natürlichen Wasserläufe sind hier kaum begradigt, so dass man sie gut an der Form erkennen kann. Die mäandernden Flüsse sind 20-60m breit. Das war nicht die Frage. Aber welche Gräben hatten einen natürlichen Vorgänger und müssten als "stream" erfasst werden? Der historische Ansatz passt nicht zu OSM. In OSM wird generell der aktuelle Zustand erfasst. Das Problem ist hier nicht die Erfassung historischer Zustände, sondern die Bewertung der Gegenwart aufgrund von Erkenntnissen über die Vergangenheit. Wollen wir von den Mappern verlangen, dass sie die Vergangenheit jedes Objekts ermitteln und danach das Haupttag festlegen? Soll ein Mapper ein Kleingewässer, dessen Vergangenheit er nicht ermitteln kann, als "stream" oder "ditch" taggen? Welche Anwendungen braucht die Unterscheidung nach der Entstehung des Gewässers? Alle Anwendungen, bei denen in irgendeiner Form eine Analyse der Struktur des Gewässernetzwerkes stattfindet. OSM wird häufiger für Kartendarstellungen als zu Strukturanalysen des Gewässernetzwerkes verwendet. Das Tagging sollte sich m.E. eher an den Bedürfnissen der Hauptnutzung orientieren. Der zentrale Punkt ist, dass natürliche Fließgewässer generell den steilsten Weg bergab fließen. Für Bergbäche mag es gelten. Für mäandernden Flüsse nicht. Begradigte Bäche und Entwässerungsgräben sind meist so angelegt, dass das Wasser auf direktem Weg ablaufen kann. In der ober genannten Region werden mehrerer Flüsse über Pumpwerke entwässert. Die Alte Sorge fließt dadurch auf den letzten 9km rückwärts. In den Gräben fließt das Wasser dagegen nur durch die Schwerkraft. Für künstliche Wasserläufe gilt beides nicht (Kontinuität im engeren Sinne natürlich schon, jedoch nicht nach außen wenn man Tunnel und Druckstollen mit einbezieht). Tunnel und Druckstollen wird man eher am "tunnel"-Tag als am "waterway"-Tag erkennen. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 20.08.2015 14:20, schrieb Christoph Hormann: On Thursday 20 August 2015, Stephan Wolff wrote: kann jemand eine sinnvoll anwendbare Definition von künstlichen / menschengemachten Wasserflächen geben? Für stehende Wasserflächen: natürlich (also water=lake/pond): die Wasserfläche existierte schon vor dem Beginn menschlicher Eingriffe/würde ohne menschliche Eingriffe existieren. Für Wasserläufe: natürlich (also waterway=river/stream und ggf. waterway=riverbank bzw. water=river für das Polygon): es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt. Bei großen Flüssen und Seen ist offensichtlich oder zumindest leicht zu ermitteln, ob sie vom Menschen geschaffen wurden. Aber gerade bei den kleinen Gewässern, um die es hier geht, ist die Unterscheidung nach diesen Kriterien sehr schwer. Wer hat schon Karten aus der Zeit der ersten Kultivierung? Welche kleinen Wasserläufe dieses Gebiets sind natürlich? http://www.openstreetmap.org/#map=13/54.3349/9.4072 Die Bezugnahme auf die Vergangenheit vor den menschlichen Eingriffen ist natürlich im Sinne der Überprüfbarkeit etwas heikel. Das macht die Unterscheidung aber noch nicht generell sinnlos. Der historische Ansatz passt nicht zu OSM. In OSM wird generell der aktuelle Zustand erfasst. Soll man zwei aktuell gleiche Wasserläufe mit unterschiedlichen Tags erfassen, wenn einer einen natürlichen Vorgänger hatte? Wer die ganze Unterscheidung komplett abschaffen möchte sollte bedenken, dass dies den Nutzen der Daten insbesondere in wasserbaulich stark erschlossenen Gebieten enorm einschränken würde. Welche Anwendungen braucht die Unterscheidung nach der Entstehung des Gewässers? Für welche Anwendungen würde es eine "enorme" Einschränkung bedeuten? Um auf Übersichtskarten nur Große Flüsse darzustellen fehlt dagegen eine Unterteilung in "kleiner Fluss", "großer Fluss" und "Strom" wie im ersten Diagramm im Wikipediaartikel Fließgewässer. https://de.wikipedia.org/wiki/Flie%C3%9Fgew%C3%A4sser Aktuell werden kleine Wasserläufe ohne erkennbares System als "ditch", "drain" oder "stream" bezeichnet. Schlimmer kann es nicht werden. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Moin, kann jemand eine sinnvoll anwendbare Definition von künstlichen / menschengemachten Wasserflächen geben? Fast alle Flüsse in Europa sind vom Menschen deutlich verändert. Bis zu welcher Abweichung vom Verlauf vor menschlichen Eingriffen ist der begradigte Flussabschnitt natürlich? Auch Schifffahrtskanäle verlaufen zu großen Teilen auf alten Flussstrecken und übernehmen die Entwässerungsfunktion des Flusses. Sind diese Teile des Kanals natürlich? Ist ein Stausee, an dessen Stelle sich vor der Stauung ein deutlich kleinerer See befand, natürlich? Oder ist die Fläche des ehemaligen Sees natürlich und der Außenbereich künstlich? Ist ein See, der im 19.Jh zur Trinkwasserversorgung angelegt wurde, natürlich? Sind ehemalige Kiesgruben, die sich durch Grundwasser und Regen in Seen wandeln, oder Löschteiche neben Bauernhöfen natürlich? Sind Gartenteiche mit Folienboden natürlich? Wie soll ein Mapper, der einen Stausee, einen Teich oder einen Graben sieht, entscheiden, ob es sich um ein verändertes, natürliches oder ein künstliches Gewässer handelt? Ich würde die Unterscheidung in künstliche und natürliche Gewässer aufgeben und sie nur nach Größe und Funktion unterscheiden. Gruß Stephan Am 19.08.2015 07:39, schrieb Michael Paulmann: Es gibt Stauseen mit water=lake und natural=water, Stauseen mit nur natural=water und Stauseen mit natural=water > und water=reservoir. ... anscheinend taggt ja jeder auch menschengemachte Wasserflächen > wie er/sie das will. 2015-08-04 16:00 GMT+02:00 Norbert Kück : Gewässer, die von Menschen NICHT GESCHAFFEN sondern VERÄNDERT wurden, sind KEINE KÜNSTLICHEN Gewässer. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 05.08.2015 16:30, schrieb Florian Lohoff:
Auch da habe ich eigentlich erstmal keinen Stress mit - Wichtig hier
ist die Kommunikation - Also wenn solche Dinger in irgendeiner form
da sind - aber nicht vor Ort ersichtlich dann erwarte ich mind. einen
Note auf dem Way der erklärt warum das so sein muss. Wenn sowas nicht
da ist und vor Ort nicht ersichtlich ist warum eine restriction
existiert dann entferne ich sowas auch ohne gross nachzufragen.
Daten, die man nicht vor Ort verifizieren kann, einfach zu löschen,
finde ich falsch. Eine Quellenangabe für jedes Tag ist in OSM nicht
obligatorisch. Eine Recherche im Internet ("spiekeroog auto") oder eine
Nachfrage beim Mapper, der das Verbot eingetragen hat, oder eine eigene
Eintragung am Objekt ("fixme=Kein Verbotsschild - Autos doch erlaubt?")
mit angemessener Frist wären m.E. mindestens erforderlich, bevor man
Informationen löscht.
Offensichtlich falsche Daten darf man natürlich ohne Nachfrage löschen.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 04.08.2015 09:57, schrieb Martin Koppenhoefer: Am 03.08.2015 um 23:09 schrieb Stephan Wolff : https://www.openstreetmap.org/way/35067961 zweispurig, beidseits Geh- und Radweg, Linienbusverkehr, Unigelände Wo steht, dass highway=residential immer öffentliche Straßen sind? in Berlin an der TU ist eine vergleichbare Straße, als Service getaggt: "residential" ist eine Straßenklasse, die Wohnbebauung voraussetzt, das ist an der Kieler Uni vermutlich auch nicht gegeben. Die Straße an der TUI Berlin kenne ich nicht. "surface=cobblestone" spricht eher für eine wenig benutzte Zufahrt. In Kiel sind offenbar alle beteiligten Mapper mit "residential" einverstanden. Ob "residential" auch für Straßen im Gewerbegebiet passt, wurde ja gerade im anderen Thread diskutiert. Solange mein erstes Beispiel unstrittig ist, gilt die Aussage, dass es "highway=unclassified" gibt, die keine öffentlichen Straßen sind. q.e.d. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 03.08.2015 um 09:42 schrieb Martin Koppenhoefer: Am 03.08.2015 um 01:53 schrieb Stephan Wolff : Das ist eine Grundsatzfrage für unser Tagging. Für fast alle Regeln gibt es Ausnahmen für spezielle Gruppen (Polizei, Rettungsdienste, Grünflächenamt, Stadtwerke, Jagdpächter, etc.) oder Sondererlaubnisse für Einzelpersonen oder Fahrzeuge. ja, daher ist "no" auch fast immer zu restriktiv Setzt du für alle Fußwege, auf denen gelegentlich Fahrzeuge des Grünflächenamts fahren, "motor_vehicle=private"? Normalerweise erfassen wir nur die allgemeinen Regeln in OSM. davon lese ich gerade zum ersten Mal, bisher bin ich davon ausgegangen dass Ausnahmen auch erfasst werden, zumindest ansatzweise. Ausgeschilderte Regeln gelten allgemein, die erfassen wir natürlich. Aber Sondererlaubnisse für Einzelpersonen oder Fahrzeuge kenne ich in OSM nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 03.08.2015 um 09:45 schrieb Martin Koppenhoefer: Am 03.08.2015 um 01:53 schrieb Stephan Wolff : highway=residential/unclassified etc sagt ja öffentliche Straße d.h. StVO. In Deutschland trifft es meist, aber nicht immer zu. könnte das hier nochmal erläutert werden, bitte? Verstehe ich das richtig, dass es highway=res/unclassified gibt die keine öffentlichen Straßen sind? Z.B. https://www.openstreetmap.org/way/155221649 zweispurig, Mittellinie, Geh- und Radweg, mit Verbindungscharakter https://www.openstreetmap.org/way/35067961 zweispurig, beidseits Geh- und Radweg, Linienbusverkehr, Unigelände Wo steht, dass highway=residential immer öffentliche Straßen sind? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 30.07.2015 um 22:22 schrieb Florian Lohoff: Wenn die Gemeinde alle Beschlüsse auf ihrer Webseite veröffentlicht, könnte man das "website"-Tag am Gemeindeobjekt als einen solchen Hinweis interpretieren :-) Ansonsten existieren keine Polygone in der realen Welt und Metainformationen gehören nicht in eine Geodatenbank. Puh - also wer von den casual-mappern guckt denn als erstes in ein Gemeindeobjekt ob denn wohl da spannendes drin steht? Man kann nicht alle wichtigen Beschlüsse der Gemeinde in das Objekt bei OSM aufnehmen. Der Mapper muss schon auf der Webseite der Gemeinde eine Recherche machen. Wie am Smiley ersichtlich, war der Vorschlag nicht ganz ernst gemeint. Und es geht ja um unterschiedlichste Gebiete. Das diese Informationen nicht in eine Geodatenbank gehören sehe ich noch ein bischen anders da es eben Geoinformationen sind. Das für OSM nur Metainformationen sind mag ja sein - Aber wenn ich mir den schrott mit den umrissen der Hochauflösenden Bing Bilder von anno Tobak oder so ansehe dann ist das eine absurde Diskussion. Ich hätte da durchaus mehrere Anwendungsfälle - Für NRW den Hinweis auf die DOPs/ALKIS Daten vom LVermA (Es gibt immer noch jede menge ID Nutzer die von uralten und lagekaputten Bing Bildern abzeichnen) oder eben solche dinger wie die Autofreien Inseln. Am Ende könnte man sogar noch z.b. den JOSM Validator mit informationen versorgen z.b. "Gebiet mit Linksverkehr" oder die default sprache so das ein name:de in Deutschland im Validator aufpoppt. Die Umrisse der hochauflösender Bildquellen habe immerhin ein definiertes Polygon, gehören aber nicht in eine Geodatenbank. Ein willkürlich gezeichnetes Polygon für jeden Defaultwert (railway:gauge; urban:maxspeed; default_language) würde unsere Datenbank mit tausenden riesiger Gebiete zumüllen. Für den Mapper wären diese Polygone auch nicht auffindbar. Jetzt aufgrund des einen Schildes alle wege auf der Straße mit einem motor_vehicle=no zu versorgen halte ich für total übertrieben. Das Verbot gilt wegen der Widmung für jede einzelne Straße auf ganzer Länge. Das Schild ist nur ein punktförmiger Hinweis darauf. =no ist falsch - Es sind dort motor_vehicles unterwegs und die dürfen das. Das ist eine Grundsatzfrage für unser Tagging. Für fast alle Regeln gibt es Ausnahmen für spezielle Gruppen (Polizei, Rettungsdienste, Grünflächenamt, Stadtwerke, Jagdpächter, etc.) oder Sondererlaubnisse für Einzelpersonen oder Fahrzeuge. Normalerweise erfassen wir nur die allgemeinen Regeln in OSM. Dann ist "=no" korrekt. Anderenfalls müssten wir nahezu alle Fußwege mit "motor_vehicle=private" ergänzen. Selbst ein Zeichen 250 ist kein access=no. 99% der Mapper haben eine andere Meinung als du. ;-) Ein Zeichen 250 ist ein "Fahrzeuge aller Art". Mit dem Pferd oder zu Fuß darf ich da sehr wohl rein. Du hast recht. Ich hatte mich verlesen. highway=residential/unclassified etc sagt ja öffentliche Straße d.h. StVO. In Deutschland trifft es meist, aber nicht immer zu. Gib mir doch mal ein Beispiel für eine StVO konforme Beschilderung für ein access=no. Ich kenne da gerade keine. § 45 STVO "Die Straßenverkehrsbehörden können die Benutzung bestimmter Straßen oder Straßenstrecken aus Gründen der Sicherheit oder Ordnung des Verkehrs beschränken oder verbieten und den Verkehr umleiten" + ein Dutzend weitere Gründe Ein Schild zeigt das Verbot nur an. Ein über die Straße gespanntes Flatterband reicht vermutlich schon als Kennzeichnung. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 30.07.2015 09:54, schrieb Florian Lohoff: Mir schwebte eigentlich eher vor das man quasi über Polygone seperat in einer Datenbank mappingregeln oder generell regionale infos ablegen kann. Diese URL/ID wird dann beim Download von Daten aus der API gleich mitgeliefert so das JOSM z.b. ein Popup zeigen kann nach dem Motto: Im Heruntergeladenen Bereich existieren Regionale Informationen - Vor dem Hochladen bitte lesen: Wenn die Gemeinde alle Beschlüsse auf ihrer Webseite veröffentlicht, könnte man das "website"-Tag am Gemeindeobjekt als einen solchen Hinweis interpretieren :-) Ansonsten existieren keine Polygone in der realen Welt und Metainformationen gehören nicht in eine Geodatenbank. In anderen Orten sind vielleicht nur zwei Straßen für den Kfz-Verkehr verboten. Zu jeder einzelnen Gemeindestraße existiert aber eine Widmung und deshalb gehört diese Information zum highway-Objekt. Inseln haben typischerweise GAR KEINE Zufahrt. Das ist ja genau das spannende. Es ist ein isolierter Graph. Beschilderungen dieser art sind aber rechtlich eigentlich punktförmige Verbote mit einer Richtung auf der Straße. D.h. ich darf den Punkt auf der Straße nicht in der jeweiligen Richtung überschreiten. In OSM tragen wir die als Streckenverbote ein (Was falsch ist). Jetzt aufgrund des einen Schildes alle wege auf der Straße mit einem motor_vehicle=no zu versorgen halte ich für total übertrieben. Das Verbot gilt wegen der Widmung für jede einzelne Straße auf ganzer Länge. Das Schild ist nur ein punktförmiger Hinweis darauf. Es besteht ein allgemeines Verbot mit wenigen Ausnahmegenehmigungen. Es besteht aber eben kein generelles Verbot aller Kraftfahrtzeuge. Ich sehe immer wieder mapper die irgendwelche Straßen mit access=no taggen. Das ist in 99% aller fälle falsch. Selbst ein Zeichen 250 ist kein access=no. 99% der Mapper haben eine andere Meinung als du. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 29.07.2015 11:07, schrieb Florian Lohoff: On Mon, Jul 27, 2015 at 11:35:18PM +0200, Stephan Wolff wrote: es ist für die Diskussion hilfreich, die "Deutsche Autofreie Insel" als Spiekerogg zu benennen und einen betroffenen Weg zu verlinken: Auch ein Link auf die Bilder bei Mapillary würde helfen. Also wer Spiekeroog nicht bei Mapillary findet dem kann ich nicht Helfen. Die Mapillary Bilder sind im ueberigen alle von mir um eben auch den zustand der Beschilderung zu Dokumentieren. Natürlich kann man herausfinden, welche Insel du bearbeitet hast und wo die Bilder zu finden sind. Ein direkter Link macht es aber deutlich einfacher. In fast allen Fußgängerzonen fahren gelegentlich Fahrzeuge zur Anlieferung, Entsorgung, Aufbau von Marktständen mit Sondergenehmigung. Man kann streiten, ob "motor_vehicle=no" oder "motor_vehicle=private" dafür korrekt ist. >> Das bei "highway=residential" implizierte "motor_vehicle=yes" ist auf Spiekerogg definitiv falsch. Woraus ergibt sich das? Wenn das definitiv falsch ist müsste es eine Beschilderung geben. Nein, die weitaus meisten Verbote existieren nur als Gesetz, Verordnung oder Satzung. Wir mappen auch diese Verbote. motor_vehicle=no ist einfach falsch und kaputt. Es gibt genau ein einziges Schild das Kraftfahrzeuge regelt auf Spiekeroog. Wenn es die einzige Zufahrt ist, ist die Beschilderung vollständig. Die SpiekeroogKOM fährt überall mit dem ElektroLKW rum und das ist nach StVO ein Kraftfahrtzeug. Also ist ein motor_vehicle=no einfach falsch. Wenn das alles nach einer Rechtsverordnung passiert müsste da ein motor_vehicle=permissive oder ähnliches drauf. Es besteht ein allgemeines Verbot mit wenigen Ausnahmegenehmigungen. Aus einem Urteilstext des OVG Lüneburg 7. Senat, Urteil vom 21.03.2013: "Aufgrund einer Widmung der [Gemeinde] von 1969 ist auf den Spiekerooger Gemeindestraßen der Verkehr mit Kraftfahrzeugen verboten. Die Straßenverkehrsbehörde des Landkreises Wittmund hat dementsprechend ein Kraftfahrzeugverkehrsverbot angeordnet[] Der Landkreis Wittmund erteilte dem Kläger unter dem 20. Dezember 2007 Ausnahmegenehmigungen für seine Fahrzeuge von dem auf der Insel Spiekeroog angeordneten Kraftfahrzeugverkehrsverbot." Eine generelle Erlaubnis besteht also nicht. Aber es ging nicht primär um das mappen von Spiekeroog sondern das vorhalten von regionalen Besonderheiten. Wo findet der gelegenheitsmapper für eine Region mappingregeln für eben diese Besonderheiten. Es bestehen besondere lokale Regeln der Straßennutzung. Man findet sie in fast jedem Artikel über Spiekeroog. Die Mappingregeln gelten allgemein. Auf "motor_vehicle=no" ändern und einen Link zur Rechtsverordnung im Kommentar des Changesets unterbringen :-) Wo ist die Rechtsverordung? Vermutlich ist die Widmung der Straßen im Archiv der Gemeinde einsehbar. Im Internet habe ich sie nicht gefunden. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 27.07.2015 um 15:10 schrieb Florian Lohoff: Hi, ich bin auf einer Deutschen Autofreien Insel und hier hat jemand in den letzten 12 Monaten quasi alle Straßen mit einem motor_vehicle=no getagged. Mal davon abgesehen das es eine solche Beschilderung nicht existiert fahren hier ja durchaus die Kommunalen Fahrzeuge und des regionalen Logistikunternehmens mit dem Elektro-LKW - Was ja nach StVO auch Kraftfahrtzeuge sind. Ich halte das tagging für ziemlichen unsinn. Da wird gemapped wie man meint und nicht wie defakto beschildert ist. Da wird auch schnell mal irgendwas zu einem highway=pedestrian was eine völlig normale - wenn auch enge Straße ist (Mit normalem Logistikverkehr). Ich habe jetzt mal einiges korrigiert und habe entsprechend auch Fotos bei Mapillary der Beschilderung vor Ort. Ich habe auf den einschlägigen ggfs. strittigen Wegen mal Notes hinterlassen. Moin, es ist für die Diskussion hilfreich, die "Deutsche Autofreie Insel" als Spiekerogg zu benennen und einen betroffenen Weg zu verlinken: https://www.openstreetmap.org/way/4470494/history#map=15/53.7681/7.6988 Auch ein Link auf die Bilder bei Mapillary würde helfen. In fast allen Fußgängerzonen fahren gelegentlich Fahrzeuge zur Anlieferung, Entsorgung, Aufbau von Marktständen mit Sondergenehmigung. Man kann streiten, ob "motor_vehicle=no" oder "motor_vehicle=private" dafür korrekt ist. Das bei "highway=residential" implizierte "motor_vehicle=yes" ist auf Spiekerogg definitiv falsch. Die Reihenfolge "erst diskutieren - dann editieren" wäre sinnvoll. > Ideen? Auf "motor_vehicle=no" ändern und einen Link zur Rechtsverordnung im Kommentar des Changesets unterbringen :-) Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank
Am 29.05.2015 um 21:04 schrieb Christoph Hormann: Es geht hier nicht um die Erfassung von Strömungen in einem Gewässer und auch nicht darum, dass irgendjemand behauptet, dass waterway=riverbank ein Tag ohne jede Probleme wäre, sondern darum, dass natural=water + water=river eher einen Rückschritt gegenüber dem riverbank-Tagging darstellt. Die genannten Probleme können aber nur dann auftreten, wenn man "natural=water" ohne "water=*" verwendet. Da die Angabe von "water=*" deutlich differenzierter als das alte Schema ist, werde ich diese Möglichkeiten (zumindest teilweise) nutzen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank
Am 29.05.2015 10:32, schrieb Christoph Hormann: On Friday 29 May 2015, Stephan Wolff wrote: Das würde ein weltweites Tagging-Schema zerstören... Da die Übergänge zwischen den Wasserflächen von Flüssen, Kanälen und Seen (im doppelten Wortsinn) fließend sind, finde ich das neue Schema logisch und praktikabel. Das ist genau der Knackpunkt - es mag wie in vielen anderen Bereichen auch Grenzfälle geben. In der überwiegenden Zahl der Fälle ist die Unterscheidung jedoch vor Ort eindeutig möglich und für die meisten Datennutzungen die über einfache Karten nach dem Schema 'alles Blau malen' hinaus gehen ist diese Unterscheidung sehr wichtig und sollte deshalb idealerweise bereits im primären Tag erfolgen. Welche Anwendungen sind denn konkret betroffen? Dies ist bei waterway=riverbank für stehend/fließend der Fall, nicht jedoch für natürlich/künstlich (waterway=riverbank wird traditionell auch für Kanäle verwendet). Eine gerichtete Strömung über ein Flächenobjekt zu beschreiben, ist ohnehin schwierig. Wenn man "waterway=riverbank" auch für Kanäle verwendet, ist es eher die Unterscheidung rundlich/länglich. natural=water + water=* erlaubt generell auch das undifferenzierte Tagging von Wasserflächen, was auch in über 90 Prozent der Fälle so gemacht wird - siehe http://taginfo.openstreetmap.org/tags/natural=water#combinations und der Umstieg von waterway=riverbank auf natural=water + water=river wird dies verstärken, denn das water=river wird dann oft - weil scheinbar unnötig - weggelassen. Insgesamt eine schlechte Entwicklung. Vielleicht setzt sich "water=*" auch langsam durch und man kann zwischen Flüssen, Altarmen, Kanälen, Seen und Teichen unterscheiden. Das wäre eine sehr gute Entwicklung. Dass waterway=riverbank unschön ist, weil es eigentlich ein Linien-Tag aus der vor-Multipolygon-Zeit ist und weil es - siehe oben - keine Unterscheidung Fluss-Kanal ermöglicht steht außer Frage. Im Proposal zur Änderung wird das Thema Unterscheidung fließende/stehende Gewässer jedoch leider nicht thematisiert. Gab es diese Unterscheidung bislang? Dann hätte man waterway=riverbank für Kanäle verbieten müssen. Ich würde deshalb grundsätzlich empfehlen, im Allgemeinen bei der Verwendung von waterway=riverbank für Flüsse zu bleiben und bei der Verwendung von natural=water *immer* ein water=* zu taggen. Dem zweiten Teil kann ich zustimmen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank
Am 29.05.2015 10:02, schrieb Martin Koppenhoefer: Da die Übergänge zwischen den Wasserflächen von Flüssen, Kanälen und Seen (im doppelten Wortsinn) fließend sind, finde ich das neue Schema logisch und praktikabel. verstehe ich nicht. Es ist doch egal ob man water=river oder waterway=riverbank taggt, wo der Fluss aufhört und der See anfängt muss man so oder so entscheiden. Es ist nicht einmal definiert, wann man eine Verbreiterung eines Flusses als See bezeichnet. Wenn es weder eine klare inhaltliche noch räumliche Grenze gibt, finde ich die Verwendung des gleichen Haupttags mit Differenzierung im Subtag logisch. Das neue Schema ist mehr als ein Jahr alt, viele Flüsse sind schon so erfasst. Wenn du die Änderung erst jetzt entdeckst, ist die "Zerstörung" offenbar nicht bedeutend. Welche Anwendung ist überhaupt betroffen? waterway=riverbank komplett rausnehmen aus dem Fluss-Artikel finde ich auch nicht gerade hilfreich, grenzt in der Form für mich an Vandalismus, immerhin gibt es nach wie vor 283K Objekte, die diesen Tag haben, water=river sind gerade mal 10.700 vorhanden (nach wie Du selbst schreibst, über einem Jahr). Zum Wiki-Artikel gebe ich dir recht. Man darf "waterway=riverbank" nicht einfach streichen. Für die Renderer und anderen Anwendungen scheint die Umstellung aber problemlos zu sein. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank
Am 29.05.2015 um 06:25 schrieb Markus: Habe hier eine merkwürdige Änderung entdeckt: http://wiki.openstreetmap.org/w/index.php?title=Tag:waterway=river&diff=next&oldid=1176333 Das würde ein weltweites Tagging-Schema zerstören... Da die Übergänge zwischen den Wasserflächen von Flüssen, Kanälen und Seen (im doppelten Wortsinn) fließend sind, finde ich das neue Schema logisch und praktikabel. Das neue Schema ist mehr als ein Jahr alt, viele Flüsse sind schon so erfasst. Wenn du die Änderung erst jetzt entdeckst, ist die "Zerstörung" offenbar nicht bedeutend. Welche Anwendung ist überhaupt betroffen? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] POI als Punkt oder Fläche mappen
Hallo zusammen, bei unserem heutigen OSM Stammtisch kam die Frage auf was aktuell der OSM Weg ist wenn durch genauere Informationen ein bereits als Punkt (Node) existierender POI in eine Fläche überführt werden soll. Es gibt wohl in der Community verschiedene Sichtweisen. Ich will mit einer kleinen Umfrage mal ein Meinungsbild einholen wie so etwas eurer Meinung nach gemapped wird. Ausgangslage ist also ein einfacher POIm der detaillierter als Fläche gemapped werden könnte. Fläche deckt dabei den kompletten POI ab. Keine Spezialfälle wie mehrere Shops im gleichen Gebäude oder so. A) POIs sollen niemals als Fläche gemapped werden. Der POI würde als Punkt innerhalb einer Fläche liegen die nur als Gebäude getagged ist B) Die Tags des Nodes werden der Fläche hinzugefügt und dann der Node gelöscht. History der Entstehung des Tags bleibt im OSM Full-Planet erhalten. C) Der bestehende Node wird verschoben und Bestandteil der Fläche. Die Tags werden vom Node entfernt und der Fläche hinzugefügt. History ist eventuell etwas leichter zu erreichen da der Node noch sichtbar ist. D) Node und Fläche sollen gleichzeitig existieren und beide alle Tags enthalten Hier mal ein Doodle dazu. (irgendwo gab es glaube ich auch eine "Umfrageplattform", habe das aber auf die Schnelle nicht gefunden) http://doodle.com/sfp3g2rtd4cg4mxp Bitte gebt so innerhalb der nächsten zehn Tage eure Meinung ab. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenspende Naturschutzgebiete in SH
Moin, ich habe vom einem Mitarbeiter des Landesamts für Landwirtschaft, Umwelt und ländliche Räume Schleswig-Holstein (LLUR) einen Datensatz mit allen NSGs, FFH- und Vogelschutzgebieten in SH zur Nutzung in OSM bekommen. Weitere Informationen dazu habe ich ins Forum geschrieben: http://forum.openstreetmap.org/viewtopic.php?id=30181 Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update of german Aral petrol stations
On 12.02.2015 07:19, Michael Kugelmann wrote: Am 11.02.2015 um 18:28 schrieb Michael Reichert: Ich persönlich denke, dass die ODbL als Lizenz für eine Import nicht ausreichend ist. Was passiert, wenn sich die Zweidrittelmehrheit der aktiven Mapper nach Artikel 3 der Contributor Terms für eine neue Lizenz entscheidet? H Aber: unter irgendeinem Account werden die Daten importiert. Und dieser Account erkennt bei der Anmeldung auch die CTs an => da steht doch IIRC dring dass sich die Lizenz ändern kann. Somit dürfen IMHO die einmal importierten Daten enthalten bleiben [oder mache ich einen Denkfehler?]. Ja. Dein Denkfehler ist, dass durch das Akzeptieren der Contributor, Term der Contributor der OSMF gegenüber bestätigt, dass er die Rechte an den Daten hat die er beiträgt um der OSMF die genannten Nutzungsrechte einzuräumen. In diesem Fall hätte der Importeur gelogen. Er ist nicht Eigentümer der Daten und kann somit auch das Nutzungsrecht nicht einräumen. Typischerweise ist das dann ein Fall für die DWG um eine Redaction der Daten, also ein Revert inklusive Bereinigung der History, durchzuführen. Sonst wäre es ja einfach die Daten von TeleAtlas und co zu importieren. Eine Lösung ist, sich zum Beispiel folgendes genehmigen zu lassen: "Wir gestatten die Verwendung unserer Daten in OpenStreetMap gemäß den Contributor Terms". Als Erklärung kann man dann noch einen Link au die CT beilegen und bei Bedarf auch sagen, dass die Daten derzeit unter der ODbL veröffentlicht werden. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Start-/Landebahn
Am 25.01.2015 21:02, schrieb kelvan bugmenot: uU etwas OT: Was mir auch klar wurde bei dem Gespräch ist, dass die aktuellen aeroway tags etwas nunja rudimentär und teilweise unpräzise sind. Eine Sache scheint für Flughäfen (zumindest für den Bereich mit dem ich gesprochen habe) essentiell zu sein, die Unterscheidung zwischen taxiway und taxilane. Der Unterschied hier ist ca wie zwischen einer Landstrasse und einer Strasse am Parkplatz. Habe dazu ein Proposal im Wiki angelegt: https://wiki.openstreetmap.org/wiki/Proposed_features/taxilane Nachteile deines Vorschlags: - nicht kompatibel zu bestehenden Daten - man erkennt nicht, nach welcher Definition ein "taxiway" erstellt wurde - ohne die Kenntnis der Trennlinie kann man keine korrekten Daten erstellen Sinnvoller wäre m.E. ein Zusatztag zu "taxiway", das die Zuständigkeit (ATC oder Airport) angibt. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungsfindung und Toleranz bei OSM
Am 25.01.2015 um 20:40 schrieb Frederik Ramm: On 01/25/2015 06:12 PM, Stephan Wolff wrote: Während im Wiki [1] noch über den Sinn der associatedStreet-Relationen (mit bislang unklarem Ausgang) abgestimmt wird, wird im deutschen Forum im Thread "Qualitätssicherung associatedStreet-Relationen" dazu aufgerufen, alle diese Relationen in Deutschland zu löschen. Ich glaube, da gibst Du die Diskussion im Forum unzureichend wieder. Ein Satz kann keine Diskussion wiedergeben. Welche Information fehlt dir? Dass von korrekten associatedStreet-Relationen vor dem Löschen der Straßenname übernommen wird? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Entscheidungsfindung und Toleranz bei OSM
Für alle, die im Forum nicht mitlesen: Während im Wiki [1] noch über den Sinn der associatedStreet-Relationen (mit bislang unklarem Ausgang) abgestimmt wird, wird im deutschen Forum im Thread "Qualitätssicherung associatedStreet-Relationen" dazu aufgerufen, alle diese Relationen in Deutschland zu löschen. Mich erschreckt die fehlende Toleranz und der fehlende Respekt vor den Daten anderer Mapper. Ich hoffe, dass die Entscheidungsfindung durch Löschen von Daten nicht zur Regel in OSM wird. [1] https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet [2] http://forum.openstreetmap.org/viewtopic.php?id=29816&p=1 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mühlgraben
Am 23.01.2015 10:40, schrieb André Riedel: Am 21. Januar 2015 um 14:00 schrieb André Riedel : Fragt man Overpass findet man ganze verschiedene Interpretationen von Wasserwegen mit dem Name "Mühlgraben": Durch Begriff "Mühlbach" hat sich die Nutzung von stream stark vermehrt. In Norddeutschland dürften "Mühlengraben" und "Mühlenbach" die häufigeren Namensvarianten sein. Persönlich würde ich stream nur dann verwenden, wenn man "darüber springen kann". drain und river würde ich komplett ausschließen. "river" und "stream" unterscheiden sich doch nur in der Breite. Warum sollte man das eine akzeptieren und das andere ausschließen? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mühlgraben
Moin! Am 21.01.2015 um 14:00 schrieb André Riedel: Hallo, wie trägt man einen Mühlgraben ein? Ich nehme an, du meinst den Zufluss zu einer historischen Wassermühle. Wassermühlen sind dort entstanden, wo man einen Bach aufstauen konnte und genügend Gefälle für ein Wasserrad hatte. Bei hinreichender Wassermenge kam man auch ohne Mühlenteich aus. Bäche werden als "waterway=stream" getaggt, auch die Abschnitte, die ein künstliches Gewässerbett haben (was in Deutschland auf einen großen Teil der Flüsse und Bäche zutrifft). "canal" ist laut englischem Wiki auf Schifffahrtkanäle und sehr große Bewässerungskanäle beschränkt: "Use waterway=canal for man-made waterways used for transportation or also for the largest waterways created for irrigation purposes." Im deutschen Wiki fehlt leider die Größenangabe. Dafür wird ausdrücklich gesagt "Kanalisierte Flüsse werden mit waterway=river bezeichnet." Das sollte entsprechend auch für kanalisierte Bäche gelten. Es erscheint mir sinnlos, Schifffahrtkanäle und Mühlgräben mit demselben Tag zu bezeichnen. Man kann ein solches Tag nicht sinnvoll auswerten. Jede Darstellung durch den Renderer wäre für eines der Beispiele völlig unangemessen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrageplattform
Am 21.01.2015 10:47, schrieb Harald Hartmann: Nachdem ich ein bisschen Zeit hatte, und mich mal wieder ein bisschen mit PHP beschäftigen, sowie auch einmal die OAuth Authentifizierung ausprobieren wollte, ist als Prototyp die Umfrageplattform für OpenStreetMap (http://osm.haraldhartmann.de/umfrage) entstanden. Technisch finde ich die Umfrageplattform sehr gut gelungen (bis auf das einzelne Absenden der Fragen). Die Darstellung der Ergebnisse abhängig von der Erfahrung der Mapper bringt einen Zusatznutzen. Ich habe in der Umfrageplattform zwei Fragen gestellt, die immer wieder für Diskussionen sorgen - so zumindest mein Eindruck nach fast einem Jahr aktiven Dabeiseins. Die Fragen sind auch so gestellt, dass sie fragen, wie man es aktuell macht, unabhängig von der "Lehrmeinung", Wiki oder Diskussionen Der Nutzen einer Umfrage hängt sehr davon ab, ob die Fragen und Antwortmöglichkeiten neutral und verständlich formuliert sind. Das ist bei den zwei Fragen von Harald der Fall. Manche Taggingfrage wird nicht so einfach zu formulieren sein. Wertende Begriffe wie "überflüssig" oder "verbessern" oder Sarahs Frage "Landuse und Strassen verkleben", würden eine Umfrage nutzlos machen. Die Frage "wie man es aktuell macht" könnte man besser durch eine Analyse der Changesets der letzten Monate beantworten. Interessant ist doch eher die Frage, welche Variante man für die Zukunft bevorzugen würde (insbesondere wenn es um neue Ideen geht). Bei mehr als zwei Antwortoptionen gibt die Auswahl einer Variante eine Meinung nur teilweise wieder. Ein Nutzer könnte Option A und B gut finden, C akzeptabel und D falsch. Vielleicht könnte man besser jede Option auf einer Skala zwischen "voller Zustimmung" und "voller Ablehnung" einzeln bewerten. Wie soll die Umfrageplattform organisiert sein? Wenn ein Moderator oder ein kleines Team Themen auswählt und daraus Fragen neutral formuliert, wäre eine solche Plattform sehr hilfreich. Wenn jeder Umfragen beliebig formulieren und zur Abstimmung bringen kann, wäre das m.E. kein Gewinn gegenüber den bisherigen Diskussionen. Je nachdem wie das Feedback (bitte ausschließlich über das Feedbackformular auf der Seite) ist, würden sich bestimmt Mittel und Wege finden lassen, den Prototyp auszubauen. Wo ist das Feedbackformular? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Start-/Landebahn
Am 12.01.2015 17:37, schrieb Martin Koppenhoefer: Am 12. Januar 2015 um 11:36 schrieb Stephan Wolff : Einen way. Eine Piste ist gerichtet, Tags wie "incline=*" wäre für Flächen sinnlos. Die Breite lässt sich problemlos als "width" beschreiben. Das deutsche Wiki zu "aeroway=runway" ist eindeutig, das englische leider nicht. man kann auch durchaus in Flächen eine Richtung erkennen, echte "ways" gibt es sowieso nur in der db und der Mathematik, aber nicht im echten Leben. Mit diesem Argument könnte man auch alle Mittellinien von Straßen und Flüssen durch die Fläche ersetzen. Für viele praktische Anwendungen hat die Abstraktion auf eine Linie aber viele Vorteile. Im Gegensatz zu den meisten Straßen und Flüssen mit wechselnden Breiten wird eine Piste durch die Mittellinie und Breite exakt definiert. Um die Breite "problemlos als width" zu beschreiben, muss man sie erstmal kennen / messen, was bei Landebahnen oft nicht praktisch geht. Die Breite ist vom Betreiber definiert. Man kann sich leicht der Wikipedia oder einer Luftfahrtpublikation entnehmen. Die Fläche der Piste ist natürlich nicht einfacher zu erkennen. Gerade an Übergängen zu den Rollwegen können dabei leicht Fehler entstehen. Einen incline-tag halte ich hier auch für wenig sinnvoll, man kann aber > z.B. die Höhen einzelner Punkte angeben, was dann auch deutlich mehr Informationsgehalt hat als der incline-tag. Ausser an Treppen nutze ich den eigentlich nie, Auch die Bahnneigung ist ein offizieller Wert, den die Piloten benötigen, um die Startstrecke zu berechnen. Man kann sie leicht aus einer Liste übernehmen. Die Höhen einzelner Punkte dürften kaum in der nötigen Genauigkeit zu gewinnen sein. Grundsätzlich finde ich es sinnvoll, die allgemein üblichen Daten auch in OSM zu verwenden. Meist sind dies die Werte, sie auch praktisch benutzt werden. Als Mensch kann ich mit Länge und Breite einer Piste etwas anfangen, mit der Koordinatenliste eines Polygonzugs nicht. Ob die Höhen einzelner Punkte mehr Information als die Bahnneigung hat, ist irrelevant, wenn ich die Neigung in ein Formular eintragen muss. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Start-/Landebahn
Am 09.01.2015 18:35, schrieb Martin Scholtes: Hallo zusammen, ich hätte da eine Frage. Kann man eine Start-/Landebahn als Fläche taggen oder sollte man nur einen Way draus machen? Einen way. Eine Piste ist gerichtet, Tags wie "incline=*" wäre für Flächen sinnlos. Die Breite lässt sich problemlos als "width" beschreiben. Das deutsche Wiki zu "aeroway=runway" ist eindeutig, das englische leider nicht. Früher hat man manchmal runde Grasplätze gebaut und ist jeweils gegen den Wind gestartet und gelandet. Falls es solche Plätze ohne definierte Landerichtung noch gibt, wäre dort eine Fläche als runway angemessen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Fehler
On 30.12.2014 05:21, Markus wrote: Weiss jemand, was diese Fehlermeldung bedeutet: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Du hattest diese Frage schon mal gestellt. Es geht darum das Zertifikat für das digitale signieren und verschlüsseln zu installieren. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entfernungs-Skala/Massstab
On 06.12.2014 20:02, davidoff12...@yahoo.de wrote: Im Gegensatz zu Google Maps oder Papierkarten ist bei OpenStreetmap zumindest per Vorgabe kein Maßstab ersichtlich. Es erschwert die Orientierung erheblich, bzw. macht sie umständlicher, wenn man die Entfernungen nicht einschätzen kann und erst den Routenplaner dafür bemühen muß. Mache ich was falsch oder ist Besserung in Sicht? was genau verstehst du unter Maßstab? So etwas wie die Anzeige unten links im Eck, die angibt wie lang 300km bzw. 100 Meilen sind? http://osm.org/go/euEQg- Die Anzeige verändert sich wenn du in die Karte reinzoomst. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM - Fernsteuerung - Sicherheit
On 24.11.2014 19:34, Markus wrote: - welche sollte man aus Sicherheitsgründen ausschalten? warum? Gefahr für deinen PC besteht bei den Vorgaben keine. Wenn du paranoid veranlagt bist solltest du das Feature abgeschaltet lassen, da Webseiten erkennen könnten dass bei Dir JOSM läuft. Was auch immer man mit der Info anfangen könnte. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Hallo Joachim, On 12.11.2014 06:40, Joachim Kast wrote: Da ich die Angelegenheit ruhig, sachlich und nachhaltig regeln möchte, lasse ich mir natürlich von keiner Seite eine Frist setzen. ich habe dich ja nun auch schon persönlich getroffen und als ruhigen und sachlichen Menschen erlebt. Ich denke du wirst hier schon so vermitteln können dass wir eine Lösung haben bei der sowohl die Community und OSM als Ganzes als auch das Projektbüro zufrieden sind. Schließlich wollen wir ja alle, dass die OSM Daten auch verwendet werden. Ich habe nicht recherchiert wer dieser Andreas eigentlich ist, aber der Kommentar einen Tag zu löschen falls er nicht binnen Frist im Wiki dokumentiert (und vorher abgestimmt ist) zeigt doch ein größeres Defizit im Verständnis wie das Tagging bei OSM funktioniert. Lass dich davon nicht abschrecken. Du machst einen guten Job. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vertrauen in OSM-Wochennotiz
On 04.10.2014 18:05, Andreas Labres wrote: On 04.10.14 11:30, Stephan Knauss wrote: Geht preislich ab USD 60 für zwei Jahre los: Bei StartSSL gibt's auch Gratis-Zertifikate und die funktionieren genauso. Also man /muss/ kein Geld dafür ausgeben! Ich administriere den Server nicht. Das Zertifikat dort ist ein wildcard für alle subdomains. Die kosten in der Regel Geld. Wenn es auch ein "normales", ohne wildcard sein darf ist es kostenlos zu bekommen. Benötigt dann aber in der Regel Unterstützung für SNI weil IP-Adressen nicht mehr im Überfluss da sind. Und damit sperrt man dann alle Nutzer aus die mit antiquierter Technik unterwegs sind. Alternativ könnte man statt selbst signiert auch CACert verwenden. Hilft aber der breiten Masse der nicht so technik-affinen Nutzer auch nicht. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vertrauen in OSM-Wochennotiz
Hallo Markus, On 04.10.2014 11:11, Markus wrote: Aber wieso schreibt mir diese immer, dass sie "nicht vertrauenswürdig" sei? ich vermute mal du rufst den Blog über eine https Verbindung auf. Dann kommt die Meldung im Browser daher, dass du das Team noch nicht genügend unterstützt hast. Du müsstest alle zwei Jahre eine kleine Spende machen so dass SSL Zertifikate verwendet werden können die in den verbreiteten Browsern schon fest verdrahtet sind als vertrauenswürdig. Geht preislich ab USD 60 für zwei Jahre los: https://www.startssl.com/?app=2 Gibt auch noch andere Anbieter, die aber meist deutlich teurer sind. Am besten machst du gleich die Spende, dann können die Admins das Zertifikat beantragen und installieren. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] City Maps 2Go Pro heute kostenlos bei Amazon
Im Amazon Android-Store gibt es heute eine OSM Kartenanwendung fürs Smartphone geschenkt. Kostet sonst regulär 2 Euro. http://www.amazon.de/gp/product/B008X8RSTM/ Wer auch sonst bei Amazon einkauft: Mit diesem Link auf die Seite gehen, dann bekommt OSM bis zu 10% des Einkaufswerts: http://www.amazon.de/?_encoding=UTF8&tag=opensde-21 Der Trick dabei ist, dass bei "allgemeinen" Produkten die Vergütung steigt je mehr Produkte gekauft werden (beim Preis gibt es eine Obergrenze von dem was OSM erhält, teurer als ~170€ je Produkt bringt für OSM dann keine höhere Einnahme). Und es lassen sich nicht mehrere Werbeprogramme kombinieren. http://wiki.openstreetmap.org/wiki/Merchandise/Stats Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Account für Workshop
Hallo Markus, On 23.09.2014 09:05, Markus wrote: Einen Account einrichten ist für viele eine technische Hürde. Deshalb legen wir mit jedem Teilnehmer einen persönlichen Account an und sorgen dafür, dass er die Zugangsdaten aufschreibt und mitnimmt, und üben mit ihm das Einloggen. Das dauert bei 10 Teilnehmern locker eine halbe Stunde... Wir müssen bei OSM nicht "jeden" haben. Das Anlegen eines Accounts ist im Vergleich zu den Herausforderungen beim Editieren der Daten ein Klacks. Wenn jemand schon nicht in der Lage ist in ein Formularfeld seine eMail Adresse einzutragen und sich einen Benutzernamen und Passwort auszudenken dann will ich nicht, dass so jemand bei OSM editiert. Das zerstört mehr Daten und schafft Arbeit als dass es Gewinn bringt. Einen gewissen Qualitätsanspruch zu haben ist durchaus in Ordnung. Und dazu gehört auch den Teilnehmern der Community ein Mindestverständnis von der Technik abzuverlangen. Du willst auch keine Spaziergänger mit Flip-Flops in den Alpen auf einem Klettersteig. Das hat nichts mit Diskriminierung zu tun sondern schützt alle Beteiligten vor negativen Folgen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Account für Workshop - dev-Server
Markus writes: Hier geht es mir eher um Messen wie die INTERGEO, wo JOSM auf mehreren Rechnern läuft. Wäre da ein Sandkasten zum sich austoben nicht viel besser geeignet? Wenn die Nutzer sich erst mal mit dem Editor auskennen kann man ja später immer noch sich an die Live-Datenbank rantrauen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Fail oder neue Insel? ;-)
chris66 writes: Am 22.09.2014 08:12, schrieb Elstermann, Mike: http://geoobserver.wordpress.com/2014/09/22/osm-fail-oder-neue-insel/ http://www.openstreetmap.org/#map=14/0.0791/0.0488 Solche temporären Lummerländer gehören zum OSM Konzept. ;-) war das wirklich ein "Lummerland" das mit Absicht so gebaut wurde? Mal beim entsprechenden Nutzer angefragt? So dicht bei 0/0 könnte das auch ein Problem im Editor sein. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Account für Workshop
On 21.09.2014 17:59, Markus wrote: Wie kann man einen temporären OSM-Account erstellen? beispielsweise für einen Workshop? Dazu ist der dev-server da. Die Live-Datenbank ist keine Spielwiese. Hier kannst du dich anmelden. Das lässt sich auch in JOSM als API für den Editor eintragen. http://master.apis.dev.openstreetmap.org/ Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo Google besser ist als OSM
On 31.08.2014 22:55, simson.gert...@gmail.com wrote: http://compare.osm-tools.org/?zoom=15&lat=50.79866&lon=12.95761&layers=BT00F An dieser Stelle sehe ich mehrere dicke rote Markierungen. Dies sind die Gornauer Straße und die Jägerschlößchenstraße. Bei diesem Vergleich http://sautter.com/map/?zoom=16&lat=50.79804&lon=12.95035&layers=B000TFFF sieht man, dass die Straßen von google und osm aber eigentlich sehr gut übereinander liegen. Wo ist da der Wurm drin? Es werden Hauptstraßen ausgewertet. Google denkt hier, dass es eine Hauptstraße sein sollte. In OSM ist sie als Nebenstraße (highway=residential) gemappt. Details zur Technik habe ich hier beschrieben: http://www.technologyblog.de/2014/08/wo-fehlen-bei-openstreetmap-noch-daten/ Ich denke in Deutschland wirst du dich schwer tun noch fehlende Hauptstraßen zu finden. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo Google besser ist als OSM
On 31.08.2014 22:31, Dieter Jasper wrote: Am 30.08.2014 23:12, schrieb Stephan Knauss: Damit sieht man schnell wo Google glaubt dass es Hauptstraßen gibt die bei OSM nicht verzeichnet sind. Tracks in OSM werden nicht berücksichtigt. Richtig? Da es um Hauptstraßen geht: Nein. Ein highway=track ist eine ähnlich untergeordnete Straße wie ein residential. Wenn du so eine Stelle hast, dann ist entweder Google mit der Hauptstraße ziemlich daneben oder das Tagging in OSM. Gibt so ein paar Fälle in OSM wo wichtige Straßen als "Track" gemappt sind weil nicht asphaltiert. Eigentlich wollte der Mapper aber das "surface" Tag verwenden. Oder hätte besser verwenden wollen ;) Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo Google besser ist als OSM
Hallo Jochen, On 31.08.2014 11:01, Jochen Topf wrote: http://compare.osm-tools.org/ Beim Armchair mappen könnt ihr euch nun auf die wirklich wichtigen Straßen konzentrieren. Coole Karte. Ich mag vorallem die psychodelischen Bilder, die beim zoomen und rumschieben kurz zu sehen sind. :-) Ja. OpenLayers verschiebt die Layer leider nicht gleichzeitig. Die Google-Bilddaten selbst will ich nicht manipulieren um noch im Rahmen der Terms of Use zu bleiben. Sonst hätte ich da direkt reinmalen können. Dann wäre es auch nur ein Layer gewesen. Problem ist, dass ich nicht sehr nahe ranzoomen kann und daher der Ausschnitt da, wo ich versucht hab, von der API immer als zu gross abgelehnt wurde und das Laden in den JOSM nicht klappt daher. Hast du da mal ein Beispiel? Bei mir ist das maximale Zoom 15 wenn ich ganz reingezoomt habe. Da habe ich kein Problem. Ist der angezeigte Kartenausschnitt bei Dir ungewöhnlich groß? Praktisch wäre auch, wenn man auf die OSM-Karte umstellen kann, dann kann man u.U. ohne das Laden in den Editor erkennen, wo man ein false positive hat. Das habe ich noch eingebaut. Man kann jetzt auch noch auf OSM-Rendering oder BING Luftbild umschalten. Aus irgend einem Grund ändert sich dabei zwar auch das CSS des Layer Selectors, aber Hauptsache das Tool ist damit nützlicher. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wo Google besser ist als OSM
Hallo, ich kann meinen Google vs. OSM Kartenvergleich nun weltweit anbieten. Damit sieht man schnell wo Google glaubt dass es Hauptstraßen gibt die bei OSM nicht verzeichnet sind. Oder andersrum: Gegenden in denen wir noch Straßen von Luftbildern übernehmen sollten. Ich habe das Ganze in meinem Blog beschrieben: http://www.technologyblog.de/2014/08/wo-fehlen-bei-openstreetmap-noch-daten/ Die Kurzform: Ihr seht auf der Karte die Google Hauptstraßen und Gewässer bei denen es in OSM keine Entsprechung gibt. In perfekt gemappten Gebieten ist die Karte dann grau. Wenn ihr eine Stelle genauer ansehen oder im Editor vom Luftbild abmalen wollt könnt ihr mit den Buttons auf der linken Seite den Bereich im Editor laden. Ich bevorzuge JOSM, sollte aber auch mit iD und Potlatch gehen. http://compare.osm-tools.org/ Beim Armchair mappen könnt ihr euch nun auf die wirklich wichtigen Straßen konzentrieren. Viel Spaß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Referenzpunkt für GPS-Gerät
On 26.07.2014 20:22, Ronnie Soak wrote: Du meinst “informativ den momentanen Fehler sehen“? Handelsübliche GPS kann man nicht kalibrieren. Außerdem ist der Fehler an jedem Ort und zu jeder Zeit anders. was braucht eigentlich die rtklib an Hardware? Ist das bezahlbar? Also sagen wir mal kleiner 100€? Dann könnte man ja an den Referenzpunkt einen Empfänger stellen und mit seinem GPS abgleichen mit dem man in der Umgebung die Straßen erfasst. Ob sich das noch lohnt wenn man genügend Luftbilder hat die mit einer Lagegenauigkeit von ca. 1m angepriesen werden (google, Bing dürfte vergleichbar sein) wäre die Frage. Man will ja keinen Mähdrescher zentimetergenau übers Feld fernsteuern... Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfahrtsbeschreibung SOTM EU führt über gesperrte Straße
fly writes: Das sieht bei mir leider auch nicht besser aus. Dauernd Sonderlinien und Fahrplanänderungen. Und was mache ich denn jetzt, wenn es hoffentlich nur drei Wochen dauert, dadurch allerdings der zentrale Umsteigebahnhof betroffen ist ? Ist es OK hier alles umzumodeln und in drei Wochen wieder zurück ? eher nicht ändern. Selbst ich als OSM aktiver mache deutlich seltener Updates auf mein OSMand. Da hätte ich dann somit längere Zeit "veraltete Daten" eingefangen. Die Schmerzgrenze für so temporäre Geschichten dürfte ungefähr bei einem viertel bis halben Jahr liegen. Alles was kürzer ist lohnt sich nicht im OSM zu ändern. Die Diskussion gibt es immer mal wieder. Für so kurzfristige Sachen gibt es alternative Mittel und Wege. Beim Audo hat sich ja wohl TPEG durchgesetzt, für ÖPNV gibt es sicher auch so was ähnliches um kurzfristige Ausfälle abbilden zu können. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geodaten des Bundes
Am 27.05.2014 20:50, schrieb Joachim Kast: Ich bin im Juni/Juli zu Workshops beim Lenkungsgremium GDI-DE und beim BMI eingeladen. Dabei werde ich natürlich (wie immer) auf die verzwickte Situation der Namensnennung sowie deren Lösung in Berlin und NRW hinweisen. Das wäre moralisch einfacher, wenn OSM umgekehrt genauso flexibel wäre. Wenn diese Termine vorbei sind, werde ich hier über den aktuellen Stand berichten. Danke für dein Engagement. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geodaten des Bundes
Moin, gibt es etwas Neues zur Nutzung der Geodaten des Bundes in OSM? Ich habe eine Aussage von Joachim Kast aus dem letzten Oktober gefunden: Ich habe im Vorfeld der letze Woche stattgefunden INSPIRE-Konferenz des BMI die Beauftragte der Bundesregierung für Informationstechnik gebeten, zu überprüfen, ob der Bund das schon erwänte "Berliner Modell" der Namensnennung anwenden könnte. Wegen der derzeit laufenden Koalitionsverhandlungen rechne ich auch nicht mit einer schnellen Antwort. Es scheint absurd, dass der Bund und OSM die gleiche Bedingung an die Nutzer stellen und die Lizenzen deshalb nicht kompatibel sind. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten
Am 20.05.2014 16:17, schrieb Falk Zscheile: Am 20. Mai 2014 10:13 schrieb Sven Anders : source:name=Straßenverzeichniss Hamburg vom 07.05.2009 source:name=Schild am Eingang des Kleingartens. Dann sollte man das aber so weit abstrahieren, dass eine Maschinenlesbarkeit gewährleistet ist! Sonst hält sich der Mehrwert des zusätzlichen Tags doch sehr in Grenzen. Ja, die Beispieltexte sind nicht nutzbar. Wenn man abstrahiert source:name=offical, local [was weiß ich] hätten auch die Leute, die Straßenlistenauswertungen machen oder eben Navigationssoftware bauen (Ausgangsproblem) etwas davon, weil sie bei der Datenauswertung Besonderheiten identifizieren und eine Lösung erarbeiten können. Für einige Anwendungen wäre diese Information sicherlich nützlich, aber: - es gibt fast 74.000.000 way mit "highway" in der Datenbank. - viele Mapper werden wohl die Mühe scheuen, viel Arbeit in eine Zusatzinformation von geringem Nutzen zu investieren. - die meisten Mapper können gar nicht entscheiden, vom wem Name auf dem Straßenschild festgelegt wurde. Insbesondere in den Problemfällen (Militar-, Uni oder Kleingartengelände) ist es vor Ort oft nicht erkennbar. Praktisch ist die Idee wohl nicht umsetzbar. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wegenamen in Kleingärten
Am 19.05.2014 16:05, schrieb Martin Koppenhoefer: Am 19. Mai 2014 15:50 schrieb Stephan Wolff : während Parzellennummern nach "ref" (reference numbers or codes) gehören. was die Namen angeht bin ich bei Dir, aber aus dem Wiki oder der Praxis was für "ref" abzuleiten halte ich schon für gewagt. Man könnte sicherlich "ref" verwenden, weil es sehr unspezifisch definiert ist und auch in der Praxis sehr oft verwendet wird, wenn es "irgendwelche Nummern" zu taggen gibt, aber man könnte sich da genauso gut auch was Spezifischeres für "Parzellennummer" denken, mit dem Vorteil, im Zweifel nicht raten zu müssen, welche Art Nummer nun gemeint ist. Ja, das war unsauber formuliert. Eine Parzellennummer ist kein "name", eine Parzellennummer passt zur Definition von "ref", für Kleingartenparzellen dürfte dies die allgemein übliche Nummerierung sein (während es für Straßen, Brücken, Grundstücke etc. mehrere Systeme gibt) und es wird im Wiki Tag:allotments=plot so vorgeschlagen. Daher ist "ref" zumindest ein geeignetes Tag. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wegenamen in Kleingärten
Moin, die Definitionen zu Namen im Wiki sind stabil und zumindest zwischen deutscher und englischer Version recht konsistent: name: allgemeine Bezeichnung/ Standardname/ common default name name ist nur der Name, keine Kategorie, Typ, Beschreibung name is the name only not categorie, type, description loc_name: lokale Bezeichnung/ slang name or unofficial-sounding In einer umfassenden Datenbank kann es keine für alle Anwendungen optimale Datenstruktur geben. Eine Änderung der Definition für eine spezielle Anwendung ist kaum durchsetzbar (und m.E. auch nicht sinnvoll). Den größten Nutzen erhalten wir, wenn sich alle an die Definition im Wiki halten. Wegenamen in Kleingärten gehören nach der oben genannten Definition nach "name" während Parzellennummern nach "ref" (reference numbers or codes) gehören. Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber nicht in der Karte. Nein, die Darstellung in einer Karte sollte kein Argument sein. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rettet die Kleingarten-Wegenamen
Am 19.05.2014 14:33, schrieb Wolfgang Hinsch: Praktische Folge: Der (z.B.) Taxifahrer bekommt entweder eine Hasskappe, weil er den Namen in seinem OSM-Navi nicht findet, oder weil er den Namen 10x findet. Zum Vergleich: Google findet für "Dahlienweg Hamburg" fast 350.000 Ergebnisse und ist trotzdem nicht unbrauchbar. Wo liegt das Problem, wenn die OSM-Ergebnisse nach der Bedeutung der Straße (Hauptstraße...Spielstraße, Feldweg, Pfad) sortiert werden? Dann ist die "amtlich benannte" Straße fast immer an erster Stelle. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit
Am 30.03.2014 13:57, schrieb Florian Schäfer: > Hallo Liste, > ich würde gerne mal bei euch ein kleines Meinungsbild einholen über > die Verwendung des Keys noexit > > In den folgenden Situationen habe ich beispielsweise schon > noexit=yes-Tags gesehen: > *A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357 > <https://commons.wikimedia.org/wiki/File:Zeichen_357.svg>) Ich finde "noexit" allenfalls in diesem Fall sinnvoll. Private Wege zu Haustüren oder Garagen, die dort abzweigen, würde ich ignorieren. Laut deutschen Wiki ist "noexit" nur für Punkte definiert, in der englischen Version auch für Wege, ohne dass dies genauer beschrieben ist. Würde man Wendeschleifen in Sackgassen mit "noexit=yes" versehen? Sollte man alle Werte außer "yes" und "no" entfernen oder ist eine Erweiterung wie "noexit=motor_vehicle" (169 Verwendungen) sinnvoll? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Moin! Am 01.04.2014 10:14, schrieb Falk Zscheile: Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen, um der möglichen Doppelbedeutung von tags entgegenzuwirken. Damit führst du doch eine Doppelbedeutung erst ein. Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit "traffic_sign=DE:397" der Inhalt vollständig beschrieben. Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur Straße nötig wäre, fehlt natürlich noch. "access:traffic_sign" statt "traffic_sign" wird jede Auswertung verhindern und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung beinhaltet. "noexit=yes" beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. PS.: So handhabe ich es auch bei der Radweg-/Fußweg-/-kombinations-/Poblematik. Aber hoffentlich nicht mit "access"-Tags. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit
Am 30.03.2014 13:57, schrieb Florian Schäfer: Hallo Liste, ich würde gerne mal bei euch ein kleines Meinungsbild einholen über die Verwendung des Keys noexit In den folgenden Situationen habe ich beispielsweise schon noexit=yes-Tags gesehen: *A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357 <https://commons.wikimedia.org/wiki/File:Zeichen_357.svg>) Ich finde "noexit" allenfalls in diesem Fall sinnvoll. Private Wege zu Haustüren oder Garagen, die dort abzweigen, würde ich ignorieren. Laut deutschen Wiki ist "noexit" nur für Punkte definiert, in der englischen Version auch für Wege, ohne dass dies genauer beschrieben ist. Würde man Wendeschleifen in Sackgassen mit "noexit=yes" versehen? Sollte man alle Werte außer "yes" und "no" entfernen oder ist eine Erweiterung wie "noexit=motor_vehicle" (169 Verwendungen) sinnvoll? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Moin! Am 01.04.2014 10:14, schrieb Falk Zscheile: > Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den > etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen, > um der möglichen Doppelbedeutung von tags entgegenzuwirken. Damit führst du doch eine Doppelbedeutung erst ein. > Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, > access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit "traffic_sign=DE:397" der Inhalt vollständig beschrieben. Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur Straße nötig wäre, fehlt natürlich noch. "access:traffic_sign" statt "traffic_sign" wird jede Auswertung verhindern und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung beinhaltet. "noexit=yes" beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. > PS.: So handhabe ich es auch bei der > Radweg-/Fußweg-/-kombinations-/Poblematik. Aber hoffentlich nicht mit "access"-Tags. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Moin, mich erschreckt die kompromisslose Haltung und die teils aggressive Wortwahl als Reaktion auf eine höflich geschriebene Bitte. Ich habe in einigen Fällen darauf verzichtet, mir bekannte Fakten in OSM einzutragen. Einen Seeadlerhorst und den stationären Bauwagen eines Waldkindergartens habe ich gar nicht erfasst, ein außerhalb des Ortes gelegenes Vereinsheim ohne Beschilderung nur mit "building=yes". Wir sollten in wenigen Einzelfällen auf Eintragungen in OSM verzichten, auch wenn kein gesetzlicher Anspruch darauf besteht. Hochsitze haben m.E. nur eine geringe Relevanz, da sie nicht zum Gebrauch für die Allgemeinheit bestimmt sind und wegen der getarnten Bauweise und relativ häufiger Standortänderungen auch schlecht als Wegmarke geeignet sind. Falls es in einer Region zu starkem Vandalismus an Hochsitzen gekommen ist oder der Anfragende sogar plausibel machen kann, dass OSM-Karten für gezielte Beschädigung genutzt wurden, könnte ich mir eine Entfernung dieser Daten vorstellen. Don't be evil. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehler beim Konvertieren von .OSM nach .MAP
Das plugin scheint schon seit 2012 defekt zu sein. Wenn sich da keiner mehr darum kümmert wird es wohl Zeit sich nach einer Alternative umzusehen. 64bit IDs können mit der alten Version Probleme machen. Siehe auch osmosis-dev vom 8. Oktober 2012. Stephan On March 6, 2014 3:47:01 PM CET, hike39 wrote: >Nun habe ich selbst herausgefunden, dass das Problem in der Kombination >Osmosis 0.43.1 und Mapsforge-Map-Writer 0.3.0 liegt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenschutz bei OSM (war: Mapnik Administration blockt QLandkarteGT)
Hartmut Holzgraefe writes: On 02/20/2014 02:38 PM, Jörg Frings-Fürst wrote: 2.) Es ist nicht unmöglich sich jeweils 4 Zahlengruppen von 1-255 zu merken. schon bei meinem bescheidenen privaten Webserver ist es oft kaum möglich in einem "tail -f access.log" aus dem vorbeirauschenden ASCII-Brei irgendetwas erkennbares aufzuschnappen ... das sich merken ist also nicht das Problem, überhaupt etwas merkbares zu erkennen ist es ... Don't feed the trolls! <*> Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenschutz bei Geodaten?
Am 19.02.2014 20:00, schrieb Steffen Wolf:
Hmm, ich les grad noch die Erklaerungen zu den einzelnen Punkten:
Massstab 1:5000, da werden in der Deutschen Grundkarte
Flurstuecksgrenzen und einzelne Hausnummern dargestellt. Das sieht der
Leitfaden auch nicht als bedenklich an. Das beruhigt mich etwa in
Hinblick auf unsere Hausnummernsammelei. Aber eigentlich gehen wir ja
weiter und stellen auch noch die Haeuser dar. Dazu sagt der Leitfaden
aber nix.
Ich würde das so verstehen:
Hausumrisse tauchen schon auf Karten ab etwa 1:50.000 auf und sind
unproblematisch. Selbst mit den Zusatzinformationen der Hausnummern und
Flurstücksgrenzen der Deutschen Grundkarte ist es unbedenklich.
Auf problematische Zusatzinformationen ("Hier wohnt der Prominente ...")
können und sollten wir m.E. verzichten.
Gruß an meinen (fast) Namensvetter
Stephan Wolff
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] St.-ZickeZacke-Str.
On 06.02.2014 19:18, Martin Raifer wrote: Lustig, die Engländer haben anscheinend kein Problem mit dem "St." in Eigennamen (und das trotz Verwechslungsgefahr "Saint"/"Street"): http://www.openstreetmap.org/way/4959544#map=19/51.51372/-0.09845 Und bei uns hat niemand ein Problem damit das "Sankt" auszuschreiben. So what? http://www.openstreetmap.org/#map=19/48.36587/10.90284 Was hat dieses Beispiel nun gebracht? Ursprungsfrage war ja, ob man in den "name" Tag den ganzen Namen einträgt oder eine in der jeweiligen Schriftform gebräuchliche Abkürzung. Und bei OSM ist es schon seit Jahren so, dass es immer die Langfassung sein soll. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] St.-ZickeZacke-Str.
Martin Raifer writes: Text-to-Speech Gute Text-to-Speech Software sollte aber mit diesen Abkürzungen locker umgehen können. Und wenn nicht, dann bedarf es für die jeweilige Anwendung schlicht eines Post-Processing Schritts, der die Abkürzungen entsprechend expandiert. Wieso es dem Mapper schwer machen wegen möglicherweise schlechter Anwendungs-Software? Oder im OSM-Slang: „Wir mappen nicht für das Text-to-Speech Programm!“ Du würdest für das TTS mappen wenn du in den Name-Tag etwas einträgst was nicht der Name ist nur um es hübsch in der TTS zu haben. Will ja niemand. Es soll nur der ganze Name in den name tag, ohne Abkürzungen. Etwas *nicht* abzukürzen ist wohl kaum eine böse Aktion die auch nur im entferntesten unter "Taggen für Renderer" fällt. Wie willst du denn die schon genannte "St. Effenberg Fussballstr." expandieren? Das klappt nur wenn deine Software eine vollständige Liste von allen Abkürzungen hat die eindeutig expandierbar ist. Einen Schriftsteller "Stefan Lukas" kannst du nicht von einem "Sankt Lukas" unterscheiden wenn du nur "St. Lukas" hast. Wenn du nur das Schild "St. Lukas" siehst und keine weitere Ortskenntnis oder Zusatzinfo hast, dann trägst du auch nur das in den name tag ein. Wenn du weißt, dass es ein "Stefan Lukas" oder ein "Sankt Lukas" ist, dann trägst du das ein. Was ist an einer Regel "Trage den vollständigen Namen ohne Abkürzungen in den Name Tag ein. Wenn du nur die abgekürzte Fassung kennst dann trage nur diese ein." so kompliziert? Ein Mapper der schon daran scheitert sollte besser nicht bei OSM mitspielen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] St.-ZickeZacke-Str.
Martin Raifer writes: Es geht doch praktisch fast nur um zwei Fälle: "St." und "Dr.". Beides sind in gewisser Weise Titel von Personen, die im echten Leben fast immer abgekürzt werden. "St." kann "Sankt" oder "Saint" werden. Je nach Name der dahinter kommt. Das lässt sich nur extrem schwer mit Software expandieren, vermutlich nur mit umfangreichen Worterbüchern. Sankt Florian oder Saint Exupery. Und in Grenzgebieten vielleicht noch schwieriger. Ist es ein Französischer Name oder ein Deutscher? Je nachdem müsste anders expandiert werden. Und der Name ist eben "Sankt Florian". So spricht man auch den Namen aus. Dass es auf Schildern eventuell aus Platzgründen abgekürzt wird weil die Abkürzung gebräuchlich ist ändert ja nichts am Namen. Ist nur ein spezieller "Renderer". Wir wollen ja den Namen der Kirche/Straße erfassen und nicht die Aufschrift des Schildes. Falls es für die Schilder eine Anwendung gibt (Ortsbestimmung für Blinde mit Texterkennung durch Kameras bei schlechtem GPS Empfang?) müsste man sich für das Tagging der Schilder und deren Position halt auch was überlegen. Ändert aber nicht den Namen der Kirche oder Straße die das Schild benennt. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] St.-ZickeZacke-Str.
On 03.02.2014 19:17, Martin Raifer wrote: Außerdem: Wenn jemand den "ganz normalen Sprachgebrauch" eines Landes nicht kennt, kann ein ausgeschriebener Name genauso (oder sogar viel eher noch) für Verwirrung sorgen: Auf der Karte stünde "Sankt Peter Hauptstraße", am Schild aber steht "St. Peter Hauptstraße"[1] – kann man ohne deutsche Sprachkenntnis mit einiger Gewissheit sagen, ob das jetzt die gemeinte Straße ist? Ich behaupte nein. Bitte trennt euch endlich mal von der irrigen Annahme dass OSM nur eine Karte ist. OSM ist viel mehr. Was mache ich zum Beispiel wenn ich eine Navi programmiere die per Text-To-Speech die Namen ansagt? "Bitte rechts abbiegen in die Es-Te-Punkt Peter Straße"? Dass man per Software nicht so einfach auf den langen Namen kommt ist zur genüge erklärt worden. Und das "Sankt Peter" ist nun mal der Name. Also kommt der bitte auch in den name Tag. Wenn jemand ein Problem damit hat das "Sankt" in ein "St." abzukürzen biete ich gerne an das in jeder gebräuchlichen Programmiersprache zu lösen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OsmAnd+ heute gratis bei Amazon
Hallo, wer auf seinem Android Telefon auch den Store von Amazon installiert hat bekommt heute die Vollversion von OsmAnd gratis. http://www.amazon.de/dp/B00D0SEGMC Viel Spaß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:Tag:waterway=weir - Problem mit zweideutiger Übersetzung
Richard Z. writes: mir ist jetzt schon ein paarmal aufgefallen, daß Mapper etwas mit waterway=weir getaggt haben was ich eigentlich mit waterway=dam mappen würde - weil (außer im Katastrophenfall) nie Wasser drüberfließt. Fließt das Wasser denn generell ab? Jedenfalls schreibt die deutsche Wikipedia über Wehr (Wasserbau): "Wehre können zeitweise überströmt oder durchströmt (oder beides gleichzeitig) sein." Hier Beispielbilder für Wehre: http://commons.wikimedia.org/wiki/File:Tainter_Gate.jpg http://commons.wikimedia.org/wiki/File:Schweinfurt_Walzenwehr_1.jpg Die Abgrenzung zu einem Staudamm ist aber wirklich schwierig, oder? In der Wikipedia ist das hier ein Beispiel für einen Damm: http://upload.wikimedia.org/wikipedia/de/8/89/Selbstgebauter_Staudamm.JPG Was ist an dem jetzt so signifikant anders als an einem Wehr das überströmt/durchströmt wird? Und dann beschreibt die Wikipedia noch eine "Staustufe". http://de.wikipedia.org/wiki/Staustufe Oder eine Talsperre: http://de.wikipedia.org/wiki/Talsperre Die hat dann auch gleich noch eine juristische Definition dabei. Ich denke aber dass wir bei OSM es nicht so kompliziert machen sollten. Nicht alle Mapper sind gelernte Wasserbau Experten. Wir brauchen eine Definition die von 95% der Mappern verstanden und angewendet werden kann. Und die Definition sollte bei uns genauso verwendbar sein wie in Asien. Warum nicht einfach noch ein paar Fotos als Beispiel mit auf die Wikiseite? Dann kann sich der Mapper schon das aussuchen was am besten zu seinem Bauwerk passt. Und die jeweiligen Experten für Wasserbau können dann die genz wenigen Bauwerke die doch falsch getaggt sind entsprechend korrigieren und ein foto mit Erklärung ins wiki einfügen damit es das nächste mal noch eindeutiger wird. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 14.01.2014 08:54, André Riedel wrote: Ich sehe schon, es ist noch komplizierter als ich dachte. Eine Set würde ich in API 0.7 bevorzugen, denn so könnte man bspw. die Unterschiedlichen Öffnungszeiten kenntlich machen. mein Gedanke war, dass der Set ein Datentyp ist. also so in etwa das um das "amenity=hotel;restaurant" zu ersetzen hotel restaurant Das was du machst finde ich vom Bauchgefühl her unglücklich. Ich würde das doch trennen wollen. Es ist ja auch geographisch nicht der gleiche Ort. Eventuell die gleiche Adresse, aber die Leute übernachten bestimmt nicht im Restaurant. Das ist also schon räumlich getrennt. Eventuell ist das Hotel ja in Wirklichkeit ein Stockwerk drüber oder so. Es ging mir mehr um die Sachen bei denen es sich nicht trennen lässt. Wie eben das Stück Autobahn von Stuttgart Richtung Karlsruhe: A 8 A 81 Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 13.01.2014 23:40, Frederik Ramm wrote: Du hast schon recht, es waere wuenschenswert, wenn Software das "automatisch richtig" machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur key=value Paare, sondern noch etwas mehr. Eine Idee für Api 0.7 Geordnete Listen: Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge nacheinander kommen. Doppelte Values sind erlaubt. Sets: Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, doppelte Values sind verboten. Wäre eine größere Änderung, dürfte aber viele der bisherigen Verwendungen vom Semikolon abdecken. Bisherige Werte in der Datenbank blieben als value erhalten bis es jemand von Hand (oder script) konvertiert. ABER: Das ist eine recht große Änderung die eine Modifikation an jeder Software erfordern würde die die Daten verarbeiten will. Um kompatibel zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon für nicht angepasste alte Software. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 13.01.2014 22:12, Peter Wendorff wrote: jetzt fängst du aber mit Ausweichtaktiken an. Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf Highway Shields ausgerichtet. Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat. Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die Lösung des Problems nicht. http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PV-Anlage
Am 06.12.2013 17:04, schrieb chris66: Am 06.12.2013 16:54, schrieb Fabian Schmidt: OSM überrascht mich immer wieder: http://www.openstreetmap.org/#map=17/51.018/13.804 Mich überrascht es negativ. Einen Mehrwert gegenüber einem Gesamtobjekt kann ich nicht erkennen, aber solche Spielereien schaden allen bestehenden Auswertungen des Tags, ob als Listen oder Symbolen in Karten. Dass die 141 Solarzellen einzeln gemappt sind (laut Wiki wohl zulässig)? Die Definition im Wiki ist leider unbrauchbar: "A generator [] is a device that converts one form of energy to another." Darunter würden auch die Kraftwerkskessel (Kohle zu Dampf), Motoren, Heizungen und alle elektrischen Verbraucher fallen. Die Analogie zum Generator im Kraftwerk wäre eher der Wechselrichter im Solarkraftwerk. Man könnte nur den Wechselrichter oder die zusammengeschalteten Solarmodule mit Wechselrichter als einen "generator" erfassen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Definition Schule
Moin, "amenity=school" wird teilweise für Tanzschulen, Sprachschulen, Seminare oder Hörsäle/Vortragsräume benutzt. Das englischsprachige Wiki beschreibt nur klassische Schulen: "Use amenity=school to identify a place where pupils, normally between the ages of about 5 and 18 are taught under the supervision of teachers. This includes primary and secondary schools" Das deutsche Wiki ist leider nicht so eindeutig: "Auf talk-de gab es im März 2010 eine längere Diskussion über die Definition von Schule im Sinne des hier beschriebenen Tags. Im wesentlichen standen sich zwei Meinungen gegenüber: Zum einen wurde Schule als Bildungseinrichtungen im weitesten Sinne verstanden (Gymnasium, Fahrschule, Segelschule etc.). Zum anderen sollten unter Schule nur die klassischen Schulen (Grundschule, Hauptschule, Realschule, Gymnasium, Berufsschule) verstanden werden..." Besteht die Meinungsverschiedenheit noch oder können wir die Definition des englischen Wikis übernehmen? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues JOSM-Plugin
chris66 writes: Im Forum tauchen gerade lizenztechnische Bedenken auf: ... Gegen die von Ihren "OSM-Mappern" mittels GIS-Editoren beabsichtigten Nutzungen der WMS-Darstellungsdienste des NRW-Atlas zur Lagekontrolle, Qualitätssicherung und zur Ableitung von Geodaten kann ich keine Einwände erkennen. Lediglich das Kopieren meiner Datenbankinhalte - also ein direktes Speichern der aufgerufenen WMS-Darstellungsdienste zur Anlage von Sekundärdatenbeständen - ist bereits urheberrechtlich untersagt. ... Ableitung oder Kopie, das ist die Frage fehlt da Kontext zur Frage? Aus diesem Zitat kann ich kein Problem erkennen. Es gibt einen WMS dienst den wir (vergleichbar den Bing Bildern) verwenden dürfen. Nur die Bilder die dort geliefert werden dürfen wir nicht Speichern um daraus Sachen wie z.B. eigene WMS Server zu machen. Eine temporäre Kopie (z.B. im Cache) wurde ja sogar erlaubt, da dadurch eben nicht die Anlage eines Sekundärdatenbestandes bezweckt wird. Wo siehst du die Einschränkung für OSM? Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 21.11.2013 17:42, schrieb Martin Koppenhoefer: Am 21. November 2013 17:23 schrieb Stephan Wolff : Meine Argumentation ist, dass Einrichtungen für Menschen anders als Objekte mit ähnlicher Bezeichnung für Pflanzen und Tiere erfasst werden. wobei es hier ja eher um eine unspezifische Eigenschaft (Windschutz, Regenschutz, Unterstand und Schutzmöglichkeit) geht. In der Not wird man (nach Rücksprache mit einem Arzt) z.B. vermutlich auch ein Medikament für Tiere nehmen, wenn es keine Alternative gibt. Das passiert, wenn der Tierarzt als "amenity=doctors" erfasst wird ;-) Deinen Grundsatz von Menschen als Gegensatz zu Pflanzen und Tieren finde ich ein bisschen haarig. Wenn ich Menschen, Tiere und Pflanzen in 2 Gruppen packen müsste, wären bei mir die Tiere eher bei den Menschen als bei den Pflanzen, weil die Anforderungen und Bedürfnisse doch näher liegen sollte. Ich will Hundeschulen und Baumschulen nicht zusammenfassen. Es können mehr als 2 Gruppen bzw. Tags sein. Eine Baumschule, in der Bäume erzogen werden, fällt nicht unter amenity=school. Habe noch nie gehört, dass in einer Baumschule Bäume ERzogen werden. Dort lernen die Bäume gerade zu stehen. Duden zu "erziehen": 2. (Gartenbau) (Pflanzen) [heran]ziehen Einen Felsüberhang würde ich auch nicht als shelter erfassen, eine Höhle mit Bank schon. wieso? Für mich macht das Dach und ggf. der umliegende Schutz den shelter aus, keineswegs die Sitzbank. Wenn man "shelter" so umfassend definiert, müsste man alle Carports, Vordächer und viele Balkone und Brücken ebenfalls so erfassen. Unter amenity (Wiki: Covering an assortment of community facilities...) wäre es trotzdem falsch. Nochmals die Frage: warum nicht "building=field_shelter"? das kann man ja machen (oder building=roof), schließt aber das amenity nicht aus. Dann besteht Einigkeit, dass "building=field_shelter" ein geeignetes Tag ist, und Uneinigkeit zu "amenity=shelter". Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 21.11.2013 08:49, schrieb NopMap: Stephan Wolff wrote Ein Viehunterstand verhält sich zum Unterstand wie die Hundeschule zur Schule oder der Krötentunnel zum Fußgängertunnel. In OSM verwenden wir dafür unterschiedliche Tags. Die Argumentation ist nicht konsistent. Um Deine Metapher aufzugreifen: Ein Unterstand verhält sich zu einem Felsüberhang wie eine Schule zur Baumschule.Es ist nicht von Menschenhand als Schutz gebaut wie die übrigen Shelter und es sagt nichts darüber aus wieviel Kletterei nötig ist um ihn zu erreichen. Meine Argumentation ist, dass Einrichtungen für Menschen anders als Objekte mit ähnlicher Bezeichnung für Pflanzen und Tiere erfasst werden. Mit Bauart und Material hat es nicht zu tun. Eine Baumschule, in der Bäume erzogen werden, fällt nicht unter amenity=school. Eine Schule für Kinder unter einem großen Baum dagegen schon. Einen Felsüberhang würde ich auch nicht als shelter erfassen, eine Höhle mit Bank schon. Nochmals die Frage: warum nicht "building=field_shelter"? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 20.11.2013 11:16, schrieb Martin Vonwald: Ein Unterstand ist ein Unterstand. Ein Viehunterstand verhält sich zum Unterstand wie die Hundeschule zur Schule oder der Krötentunnel zum Fußgängertunnel. In OSM verwenden wir dafür unterschiedliche Tags. Wenn ich im Gebirge von einem Unwetter überrascht werde, ist es mir herzlich egal ob das Dach über meinem Kopf auch explizit für mich gebaut wurde oder nicht - Hauptsache trocken. Das ist keine Begründung den Viehunterstand als amenity einzuordnen. Die meisten Objekte mit Dach sind als building erfasst. Das passt auch in diesem Fall. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ein Restaurant, zwei Eingaenge
Moin! Am 14.11.2013 13:12, schrieb Michael Neumann: habe momentan folgendes Problem, wie mappe ich ein Restaurant mit zwei Eingaengen getreu dem Motto http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element ? Nach dem KISS-Prinzip als Punkt in der Mitte des Gastraumes. Die Wahl des Eingangs hängt auch davon ab, ob man zum Saal, zur Bar oder zur Außenterrasse will. Auf den letzten Metern kann ein Router ohnehin nicht helfen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 19.11.2013 20:13, schrieb NopMap: Die alten Shelter unterscheiden sich bereits deutlich voneinander, Grillpavillion, Picknickplatz oder Schutzhütte machen einen großen Unterschied. Von daher ist es jetzt schon nötig, für eine sinnvolle Auswertung den Typ zu berücksichtigen. Das sind Freizeiteinrichtungen mit Schutzdach. Manche Anwendungen werden den Untertyp auswerten, andere werden nur ein Symbol für Shelter zeichnen. Bei 60% ist shelter_type nicht einmal benutzt. Ein landwirtschaftliches Nutzgebäude passt nicht dazu. Laut taginfo wird "shelter_type=field_shelter" auch nur 12 mal verwendet. Wir sollten dafür nicht ein etabliertes Tag umdefinieren. Wenn es Dir egal ist ob es eine Berghütte oder ein Bushäuschen ist und es Dir nur um ein Dach geht, dann ist Dir auch mit einem solchen Unterstand gedient. Viele Objekte können als Regenschutz dienen. Ein Unterstand für Rinder hinter einem Stacheldrahtzaun wäre meine letzte Wahl. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 19.11.2013 12:15, schrieb NopMap: amenity=shelter + shelter_type=field_shelter klingt genau passend. Ich finde "amenity=shelter" völlig unpassend. Seit 2006 ist das Tag als Wetterschutz für Menschen definiert. Jetzt soll ein Anfang 2013 auf einer Unterseite eingetragenes Zusatztag die Bedeutung aufheben. Damit provoziert man Missverständnisse ähnlich wie bei "disused=yes". Wer bei Regen eine Schutzhütte sucht, möchte nicht vor einem eingezäunten Viehunterstand landen. Ich würde den Viehunterstand eher als Gebäude denn als "nützliche und wichtige Einrichtungen (amenity)" sehen. Warum nicht "building=field_shelter"? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Hallo Martin, Martin Koppenhoefer writes: Am 15. November 2013 03:24 schrieb Stephan Knauss : Für OSM müssen die Daten unter den Bedingungen der Contributor Terms freigegeben werden. Wobei das nicht so ganz klar ist, ob das überhaupt gehen kann, oder? Wenn man davon ausgeht, dass der virale Aspekt der Lizenz funktioniert, und weiterhin, dass alle Daten, die nicht in komplett leerer Umgebung erstellt wurden oder von externen Quellen importiert wurden, auch von ODbL Daten abgeleitet sind, dann haben die Mapper gar nicht mehr das Recht an "ihren" Daten, sondern diese sind von vornherein und ausschließlich ODbL (sozusagen von der Umgebung und dem Bestand in OSM "abgefärbt"), Ist das wirklich so? Wäre bestimmt mal eine interessante Frage für die Legal-Mailingliste oder eine Working group. Ich war bislang der Meinung, dass unsere Datenbank eben gerade nicht unter der ODbL steht. Die Daten gehören der Foundation, mit den Contributor Terms übertragen wir sie. Dadurch sind die abgeleiteten Daten auch nicht von ODbL sondern von anderen Daten abgeleitet für die die CT gelten. Anders wäre es doch auch garnicht möglich dass wir die Lizenz wechseln. Das was später unter der ODbL steht ist der Export der Daten, zum Beispiel als Planet file. Dadurch können auch Andere die Daten frei (unter den ODbL Bedingungen) nutzen. Einen Rückfluss von Änderungen zu OSM erlaubt das aber eben noch nicht, da sehen uns unsere eigenen CT im Weg. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Hallo Dirk und andere, Dirk Sohler writes: Alexander Lehner schrieb: wir haben von der Stadt Landshut Hausnummern erhalten und die mit ein paar kleinen Auflagen in OSM uebernehmen duerfen. Na ja, entweder die Daten dürfen unter der ODbL verwendet werden, oder nicht … Ein „dazwischen“ gibt es nicht. eventuell sind einige noch nicht so lange dabei um sich noch an das Drama wegen der Lizenzumstellung zu erinnern. Wir müssen alles tun um zu Verhindern dass wir in der Zukunft wieder größere Teile der Daten löschen müssen. Konkret: Daten die unter ODbL lizensiert sind sind eben NICHT mit OSM kompatibel. Für OSM müssen die Daten unter den Bedingungen der Contributor Terms freigegeben werden. Da steht dann auch zum Beispiel drin dass wir die Daten in der Zukunft auch unter einen anderen Lizenz veröffentlichen können wenn die Mehrheit dafür ist. Datensammlungen die nur unter der ODbL stehen erfüllen diese Anforderungen nicht und können daher auch nicht zu OSM hinzugefügt werden. Bitte beachtet das bei den Verhandlungen um Datenspenden. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, "Lübecker Methode")
Moin, für eine brauchbare Fahrradkarte genügt es offensichtlich nicht, wenn Straße und Radweg einzeln erfasst sind (siehe Mapnikkarte mit je nach Zoomlevel sichtbaren, halb überdeckten oder gar nicht sichtbaren straßenbegleitenden Radwegen). Auch für gutes Fahrradrouting muss man straßenbegleitende von eigenständigen Radwegen unterscheiden können. Mein Garmin-GPS hat mich teils vom Radweg auf die Straße und zurück auf den Radweg geschickt, um wenige Meter in der Kurve abzukürzen. Das Lübecker-Modell mit dem Tag "cycleway:*=sidepath", den Relation für eigenständige Radwege an Straßen und den "sidepath:refname=*" mit willkürlich gewählten Pseudonamen finde ich seltsam. Ich teile die von Rainer genannten Kritikpunkte. Wir sollten uns endlich eine bessere Lösung überlegen. Offenbar braucht man die Information, ob ein Radweg straßenbegleitend oder eigenständig ist, und umgekehrt, ob zu einer Straße ein Radweg als eigener way existiert. Dafür wäre je ein einfaches Tag ausreichend. Brauchen wir eine Relation, die alle Wegsegmente (Straße und Radweg) zusammenfasst? Brauchen wir eine explizite segmentweise Zuordnung straßenbegleitender Radwege zur Straße? Für straßenbegleitende Fußwege sollte das Modell natürlich auch anwendbar sein. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abkürzungen (bei Sportvereinen) im Namen
Am 14.10.2013 17:51, schrieb fly: Am 14.10.2013 17:32, schrieb Martin Koppenhoefer: Am 14. Oktober 2013 17:26 schrieb fly : Ich habe bisher diese Abkürzungen ausgeschrieben und wenn überhaupt name:de mit der Abkürzung geschrieben. Im Süd-Süd-Westen bin ich da aber wohl allein auf weiter Flur. Auch in Norddeutschland ist diese Interpretation sehr selten :-) M.E. sind da die meisten Vereine vor allem unter der Abkürzung bekannt, teilweise ist auch weitgehend unbekannt, was das überhaupt ausgeschrieben bedeutet, von daher finde ich die Abkürzung OK, ggf. könnte man beides eintragen (also entweder zusätzlich short_name oder zusätzlich official_name). +1 und was ist nun entscheidend oder gar keine name=* und nur short_name=* plus official_name=* mit den jeweiligen Übersetzungen ? Die übliche Namensform nach "name", bei Bedarf zusätzlich "short_name", "official_name" oder "alt_name". bei Ortsbezeichnungen wird es noch spannender, da meistens nicht genug Platz auf Schildern und Karten ist, wird in der Regel abgekürzt. Allerdings wenn ich nun oral nach dem Weg frage wird der Name komplett ausgesprochen. Auch hier sollte der am häufigsten benutzte Name als "name" erfasst werden. Das muss nicht der offizielle Name sein. Statt "Freie und Hansestadt Hamburg" spagt man meist nur "Hamburg". Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues Werkzeug für Sesselmapper
On 02.10.2013 18:25, Henning Scholland wrote: ein wirklich nützliches Tool, leider nicht meine Mappinggegend :( Daher auch gleich eine Frage bzgl. deiner Einschränkung. Willst du nicht mehr machen als Südostasien oder sind es technische Limits? Aktuell sind es eher technische Limits. Der Server auf dem das läuft ist ein vergleichsweise kleiner vServer und aktualisiert nur die Daten für Südostasien. Da ich keine zweite Datenbank pflegen und aktuell halten wollte beschränkt sich das darauf. In meinem Blog hatte ich etwas über die technischen Hintergründe geschrieben wie es umgesetzt ist. Für eine weltweite Umsetzung fürchte ich wird die Abfrage über die Datenbank zu lange dauern. Das müsste über eine eigene Abfrage gemacht werden. Ich denke ein kleines Osmium Programm könnte das recht schnell erledigen. Die Daten können dann importiert und gegen die Abdeckung verglichen werden. In vielen Gegenden wird das Ergebnis dann das gleiche sein wie das was bestehende Tools zu unverbundenen Wegen schon anzeigen. Mitteleuropa/Nordamerika hat einfach eine wirklich gute Abdeckung. Und das war ja genau das Spannende an dem Werkzeug, dass es die Punkte nicht anzeigt bei denen es schwierig ist etwas zu tun ohne bessere Daten zu haben. Aber prinzipiell technisch umsetzbar wäre es. Die Bing-Polygone zu haben ist dann das nächste Problem. Und es gibt in manchen Ländern auch noch andere Quellen. Vorerst fürchte ich daher wird es bei dem Bereich um Südostasien bleiben. Du kannst ja immer noch deine "Mappinggegend" an das Tool anpassen und in Laos oder Vietnam vom Luftbild mappen :) Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gelöschte Linien finden und wieder herstellen
Am 02.10.2013 16:35, schrieb fly: Wäre echt super, würde aber auch ganz schön viel Speicherplatz benötigen oder dachtest Du an live-rendern ? Nein, ich dachte nur eine eine API mit Datumsangabe. Der Server müsste "nur" den "full history dump" effizient filtern. Die Daten könnte man dann im Editor analysieren oder mit Maperitive rendern. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
