Re: [OSM-legal-talk] Adding OSM-ids to an external database and publish in CC-BY
Am 31.03.20 um 19:56 schrieb Martin Koppenhoefer: > In Italy we have been discussing this situation: a member of the community > wants to add links to OSM objects into a list of specific shops (those that > are open during the covid-19 pandemia). > > The list will be published here: https://www.covid19italia.help/opendata/ > with an CC-BY-4.0 license. > > The links will be of the kind https://www.openstreetmap.org/relation/1834818 > In decision C‑466/12 - Svensson and Others , the European Court of Justice stated: "[...] that the provision on a website of clickable links to works freely available on another website does not constitute an act of communication to the public, as referred to in that provision." > Question is, will it be possible to publish such a list, containing OSM-ids > (or links to OSM objects) with a CC-BY-4.0 license? > In my opinion, this case applies not only to links to works, but also to links to publicly accessible databases. Since links to database objects are not legally relevant duplication of the database, no license terms of the ODbL need to be observed in this case. Falk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Legal regulation of the use of OSM data
Am 12.03.20 um 16:54 schrieb Полина Новикова via legal-talk: > > Hello, everybody! > > Please deal with the issue of legal regulation of OSM data. > > If we collect data from your API in XML format or perhaps directly from the > front of the API in JSON format (is there any difference in this situation?). > The final format for displaying data is the pins of organizations in the > custom (our) design, which we place on a third-party map, with the ability to > do so under license. Users can find out what type of organization and what > kind of organization, filter organizations on the map, i.e., for example, > view only hospitals. We assume to take and reflect on the map only socially > significant objects on the map - schools, kindergartens, sports institutions, > hospitals and shops (a fairly small number of objects). Is this obvious > limits to the usefulness? > > If we allow to use the specified data on our site, which we put on a map, and > under the terms of the purpose is not to extract the data, but only for the > user to see these data, i.e. the goal is to bring it to the end user as shown > in the example with Garmin maps on the site at the link > https://wiki.openstreetmap.org/wiki/Open_Data_License/Produced_Work_-_Guideline > and it says it's Produced Work. In our situation, is this also a Produced > Work? > I am not sure if I understand the facts correctly. In general, however, one can say: If you query all "amenity = hospital" for a specific region, then this is a database extract from the OSM database for which section 4.4 of the ODbL applies. It does not matter whether the query is made by many individual queries or by a single large query. If you show the geographical position and the related information of "amenity = hospital" on a map, this display is a produced work. It is particularly important to note that if you use information from "amenity = hospital" from the OSM database with your own data and information about hospitals, then you create a "derivative database". In this case, section 4.6 of the ODbL also applies. The own data are then to be released on request (share alike)! > And I would like to clarify about attribution. The guideline states that we > should indicate that we are contributors and provide a link to distribution > under the ODbL license, on the other hand, for Produced Work in clause 4.3. > license ODbL is written a little differently and that is not consistent with > the logic written in guidline. Based on this, the question arises whether it > is enough that we specify that the map simply contains information from the > OSM as indicated at the beginning of paragraph 4.3? I agree with you that the FAQ does not properly fit the licensing terms in 4.3 of the ODbL. In particular, the descriptions in the FAQ do not do justice to the idea behind the attribution. You can choose your own license for a produced work, see section 4.5. b of the ODbL. A proprietary license is also possible for the produced work. The idea behind the attribution with the specification of the license refers to it. A proprietary license can prevent the user from reusing the produced work. The attribution and license information for the source should enable the user to create a comparable produced work from the open data. For this reason, the ODbL recommends stating the name of the database and the license in section 4.3a of the ODbL. I therefore recommend the following information: "Data: OpenStreetMap-Contributors (Open Database License)". In addition to the information on the data, a separate license can be added for the produced work: "Map design: (c) [name], license XYZ. Regards, Falk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] OSM auf den Chemnitzer Linux-Tagen (14.3.-15.3.)
Am Mo., 6. Jan. 2020 um 20:43 Uhr schrieb Michael Kugelmann via Talk-de : > > Am 06.01.2020 um 15:27 schrieb André Riedel: > > https://chemnitzer.linux-tage.de/2020/de > schade: findet am 14. und 15.3. 2019 statt und kollidiert somit leider > mit dem OSM-Samstag der FOSSGIS-Konferenz in Freiburg: > https://fossgis-konferenz.de/2020/ > https://wiki.openstreetmap.org/wiki/FOSSGIS_2020 bzw. > https://wiki.openstreetmap.org/wiki/FOSSGIS_2020/OSM-Samstag Dann kann es am OSM-Stand auf den Chemnitzer Linuxtagen eine Liveübertragung aus Freiburg geben :-) Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feature Proposal - Abstimmung von "Empfehlung zur Verwendung von Multipolygonen"
Moin, Am Mi., 19. Dez. 2018 um 17:38 Uhr schrieb Michael Reichert : > Am 19.12.18 um 13:30 schrieb Christoph Hormann: > > Ich muss sagen, dass ich ziemlich enttäuscht davon bin, dass mein > > zweimaliger Hinweis hier (in Antwort auf Nakaner vom 23.11. und in > > Antwort auf Tigerfell vom 27.11.) hinsichtlich der Nachvollziehbarkeit > > und Klarheit der Regeln insbesondere für neue Mapper kein Gehör fand. > > > > Unabhängig vom Abstimmungs-Ergebnis wird da so kein Community-Konsens > > draus, wenn selbst so offensichtliche und begründete Vorschläge mit > > keinerlei Potential für inhaltliche Konflikte keine Berücksichtigung > > finden. > > > > Und wenn dann Frederiks Einwände in der Abstimmung, die zum Teil in eine > > ganz ähnliche Richtung gehen, damit entgegnet werden, dass man sie doch > > früher hätte einbringen sollen (Duh! Siehe oben) dann deutet das für > > mich ein bisschen darauf hin, dass hier manche mehr die homogenen > > Ansichten einer kleinen Gruppe in die Welt exportieren wollen, als zu > > einem breiten Konsens zu kommen, den alle verstehen und den die > > allermeisten unterstützen können. > > Ich selbst finde die Regeln in ihrer derzeit zur Abstimmung stehenden > Form ebenfalls schlecht geschrieben und habe nur zähneknirschend > zugestimmt. Die Kritik ist aber berechtigt. > > Kritik mit "das hättest du auch früher sagen können" zu entgegnen, finde > ich nicht gut. Stattdessen sollte man die Abstimmung abbrechen und > zurück in die Entwurfsphase gehen. > Es wird immer so sein, dass es Punkte gibt, die einem persönlich nicht gefallen oder die man gern anders hätte. Ein Abstimmungsprozess ist durch das Gesamtpaket, das zur Abstimmung steht, auch immer eine Abstraktion von der eigenen Auffassung. Genau aus diesem Grund ist es auch immer einfach, über Politik zu schimpfen. Hier erleben wir am eigenen Leib, wie schwierig es ist, Kompromisse zu finden, die eine möglichst breite Zustimmung erfahren. > Wenn das Proposal durchfällt (74 Prozent Mehrheit sind nominell > erforderlich, aber bei 39 abgegebenen Stimmen ist die Abstimmung IMHO > nicht repräsentativ), werde ich ihm nicht nachweinen, sondern einen > zweiten, durchdachteren und besser begründeten Versuch starten. > Ich war eher positiv überrascht, dass überhaupt "so viele" eine Stimme abgegeben haben. Einen Überblick, was sonst so übliche Teilnehmerzahlen sind, habe ich aber nicht. Die "Repräsentativitätskeule" wird ohnehin immer von Gegnern eines proposals gezückt werden. Wir haben eben keine guten Mechanismen zur quantitativen Meinungsforschung. Das Argument der "Nichtrepräsentativität" funktioniert also faktisch immer. Als qualitativ nutzbares Meinungsbild taugt die Abstimmung zumindest im Ansatz. Es ist in der Regel immer zu wenig Zeit für ein perfektes Proposal. Entweder man stimmt zeitnah ab oder es verläuft sich im Sande, bis eine neue Diskussion los brandet, weil alle mit dem Istzustand unzufrieden sind. Das Proposal ist ein WEg weg vom Istzustand. Das unser Meinungsfindungsverfahren mit ihren Abstimmungsprozessen nicht besonders gut sind, ist bekannt. Wir haben leider bisher nichts besseres. Ich fände es toll, wenn man ein Verfahren hätten, bei dem Beispielsweise alle, die in einem bestimmten Zeitraum ein relevantes Objekt bearbeiten oder erstellen (z.B. Polygon) zur Abstimmung aufgefordert würden. Dann hätte man zumindest von denen, die damit arbeiten, ein repräsentatives Meinungsbild. Dann könnte man die Gesamtstimmungslage zu einem Proposal besser einfangen. > @Tigerfell Denk mal bitte darüber nach, ob du das hier so wirklich > durchziehen möchtest oder du nicht auch einen Abbruch für sinnvoll > erachtest. > Das Ergebnis wird nicht repräsentativer, wenn wir nochmal darüber abstimmen. Ob das überhaupt gelingt, weil bei Formulierungsänderungen ggf. auch neu diskutiert werden muss, ist für mich ohnehin fraglich. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] service=driveway für alles was service ist?
Am Mi., 28. Nov. 2018 um 08:19 Uhr schrieb Florian Lohoff : > Hi, > ich habe eine Diskussion zum Thema highway=service/service=driveway > angezettelt weil [...]. > > Ich halte das für falsch - [...]. > > In https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dservice > ist das 2016 geändert worden von: > > "Ein driveway ist eine Auffahrt. Damit ist oft eine private > Zufahrtsstraße gemeint, die zu einem Haus oder einer Firma führt." > > zu > > "Zufahrtsweg zu einem Wohn-, Geschäfts- oder Firmengrundstück" > > Letzteres ist Sprachlich natürlich schöner, ist aber in der Bedeutung > nicht identisch zu ersterem. > > "Auffahrt" ist eher was ich als sub 100m bezeichne. Kleine Stiche auf > die Grundstücke. Nicht alle Wege auf einem IKEA Gelände oder > 300m lange Zufahrten zu farmyards. > > Genau so wird das aber gerade interpretiert. Quasi alles was irgendwie > mal als Zufahrt zu irgendwas dienen kann ist jetzt ein driveway. > > Meinungen? > > Dein Verständnis zu driveway deckt sich mit dem meinigen. Das sind auch für mich kurze Wege/Straßen, die als Zufahrt auf Grundstücke dienen (und keine darüber hinausgehende Erschließungsfunktion für das Grundstück haben). Auch aus kartographischer Sicht macht das Sinn. Aus den Karten lassen unsere OpenStreetMap Kartographen den driveway deutlich früher verschwinden, als einen normalen highway=service. Kurze Auffahrten zu Wohngrundstücken ballern nur unnötig die Karte zu (weil wir Straßen von der breite her Überproportional zur tatsächlichen Breite darstellen) und liefern keinen Mehrwert. Längere Straßenstücke auf Firmengeländen haben einen darüber hinausgehenden Informationswert, weil sie länger sind und eben Parkplätze oder Gebäude straßentechnisch verbinden. service=driveway sollte also kein Fülltag für highway=service sein, dem ein Subtag fehlt. Soweit meine Meinung dazu. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen/Wege // Trolling in changesets
Ich möchte das ganze im Folgenden versuchen ein wenig auf eine Meta-Ebene zu heben, möchte aber nicht verhelen, dass ich auf highway=value geklebte landuse=value nicht mag bzw. ablehnend gegenüber stehe. Aber auch ich habe mal als "Verkleber" angefangen: Abgesehen von der Sinnhaftigkeit (keine Metaebene) gibt es auf der Metaebene folgende Aspekte: 1. Durch die snap-Funktion im JOSM lassen landuse und highway viel leichter verbinden, als wieder trennen. Dadurch haben die "Verschmelzer" beim Mappen einen taktischen und zeitlichen Vorteil gegenüber den "Trennern". 2. Das getrennte erfassen erfordert mehr Genauigkeit. Man muss viel weiter hineinzoomen, um Flächen zu erfassen, damit man nicht selbst "Opfer" der snap-Funktion von JOSM wird. Man hat also einen kleineren Kartenausschnitt auf dem Bildschirm. Hierdurch benötigt man mehr Zeit und muss trotzdem aufpassen (wegen der snap-Funktion). Auch Mapper sind sind nur Menschen, also bequem und möchten trotzdem viel pro Zeiteinheit schaffen. Auch das ist ein strategischer Nachteil der getrennten Erfassung. Die Verschmelzer sind faktisch im Vorteil, weil sie mehr pro Zeiteinheit Mappen können. Dann können sie ggf. auch noch sagen, "Seht her, in den Daten ist viel mehr verklebt als getrennt! Wir sind die Mehrheit, wir haben Recht!" 3. Durch das verschmelzen sieht die Datenbasis im JOSM auch besser -- weil aufgeräumter wirkend -- aus, als mehrere parallele Linien. Man sollte diesen ästhetischen Aspekt nicht vernachlässigen. Wir sind ein Projekt, das von Laien getragen wird. Da spielen solche Aspekte eine viel größere Rolle, als in einem professionellen Umfeld mit festgefügten Regeln und Normen (wir müssen Regeln und Normen erst finden und ständig darüber diskutieren). 4. Menschliches Beharrungsvermögen: Niemand gibt gern Gewohnheiten auf. Warum sollte also ein "Verschmelzer" sich ändern? Zumal der Verschmelzer merkt, dass die andere Methode aufwendiger ist und mehr Sorgfalt erfordert. (Vielleicht liegt die Sorgfalt auch nicht so in seiner Natur, wogegen die "Trenner" eher von pingeliger Natur sind). 5. Eine eigene Ausprägung von Beharrungsvermögen ist: Die Arbeit des "Verschmelzers", das Verschmelzen, wird ein Stück weit entwertet, wenn jetzt immer getrennt werden soll. Niemand sieht seine Arbeit gern entwertet und wird daher immer alles versuchen, diese zu erhalten und gegen Änderungen zu verteidigen. 6. Eine weitere Ausprägung des Beharrungsvermögens findet sich auch bei der Regeldiskussion "das ist so nicht/anders Dokumentiert". Einerseits sind Regeln sehr wichtig, weil erst sie eine Basis geben, auf der man gemeinsam arbeiten kann. Andererseits ändern sich die Gegebenheiten, auf denen die Regeln basieren. Vor fünf Jahren war man froh ein einigermaßen vollständiges Straßennetz (DE) zu haben. Da wollte man nicht über Straßenflächen diskutieren und gab sich entsprechende Regeln. Doch warum sollen die Regeln heute noch gelten? Die Regeln bei OSM sind ja nicht die (universell gültigen) Menschenrechte. Also: geänderte Situation, geänderte Regeln. Das Problem: Man erkennt quasi immer nur in der Retrospektive, ob sich die Situation tatsächlich geändert hat. Da also niemand aus der Zukunft zurückblicken kann, entstehen solche langen Threads zwischen "Verklebern" und "Trennern". Daraus folgt für mich auf der Handlungsebene: Bei den Punkten 1. bis 3. muss auf Ebene der Werkzeuge zunächst Waffengleichheit zwischen Verklebern und Trennern hergestellt werden! Bei den Punkten 1. bis 3. wünsche ich mir einfach einen mutigen Entwickler, der eine Warnung einbaut, wenn landuse als Fläche und highway als way miteinander verbunden werden sollen. Problem: Wir zeichnen erst die Geometrie und geben dann die Eigenschaften/Tags. Aufgrund meiner Grundauffassung sollte das überhaupt nicht möglich sein bzw. um den Verschmelzern nicht auf die Füße zu treten nur als "opt in". Dann wäre zumindest was die Schwierigkeit angeht einigermaßen Waffengleichheit hergestellt und neue Mapper kommen nicht mehr so leicht in Versuchung zum "Verkleber" zu werden. Eine schöne Lösung wäre es auch, wenn die snap-Funktion bei highways nicht funktionieren würde (zumindest nicht für ways, die noch keine Tags haben und generell nicht für landuse auf highway). Wichtig ist, dass man das snap-Verhalten von landuse auf highway (way) in der Grundfunktion abstellt, damit die Leute gar nicht erst "klebstoffsüchtig" [Entschuldigung für den Kalauer] werden. Dann stellen sich die Probleme aus Nr. 4 bis 6 nicht in gleichem Maße. Dann erledigt sich das Problem in einem gewissen Maß von selbst. "Es wächst sich raus." Eine andere Möglichkeit ist es endlich handliche Tools zu entwickeln, die das Entkleben genauso einfach machen, wie das Verkleben. Das hat aber die große Gefahr von "edit wars". An den Punkten 4. bis 6. kann man ansonsten in einem Freiwilligenprojekt nicht viel ändern, außer vielleicht, das die Beteiligten selbst Reflektieren, mal was anderes ausprobieren und dann zu dem Ergebnis kommen "ist ja gar
Re: [Talk-de] Navads-Tankstellenimport
Am 29. März 2018 um 00:27 schrieb Tom Pfeifer: > Wenn ich eine lokale Tanke herangezoomt habe, und als "good" bestätige, > werde ich mit Überlichtgeschwindigkeit an einen anderen Ort in DE gebeamt, > von dessen Existenz ich bisher nicht einmal geahnt habe. Das folgende Vorgehen löst das Problem: 1. auf http://audit.osmz.ru/profile gehen 2. ggf. einloggen, 3. ein Rechteck über die Region ziehen, die man begutachten möchte 4. return -- man kommt (wieder) auf die Einstiegsseite mit den zu validierenden Importen (http://audit.osmz.ru/) 5. wenn man nun "NavAds Fuel Stations Import (Germany)" auswählt 6. erscheinen nur noch Einträge aus dem unter 3. gewählten Bereich Ich hoffe das macht es leichter. Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navads-Tankstellenimport
Am 29. März 2018 um 00:27 schrieb Tom Pfeifer <t.pfei...@computer.org>: > On 28.03.2018 23:06, Falk Zscheile wrote: >> >> Am 28. März 2018 um 21:58 schrieb Harald Hartmann >> <osm-talk...@haraldhartmann.de>: >>> >>> Hmm, geht's wohl schon in die nächste Runde? >>> >>> weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de >> >> >> Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node >> sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die >> Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll >> vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft >> wurden, gibt es auch :-) > > > Wenn ich eine lokale Tanke herangezoomt habe, und als "good" bestätige, > werde ich mit Überlichtgeschwindigkeit an einen anderen Ort in DE gebeamt, > von dessen Existenz ich bisher nicht einmal geahnt habe. Ich habe Ilya eine Mail geschrieben, mit der Bitte, dieses Rouletteverhalten abzustellen bzw. eine entsprechende Option zu implementieren. > Nach lokaler > Überprüfung sieht das dann nicht mehr aus. > Es ist noch nicht perfekt. Aber gegenüber dem ursprünglichen Plan ist das ein riesiger Fortschritt und die Umsetzung ist sehr schnell erfolgt. Ich finde schon, dass das einen gewissen Vorbildcharakter hat. Wir haben schon immer Mapper, die über die ganze Republik nach Fehlern suchen und berichtigen. Wichtig ist, dass lokale Kontrolle möglich ist. Vielleicht motiviert es ja den einen oder anderen Mapper, bei widersprechenden Öffnungszeiten noch einmal vor Ort zu kontrollieren. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navads-Tankstellenimport
Am 28. März 2018 um 21:58 schrieb Harald Hartmann: > Hmm, geht's wohl schon in die nächste Runde? > > weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de > Vielen Dank für den Hinweis. Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft wurden, gibt es auch :-) Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navads-Tankstellenimport
Moin, wenn es auf eine ja/nein Entscheidung (also ohne Kompromissmöglichkeiten) hinaus läuft, dann hast du für den Text meine Rückendeckung. Ansonsten ist die Darstellung ja schon so ausgefuchst, dass es für den Importwilligen möglich sein sollte, an die einzelnen Daten eine Auswahlmöglichkeit für deutsche Mapper hinzuzufügen: ja, bitte importieren, nein, dieses Datum nicht importieren (weil irgendetwas nicht stimmt). Ein Großteil der Daten passt ja vermutlich, so das eine opt in Lösung für mich ein guter Kompromiss für Deutschland wäre. Wir sind eine so große Community, dass der Datensatz sicher in kurzer Zeit geprüft und dann fit für den Import wäre. Falls er von den Mappern nicht geprüft wird, also keine Freigabe für die einzelnen Daten erfolgt, dann wäre das eine Abstimmung mit den Füßen, dass man den Import nicht wünscht. Gruß Falk Am 27. März 2018 um 23:10 schrieb Michael Reichert: > Hallo, > > Am 26.03.2018 um 23:50 schrieb Michael Reichert: >> Falls euch solche oder andere Fehler auffallen, so meldet euch bitte >> hier oder direkt auf der Imports-Mailingliste. > > ich bin euch für eure Kommentare und Fehlermeldungen sehr dankbar. Wenn > ich die Community vertreten würde, würde ich meine Auflistung der > gefundenen Fehler mit folgenden Worten abschließen: > >> (Zusammenfassung eurer Kommentare und Fehlerberichte) >> >> German POI data is not complete and will never be complete. We welcome help >> to improve the POI data in Germany. However, the quality of the import does >> not meet our expectations. We ourselves have also areas which do not have >> active mappers who take care for their area. Therefore, errors introduced by >> the import in this area will not be fixed. In addition, it is not the task >> of us, the *volunteers*, to fix a commercial dataset. >> >> *This import is against the interests of the German OSM community* Providing >> a list or a diff between the Navads dataset and OSM is welcomed and will >> help us to improve our work without increasing the burden for the manager of >> the import to invest more work into fixing all the errors of the data and >> the software. >> >> Best regards >> >> Michael Reichert aka Nakaner >> after discussion and on behalf of the German OpenStreetMap community on the >> German OSM Forum and the Talk-de mailing list > > Deutsche Übersetzung: >> (Zusammenfassung eurer Kommentare und Fehlerberichte) >> >> POI-Daten sind auch in Deutschland unvollständig und werden unvollständig >> bleiben. Wir begrüßen Unterstützung bei der Verbesserung des >> POI-Datenbestands in Deutschland. Trotzdem entspricht die Datenqualität des >> Imports nicht unseren Erwartungen. Wir selbst haben auch Gegenden ohne >> aktive Mapper, die sich um ihre Gegend kümmern. Daher werden Fehler, die der >> Import mit sich bringt, nicht behoben werden. Außerdem ist es nicht die >> unsere Aufgabe als *Freiwillige* den Datenbestand eines kommerziellen >> Anbieters zu verbessern. >> >> *Dieser Import ist gegen die Interessen der deutschen OSM-Community*. Das >> Anbieten einer Liste oder der Unterschiede zwischen dem Navads-Datenbestand >> und OSM ist gern gesehen und hilft uns, unser Werk zu verbessern, ohne die >> Aufwand des Importmanagers in die Verbesserung der Daten oder der Software >> zu erhöhen. >> >> Viele Grüße >> >> Michael Reichert aka Nakaner >> nach Diskussion und im Namen der deutschen OpenStreetMap-Community im >> deutschen OSM-Forum und auf der Mailingliste Talk-de > > Fühlt sich jemand von diesen Worten nicht ausreichend repräsentiert? > Vertritt jemand eine abweichende Meinung und möchte diese kundtun? > Verbesserungsvorschläge für diese Zusammenfassung sind ausdrücklich > willkommen. > > 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] Navads-Tankstellenimport
Hier liegt ein Fehler vor (keine Tankstelle vorhanden). Etwas weiter im Nordwesten gibt es eine Tankstelle in meiner Erinnerung ist das aber nicht Aral: http://audit.osmz.ru/browse/navads_fuel/NVDS114_27007300DE1 Hier passen name (Jet) und das neu hinzugefügte brand (avia) nicht zueinander: http://audit.osmz.ru/browse/navads_fuel/NVDS126_3243 Zudem scheint der Import auch Betriebs- oder Firmentankstellen mitzubringen, aber das lässt sich aus der Ferne nur schwer sagen. Für mich sehen diese Stellen aus der Ferne nach LKW-Diesel Stationen aus, die nicht zwingend öffentlich zugänglich sein müssen: http://audit.osmz.ru/browse/navads_fuel/NVDS126_3043 (Gelände der "Regionalbus Rostock") http://audit.osmz.ru/browse/navads_fuel/NVDS126_3243 http://audit.osmz.ru/browse/navads_fuel/NVDS126_3042 Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenMetroMaps - Ideenwerkstatt am 11. Februar 2018 in Berlin
Moin, Am 7. Februar 2018 um 09:20 schrieb Frederik Ramm: > On 02/05/18 19:14, Stefan Kaufmann wrote: >>> Bei OSM sind wir da >>> anderer Meinung, schließlich beanspruchen wir sogar Schutzrechte auf >>> unsere Faktensammlung (und in Europa gibt es diese Rechte auch). >> >> „Wir“ finde ich eine etwas sportliche Aussage. Ich z.B. finde diese >> Haltung gefaehrlich. > > Ja, natürlich gibt es in OSM eine große Breite verschiedener Meinungen. > Die Meinung, die sich am Ende eines rund fünf Jahre dauernden Prozesses > durchgesetzt hat und die OSM als Projekt daher vertritt, ist allerdings > die, dass unsere Daten als Datensammlung ein Schutzrecht geniessen, das > wir mit Hilfe unserer ODbL-Lizenz gestalten. > > Wer sich näher für des Schutz der OpenStreetMap-Daten als Datenbank (Datenbankherstellerrecht) und deren lizenzrechtliche Handhabung durch die ODbL interessiert, der ist herzlich in meinem Workshop zur ODbL auf der diesjährigen FOSSGIS-Konferenz eingeladen: https://www.fossgis-konferenz.de/2018/programm/event.php?id=5269 Viele Grüß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Chemnitzer Linuxtage 2018
Moin, kann jemand sagen, ob mittlerweile eine Anmeldung von OSM für die CLT 2018 erfolgt ist? Viele Grüße Falk Am 5. Januar 2018 um 08:49 schrieb André Riedel: > Hallo Lars, > > ich hatte in den letzten Jahren immer die Anmeldung organisiert. In > diesem Jahr soll es natürlich auch wieder einen Stand geben, die > Anmeldung wird fristgerecht eingereicht. > > Wer möchte darf sich gern für einen Betreuungsstand melden. Die > meisten Fragen kommen zu Themen, wie etwas gemappt wird oder was es > neues gibt. Die tiefergehenden Fragen können dann gern an die > „Spezialisten“ verwiesen werden, das hat in den letzten Jahren gut > funktioniert. Man muss nicht die ganze Zeit am Stand sein, jeder wird > die Chance haben interessante Vorträge zu besuchen. Als Dankeschön > gibt es von den Chemnitzer Linuxtagen am Samstag Abend ein tolles > Buffet mit allen bekannten Gesichtern der OSS-Welt. > > Beste Grüße > André > > Am 29. Dezember 2017 um 00:50 schrieb lars lingner : >> Hallo zusammen, >> >> auf dem 34C3 wurde ich heute gefragt, warum von OSM bisher keine >> Anmeldung für die Chemnitzer Linuxtage 2018 [1] kam. Die Frage konnte >> ich nicht beantworten und ich muss gestehen, ich war auch noch nie dabei. >> >> Es wäre laut OSM-Wiki [2] das 10. Jahr mit OSM-Beteiligung. Irgendwie >> muss OSM auch einen positiven Eindruck hinterlassen haben, wenn man auf >> eine fehlende Anmeldung hingewiesen wird. >> >> Besteht denn Interesse einen Stand auf den CLT zu haben? Gibt es Hürden? >> Wird Hilfe benötigt? >> >> Eine Anmeldung ist noch bis 08.01.2018 möglich. >> >> >> Viele Grüße vom 34C3, >> >> Lars >> >> >> [1] https://chemnitzer.linux-tage.de >> [2] http://wiki.openstreetmap.org/wiki/Chemnitzer_Linux-Tage_2017 > > ___ > 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] OSGeo/FOSSGIS/OSM-Stand auf der FrOSCon
Moin, ich möchte im Folgenden eine kurze Rückmeldung vom OSGeo/FOSSGIS/OSM-Stand auf der diesjährigen FrOSCon geben. Der Aufbau des Standes wurde von unseren Organisatoren der OSGeo & OSM Subkonferenz gleich mit erledigt. Als ich am späten Nachmittag hinzukam, war schon fast alles ferig "aufgetischt". Die Standbetreuung wurde am Samstag im wesentlichen von Astrid, Harald und mir übernommen, wobei Astrid später ins Videoteam für die Subkonferenz wechselte. Die Fragen zu FOSS haben wir dann nach bestem Wissen und Gewissen beantwortet, denn der Wissensschwerpunkt am Stand lag nach dem Wechsel eindeutig im Bereich OSM. Am Sonntag waren dann Harald und ich wieder für Fragen der Besucher am Stand bevor Harald allein das Zepter übernahm, weil mich das Abenteuer einer langen Bahnreise rief ... Das Interesse an der Arbeit von OpenStreetMap ist nach meinem Eindruck ungebrochen. Die Gespräche und Nachfragen am Stand hatten ein sehr weites Spektrum, dass von "Was macht ihr eigentlich?", "Wie weit seid ihr inzwischen? Ich habe vor Jahren auch mal etwas beigetragen.", bis hin zu ganz konkreten Fragen zum Taggig oder zur Anwendung der Daten/Karten ging. Aber auch Fragen wie: "Warum bietet ihr nicht den gleichen Service wie Google?" waren dabei. Für mich hat sich hierbei gezeigt, dass OpenStreetMap einen so breiten Anwendungsbereich hat, dass es unmöglich ist, bei allen Themen so umfassend zu antworten, wie man es eigentlich möchte. Hier hat sich gezeigt, dass die Arbeit, die das Videoteam seit Jahren auf den FOSSGIS-Konferenzen leistet (danke!), Gold wert ist. Den Fragestellern konnte ich dann zumindest mit dem Verweis auf die eine oder andere Viedeoaufzeichnung weiterhelfen. Die OSM-Flyer und die Karten mit der Ankündigung der FOSSGIS-Konferenz in Bonn waren bereits am ersten Tag vergriffen aber zum Glück gibt es Smartphones. So fand die Verbreitung der Informationen am zweiten Tag auf digitalem Weg durch Abfotografieren statt. Für mich war es die erste Standbetreuung für FOSSGIS/OSM. Schon allein für die vielen positiven Rückmeldungen, die zum Projekt am Stand ankamen, hat es sich gelohnt, dabei zu sein. Auch wenn wir intern oft mit uns hadern, weil es scheinbar nicht schnell genug oder nicht "richtig" voran geht -- von außen werden wir als durchaus erfolgreich wahrgenommen. Ich kann also jedem, der gerade mal wieder mit sich und dem Projekt hadert, eine solche Standbetreuung empfehlen. Die Rückmeldungen zeigen, dass sich die Beiträge aller Beitragenden (vom Kritiker über den Macher bis hin zum Beharrer) lohnen und dass die so entstandenen Ergebnisse außerhalb der Community große Anerkennung erfahren. Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nautische Sperrgebiete [war: Farbe des Meeres in OSM-Carto]
2. Anstatt von military als Schlüssel evtl navy verwenden, also navy=danger_area 3. Den der gewarnt wird/für den es gefährlich wird als Schlüssel verwenden: mariners=danger_area danger_area=military (orientiert an aviation=danger_area) Im Ergebnis würde mir das OSeaM Tag völlig reichen, aber Puristen werden hier einwenden, das OSeaM ein eigenes extravagantes von OSM abweichendes Taggingschema verwendet. Aber wenn es hilft doppeltes Tagging unnötig zu machen und gleichzeitig kartographische Sündenfälle vermieden werden können -- dann bekommt es meinen Segen. Man muss das Rad ja nicht doppelt erfinden. Gruß Falk Gruß Falk Am 16. August 2017 um 14:59 schrieb Falk Zscheile <falk.zsche...@gmail.com>: > Es läuft ja darauf hinaus, dass wir das verwendete > military=danger_area für Seegebiete ablösen, weil es dort (anders als > an Land nicht passt). durch ein anderes Tag kann man das bei OSM zum > Ausdruck bringen. > > Mir Fallen die folgenden Lösungen ein: > > 1. Löschen von military=danger_area und ausschließlicher Rückgriff auf > das OSeaM-Tag seamark:restricted_area:category=military > > > Am 15. August 2017 um 16:55 schrieb chris66 <chris66...@gmx.de>: >> Am 15.08.2017 um 16:46 schrieb Markus: >> >>> Für das Rendering in Seekarten gibt es international genormte Icons und >>> Farben. >> >> >> Danke für die ausführliche Info. >> >> Nun ist die Frage, das bestehende Tagging (military=danger_area) so belassen >> oder durch was anderes zu ersetzen, zB.: >> >> military=restricted_area oder >> seamark:xxx=yyy (falls es bei den Kollegen schon was gibt). >> >> Chris >> >> >> >> >> >> ___ >> 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] Nautische Sperrgebiete [war: Farbe des Meeres in OSM-Carto]
Es läuft ja darauf hinaus, dass wir das verwendete military=danger_area für Seegebiete ablösen, weil es dort (anders als an Land nicht passt). durch ein anderes Tag kann man das bei OSM zum Ausdruck bringen. Mir Fallen die folgenden Lösungen ein: 1. Löschen von military=danger_area und ausschließlicher Rückgriff auf das OSeaM-Tag seamark:restricted_area:category=military Am 15. August 2017 um 16:55 schrieb chris66: > Am 15.08.2017 um 16:46 schrieb Markus: > >> Für das Rendering in Seekarten gibt es international genormte Icons und >> Farben. > > > Danke für die ausführliche Info. > > Nun ist die Frage, das bestehende Tagging (military=danger_area) so belassen > oder durch was anderes zu ersetzen, zB.: > > military=restricted_area oder > seamark:xxx=yyy (falls es bei den Kollegen schon was gibt). > > Chris > > > > > > ___ > 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] Farbe des Meeres in OSM-Carto
In der Ostsee gibt es ein ähnliches kartographisches "Ärgernis": http://www.openstreetmap.org/way/173480188#map=10/54.3993/14.0570=N 2017-08-15 13:30 GMT+02:00 Hartmut Holzgraefe: > name=Danger Area Sylt A > > Das dürfte seinen Grund haben warum das rot ist.. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. Kartographisch ist es auf jeden Fall nicht schön, weil viel zu prominent dargestell. Das Verbot (wenn überhaupt, s.u,) richtet sich nur an die Schifffahrt. Was an Land als Sperrgebiet bei dieser Kartendarstellung Sinn macht, macht es noch lange nicht auf hoher See. Bei OSM kann man sich über das richtige Tagging ja vortrefflich streiten, ohne zu einem Ergebnis zu kommen. Meines erachtens ist es nicht nur kartographisch unschön dargestellt, sondern auch tatsächlich falsch. militay=danger_area soll ja so etwas wie ein Gebiet mit schwerpunktmäßig militärischer Nutzung und korrespondierender Verbote für zivilisten markieren. Dagegen spricht meines Erachtens, dass sich die danger_area teilweise außerhalb der 12 Seemeilenzone befindet. Dort gibt es keine Staatsgewalt, die einem das Betreten oder Befahren einfach mal so verbieten kann. Und auch innerhalb der 12 Seemeilenzone besteht das Recht der friedlichen Durchfahrt. Ein tagging was in Richtung gesperrtes oder verbotenes Gebiet geht, ist daher meines Erachtens nicht haltbar. Zudem laufen ganz reguläre Fährlinien durch diese Gebiete (in der Ostsee). Würde es sich um gesperrte, verbotene oder besonders (lebens-) gefährliche Gebiete handeln, dann wäre dass kaum der Fall. Auch ein Blick in OpenSeaMap zeigt anhand der Betonnung und der Fahrzeuge (AIS), dass es sich im Grunde um normal genutztes Seegebiet handelt. Die Bekanntmachungen für Seefahrer, durch welche diese Gebiete eingerichtet/bekannt gemacht wurden kann ich leider nicht mehr finden. Grob umschrieben sind es (wohl) Gebiete, in denen potentiell militärische Übungen stattfinden können und dann besondere Aufmerksamkeit durch die Schifffahrt geboten ist, mehr aber auch nicht. Vielleicht wissen die eingefleischten OpenSeaMapper mehr dazu? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Drei Tage mit dem Plug-In Hybrid
Am 30. März 2017 um 14:14 schrieb Harald Hartmann: > Am 30.03.2017 um 09:17 schrieb Uwe Sennewald: >> Habt ihr schon mal was von LEMnet ( http://www.lemnet.org/de ) gehört ? >> Die nutzen OSM , müllen es aber mit den Informationen zu den >> Ladestationen nicht voll. > > Hmm, und in wie weit nutzen die OSM? Also die ersten Stickpunkte die ich > so gemacht habe, lässt den Eindruck erwecken, dass sie NUR einfach eine > OSM Karte (Tiles) verwenden, von den angezeigten POIs > (amenity=charging_station, etc.) war kein einziger in der OSM Datenbank. > Wenn ich Uwes E-Mail richtig verstanden habe, dann soll es gerade ein großer Vorteil von LEMnet sein, dass die Ladesäulen außerhalb der OSM-Datenbank gepflegt werden. Da kann man sicher unterschiedlicher Ansicht sein ... Auf der FOSSGIS 2017 gab es einen interessanten Vortrag zu der Frage, wo Ladesäulen im Idealfall errichtet werden sollten: https://www.fossgis-konferenz.de/2017/programm/event.php?id=5185 Das löst natürlich leider das aktuelle Ladesäulenproblem nicht im geringsten ... Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mobile Verkaufsstände
Moin, ich stelle mir gerade vor, wie das in der Datenbank aussieht, wenn dort Montags der Hähnchengrill steht, Dienstags der Fischhändler ... Dann gibt es neben dem Wochenmarkt noch den Oster-, Pfingst- und Weihnachtsmarkt, die auch alle key=intermittent sind. Eine gewisse dauerhafte Verbundenheit mit der Erdoberfläche sollten unsere (Geo-)Daten schon haben. Ich würde daher derlei bewegliche aber regelmäßig wiederkehrende Verkaufsstände nicht in der Datenbank erfassen. Gruß Falk Am 13. Juli 2016 um 11:27 schrieb Carl von Einem: > Hi, > > auch Wochenmärkte [1] sind nur einmal wöchentlich für ein paar Stunden in > Betrieb, und ausserhalb der Zeit deutet an der Stelle nichts darauf hin. > Meistens auf einem Platz oder am Rand einer Strasse, aber teilweise ist dann > sogar die entsprechende Strasse in der Zeit für die Verkaufswägen gesperrt. > > Und Wochenmarkt-Händler sowie Hendlgriller dürften langfristige > Genehmigungen für Stellplatz und Betriebszeit von der jeweiligen Kommune > haben. > > Dann gibt es noch Bücherbusse [2] und sogar mobile Bankfilialen, die ähnlich > kurze, aber regelmässige Öffnungszeiten an einem festgelegten Ort haben. > > Und als "tag, der signalisiert, dass das Teil da in 95% der Zeit in der man > vorbeikommt überhaupt nicht anzutreffen ist", würde ich opening_hours > vorschlagen. > > Gruss, > Carl > > [1] https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dmarketplace > [2] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dmobile_library > > Sven Geggus wrote on 13.07.16 10:37: >> >> Moin, >> >> in meinem Umfeld hat jemand einen mobilen Hähnchengrill als >> amenity=fast_food erfasst. >> >> Ich selbst habe das Teil an dieser Stelle noch nie gesehen, was wohl daran >> liegt, dass ich selten Mittwochs zwischen 11Uhr und 19Uhr an dieser Stelle >> vorbeikomme. >> >> http://www.openstreetmap.org/node/3630432095 >> >> Nun frage ich mich ob sowas überhaupt in die Datenbank gehört. >> >> Wie seht ihr das? >> >> Wenn ja, gibt es einen Tag, der signalisiert, dass das Teil da in 95% der >> Zeit in der man vorbeikommt überhaupt nicht anzutreffen ist? >> >> Sven >> > > ___ > 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] Verwendung von Markenlogos in Karten?
Am 11. Juni 2016 um 14:20 schrieb gmbo: > Am 11.06.2016 um 13:21 schrieb Eifelhunde: >> >> >> >> Am 08.06.2016 um 16:33 schrieb Sven Geggus: >>> >>> Nun sind dies Logos aber natürlich alles registrierte Marken das heißt es >>> dürfte illegal sein, diese in einer öffentlichen karte zu verwenden. >> >> >> Wikipedia verwendet die auch über die Jahre ohne das sich wer beschwert >> hat. >> > > In Wikipedia dürfen die Logos nur dort verwendet werden, wo der Artikel > eindeutig nur über die Marke geschrieben ist. Also ein eindeutiger > Zusammenhang zur Marke besteht. > > Da ist es bei der Karte nicht so einfach. Im Normalfall wird das Markenlogo > zwar richtig verwendet, aber Wie ich scon schrieb müsste dann wirklich > Eindeutigkeit herschen. > Und die ist bei unserem Tagging nicht gegeben. > Wir können nicht unterscheiden ist es Aldi Nord oder Süd. Gut hier wäre es > möglich beide Logos zu einem zu machen. > Bei Netto und Netto Marken Discount geht es aber nicht. > Hallo, ob eine Marke ohne Lizenz/Gestattung des Markeninhabers genutzt werden darf, das richtet sich im vorliegenden Fall nach § 23 MarkenG: "Der Inhaber einer Marke oder einer geschäftlichen Bezeichnung hat nicht das Recht, einem Dritten zu untersagen, im geschäftlichen Verkehr [...] 2. ein mit der Marke oder der geschäftlichen Bezeichnung identisches Zeichen oder ein ähnliches Zeichen als Angabe über Merkmale oder Eigenschaften von Waren oder Dienstleistungen, wie insbesondere ihre Art, ihre Beschaffenheit, ihre Bestimmung, ihren Wert, ihre geographische Herkunft oder die Zeit ihrer Herstellung oder ihrer Erbringung, zu benutzen, [...] sofern die Benutzung nicht gegen die guten Sitten verstößt." http://www.gesetze-im-internet.de/markeng/__23.html Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wahlbezirksgrenzen als boundary/administrative
Am 15. April 2016 um 00:32 schrieb Frederik Ramm: > Hi, > > On 04/14/2016 12:51 PM, Florian Lohoff wrote: >> Irgendwie finde ich das mit dem boundary=administrative ziemlich >> unglücklich. Auf der einen Seite ist das natürlich richtig das das >> "Administrative" Grenzen sind - aber ich vermute das OSMAnd >> jetzt nicht der einzige ist der sich da verwirren lässt. > > Wenn's nach mir geht, raus mit dem Mist. Verwaltungsgrenzen und > PLZ-Gebiete kann ich noch einsehen. Aber Wahlkreise, > Grundschuleinzugsgebiete, Kirchengemeindegrenzen, das Sendegebiet vom > NDR und das Liefergebiet vom Pizzadienst sind Grenzen, die in OSM nichts > zu suchen haben. > Einmal angenommen bei OSM kommen wir zu dem Konsens, dass derlei Daten nicht in die OSM-Datenbank sollen, es aber eine relevante Gruppe gibt, die solche Daten erheben und pflegen möchte -- welche Alternativen gäbe es? Ist es möglich sich eine eigene Datenbank auf Basis der OSM-API und allem drumherum aufzusetzen, um die Daten pflegen und erfassen zu können und gleichzeitig die Tools zu Nutzen, die wir um unsere OSM-Datenbank herum gebaut haben, z.B. JOSM? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Staatliches Gesundheitsamt
Am 8. Februar 2015 um 15:59 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 07.02.2015 um 11:08 schrieb Falk Zscheile falk.zsche...@gmail.com: office=administrative finde ich eine gute Idee. -1, office trifft es m.E. nicht, dort finden (amts)ärztliche Untersuchungen statt, etc., das hat nicht (nur) mit Büro zu tun Behörden sind zunächst einmal aktenmäßiger Umgang mit Lebenssachverhalten. Ärztliche Untersuchungen sind nichts anderes als Tatsachenermitlungen für die Akte. An die festgestellten Tatsachen, wie sie in der Akte liegen, knüpft sich dann eine bestimmte Rechtsfolge, z.B. Erteilung eines Gesundheitszeugnisses etc. Also nichts, was einer Einordnung als Office entgegen stünde. Es geht ja bei dem Tag erst einmal um Behörden allgemein und nicht um Gesundheitsbehörde im besonderen! Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Staatliches Gesundheitsamt
Am 8. Februar 2015 um 20:35 schrieb Swen Wacker swen.wac...@gmail.com: Am 7. Februar 2015 um 11:08 schrieb Falk Zscheile falk.zsche...@gmail.com: Es gibt nicht nur staatliche Behörden (die man auch noch zwischen Bund und Ländern differenzieren kann), sondern auch kommunale Behörden etc. Die deutsche Behördenstruktur aus rechtlicher Sicht abbilden zu wollen, dafür fehlt es OSM derzeit an Möglichkeiten Das Wiki sagt in http://wiki.openstreetmap.org/wiki/DE:Key:office office=administrative Kreis-, Gemeinde-, Verwaltungs- und Aufsichtsbehörden, die keine Bundes- oder Landesbehörden sind office=government Büro einer Regierung / Behörde / Regierungseinrichtung Wenn ersteres zutrifft, dann sind office=government Landes- und Bundesbehörden Damit wäre die föderale Struktur in D recht gut abgedeckt. Ich halte die von dir zitierte Differenzierung für nicht zielführend. Es gibt aus meiner Sicht keinen vernünftigen Grund so zu differenzieren. In den Stadtstaaten gibt es dann nur government wogegen es in Flächenstaaten government und administrative gibt, obwohl die Aufgaben überall gleich sind. Wenn man diese Unterscheidung wirklich treffen will, kann man auch auf das operator-Tag zurückgreifen und die Trägerkörperschaft (Kommune, Kreis, Bund, Land etc.)damit angeben. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Staatliches Gesundheitsamt
Am 7. Februar 2015 um 10:34 schrieb Helmut Kauer li...@helmut-kauer.de: Hallo, wie mapt ihr ein Staatliches Gesundheitsamt? office= ? Weder Gesundheitsamt noch health agencies ergaben einen Treffer. Vielleicht wurde soetwas noch nie gemappt. Hinzu kommt, dass auch office=administrative nicht ganz stimmt, da es sich um eine staatliche Behörde handelt, deren Kosten aber die Kommune mit trägt (Gebäude bzw Miete stellt) Für eure Ideen schon mal danke. office=administrative finde ich eine gute Idee. Es gibt nicht nur staatliche Behörden (die man auch noch zwischen Bund und Ländern differenzieren kann), sondern auch kommunale Behörden etc. Die deutsche Behördenstruktur aus rechtlicher Sicht abbilden zu wollen, dafür fehlt es OSM derzeit an Möglichkeiten und ich glaube auch nicht, dass es für unsere Zwecke notwendig ist. Das ist schon keine raumbezogene Information mehr. Aufgaben und Funktion sind ohnehin von Staat zu Staat verschieden. Einziges ziel kann es meines Erachtens daher sein, dass die Behörde samt Adresse gefunden wird. Derjenige, der weiß, dass er zum Gesundheitsamt der Stadt XY muss, sollte das als Treffer in der Datenbank und damit auch als Kartendarstellung finden. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrageplattform
Am 21. Januar 2015 um 15:22 schrieb Andreas Neumann andr-neum...@gmx.net: On 21.01.2015 13:23, Harald Hartmann wrote: Hallo Andreas, die abgefragten Daten werden wie folgt verwendet: - osm user id (fürs Unterbinden des Mehrfachvotings), changesets und account created (für die Auswertungen) werden an der stimme gespeichert Im Umkehrschluss bedeutet das aber, dass du mein Abstimmverhalten nachvollziehen kannst. Solange es nur um wie tagge ich was geht, sollte es keine Probleme geben, aber wenn persönliche Daten abgefragt werden (trägst du nur freudenhäuser ein, die du vorher inspiziert hast) könnte es problematisch werden. Wieso? Alle personenbezogenen Daten werden nach dem Bundesdatenschutzgesetz erst einmal gleich behandelt. Nur für besonders sensible Daten gibt es noch gesonderte Vorschriften. Insbesondere kann jeder in die Erhebung, Verarbeitung und Nutzung seiner personenbezogenen Daten einwilligen, § 4 BDSG. Es gibt kein ich nehme freiwillig an der Erhebung teil, wende mich aber gegen die Verwendung meiner Daten zum mit der Erhebung verfolgten Zweck. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Aufsatz: Die Änderung des Lizenzmodells von OpenStreetMap
Hallo, in Mario Martini/Georg Thiel/Astrid Röttgen (Hrsg.), Geodaten und Open Government - Perspektiven digitaler Staatlichkeit, Speyer, November 2014 [Speyerer Forschungsberichte, Nr. 280] ist ein Aufsatz von mir zum Thema Die Änderung des Lizenzmodells von OpenStreetMap veröffentlicht worden. Die Publikation ist über http://www.foev-speyer.de/publikationen/pubdb.asp?reihen_id=1 als PDF zugänglich. Für den Download ist allerdings die Angabe eines Namens und einer E-Mailadresse notwendig. Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Copyright-Frage: Bekanntmachung einer Verordnung des Landkreises
Am 23. November 2014 um 15:25 schrieb smart...@gmx-topmail.de: Hallo, demnach kann man die Grenze übernehmen und als source wäre einzutragen: Laut § 5 Abs. 1 UrhG Gemeinfrei sowie §1 Abs. 3 Verordnung über das Naturschutzgebiet Veerseniederung in der Gemeinde Scheeßel und der Samtgemeinde Bothel im Landkreis Rotenburg (Wümme): Die Karten sind Bestandteile der Verordnung. http://www.landkreis-row.de/city_info/display/dokument/show.cfm?region_id=160id=370106design_id=1757type_id=0titletext=1 sehe ich das richtig? Das ist meines Erachtens schon mehr als rechtlich notwendig wäre. Selbst Quelle § 1 Abs. 3 VO NSG Veerseniederung wäre ausreichend. § 5 UrhG gilt unabhängig davon, ob man ihn nennt oder nicht. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Copyright-Frage: Bekanntmachung einer Verordnung des Landkreises
Am 23. November 2014 um 15:16 schrieb Mark Obrembalski m...@obrembalski.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.11.2014 14:10, Frederik Ramm wrote: Das folgende alles von einem Nichtjuristen, also mit Vorsichtzu geniessen: Ich (kein Jurist, aber in der Rechtsdokumentation tätig) glaube, da könnten Juristen auch keine sichereren Aussagen machen. So ist es. § 5 UrhG stammt aus einer Zeit, als an Open Data noch nicht im Ansatz gedacht wurde. Im Prinzip ist es eine Transparenzregel: Alles was unter den Tatbestand fällt soll möglichst einfach zu verbreiten sein, damit der rechtsunterworfene Bürger möglichst leicht Kenntnis nehmen kann. Klassischerweise stellt sich bei Gesetzen und Verordnungen auch nicht die Frage nach einer Weiterverarbeitung. In Gesetzen/Verordnungen veröffentlichte Karten sind insoweit ein Sonderfall. In § 5 Abs. 2 UrhG wird für die dort genannten Fälle durch Verweis auf § 62 UrhG explizit ein Veränderungsverbot angeordnet. Bei § 5 Abs. 1 UrhG fehlt eine solche Anordnung. Der Umkehrschluss ist, dass es hier zulässig ist und eine Weiterverarbeitung einschließlich Veränderung möglich. Aber wie gesagt, § 5 UrhG ist im Kern keine Open Data Regelung. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Am 8. November 2014 16:46 schrieb Andreas Neumann andr-neum...@gmx.net: Ich verstehe nur nicht, warum ich Doppeleinträge haben soll (zumal ich den Mist wieder irgendwie auswerten muss)? Ich verstehe nicht, warum beide Einträge als Firma gemappt werden sollen und ich verstehe nicht, was der Sinn hinter der Anweisung des Bundesministeriums ist. Mein Blick in die Glaskugel sagt mir eher: Das Ministerium hat ein Produkt in Auftrag gegeben und die beauftragte Firma versucht unsere Datenbank so hinzubiegen, dass von ihr mit möglichst wenig Aufwand das Produkt erstellt werden kann. Das stellt die beauftragte Firma dann so dar, als ob das Ministerium zwei Einträge in der Datenbank wünscht, dabei wünscht das Ministerium vermutlich nur zwei E-Mailadressen im Produkt und der Rest ist dem Ministerium völlig egal. Aber das ist nur meine Vermutung. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unscharfe Objekte (Bucht, Berg, Gebiet, Kanal, Meeresteil, etc)
Am 4. November 2014 17:21 schrieb Markus liste12a4...@gmx.de: Jede Zone hat eine Bezeichnung und weitere Attribute. _Lösungsvorschlag_ Spezieller *DB-Layer für unscharfe Objekte* Spezieller Editor (oder Tool in JOSM) Mein Vorschlag, den ich schon mal an anderer Stelle hier auf der Liste unterbreitete: Aus meiner Sich muss man erst einmal unterscheiden, ob es sich um genau umgrenztes gebiet handelt oder um ein Gebiet mit fließenden Übergängen. Für gebiete mit fließenden Übergängen ist es m.E. ausreichend und vor allem Sinnvoll, wenn man einzelne Tags in der Art is_in:zonenbezeichnung=value an schon vorhandene Nodes und Ways setzt. Dann kann man zwar aus der Datenbank nicht unmittelbar fertige Zonen extrahieren, aber schöne Punktewolken, anhand deren Verteilung man dann die Ausdehnung des Gebietes bestimmen kann. Also zum Beispiel könnte die Nodes der Küstenlinie der Deutschen Bucht is_in:bight=Deutsche Bucht bekommen genau so wie Tonnen, die in der Deutschen Bucht liegen etc. aus der Verteilung dieses Tags könnte man dann die Ausdehnung der Deutschen bucht als Fläche bestimmen. Oder wenn gar nichts anderes hilft ein is_in:sea_area=value. Wobei value immer eine Name ist. aus einem tag lassen sich mehrere Informationen ableiten: 1. die Gattung: sea_area, bight, etc. 2. der Name des Gebietes, 3. die Ausdehnung des Gebietes. Das Schema würde m.E. sogar funktionieren, wenn man im Schema auf die Gattungsbezeichnung verzichtet. Dann bekommt man immer noch die Info hier ist ein Gebiet mit ungefähr der Ausdehnung, dass den Namen XYZ trägt. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte auf openstreetmap.de defekt
Am 24. Oktober 2014 15:02 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten ist ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte ansieht. Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus meiner Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit aufgelöst die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und Akribie aufgenommen wie der Times Square in New York. Aber auch wir haben es mit knappen Ressourcen zu tun (z.B. Rechenkapazität). Man könnte also z.B. Regionen identifizieren, wo man einen höhere Auflösungen rendert ... Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche OSM-Vertretung sinnvoll?
Am 24. Oktober 2014 14:23 schrieb Michael Buege mich...@buegehome.de: Die Zeiten haben sich geändert, das Projekt hat sich etabliert und gefestigt. Neben technischen und praktischen Fragen spielen immer mehr Themen eine Rolle, die man mehr oder weniger als politisch bezeichnen kann. Da ich es persönlich bei Vereinen eher mit Groucho Marx halte, kann ich nicht einschätzen, ob ein deutscher OSM-Verein taugt als Interessenvertretung der hiesigen Gemeinde. Aber eine Diskussion darüber wäre imho wieder angebracht, denn, wie gesagt, die Zeiten haben sich geändert... Was genau hat sich deiner Meinung nach geändert? Und wo wäre bei diesen Änderungen der konkrete Vorteil gegenüber dem FOSSGIS als Trägerverein? Welche politischen Themen sind es, die du besser oder anderes repräsentiert sehen möchtest? Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte auf openstreetmap.de defekt
Am 24. Oktober 2014 16:11 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Freitag, 24. Oktober 2014, 15:18:06 schrieb Falk Zscheile: Am 24. Oktober 2014 15:02 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten ist ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte ansieht. Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus meiner Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit aufgelöst die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und Akribie aufgenommen wie der Times Square in New York. Aber auch wir haben es mit knappen Ressourcen zu tun (z.B. Rechenkapazität). Man könnte also z.B. Regionen identifizieren, wo man einen höhere Auflösungen rendert ... Wobei wir wieder beim Anbieter von Karten sind, nicht bei OSM. Wir schaffen eine Geodatenbank. Das Rendern ist nicht Sache von OSM, sondern eine von vielen möglichen Anwendungen. Unsere Karte auf der Hauptseite, en wie de, ist vor allem eine Motivationsstütze für die Mapper und nur ganz, ganz nebenbei und unter engen Voraussetzungen ein Angebot für die Öffentlichkeit. Alles richtig was du sagst. Mit der konsequenz, die du ziehst bin ich allerdings nicht einverstanden. Daraus folgt eben nicht zwingend, dass die Info nicht für uns von Interesse ist. Insofern ist es auch logisch und folgerichtig, dass ein Unternehmen wie Mapbox als Datennutzer sich fragt, wo am meisten Nachfrage besteht. Überraschenderweise da, wo die meisten Leute in einer einigermaßen durchtechnisierten Umgebung leben. Das hätte man auch mit dem Finger im Wind erraten können, aber jetzt ist es eben amtlich. So ähnlich wird Geld mit Verkehrszählungen verbraten. Jeder weiß, dass auf der A8 mehr los ist als auf der Dorfstraße von Hinterpfaffenburgstedtwinkelstättenhofen. Aber gezählt ist es doch viel ordentlicher und amtlicher ;-) Ich glaube hier bist du etwas voreingenommen, was sozialwissenschaftliche Forschung angeht. Die Welt ist voller Beispiele, in denen erst durch empirische Sozialforschung gezeigt werden konnte, dass es nicht so ist, wie es scheint. Oft trügt nämlich die menschliche Wahrnehmung ganz gewaltig. Aber hier wird es OT. wir können diesen Aspekt aber gern privat weiter vertiefen. Gegenden, in denen möglicherweise höher aufgelöst gerendert werden _könnte_, ergeben sich so durch die Datendichte. Das ist ein eigener Ansatz. Er führt möglicherweise zur gleichen Erkenntnis. Das wissen wir aber erst, wenn sich jemand findet, der beide Methoden miteinander vergleicht. Ein Aspekt von OSM ist ja auch, dass wir viel ausprobieren/erfassen, ohne zu wissen wozu genau es gut ist :-) OSM ist mehr als eine Geodatenbank, es ist ein soziales Phänomen. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Am 9. Oktober 2014 12:10 schrieb Swen Wacker swen.wac...@gmail.com: Mal aus der Sicht eines relativen Neulings dazwischengeworfen: Am 8. Oktober 2014 07:49 schrieb Falk Zscheile falk.zsche...@gmail.com: Bei der ganzen Problematik überschneiden sich verschiedene Probleme. 1. (...) Entsprechend des technischen Hintergrundes der meisten OSMer Ist das empirisch belegt oder eine Vermutung/Hoffnung/Befürchtung? Es gibt Untersuchungen dazu, aber Quellen habe ich gerade nicht zur Hand. 2. OSM ist ein soziales Phänomen. Bisher fehlt es auf der Dokumentationsseite/Wikiseite an Werkzeugen mit denen man diese Phänomen abbilden kann. Bevor ich etwas dokumentieren kann, muss eben dies erstmal entscheiden worden. Es nehme - in meiner aktuellen, subjektiven Anfängerwahrnehmung - die aus meiner Sicht notwendig erscheinenden Entscheidungs- und Dokumentationsstrukturen nicht in aller Klarheit war. Wo wird was entscheiden? Wer dokumentiert das wo? Was Festlegungen gelten weltweit, welche sprachraumsweit, welche regional? Welche Mechanismen gelten für Übergangszeiten (Stichwort deprecated)? Gibt es bestimmte Qualitätslevel, die man erreichen/halten möchte? Gibt es eine Linie, entlang der sich scheidet, was in die Datenbank und was in externe Layer/DB gehören sollte? Und so weiter. Du gibst doch schon sehr schön den Streitstand/Zustand wieder. Im Prinzip hast du die soziale Komponente von OSM damit schon kennengelernt. Und der von dir beschriebene Zustand zeigt, dass sich etwas ändern muss. Die Frage ist nur was und wie. Was wir nicht wollen, das sind hierarchische Entscheidungsprozesse. Also müssen wir andere Wege finden, zu sehen wie die Mehrheiten verteilt sind. auch wenn wir hier meistens so tun, als gebe es nur einen richtigen Weg, so zeigen die Diskussionen aber, dass man zum gleichen Tag gut anderer Meinung sein kann. Wenn wir aber nicht mit harten ja/nein Abstimmungen arbeiten wolle, dann müssen wir andere Mittel und Wege finden, um das Schema voran zu bringen und nicht im status quo des Streits zu verharren. In diese Richtung gehen meine Ideen. Ich habe bislang gelernt - Es gibt ein Wiki, in dem was steht. Oder was nicht steht. Mal stimmt es. Mal stimmt es nicht. Mal ist es eindeutig formuliert (Das geht so:...), mal windelweich (Es gibt Mapper, die sind der Meinung ...) Mal ist wohl das deutsche Wiki (für mich als Mapper in D) relevant, mal wohl das englischsprachige. Mal ist das deutsche Wiki nur in Deutschland relevant. Diskussionsseiten gibt es auch. Oft wird beispielsweise das Argument dass das englische Wiki verbindlich sei nicht gebraucht, weil es wirklich besser ist, sondern weil dem Verweiser aufs englische Wiki einfach die vorgebrachte Meinung nicht passt. Oft ist das deutsche Wiki einfach schon weiter, weil die Community in DE besonders groß und aktiv ist und schon Probleme hat, an die andere noch keinen Gedanken verschwinden, weil sie noch mit der Ersterfassung von Straßen beschäftigt sind. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Am 9. Oktober 2014 23:15 schrieb Swen Wacker swen.wac...@gmail.com: Am 9. Oktober 2014 19:24 schrieb Falk Zscheile falk.zsche...@gmail.com: Am 9. Oktober 2014 12:10 schrieb Swen Wacker swen.wac...@gmail.com: Was wir nicht wollen, das sind hierarchische Entscheidungsprozesse. Nicht aus Penibilität, sonder lernwillig gefragt: Wer ist wir und wo und wie habt ihr das beschlossen? Wir das ist die Community. Und nein es gibt keinen Beschluss in der Art 65 % sing gegen hierarchische Entscheidungsprozesse, 30 % sind dafür und 5 % haben keine Meinung. Und mit welchen Argumenten? Es soll nicht laufen wie vor Jahren bei der Wikipedia. Und wie konntet ihr das, wenn es keine hierarchische Entscheidungsprozesse gibt? Mache hier oder im Forum den Vorschlag ein hierarchisches Entscheidungssystem einzuführen und du wirst sehen, wie man auch ohne förmlichen Beschluss etwas ablehnen kann :-) Oder positiv gefragt: Welche Entscheidungsprozesse wollt ihr denn? Hier können du und ich nicht mit wir im sinne der Auffassung der Community operieren. Mein Eindruck ist, das die Problematik um die soziologische Komponente unseres Taggingschemas von einem Großteil der Community noch nicht gesehen geschweige denn wahrgenommen wird. Das erste Problem ist schon, dass sich nur die wenigsten überhaupt zu Wort melden und bestimmte Vielschreiber unter Umständen mehr Gewicht erhalten, als es dem tatsächlichen Meinungsbild in der Community entspricht. Wenn es so einen (oder solche) gibt, kann man das/die Ergebnisse auch dokumentieren. Ansonsten beschreibt man in der Doku einen Zustand - Abstimmung mit Füßen, sozusagen. Das Kernproblem unser Tags ist, das man sie verschieden Interpretieren kann. Jeder kann sich unter dem gleichen Begriff etwas anderes Vorstellen. Das meinte ich mit randscharf und kernprägnant. Wissenschaftliche Sprache versucht per Definition die Ränder einer Sache genau zu bestimmen. Kernprägnant zielt auf den inhaltlichen Kern ab, hat aber zu anderen Begriffen keine scharfen Grenzen. Unsere Tags werden in der Regel kernprägnant verstanden. Dann hat man vielleicht eine Abstimmung mit den Füßen, aber das Schema entwickelt und verbessert sich nicht mehr, weil die Mapper nicht zu dem Punkt gelangen -- offensichtlich ist unsere Definition unscharf, wie müssen wir sie ändern um die Zweifelsfrage zu klären. Oft liegt es auch nur daran, das mit einem Tag viele unterschiedliche Aspekte zusammengefasst werden, so dass jeder den Schwerpunkt anders legen kann und entsprechend Streit um die richtige Bedeutung ausbricht. Dabei bietet unser Taggingschema den Vorteil, dass man nicht auf einem Tag beharren muss, sondern neue tags schaffen und bestehende Tags durch sub-Tags ergänzen kann. Das sind eigentlich (!) gute Voraussetzungen um vorwärts zu kommen. Die Radweg-Fußweg-Kombinationsproblematik ist ein schönes Beispiel dafür, wie man Jahrelang diskutieren kann ohne ein brauchbares Ergebnis für die Kartenauswertung zu bekommen. Die einen Mappen/Taggen nach dem Verkehrszeichen, die nächsten nach dem Ausbauzustand und andere nach einer Kombination aus beiden Aspekten etc. Die soziale Komponente scheint mir zu sein - und davor haben ich hohen Respekt - dass hier sehr viele damit leben können, dass die einen es so machen und die anderen so - und dennoch ein Werk entsteht, aus dem (auch durch die Interpretation der Renderer?) _eine_ Karte entstehen kann. Siehe oben zum Taggingschema. Ja, wir können uns eine große Portion Liberalismus leisten. Das geht aber auch ohne dass man bei den Definitionen wirklich voran kommt. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Bei der ganzen Problematik überschneiden sich verschiedene Probleme. 1. Das Taggingschema wird von den meisten als eine technische Anleitung zur Abbildung der Wirklichkeit gesehen. Entsprechend des technischen Hintergrundes der meisten OSMer wird dabei von einem richtig/falsch Schema gedacht. Dabei werden zwei Dinge nicht berücksichtigt: 1.a) Wenn sich jemand ein Tagging für einen Gegenstand aus der Wirklichkeit ausdenkt, so tut er dies aus der Froschperspektive und hat das große ganze nicht im Blick. Schon eine kleine Positionsveränderung des Frosches bringt einen riesigen Perspektivwechsel. So entstehen verschiedene Interpretationen, Konflikte und Widersprüche. 1.b) Anders als die Wissenschaftssprache ist das Taggingschema von OSM nicht Randscharf, sondern Kernprägnant. Also: Klar ist, was im Kern gemeint ist, an den Rändern der Tags aber gibt es Unklarheiten, Konflikte und Überschneidungen. 2. OSM ist ein soziales Phänomen. Bisher fehlt es auf der Dokumentationsseite/Wikiseite an Werkzeugen mit denen man diese Phänomen abbilden kann. 2.a.Beispielsweise, das man über Sätze im Wiki einzeln abstimmen kann. Nicht als Verbindliche Abstimmung, sondern in der Art dieser Aussage stimme ich zu/stimme ich nicht zu auf diese weise ließe sich erkennen, an welchen Stellen die Auffassungen auseinander gehen. An diesen Stellen könnten dann gezielt Diskussionen zur Verfeinerung von Definitionen und Tags ansetzen. 2.b) Auch eine Seite mit Bildern zur Abstimmung könnte hilfreich sein: Auf einem Bild ist ein Feldweg abgebildet. Die Mapper können hier dann ihre Meinung hinterlassen, z.B. ich sehe einen tracktype=2 oder ich sehe einen tracktype=3 etc. Dann würde klarer werden, wie viel Streit bei OSM eigentlich nicht um das Tag, sondern um dessen Wahrnehmung durch unterschiedliche Individuen geht. 3. Den besten Überblick über das Taggingschema und seine Auswüchse/Überschneidungen/Unklarheiten/Widersprüche haben wohl die Entwickler von Karten und Routingsoftware. Denn diese Personen müssen aus einem Bunten Blumenstrauß an Tags in ihrer Karte ein einheitliches und konsistentes Bild erzeugen. Es fehlt auch hier ein Werkzeug, wo sich diese Entwickler austauschen können, wie sie das OSM-Taggingschema zu einer brauchbaren Karten normalisieren Gruß Falk Am 5. Oktober 2014 14:05 schrieb Stefan Keller sfkel...@gmail.com: Am 5. Oktober 2014 11:41 schrieb Florian Lohoff f...@zz.de: Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der Natur der Sache kopiert da jeder zeugs hin und her und ändert das . ... Dazu kommen noch jede menge semantische änderungen die alleine durch die Übersetzungen eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle subjektiv. Und da ja auch niemand sagt Die Englische version der Seite ist die führende ist am Ende das Wiki ein Oktopus mit 250 Armen. D.h., dass wir keine aufgeräumte Datenbank haben, v.a. weil das Wiki nicht aufgeräumt ist? Falls ja, dann müsste man wohl an Aktionen wie Wiki-Übersetzungs-Verbesserung und Wiki-Aufräumen denken? Es müsste ja nicht gleich das Ganze Wiki sein, sondern nur Vorschlag 3. mit den Seiten http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und http://wiki.openstreetmap.org/wiki/Map_Features u LG, S. Am 5. Oktober 2014 11:41 schrieb Florian Lohoff f...@zz.de: On Sat, Oct 04, 2014 at 08:51:07PM +0200, Stefan Keller wrote: Ok. Aber Tatsache ist m.E., dass es Verbesserungspotential gibt. Und wie es scheint, geht es nicht nur um Neulinge. Auch gestandene Mapper können übersehen, dass es geläufigere und aktuellere Tagging-Schemen gibt. Wenn dem so ist, wie könnte man das verbessern? 1. Sind die Suchfunktionen von Wiki und z.B. Taginfo ungenügend (bzw. ungenutzt)? 2. Sind im Wiki die Seiten http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und http://wiki.openstreetmap.org/wiki/Map_Features ungenügend? 3. Sollte man es mit einer interaktiven Bestimmungs-Anleitung versuchen? 4. Oder einem Plugin (ähnlich OSMantic für JOSM = Hat das jemand ausprobiert)? Oder liegt es einfach daran, dass die Daten mit alten Tagging-Schemen zuwenig schnell verbessert werden? Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der Natur der Sache kopiert da jeder zeugs hin und her und ändert das . Irgendwann gibts es 20 Tagging Schemata und jedes sieht semi-akzeptiert aus. Jeder mapped dann so vor sich hin und beruft sich auf das Schema was er für das richtige hält. Dazu kommen noch jede menge semantische änderungen die alleine durch die Übersetzungen eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle subjektiv. Und da ja auch niemand sagt Die Englische version der Seite ist die führende ist am Ende das Wiki ein Oktopus mit 250 Armen. Flo -- Florian Lohoff f...@zz.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux)
Re: [Talk-de] Unbenutzbare Wanderwege - was tun?
Am 27. September 2014 12:28 schrieb thsMD thomas.schind...@ovgu.de: dieterdreist wrote Am 25. September 2014 13:03 schrieb thsMD lt; thomas.schindler@ gt;: 3. Parallel zu den besagten Wegen gibt es neue Wege. wie weit entfernt sind die denn? Evtl. hat sich ja auch nur lokal die Wegeführung durch Geröllabgänge geändert? Hi, genau das vermute ich. Wegführung geändert und irgendwer hat den neuen Weg hinzugefügt. Abstand max. 200m. An einer Stelle gibt es sogar 3 Varianten von denen genau eine ausgeschildert ist. Dann ist der alte 'Weg auch aus meiner Sicht reif zur Löschung. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unbenutzbare Wanderwege - was tun?
Am 26. September 2014 07:50 schrieb bkmap burkhard.kirch...@web.de: Am 25.09.2014 13:03, schrieb thsMD: Noch eine Zusatzfrage: Welche Attribute verwendet man, wenn Radfahren auf dem Weg explizit nicht verboten ist (kein Schild), ich aber der Meinung bin, dass dort keiner mit seinem Rad langfahren möchte? Theoretisch gilt für Wege ohne Schilder (aus Art. 25 BayNatSchG): Also bei mir steht da etwas von Tiehrhege! Du meinst vermutlich Art. 13 Abs. 3 BayWaldG.[1] Das Radfahren, das Fahren mit Krankenfahrstühlen und das Reiten ist im Wald nur auf Straßen und geeigneten Wegen zulässig. Die Vorschriften des Straßen- und Wegerechts und des Straßenverkehrsrechts bleiben unberührt. Die Betonung liegt auf Wald. In den Alpen gibt es ja noch andere Landschaftsformen. Beim ausgangsposting habe ich mir eher eine hochalpine Landschaft ohne Bäume vorgestellt. Gut möglich, dass da meine Phantasie mit mir durchgegangen ist und ein anderes Szenario zugrunde lag. Zur Benutzung der freien natur findet sich etwas in Art. 28 BayNatSchG.[2] Der beschränkt das Fahren aber in der Tat auch auf Wege. Im Kern hast du also Recht ... Gruß Falk [1] http://www.gesetze-bayern.de/jportal/portal/page/bsbayprod.psml?showdoccase=1doc.id=jlr-WaldGBY2005rahmendoc.part=X [2] http://www.gesetze-bayern.de/jportal/?quelle=jlinkdocid=jlr-NatSchGBY2011rahmenpsml=bsbayprod.psmlmax=trueaiz=true ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebiete bezeichnen
Am 26. September 2014 12:43 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 25. September 2014 22:46 schrieb malenki o...@malenki.ch: Kürzlich wurde ich im Hilfe am Westerwald (ein Mittelgebirge)¹ gebeten; der war aber bereits ohne mein Zutun repariert worden. Regionen werden also durchaus schon gemappt. ¹ http://de.wikipedia.org/wiki/Westerwald http://www.openstreetmap.org/relation/3273435 wobei das im Detail natürlich fragwürdig ist. Wenn ich mir hier ansehe, dass die Basaltwerke noch mit einem Zipfel im Westerwald sind: http://www.openstreetmap.org/?mlat=50.68842mlon=7.32396#map=17/50.68842/7.32396 oder diese Einfamilien(?)-Häuser zum Teil ja, zum Teil nicht: http://www.openstreetmap.org/?mlat=50.68359mlon=7.31864#map=18/50.68359/7.31864 dann wird klar, dass so was eigentlich keine schönen Daten sind, meint: der Datentyp Polygon mit seinen klaren Grenzen passt nicht nur Natur dessen, was beschrieben werden soll. Das kann man zwar verfeinern, aber richtig klar wird es nie, weil man vermutlich auch in der Realität beide Standpunkte vertreten kann (Ist im Westerwald bzw. ist nicht im WW). Z.B. manche Vororte von Koblenz sind im Westerwald, Koblenz aber nicht? Dieser Punkt hier ist im Westerwald: http://www.openstreetmap.org/?mlat=50.3191mlon=7.5918#map=15/50.3191/7.5918 der hier aber nicht? http://www.openstreetmap.org/?mlat=50.3203mlon=7.5874#map=15/50.3203/7.5874 Solche Gebiete den Fluss durchschneiden zu lassen halte ich eher für eine schlechte Idee, der Fluss(abschnitt) wird doch ganz oder gar nicht dazugehören? Ziemlich sicher werden solche Konstrukte auch alle Nas' lang kaputtgehen (ähnlich den politischen Grenzen). Ich bin nach wie vor der Meinung, man sollte dafür einen neuen Datentyp erfinden, z.B. eine Sammlung von beliebigen Dingen (Nodes und vielleicht auch ways), die dann entweder als drin oder draußen bezeichnet werden (Rolle), bzw. in Fällen einer harten Grenze (Fluss, Bergrücken, Küste etc.) auch als echte Grenze (in Teilbereichen). Ein Polygon zur Strukturierung solcher Gebiete erscheint mir auch ungeeignet. Genau wie der Anspruch mittels Relation alle Wege erfassen zu wollen, die das Gewiet umgrenzen. Würde es nicht reichen, wenn man einzelne Nodes zu einer Relation packt. Also diese Stadt oder dieser Berggipfel liegt im Erzgebirge oder, wem das zu sehr nach Sammelrelation klingt einfach etwas analoges zu is_in=value. Dann kann man auf der Auswertungseite die Ausdehnung dieses Bereichs ermitteln und vom Renderer entsprechend beschriften lassen. Damit geht man auch dem Streit aus dem Weg, wo die Grenze genau verläuft und es entspricht unserem Crowdsourcingansatz. Keiner muss wissen, wo Erzgebirge genau anfängt oder aufhört. Es reicht, dass ich weiß dieser Berg oder diese Stadt liegt im Erzgebirge und bekommt dann das Tag/Relation. Die Region ergibt sich dann erst mit der Zeit aus der Zuordnung einzelner Nodes zu einem Region-Tag durch eine Vielzahl von Mitwirkenden. Der Nachteil ist, dass sich keine festen Grenzen unmittelbar aus der Datenbank extrahieren lassen, sondern man nur eine Datenwolke erhält. Aber gerade für so einen Anwendungsfall, wo eine klare Grenzziehung ohnehin nicht möglich ist, finde ich das ganz vernünftig. Besser jedenfalls als riesige Waypolygone oder Relationen mit Ways zu haben, die ständig kaputt gehen. Für Verwaltungsgrenzen geht das nicht, aber für difuse Grenzen wie Namen von Regionen schon. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unbenutzbare Wanderwege - was tun?
Am 24. September 2014 22:04 schrieb thsMD thomas.schind...@ovgu.de: Hi, ich mache gerade Urlaub in den Alpen. Dabei ist mit aufgefallen, dass in der OSM-Karte Bergwanderwege T3/T4 vorhanden sind, die nicht mehr benutzbar sind. Keine Wegweiser an den Kreuzungen/Einmündungen oder Kreuzungen/Einmündungen nicht gar nicht meht vorhanden. Verlauf kann man stellenweise noch erahnen, Wikipedia sagt zu T3: Weg am Boden nicht unbedingt durchgehend sichtbar.[1] und zu T4: Wegspur nicht zwingend vorhanden..[2] Auch scheint eine Markierung dieser strecken nicht zwangsläufig vorhanden zu sein. So verstehe ich jedenfalls den Wikipediaartikel. aber Weg ist wie gesagt garantiert nicht benutzbar. Woraus schließt du die Unbenutzbarkeit (abgesehen von fehlender Markierung und fehlender durchgehender Sichtbarkeit). Was tun? Falls das deine einzugen Kriterien sind, dann nichts löschen, sondern ggf. noch trail_visibility=[value] ergänzen. Gruß Falk [1] http://de.wikipedia.org/wiki/SAC-Wanderskala [2] http://de.wikipedia.org/wiki/SAC-Wanderskala ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM quo vadis - OSM-Account für Workshop
Was ist so verkehrt daran, dass Markus die Leute an die Hand nimmt? Mir ist jemand, der schon einmal in OSM unter Anleitung editiert hat lieber, als jemand, der gar nicht hineingeschnuppert hat, weil im die Zeit oder der Mut dazu gefehlt hat. Es gibt Menschen, die sich besser dabei fühlen, wenn ihnen bei den ersten Gehversuchen jemand über die Schulter schaut. Ich finde dass sogar gut, schließlich werden so vielleicht die gröbsten Anfängerfehler vermieden. Gerade bei älteren Semestern konnte ich beobachten, dass sie mit dem Einstieg bei OSM zögern, weil sie nichts falsch machen wollen. Einige sind nur dabei, weil sie am Anfang jemanden hatten, den sie direkt fragen konnten. Wenn wir in Richtung wir brauchen niemanden, der sich nicht allein anmelden kann/will argumentieren, dann ist das meines Erachtens ein falscher elitärer Ansatz. Falk Am 23. September 2014 10:59 schrieb Michael Reichert naka...@gmx.net: Hallo, Am 2014-09-23 um 10:56 schrieb Peter Wendorff: die Herausforderungen, die du ansprichst, sind richtig, aber es sind eben auch Herausforderungen. Richtig ist auch, dass wir aufpassen müssen, nicht nur für IT-Nerds, wie du das ausdrückst, nutzbar zu sein, aber trotzdem: Ein gewisses Mitdenken zumindest kann man erwarten. Einen Benutzernamen und Passwort auszudenken sowie ein Formular und E-Mails zu benutzen, die - so hoffe ich, ohne es aktuell geprüft zu haben - selbst erklären, was zu tun ist, erfordert als Grundwissen eigentlich nur die Benutzung des Webbrowsers und des eigenen E-Mailprogramms, und darüber hinaus Lesekompetenz, um zu verstehen, was erklärt wird. Wenn wir da was verbessern können, sollten wir das tun, aber wenn - abgesehen von Verbesserungen bei diesen Erklärungen - dies schon eine Hürde in Bezug auf das Verständnis oder die Fähigkeiten des Nutzers darstellt, dann kann das fürs Tagging nicht funktionieren. Dann ist meines Erachtens erstmal der richtigere Weg, die Nutzer zum Fehlermelden via Notes aufzufordern. +1 Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. ___ 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] Adressdaten in POI nodes
Am 13. August 2014 09:14 schrieb Martin Vonwald imagic@gmail.com: Am 12. August 2014 17:44 schrieb Christian H. Bruhn br...@arcor.de: In Lübeck haben wir eine building-Relation erstellt, die als outline-member die Gebäudehülle mit den Adressinfos enthält und die einzelnen POIs als contains-member (z.B. [1]) ohne Adressangaben. Warum sollte man in einer Geo-DB jene Knoten, welche sich alle innerhalb einer bestimmten Fläche befinden, extra noch in eine Relation geben? Weil es nicht zwingend ist, dass etwas innerhalb eines Polygons auch eine Beziehung zum Polygon hat. Aber davon abgesehen bin ich kein Freund dieser Relationslösung sondern bevorzuge jedem Node seine eigene Adresse :-) Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressdaten in POI nodes
Am 9. August 2014 22:59 schrieb Andreas Neumann andr-neum...@gmx.net: Am 09.08.2014 um 18:40 schrieb Bernhard Weiskopf: Hallo an alle, z. B. in meiner Umgebung wurden bei zahlreichen Restaurant-Nodes u. ä. die Adressdaten (addr:* = …) gelöscht. Soll man die jetzt nicht mehr eintragen, weil die z. B. aus der Umrandung „building = …“ herausgelöst werden können, oder hätte der Mapper die nicht löschen sollen? Eigentlich sind die Daten redundant, jedoch ist es für einen Auswerter deutlich schwieriger, umfassende Adressdaten mit Nodes und Ways zu verknüpfen (noch grausamer sind übrigens einige Varianten mit Relationen). Ob also eine umfassende Adresse mit dem Node verknüpft wird, hängt vom Auswerter ab. Es gibt unzählige Auswerter, die dieses Feature nicht unterstützen. Dazu zählen fast alle Tools, die mit Overpass arbeiten. Aber auch Tools, wie wheelmap, wo man Adressdaten von Hand nachtragen kann. Es wird also zukünftig auch immer wieder zu redundanten Daten kommen, weshalb ich diese nie lösche. Und es ist 1. eine zusätzliche Kontrolle. Ein schlaues tool könnte Prüfen, ob das Node im Gebäudepolygon die gleichen Adressdaten hat und ggf. Alarm schlagen. 2. es ist einfacher, bei der Datenabfrage. Ich weiß GIS-Profis werden darüber nur müde lächeln ... Jedenfalls bei mir bekommen sowohl das Gebäudepolygon als auch die darin befindlichen Geschäfte die Adresstags. Eine Löschung würde ich als unnötige Maßnahme im leben und leben lassen Universum von OSM empfinden. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bebauungspläne als Amtliche Werke? Was: Radweit routen löschen? (WAS: Radweit)
Am 5. August 2014 23:58 schrieb Mark Obrembalski m...@obrembalski.de: Aber wenn man für ein Gebiet nix Besseres hat, kann man natürlich auch erst mal die Angaben aus dem Bebauungsplan eingeben, solange man nur weiß, dass das Gebiet tatsächlich schon bebaut ist. Was aber auf jeden Fall auch drinsteht, sind die eigentlichen Festsetzungen, von denen es einige meiner Meinung nach durchaus verdienen, in OSM aufgenommen zu werden. Gerade die Information, was nun als reines Wohngebiet, allgemeines Wohngebiet, Mischgebiet, Gewerbegebiet etc. ausgewiesen ist, halte ich für interessant. Dabei ist natürlich zu beachten, dass solche Festsetzungen im Sinne der Baunutzungsverordnung (BauNVO) deutsches Recht sind und sich in gleicher Weise nicht ein zu eins bei unseren Nachbarn finden. Um global verständlich zu sein müssen wir an unserem landuse=value festhalten. Was natürlich nicht heißen soll, dass das Schema nicht verbesserungswürdig ist, z.B. Unterscheidung zwischen Bodenbedeckung und Landnutzung. Wenn man Festsetzungen nach der BauNVO eintragen möchte, dann also als eigenes Tag, vielleicht landuse:de=baunvo:reines_wohngebiet oder als subtag zu landuse. Wie auch immer: Man muss berücksichtigen, dass die BauNVO eine rein nationale Kategorisierung ist. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wie tagge ich Zeltplätze?
Am 8. Juli 2014 00:01 schrieb gmbo g...@kilometerfresser.eu: Am 07.07.2014 21:04, schrieb Falk Zscheile: Es kommt zum Nebeneinander statt zum miteinander und es entstehen im schlimmsten Fall taggingschulen, die sich unvereinbar und unversöhnlich gegenüberstehen. Was meines Erachtens fehlt ist ein zentraler Anlaufpunkt, an dem man schauen, diskutieren und ausprobieren kann ohne gleich einen Editwar zu riskieren. Ggf. könnte man auch verschiedene Beispiele zur Abstimmung stellen und so ein unverbindliches Voting erhalten, welches Modell besser ankommt. Aber wer würde in einer Sandbox nachsehen in der nur getestet werden kann und über welchen Weg sollte man das finden? Sandbox trifft es vielleicht nicht ganz, was mir vorschwebt. Es soll ein Raum sein, in dem man einen Vorschlag unterbreiten und mit anderen diskutieren kann, um dann zu einer Art best practice zu kommen. Eine Sandbox in diesem Sinne müsste natürlich in geeigneter Weise mit dem Wiki und über andere Seiten, die zu Taggingfragen in der Regel konsultiert werden, verknüpft sein. Eine andere Idee: man erstellt für JOSM Taggingvorlagen, die sich an einem komplexen Objekt, wie Zeltplatz orientieren. Und als Tagvorschläge findet sich dann alles, was es auf einem Zeltplatz so gibt, ohne dass man sich durch zig andere Menüs Straße Einrichtung Geografie hangeln muss. Meiner Meinung nach sollte ein Taggingschema für komplexe Gebilde erst wertungsfrei, also ohne das nachzuschauen wie es am häufigsten genutzt wird, beschrieben werden. Das könnte wenn es beschreibbar ist auch in realen Orten gemappt werden. In der Beschreibung würde dieser Ort dann angegeben. Das funktioniert so nicht, da jeder anders Wertungsfrei ans Mappen heran geht. Das Ziel, welches man vor Augen hat, bestimmt auch ganz entscheidend das Tagging mit. Sowohl Detailgrad als auch die Verwendung bestimmter Tags. Ein wie auch immer geartetes best practice-Beispiel kann da schon den Horizont erweitern: Ach, den Wasseranschluss, den ich da auf dem Foto sehe, kann ich auch eintragen! Bei der Orientierung an Realen Orten ist immer die Gefahr, dass der status quo verteidigt wird, denn man hat das ja selbst und in jedem Fall richtig gemappt. Das ist eine zusätzliche Hürde auf dem Weg zu einer konstruktiven Diskussion. Niemand lässt sich gern sagen, dass er etwas falsch gemacht hat. Auf dem neutralen Boden einer Sandbox, losgelöst von einem existierenden Ort, ist das meines Erachtens leichter. Aber auch hier fehlt die Übergeordnete Beschreibung. Die How to map Seite wäre da ein Einsprungspunkt. Ja, das wäre auf jeden Fall einfacher zu realisieren, als meine Sandbox. Es gäbe noch eine zweite Möglichkeit einer Vorgehensweise. Dazu müsste man alle bisher gemachten Proposels und eventuell dazugehörenden Votings zu einem Thema finden, ebenfalls die sonstigen Wikieinträge. Das ganze müsste dann zusammengefasst werden und auf Widerspüche geprüft werden. Wenn alles schlüssig ist, noch auf Veränderung in der Istzeit und Vollständigkeit prüfen. Das können wir zeitlich nicht leisten. wir müssen darauf hoffen, das der relevante personenkreis anspringt und sein Wissen/ seine Meinung beiträgt. Ich weiß, wer soll das machen, man will ja nur mal eben den Stellplatz mappen, den man gerade gesehen hat, und sich nicht um das Drumherum kümmern müssen. Genau :-/ Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wie tagge ich Zeltplätze?
Am 8. Juli 2014 09:12 schrieb Peter Wendorff wendo...@uni-paderborn.de: Falsch, wieso muss jedes Tag gerendert werden? Und wieso in jeder Karte? Routen z.B. (Bus, Wanderwege etc) sind auf der allgemeinen Karte nicht sichtbar, und würden da eher stören, weil die vergleichsweise voll ist; in den Spezialkarten sind die aber super. Interessant wäre in der Tat, wenn man den Vergleich hat: wie sieht die gleiche Datengrundlage in verschiedenen Kartenstilen aus. Im besten Fall kommt man so auch von der Auffassung weg, der Mapnik-Stil auf openstreetmap.org sei das Maß aller Dinge. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wie tagge ich Zeltplätze?
Im Zusammenhang mit der Diskussion um das richtige Tagging von zeltplätzen ist mir die folgende Idee gekommen, zu der ich gern eure Meinung hören würde: Die wenigsten von uns sind Experten im Taggen von Zeltplätzen, Schulen, Freibädern und anderen komplexen Einrichtungen, die nicht nur aus einem key=value-Paar bestehen, sondern aus einer Kombination vieler verschiedener Elemente. Zum Beispiel beim Zeltplatz: verschiedene Arten von Stellplätzen, Sanitäreinrichtungen (Toiletten, Duschen), Infrastruktur (Wasser, Wege, Rezeption), Versorgungseinrichtungen, Spielplatz, Sportplatz. Die wenigsten haben Lust, sich bei jedem Mappen durchs Wiki zu wühlen, wenn sie das richtige Tag nicht im Kopf haben oder sich auf die Suche nach einem schon ordentlich gemappten Zeltplatz zu machen, den sie als tagging-Vorlage verwenden können. Und es ist auch keineswegs sicher, dass man im Wiki gleich das etablierte Tag findet. Meine Idee wäre eine Art Sandkasten in dem ein Mustertagging für komplexe Strukturen, wie z. B. Zeltplätze, stattfindet. Wenn man also einen Zeltplatz eintragen will, dann geht man auf die Musterseite und hat schon eine Übersicht über alle wichtigen Elemente. Ein weiterer angenehmer Nebeneffekt wäre sicher die Vereinheitlichung des Taggings. Auch Probleme im Taggingschema würden schneller entdeckt, weil man sie anhand eines Musterbeispiels diskutieren kann. Schließlich hätten es auch Einsteiger leichter, weil alle wichtigen Tags für einen Zeltplatz schon an einer Stelle gesammelt sind und das Zusammenspiel der Tags deutlich wird. Perspektivisch könnte man den Sandkasten dann auch an verschiedene Rendervorschriften anschließen und könnte dann auch gleich sehen, wie das Tagging auf verschiedenen Karten aussieht. Vielleicht würde man damit auch ein wenig das Mapnik-Standardstil-Problem bzw. der starken Orientierung daran abschwächen. Nur so ein Gedanke. Ich weiß, dass Ressourcen zur Umsetzung knapp sind. Aber halten ihr etwas in der oben beschriebenen Art für sinnvoll oder reicht eurer Meinung nach ein how-to-map, wie es im Wiki niedergelegt ist. Es wäre aber vielleicht auch eine Masterarbeit Wert: Verbesserung der Abstimmung in unstrukturieren Organisationen mit Hilfe 'von-was-auch-immer' am Beispiel von OSM. Gruß Falk Am 5. Juli 2014 11:51 schrieb gmbo g...@kilometerfresser.eu: Auf dem letzten Stammtisch in Essen ist uns bewusst geworden, dass es beim taggen von Campingplätzen sehr unterschiedliche Ansichten gibt. Nehmen wir die derzeitigen Taggingschemen gint es viele Widersprüche. Zur Zeit wird für Camping der Tag tourism=camp_site(51 456) benutzt und für Wohnmobile der Tag tourism=caravan_site (12 408). Bei den Campingplätzen wird dann tents=yes/no die Möglichkeit zum Aufstellen von Zelten getaggt und mit caravan==yes/no beschrieben ob dort Wohnmobile abgestellt werden dürfen. Meinem Verständnis nach ist genau das der Punkt warum es dort zu Fehlinterpretationen kommt. Denn Caravan englisch - deutsch Wohnwagen ist ja eigentlich kein Reise- oder Wohnmobil. camp_site wird beim Tagging in OSM Camping und Zeltplätze benutzt, was dem umgangssprachlichem Campingplatz entspricht, der aber eben sowohl ein Jugendzeltplatz wie einprivater Campingplatz mit Parzellen für Wohnwagen von Dauercampern sein kann auf dem das Zelten nicht erlaubt ist. Wie unterscheiden wir also einen Zeltplatz wie Tönnebön-Camp ( way 129645725 ) von einem Campingplatz auf dem man als nur Zelter nicht eingelassen wird. Ebenso gibt es Kombinationen bei denen man Zelten darf, aber Wohnmobile nicht eingelassen werden. Auf der anderen Seite gibt es Wohnmobilstellplätze die Zelten erlauben aber dafür Zelten erlauben. Dort dürfte ein Fahradfahrer mit Zelt ja auch zelten. Wie schon oben erwähnt gibt es wie man an den Übersetzungen vom englichen ins deutsche und umgekehrt unterschiedliche Sichtweiden. damit wird es für mich sehr schwer das ganze in englisch fürs Tagging zu beschreiben. LG Gisbert ___ 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] wie tagge ich Zeltplätze?
Am 7. Juli 2014 20:55 schrieb Henning Scholland o...@aighes.de: ich empfinde so einen Sandkasten als nur bedingt für OSM tauglich. Man sieht dann zwar, was man so alles an einem Objekt erfassen kann. Aber es fehlt dann die komplette Dokumentation, was das Tagging genau bedeutet. Wenn ich dir in die Sandbox einen way mit highway=track und tracktype=grade1 eintrage, weißt du mit Sicherheit nicht, wofür das nun steht. Ähnlich der Kombination von access-Tags. Eine Legende müßte vorhanden sein, sonst wäre das Konzept sicher im Nutzen eingeschränkt. Letztlich kommt man um das Handbuch-lesen nicht drum rum. Und ehrlich gesagt ist es mir lieber, da steht nur ein grobes Gerüst an Taggs an einem Objekt und der stimmt, als diverse Detail-Taggs, die fehlerhaft sind und alle Experten einen Bogen um die Ecke machen, weil ja augenscheinlich alles erfasst ist. Ich möchte, dass auch die Experten die Möglichkeit haben anhand des Sandkastenbeispiels über gutes und richtiges tagging zu diskutieren. Jetzt ist es ja eher ein nebeneinander. der eine mappt ein paar Zeltplätze in Nordeutschland, der andere in Italien. Aber keiner schaut sich an, wie es der andere macht. Es kommt zum Nebeneinander statt zum miteinander und es entstehen im schlimmsten Fall taggingschulen, die sich unvereinbar und unversöhnlich gegenüberstehen. Was meines Erachtens fehlt ist ein zentraler Anlaufpunkt, an dem man schauen, diskutieren und ausprobieren kann ohne gleich einen Editwar zu riskieren. Ggf. könnte man auch verschiedene Beispiele zur Abstimmung stellen und so ein unverbindliches Voting erhalten, welches Modell besser ankommt. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wie tagge ich Zeltplätze?
Am 7. Juli 2014 21:19 schrieb Henning Scholland o...@aighes.de: da könnte man jetzt aber auch osm-Dateien ins wiki laden und jeder schaut sie sich an. Oder man taggt ein Beispiel in OSM und diskutiert darüber. Das ist für den Anfang auf jeden Fall eine gute Idee! Problematisch ist aus meiner Sicht nur, dass man dann echte geographische Koordinaten verwenden würde und somit die Gefahr besteht, dass Modelldaten in die echte Datenbank gelangen. Ich denke ich werde bei Gelegenheit mal so eine Modelldatei basteln :-) Gibt es im OSM-Datenformat die Möglichkeit, Koordinaten als rein hypothetisch zu kennzeichnen? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie exakt Landnutzungsflächen eintragen?
Am 4. Juli 2014 21:02 schrieb Sascha Pomplun fo...@saschapomplun.de: Ich würde gerne klären wieviel Genauigkeit in OSM erwünscht ist, [...] Das ist eine schwierige Frage, denn sie hängt von vielen Randbedingungen ab: 1. Zunächst einmal davon, welche Meinung der Mapper zur Aufgabe der Kartendaten hat. Geht er mit der Vorstellung an die Sache, das maximale wozu die Daten genutzt werden (sollten), ist eine Karte auf Zoomlevel 12, dann geht er an die Datenerfassung/Eintragung ganz anders heran, als jemand, der den Datenbankinhalt als Sammlung mit offenem Verwendungszweck sieht. Eine solche Person wird eher Details mappen, die auf Z12 nicht unbedingt hübsch aussehen. 2. Randbedingung ist die Qualität der Informationen, aus denen die Daten für die OSM-Datenbank gewonnen werden. Wenn Mapper A ein detailliertes Luftbild als Hintergrund verwendet, Mapper B aber eines mit grober Auflösung so kommen dabei nicht nur ganz andere Datendetails in die Datenbank, sondern hat auch Einfluss auf das verwendete Datenschema. Jemand der gerade noch so Häuser auf dem Luftbild erkennen kann wird nicht einmal einen Gedanken daran verschwenden, dass es kleinteiliger Informationen gibt und wie diese im Datenschema und der Datenbank abgebildet werden können. 3. Das Datenschema ist alles andere als klar. oft weder in der konkreten Definition des Tags noch in der logischen Struktur der Tags zueinander. Die einzelnen landuse-Tags sind nicht konsistent zueinander und lassen sich nicht logisch zueinander ins Verhältnis setzen[1]. Das gilt zum Beispiel für die Dinge, die wir mit landuse beschreiben. So könnte (!) man landuse=vineyard als Untermenge von landuse=farmland sehen, denn es ist ein Sonderfall landwirtschaftlicher Fruchtproduktion. Man könnte (!) die einzelnen Weinbergsflächen einzeln einzeichen und das ganze mit einem landuse=farmland umschließen. rein logisch gesehen wäre das richtig. Es wird bei OSM so aber nicht gehandhabt, weil die Mehrheit der Meinung ist, zwischen Feld und Weinberg gebe es hinreichend deutliche Unterschiede. Im Übrigen fehlt natürlich auch der Informative Mehrwert. Bei Straßen ist es eben nicht mehr so klar. Wenn man es wörtlich betrachtet, dann könnte ein Feldweg oder eine Wohnstraße durchaus Teilmenge von landuse=farmland oder landuse=residential sein, würden die Flächen also nicht unterbrechen. Legt man den Fokus natürlich auf die tatsächliche Nutzung, so endet landuse=residential natürlich an der Straße (und nicht auf dem Straßenvektor!). Straße und Wohngebiet haben dann keine gemeinsame Menge. Die eine Fläche dient dem Wohnen, die andere dem fahren mit Fahrzeugen. Eine gemeinsame Obermenge wäre dann vielleicht menschliche Nutzung :-) 4. Die Qualität von OSM und damit auch der Detailgrad wird auch von der Anzahl der Mitwirkenden bestimmt. Were sich schon mal im Micro-Mapping versucht hat, weiß wie viel Zeit man an relativ kleinen Flächen verbringen kann und wie viel Wald, ausreichend genau für Z12, man in der gleichen Zeit mappen kann. Micro-Mapping wird sich also perspektivisch nicht durchsetzen, weil wir dafür nicht genug Mapper sind. Damit wird sich meine Meinung nach aber auch das Verständnis für die Probleme in diesem Bereich in Grenzen halten. Kurzum Sascha spricht altbekannt Probleme von OSM an, die sich in der sozialen Wirklichkeit als gegenseitiges Weglöschen zeigen, weil der andere ja etwas falsch gemacht hat. Außer zu versuchen, in solchen Fällen räumlich nebeneinander und nicht miteinander zu mappen, fehlen mir auch gute Ideen, wie wir das in den Griff bekommen könnten. Die Community ist so heterogen, dass man immer Mapper mit unterschiedlichem Kenntnisstand und Vorstellungen vom richtigen Detailgrad geben wird. Etwas ratlos aufgrund der Rahmenbedingungen Falk [1] Hierzu plane ich (vorbehaltlich Zeit und der Annahme) einen Vortrag auf der nächsten FOSSGIS-Konferenz. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Am 3. Juni 2014 11:03 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 02/giu/2014 um 16:07 schrieb Falk Zscheile falk.zsche...@gmail.com: Und sollen wir das jetzt einzeln je nach Hausordnung mappen oder wie soll ich deinen Hinweis verstehen? Ich finde deine Argumentation daher nicht besonders konstruktiv im Hinblick auf OSM und das Datenschema. ich hatte lediglich eingewandt, dass permissive m.E. besser passt als yes, dann kamst Du mit unpassenden Bundesverfassungsgerichtsurteilen zur Meinungsfreiheit und jetzt bin ich unkonstruktiv? ;-) Mein Eindruck war, zwischenzeitlich ein anderer, aber das war natürlich nur mein subjektives Empfinden. Ich denke, jetzt hat jeder Interessierte genug Argumente, um sich zwischen permessive und yes zu entscheiden, also zwischen quasi öffentlichem Raum und privatrechtlich gewährtem Zugang zu wählen. Bei den Aussagen und Folgerungen aus dem BVerfG-Urteil werden wir uns wohl nicht einig werden. Die Bibel liest ja auch jeder anders ;-) Eine weitere Vertiefung wäre daher OT. Aber ich denke, die nächste Diskussion, bei der wir unterschiedlicher Meinung sind, kommt auch so :-) In diesem Sinne Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Am 2. Juni 2014 02:49 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 30. Mai 2014 11:23 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Bei einem Einkaufszentrum gelten andere Regeln als in Wohnzimmer ;-) Die Regeln sind jedenfalls deutlich eher die eines privaten Hofs als die eines oeffentlichen Raumes / Strasse. Mit solch einer Aussage wäre ich in Deutschland vorsichtig. Seit dem Fraport Urteil des Bundesverfassungsgerichts[1] reicht es nicht mehr, dass ein Einkaufszenrum o. ä. in privater Hand ist um nach Belieben Dritte vom Zugang auszuschließen. Jedenfalls wenn diese Dritte ihre Grundrechte auf Meinungsäußerungs- und Versammlungsfreiheit dort ausüben wollen. Wie es in Italien ist, das weiß ich nicht. Jedenfalls sind mit dieser Entscheidung deutlich in Richtung öffentlichen Raum gerückt worden. Ich weiß, dass man access=Grundrechtsausübung nicht mappen kann, aber den Vergleich Bauernhof--Einkaufszentrum wollte ich dann doch hier nicht so stehen lassen. Normalerweise gibt es da eine Hausordnung die genau so was sagt (klar, wer wie ein potentieller Kunde aussieht wird natuerlich reingelassen, solange er sich nicht laestig verhaelt, ist ja im ureigensten Interesse, moeglichst viele Kunden anzuziehen). Hausordnung hin oder her -- der Allgemeinheit zugängliche private Areale wie Einkaufszentren, Flughäfen etc. stehen der Öffentlichkeit zur Grundrechtsausübung zur Verfügung, ob das den Eigentümern passt oder nicht (und es passt in der Regel natürlich nicht). Aber natülich hat alles auch seine Grenzen ... Beim privaten Bauernhof gilt der allgemeine Zugang so nicht. Einfach mal im Internet gesucht und das erste angeclickt: http://www.mira-einkaufszentrum.de/hausordnung.html So was aehnliches gilt praktisch in allen Einkaufszentren. In ihre Hausordnungen können die Eigentümer erst einmal alles hineinschreiben. Ob das auch vor Gericht bestand hat, das ist eine ganz anderes Frage :-). Es gibt keinen Anspruch auf ungestörtes Einkaufserlebnis in einem Einkaufszentrum. Gruß Falk [1] http://www.bundesverfassungsgericht.de/entscheidungen/rs20110222_1bvr069906.html ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Am 2. Juni 2014 12:32 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Hallo, Am Montag, den 02.06.2014, 10:15 +0200 schrieb Bernd Wurst: Hallo. Am 02.06.2014 08:41, schrieb Falk Zscheile: Die Regeln sind jedenfalls deutlich eher die eines privaten Hofs als die eines oeffentlichen Raumes / Strasse. Mit solch einer Aussage wäre ich in Deutschland vorsichtig. Seit dem Fraport Urteil des Bundesverfassungsgerichts[1] reicht es nicht mehr, dass ein Einkaufszenrum o. ä. in privater Hand ist um nach Belieben Dritte vom Zugang auszuschließen. Jedenfalls wenn diese Dritte ihre Grundrechte auf Meinungsäußerungs- und Versammlungsfreiheit dort ausüben wollen. Wie es in Italien ist, das weiß ich nicht. Jedenfalls sind mit dieser Entscheidung deutlich in Richtung öffentlichen Raum gerückt worden. Ich weiß, dass man access=Grundrechtsausübung nicht mappen kann, aber den Vergleich Bauernhof--Einkaufszentrum wollte ich dann doch hier nicht so stehen lassen. Das Urteil stützt sich maßgeblich auf den Fakt, dass die Fraport AG zu über der Hälfte in Besitz der öffentlichen Hand ist: Von der öffentlichen Hand beherrschte gemischtwirtschaftliche Unternehmen unterliegen ebenso wie im Alleineigentum des Staates stehende öffentliche Unternehmen, die in den Formen des Privatrechts organisiert sind, einer unmittelbaren Grundrechtsbindung. (46) Ja, aber erweitert auf z.B. Einkaufszentren in Randnummer 68 ff. und noch stärker 98 ff. Danke! Du hast mir soeben sehr viel Tipparbeit abgenommen :-) Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Am 2. Juni 2014 14:29 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 2. Juni 2014 12:32 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Ja, aber erweitert auf z.B. Einkaufszentren in Randnummer 68 ff. und noch stärker 98 ff. ich glaube kaum, dass dieses Urteil z.B. einen Obdachlosen davor bewahren wird, aus einem Einkaufszentrum geworfen zu werden, bzw. nicht eingelassen zu werden, genausowenig sehe ich Hinweise darauf, dass z.B. Betteln oder Hausieren oder Tanzen oder Musizieren dadurch moeglich wuerde, wenn es bisher verboten war. Und sollen wir das jetzt einzeln je nach Hausordnung mappen oder wie soll ich deinen Hinweis verstehen? Ich finde deine Argumentation daher nicht besonders konstruktiv im Hinblick auf OSM und das Datenschema. Irgend ein Fall wird sich immer finden lassen, auf den es nicht passt. Ich finde das bringt uns nicht weiter. Mein Hinweis auf das Urteil bezog sich nur darauf zu verdeutlichen, dass Einkaufszentren öffentliche Räume sind und bei OSM anders zu bewerten sind als die Privatauffahrt zu einem Bauernhof. Passieren dürfen deine Stadtmusikanten und Hausierer durchs Einkaufszentrum, sie dürfen dort bloß nicht ihrem Beruf nachgehen. Wobei das für Musiker im Hinblick auf die Kunstfreiheit im Lichte des Urteils noch genauer überlegt werden müsste. Das Urteil bezieht sich vielmehr auf die Meinungsaeusserungsfreiheit und die Versammlungsfreiheit, d.h. Kommunikation auch z.B. politischer Natur. Die Aussage, die du hier wieder unterschlägst ist: Einkaufszentren etc. sind öffentliche Räume, die grundsätzlich allen offen stehen, auch wenn sie im Privateigentum stehen und dies auch für Personen, die nicht einkaufen wollen. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geodaten des Bundes
Am 27. Mai 2014 19:38 schrieb Frederik Ramm frede...@remote.org: Hallo, On 05/27/2014 06:31 PM, Stephan Wolff wrote: Es scheint absurd, dass der Bund und OSM die gleiche Bedingung an die Nutzer stellen und die Lizenzen deshalb nicht kompatibel sind. Ist doch aber logisch, oder? Wir verlangen überall wo OSM drin ist, muss auch OSM drauf stehen; weitergehende Forderungen bezüglich der Namensnennung erheben wir nicht. Wenn ein anderer nun sagt überall wo Bund drin ist, muss auch Bund drauf stehen, dann können seine Daten eben nicht in OSM einfliessen, weil wir eben nicht mehr garantieren können, dass später noch Bund draufsteht. In § 3 Nr. 2 GeoNutzV ist vorgesehen: [dass] Veränderungen, Bearbeitungen, neue Gestaltungen oder sonstige Abwandlungen mit einem Veränderungshinweis im beigegebenen Quellenvermerk versehen werden oder, sofern die geodatenhaltende Stelle dies verlangt, der beigegebene Quellenvermerk gelöscht wird.[1] Man muss die geodatenhaltende Stelle, also den Bund, also nur dazu bringen, dass sie die Löschung des Quellenvermerks verlangt, was natürlich Überzeugungsarbeit oder eine Frage geschickter geschickter Argumentation Es könnte sein, dass die Daten durch meine Bearbeitung schlechter werden, die Namensnennung ist doch dann nicht mehr in Ihrem Interesse!? ist. Vielleicht nicht optimal, aber es ist ein Weg. Die GeoNutzV ist die zum GeoZG gehörende Verordnung. Das GeoZG regelt das Ob der Freigabe als Open Data, die GeoNutzV regelt das Wie der Freigabe von Open Data. Gruß Falk [1] http://www.gesetze-im-internet.de/geonutzv/__3.html ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geodaten des Bundes
Am 27. Mai 2014 21:40 schrieb Stephan Wolff s.wo...@web.de: 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. Naja, ein wesentlicher Unterschied ist es meines Erachtens schon, ob man eine Namensnennung verlangt, weil viele freiwillige in ihrer Freizeit etwas zu einer gemeinsamen Sache beitragen, oder ob man einen anderen Grund dafür hat. Ehrlich gesagt ist mir bei Open Government Data noch kein überzeugender Grund für die Namensnennung eingefallen. Vielleicht habt ihr ein paar Ideen? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Am 25. Mai 2014 10:48 schrieb Simon Poole si...@poole.ch: Es ist halt noch eine Heidelberger Leiche und passt nahtlos in die Reihe mit [¯...] Schädigt OSM massiv, aber dass scheint die Leute nicht zu interessieren. Die Community seh ich das nicht in der Pflicht, die kann ja die Server nicht abschalten. Simon Hat denn jemand schon mal den Kontakt zum Lehrstuhl gesucht? Es macht ja wenig Sinn, wenn wir uns jetzt hier alle beschweren und niemand der betreffenden nimmt es zur Kenntnis, weil sie die Liste nicht oder nur sporadisch lesen ... Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern-Mapping
Am 24. Mai 2014 10:27 schrieb Andreas Neumann andr-neum...@gmx.net: Am 24.05.2014 09:52, schrieb Andre Hinrichs: Lösung 5: Gleich dem Ordnungsamt Bescheid geben. Das fände ich schon böse... Das klingt böse, wäre aber der korrekte Weg. Zumal ich die verdutzten Gesichter im Ordnungsamt sehen möchte :D. Warum der korrekte Weg? Bei vielen Komunen ist es in einer Verordnung geregelt, dass jedes Grundstück eine von außen gut sichtbare Hausnummer haben muss. Leider halten sich, insbesondere auf den Vororten (wo doch jeder weiß, dass hier Nummer X ist), recht viele nicht an diese Anordnung. Die Pflicht zur Anbringung einer Hausnummer ergibt sich übrigens aus § 126 Abs. 3 Satz 1 BauGB. Du musst es ja nicht im Sinne einer Anzeige formulieren. Wenn du schilderst was OSM tut und darauf hinweist, welche Probleme du bei den Hausnummern festgestellt hast, dann ergibt sich vielleicht auch die Möglichkeit einer Kooperration -- Straßenlisten u.ä. Das hängt aber auch davon ab, ob dir Kontakt mit Menschen und Ämtern liegt. Vielleicht findet sich ja in der Behörde jemand, der für ein gegenseitiges Geben und Nehmen in diesem Bereich offen ist. Vielleicht sucht ja dere Bürgermeister gerade nach ener Möglichkeit, sich im Bereich des Open Government zu profilieren. Gruß Falk ___ 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 21. Mai 2014 01:25 schrieb Stephan Wolff s.wo...@web.de: Am 20.05.2014 16:17, schrieb Falk Zscheile: Am 20. Mai 2014 10:13 schrieb Sven Anders s...@anders-hamburg.de: 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. Es kommt darauf an, von welcher Seite man das aufzieht. In der von dir geschilderten Richtung sehe ich das genau so. Der Mapper wird -- maschienenlesbar oder nicht -- kaum ein Tag ergänzen, dessen Nutzen begrenzt ist bzw. den er nicht sieht bzw. Nutzen-Aufwand. Wenn jetzt aber die Straßenlistenauswerter einen Korrekturlayer oder ähnliches anbieten, anhand dessen man nicht amtliche Namen auffinden und mit einem Zusatztag versorgen kann, könnte ich mit schon vorstellen, dass sich Leute finden, die das übernehmen. Das ist ja auch ein ziemlich deutsches Problem. Es wird nicht viele Länder auf der Welt geben, wo man es mit amtlich gepflegten Straßenlisten zu tun hat, die einigermaßen stimmen. viele Länder werden das sicher ganz pragmatisch der Post überlassen -- könnte ich mir jedenfalls vorstellen. Vielleicht reicht es aber anhand der addr:*=value Tags an Gebäuden auf Auswertungsseite zu identifizieren, wo es sich nicht um offizielle Namen handelt. das wäre zum Beispiel auch etwas für die Aktion des Monats, Gebäudeumrisse und Adressen für Kleingartenkolonien :-) Wobei das add:*=value Schema wiederum mit den lokalen, in der Kleingartenkolonie verwendeten Adressen kollidieren dürfte. Aber irgendwo beißt sich die Katze immer in den Schwanz :-/ Gruß Falk ___ 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. Mai 2014 10:13 schrieb Sven Anders s...@anders-hamburg.de: Am 19.05.2014 15:52, schrieb Wolfgang Hinsch: Wer es für wichtig hält, kann ja taggen, ob der Name privat vergeben und amtlich anerkannt oder amtlich vergeben und privat anerkannt wurde ;-) Ja, genau das wäre mein Vorschlag: Offizielle Straße name=Dahlienweg source:name=Straßenverzeichniss Hamburg vom 07.05.2009 Kleingartenverein name=Dahlienweg 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. 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. Das setzt Maschinenlesbarkeit voraus. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS 2015 (Uni Münster) Programmkomitee
Ich könnte mir vorstellen, anstelle von Michael im Programmkomitee 2015 mitzuarbeiten. Gruß Falk Am 18. Mai 2014 18:47 schrieb Michael Kugelmann michaelk_...@gmx.de: Hallo allerseits, in den letzten Jahren war ich Mitglied des Programmkomitee der FOSSGIS Konferenz. Mein Schwerlunkt lag dabei auf dem Bereich OSM. Für die FOSSGIS 2015 stehe ich aber leider nicht zur Verfügung, gesucht werden deswegen zur Verstärkung ein oder auch gerne mehrere Vertreter mit Kenntniss der OSM-Szene. Aufgabe des Programmkomitee sind die Bewertung der eingereichten Vorträge und das Zusammenstellen eines ansprechenden Programms für die Besucher. Die Arbeit läuft zum größten Teil im WWW (z.B. pentabarf/FRAB), die Koordination in einer geschlossenen ML. Es gibt eine abschließende Sitzung des PK (physikaisches Treffen), die Teilnahme daran ist aber nicht zwingend. Der Zeitaufwand für die Tätigkeit hält sich in Grenzen, ein Schwerpunkt liegt zum Zeitpunkt des Ende der Einreichungsfrist. Nachfolgend mal der Link zur Orga-Liste: http://www.fossgis.de/wiki/Konferenz_2015/Organisationsteam#Programm-Komitee Ich würde mich sehr freuen wenn es Freiwillige gibt. Grüße, Michael. PS: die Tätigkeit ist nicht an eine FOSSGIS-Mitgliedschaft gebunden, jeder kann mitmachen! ___ 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] Wegenamen in Kleingärten
Am 19. Mai 2014 03:06 schrieb Michael Kugelmann michaelk_...@gmx.de: Am 19.05.2014 00:09, schrieb Hartmut Holzgraefe: Amtlich ist das was der operator als Namen vergeben hat, egal ob öffentliche amtliche Wege in einer Gemeinde, Wege in einer Gartenkolonie, oder Straße auf einem Werksgelände ... und damit ist es name= Insbesondere wenn der Name nicht nur auf Plänen auftaucht sondern Wege auch beschildert sind (ist in vielen Kleingärten der Fall) ist das für mich eindeutig ein name= ich will mal ein paar Anmerkungen einbringen, welche aus einem Gespräch beim Vermessungsamt der Stadt München abgeleitet sind. Ich konstruiere mal einen Fall: in einer Kleingartenanlage passiert ein schwerer Unfall, es wird ein Notarzt gerufen. Die Kleingärtner nutzen OSM-Karten (löblich), und geben Blumenweg als Unfallort an, so wie in der OSM-Karte aufgeführt. Der Notarzt nutzt eine amtliche Karte, dort gibt es keinen Blumenweg, der Notarzt weiß nicht wo er hinfahren soll. Aus derartigen Gründen sind die amtlichen Stellen der Meinung, dass nur offizielle Namen auf Karten erscheinen sollen. Namen in Kleingartenanlagen sind nicht offiziell. Ich kann die diese Argumentation sehr wohl verstehen. Es bestreitet hier auch niemand, dass dies ein wichtiger Aspekt ist. Wir sagen nur: name=value ist bei OSM nicht gleichbedeutend mit official_name=vale oder gar auf diesen beschränkt. Nebenbei in vielen Ländern würdest du mit dieser Ansicht nur Verwunderung ernten. Da sind die Leute froh, dass sie überhaupt eine Adresse haben. Nicht überall ist die Welt so durchadministriert wie bei uns. Als Lösung schlagen einige hier vor das vorhandene Tagginschema so zu nutzen, dass Irrtümer weitgehend ausgeschlossen werden, insbesondere auf der Auswertungsseite zu schauen, ob man dort nicht etwas verbessern kann, bevor man daran geht zu sagen name bedeutet etwas anderes als name Wenn es wirklich keine Lösung auf der Auswertungsseite gibt, dann könnte ich mir auch vorstellen, dass man für nicht amtlich registrierte Wege ein name=value und ein official_name=nonexistent vergibt, obwohl das auch gegen die OSM-Konvention ist und bei den Kartenrenderern vielleicht zu Problemen führt. Es handelt sich bei nonexistent ja schließlich nicht um einen echten Namen, sondern um eine technische Interpretationsregel. Jedenfalls würde ich mich über mehr Beiträge freuen, die über Lösungen nachdenken, die nicht die Inhaltsdefinition von name=value berühren. Gruß Falk ___ 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
Oder anders ausgedrückt, mit Zusatztags beschreiben, was name=value definiert, damit die Mapnik-Karte nicht berührt wird. Obwohl man auch loc_name rendern könnte, wenn name fehlt. ;-) Ich vermute mal, dass das für die meisten der Hauptgrund ist. official_name ist vergeben und sollte nicht umdefiniert werden. loc_name statt name passt IMO, soll aber nicht benutzt werden. source:name=inofficial? name_operator=local? Klingt für mich praktikabel. Wobei ich ja name:source=value besser finde :-) Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wegenamen in Kleingärten
Am 18. Mai 2014 15:37 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Hallo, in vielen Kleingartenanlagen vergeben die Kleingärtner Wegenamen nach eigenem Ermessen. Das führt dann dazu, dass z.B. der Dahlienweg in HH 10x oder öfter existiert, davon aber nur 1x offiziell von der Stadt benannt und in öffentlichen Verzeichnissen vorhanden. Wenn das Tag name für diese Wege benutzt wird, macht das die Navigation nach OSM-Daten unbrauchbar, für jeden Navi-Benutzer wie für Rettungsdienste, Taxi etc. Aber nicht, weil unsere Daten schlecht sind, sondern weil auf Auswertungsseite nicht hinreichend berücksichtigt wird, dass name=value nicht unbedingt deckungsgleich mit offical_name=value ist. Die Auswertung muss also besser werden, nicht (zwingend) die Datenbank. Wir haben, jedenfalls was name* angeht, ausreichend viele Tags um die auftretenden eventualitäten abzudecken. Der Auswerter muss sich etwas einfallen lassen, wenn neben name=value noch offical_name=value, local_name=value, short_name=value etc. auftauchen und nicht übereinstimmen. Ich würde vorschlagen, in Fällen, in denen der Name nicht offiziell ist (es gibt auch offizielle Namen), das Tag loc_name zu benutzen, da der Namen nur lokal im Bereich der jeweiligen Gartenanlage gilt. Name sollte dann nicht vergeben werden. Ich bin der Meinung name=value ist der vor Ort verwendete Name und nicht zwingend der offizielle Name, sonst wäre name auch bei Feldwegen unanwendbar, nur weil sie nicht in der Straßenliste auftauchen. Wir mappen schließlich on the ground. Ein Straße kann auch einen Namen haben, wenn das nicht amtlich festgestellt ist. Die Verwaltung vergibt nur dort Namen, wo sie die für ihre Zwecke braucht. Menschen vergeben Namen auch dort, wo es die Verwaltung nicht für nötig hält. Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber nicht in der Karte. ... und das obwohl die Straße/der Weg von den Leuten die in Nutzen einen Namen hat. Das ist nicht schön ... Ich weiß, bei den Leuten, die Straßenlistenauswertungen betreiben, sind solche basisdemokratisch vergebenen Namen sehr unbeliebt, weil sie die Fehlerquote bei der Auswertung erhöhen, aber das sollte kein Grund sein, solchen Straßen und Wegen das name-tag zu verweigern, nur damit die Statistik stimmt. Mein Vorschlag wäre der folgende: Kleingartenkolonien haben in der Regel auch eine echte Adresse. wenn man gleichzeitig neben dem Vorortnamen name=value noch addr:street=value setzt, kann man das Auswerten und für alle ein brauchbares Ergebnis erzielen. Meinungen? Hiermit geschehen. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 12. Mai 2014 11:39 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 10. Mai 2014 14:17 schrieb Dirk Sohler s...@0x7be.de: Falk Zscheile schrieb: bicycle=designated und foot=designated wird insbesondere im Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt es aber eigentlich access=designated, designated=bicycle, designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen sind. das wäre mir neu, normalerweise taggt man foot=designated bicycle=designated. Das hast du völlig richtig bemerkt. Mein Posting hatte nicht zum Inhalt so müssen wir das bei OSM machen sondern so wäre es (aus meiner Sicht logisch und konsistent Das Problem was ich sehe: Wenn wir mit unserer Mehtode zu taggen ständig nur Einzel- und Sonderfälle verursachen, dann produzieren wir unnötig Kompläxität. Man kann dann anhand der Logik keine Regeln herleiten, sondern muss alle Regeln kennen. Das kann niemand leisten, schon gar nicht in einem Hobbyprojekt. Mehr wollte ich nicht aufzeigen. Was Du oben vorschlägst geht ja schon deshalb nicht, weil jeder Schlüssel nur einmal vorkommen darf. Das generische access sollte man m.E. eher nicht oder sparsam verwenden (d.h. wenn die Regeln für alle Verkehrsarten gelten), ansonsten erhöht man nur unnötig die Komplexität und schließt ggf. Verkehrsarten aus, an die man nicht gedacht hat und die deshalb nicht explizit den generellen Wert überschreiben durch einen spezifischen tag. Etwas anderes ist aber ein Rad-/Fußweg nicht. Er schließt andere Verkehrsmittel aus, soweit sie nicht explizit zugelassen werden. Ich verstehe also im Moment nicht, was du mir erklären willst. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 9. Mai 2014 19:08 schrieb Hubert sg.fo...@gmx.de: die Grüne Box hab ich nicht gesehen. Müsste aufjedenfall mal überarbeitet werden. Ob vorgesehe, gewidmet oder ausgeschildert eingesetzt werden soll, hängt davon ab, was man unter designated versteht. Ich verstehe darunter alle ausgeschilderten Wege (Blaue VZ 237,240,241 oder eventuell sogar Radroutenschilder) aber auch rechte nichtbenutzungpflichtige Radwege (ohne jegliche Beschilderung). Daher empfinde ich verpflichtend auf den Fall als Falsch und ausgeschildert dementsprechend auch nicht passend. designated=value ist, wenn ich das richtig sehe nichts anderes und allgemein gebräuchliche Kurzform von access=designated, designated=value. Wir verwenden aber immer nur bicycle=designated und foot=designated Wie so oft bei OSM passt key=designated natürlich nicht bruchfrei zu access=value, wie es sonst verwendet wird. Sind auch Fälle denkbar wie: access=all, designated=[bestimmtes Fahrzeug]? bicycle=designated und foot=designated wird insbesondere im Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt es aber eigentlich access=designated, designated=bicycle, designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen sind. Alles höchst unbefriedigend, höchst unbefriedigend ... Oder gelingt es jemandem von euch designated und access in ein logisches und für OSM konsistentes Schema zu bringen? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 10. Mai 2014 14:17 schrieb Dirk Sohler s...@0x7be.de: Falk Zscheile schrieb: bicycle=designated und foot=designated wird insbesondere im Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt es aber eigentlich access=designated, designated=bicycle, designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen sind. Zumindest beim Zeichen 241 gilt es eben nicht, da es sich hier rechtlich um zwei direkt nebeneinanderliegende Wege handelt, einen für Fußgänger, und einen für Radfahrer. Streng genommen müssten also zwei Wege gemappt werden, einen mit „access=designated, designated=bicycle“, und einen mit „access=designated, designated=foot“ … Wobei die diversen Sonderfälle und Ausnahmen von der Benutzungspflicht hier noch gar nicht berücksichtigt sind … Also ich habe mich gerade auf der osm-mv liste in Bezug auf Autostraßen aufklären lassen, dass bei Straßen/Wegen die physische Beschaffenheit gemappt wird, also ein geteerter Weg, und nicht die rechtliche Beschaffenheit, eine Spur für Fahrräder und eine Spur für Fußgänger. Im Endeffekt sind es auch mehrere Informationen, die wir getrennt erfassen sollten: 1. der Weg als physische Einheit, 2. ggf. die Aufteilung des Weges in einzelne Spuren, 3. die Benutzungsbedingungen für den Weg bzw. die Fahrspuren. 1. wäre highway=path 2. wäre segregated=yes 3. wäre die access/designated-Problematik Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 10. Mai 2014 14:23 schrieb Hubert sg.fo...@gmx.de: das wird schwierig. Besonders in Hinblick auf backward-capability. Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu highway=footway + footway=sidewalk/crossing. Von der Key:bicycle-Seite steht zu der Werten nur: For values see access=*. Naja, so lange für backward die gleichen access-Bedingungen gelten wie für forward ist es kein Problem, sonst schon ... (Wäre übrigens ein Grund bicycle=use_sidepath nicht zu erlauben) Da bin ich mir nicht sicher. Ohne das Proposal vollständig verstanden zu haben, wäre die Information von bicycle=use_sidepath doch (aus dem Blickwinkel von access) etwa: für die Straße an der das Tag hängt: access:bicycle=no und bicycle=use_sidepath die Zusatzinformation, dass es einen parallel verlaufenden Weg gibt, den der Fahrradfahrer benutzen kann/soll/darf, oder? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 10. Mai 2014 16:11 schrieb Hubert sg.fo...@gmx.de: Am 10. Mai 2014 15:42 schrieb falk.zsche...@gmail.com: Am 10. Mai 2014 14:23 schrieb Hubert sg.fo...@gmx.de: das wird schwierig. Besonders in Hinblick auf backward-capability. Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu highway=footway + footway=sidewalk/crossing. Von der Key:bicycle-Seite steht zu der Werten nur: For values see access=*. Naja, so lange für backward die gleichen access-Bedingungen gelten wie für forward ist es kein Problem, sonst schon ... Ich glaub, da hast du mich missverstanden, oder ich dich gerade. Mit backward-capability meinte ich nicht in Bezug auf die Fahrtrichtung der Straße sondern in Hinblick auf schon in den Daten vorhandene Tags. In der Tat. Habe ich. Aber das Problem haben wir bei OSM immer, wenn sich etwas entwickelt. Und das sich nichts mehr entwickelt, das wollen wir ja auch nicht, denn perfekt ist unser Datenschema, wie mein Beispiel zeigt, noch lange nicht. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Tags = Schlagwörter
Am 28. April 2014 06:25 schrieb Dirk Sohler s...@0x7be.de: Frederik Ramm schrieb: Findet irgendjemand das gut […] Nein. „Tag“ ist, wie viele andere Begriffe, eine Etablierte Bezeichnung. Auch, wenn „Schlagwort“ eine angemessen sinnvolle Übersetzung darstellt, ist „Tag“ die bessere, weil eben etablierte Bezeichnung. Zum Internet sagt ja auch (hoffentlich) niemand „Weltnetz“, auch, wenn die Übersetzung passt :) Da sich mir nach fast 6 Jahren bei OSM immer noch ein innerer Widerstand aufbaut, wenn ich hier Tag schreibe und nicht den Wochentag meine, wäre ich für eine Übersetzung. Attribut oder Eigenschaft fände ich passend. Schlagwort ist etwas anderes und daher nicht geeignet. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Tags = Schlagwörter
Am 28. April 2014 10:03 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Falk Zscheile falk.zsche...@gmail.com wrote: Da sich mir nach fast 6 Jahren bei OSM immer noch ein innerer Widerstand aufbaut, wenn ich hier Tag schreibe und nicht den Wochentag meine, wäre ich für eine Übersetzung. Aha, und bei Montageanleitungen kommt es Dir dann vermutlich auch jedesmal komisch vor, wenn nicht gerade Montag ist %-/ Wenn ich hier der einzige bin, dem es so geht, dann ist es ja gut. Glaube ich aber nicht. Vielleicht deshalb mit Polemik etwas zurückhalten, damit hier nicht gleich alle sagen oh diskutieren macht ja hier eh keinen Sinn, man ernete nur bissige Bemerkungen. Noch weniger Hilfreich sind die Bemerkungen von Dirk a la Weltnetz -- Todschlagargument. Bis unser T(t)ag so allgemein verbreitet ist wie der Begriff Internet hat OSM noch einen weiten Weg vor sich. Also: Wer eine Übersetzung generell für falsch hält, der soll sich doch bitte an die englische JOSM-Version halten. Alle anderen können gern weiter darüber nachdenken, ob es für T(t)ag eine bessere Übersetzung als Schlagwort gibt, oder ob es als Fachbegriff nicht übersetzt werden sollte. Wobei T(t)ag im deutschen nicht besonders intuitiv ist. Das Zeile einer Übersetzung ist doch aber die leichtere Verständlichkeit. Daher meine Vorschläge Attribut oder Eigenschaft. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Tags = Schlagwörter
Am 28. April 2014 13:48 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Worauf ich raus möchte: Lokalisierung ist super, wenn Sie dem Benutzer hilft. Wenn sie aber dazu führt, dass der Benutzer Fachtermini nicht mehr einordnen kann, dann ist sie über das Ziel hinausgeschossen. Soweit sind wir uns einig. Im Falle der tags finde ich, dass das wie bei Interrupt der Fall ist. Mit Schlagwörtern assoziiere ich eine ganze Menge, die key-value tags an Objekten bei osm gehören aber nicht dazu. Auch hier sind wir konform. Daher muss der weg. Schon der Begriff Objekteigenschaften oder Merkmale wäre IMO besser als Schlagwörter, wenn man den englischen Begriff partout nicht beibehalten möchte. Was denkt ihr, sollte man vielleicht eine Umfrage starten, um die am wenigsten Abgelehnte Übersetzung von Tag herauszufinden? Oder warten wir einfach zu, bis jemand einfach Ändert und damit einen neuen Vorschlag in den Ring wirft? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baum der Woche: Kastanie
Am 15. April 2014 09:37 schrieb tumsi tu...@gmx.de: zu taggen. Vielleicht gibt es dann im Herbst eine Kastaniensammelkarte? Sollten wir nicht auch die Bärlauchfelder im Wald mappen, damit man auch in unbekannteren Gegenden schnell mal ein paar Blätter für die Küche sammeln kann? :-) Oh, das ist ein extrem schwieriges Thema. Möglicherweise brauchen wir dann neben dem surface-Tag auch noch ein vegetation-Tag, dass dann auch noch nach Bewuchshöhe differenzieren muss. Wenn unsere Mitgliederzahl auf 100 Mio. aktive (!) Mitglieder gestiegen ist, dann setze ich das Thema nochmal auf die Tagesordnung -- versprochen ;-) Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 5. April 2014 20:38 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 05/apr/2014 um 20:08 schrieb Andreas Labres l...@lab.at: Meine radikaler Lösungsansatz: wir kübeln (gedanklich) alle landuse, natural, leisure, area Tags und machen einen landcover (z.B.) Tag, der die geographisch/kartographisch relevante Flächenbeschreibung wiedergibt. Alles andere ist nur Fallback, falls es keinen landcover Tag gibt ich finde es kein Problem, wenn es überlappende Flächen gibt, solange das jeweils orthogonale Eigenschaften sind. Landnutzung und Bewuchs hängen zwar schon zusammen, im Sinne dass nicht jegliche Kombination möglich ist, aber das hat schon beides seine Berechtigung, getaggt zu werden Was meinst du in diesem Zusammenhang mit orthogonal? Das Problem ist, das wir mit dem offenen on the ground Ansatz von OSM auch ganz oft eine Froschperspektive einnehmen: Ich sehe etwas und geben dem Etwas ein Tag. Allzuoft wird dabei nicht links und rechts geschaut. So finden wir heute viele Tags, bei denen es unterschiedliche Auffassungen gibt und die hier oft für Diskussion sorgen. Das liegt oft nicht daran das man das Tag nicht richtig versteht, sondern weil es unterschidliche Interpretationen zulässt. Das liegt in der Regel daran, dass ein Tag nicht nur eine Information enthält, sondern in der Regel viele, die sich überlagern. Ein Beispiel: highway=track, tracktype=value, ist eine (je nach Sichtweise) lustige bis üble Mischung aus 1. landuse: der Weg führt durch Wald oder Feld, 2. access: da dürfen nur forst- und landwirtschaftliche Fahrzeuge fahren, 3. surface: befestigt, asphaltiert, unbefestigt, etc., 4. highway: es handelt sich um eine Straße. Das Ganze hat man auch bei Radwegen und insbesondere bei Landuse: da wird Nutzung, Bewuchs und Oberflächen lustig in einem Tag zusammengefasst, obwohl man das auch in getrennten Tags erfassen kann und sollte! Verallgemeinernd kann man sagen: die Tags werden um so unbefriedigender und der Streit um so größer, je mehr Einzelinformationen in einem Tag zusammengefasst sind. Man kann sich viel leichter darauf einigen, ob auf einer Fläche Gras wächst als darüber zu diskutieren, ob das eine Kuhweide, Heuwiese, Parkwiese, Rasen, Golfrasen etc. ist. All diese Begriffe haben eben nicht nur die Information Bewuchs, sondern auch noch zumindest eine Information zur Nutzung. Wenn jemand einfach nur Gras mappen möchte muss er sich gleichzeitig mit der Bedeutung dieser vielen unterschiedlichen Nutzungsarten beschäftigen, um das richtige Tag zu finden. Die dabei auftretenden Fehler und Missverständnisse machen in meinen Augen 75 % der Tagstreitereien bei OSM aus -- dabei wollte man doch einfach nur Gras eintragen ... Und vor allem: die geographische Information hier ist Wiese ist entkoppelt von jeglicher Frage wem gehört die Fläche?, wie wird sie genutzt?,... Wiese ist ja eine Nutzung, Grasbewuchs hingegen wäre ein landcover Genau. Und das gehört getrennt erfasst. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 5. April 2014 23:30 schrieb Christoph Hormann chris_horm...@gmx.de: On Saturday 05 April 2014, Andreas Labres wrote: On 05.04.14 20:38, Martin Koppenhoefer wrote: Wiese ist ja eine Nutzung, Grasbewuchs hingegen wäre ein landcover Eben das ist ja das Übel. Das Rendering basiert (in vielen Fällen) auf einer Nutzungsklasse. Wir sollten aber eine kartographisch Oberflächentypisierung haben, wo man Wiese als Wiese klassifizieren kann, Wald als Wald, Weingärten als Weingärten (usw., was man halt kartographisch braucht). Das ganze funktioniert aber selbst in Mitteleuropa nicht - eine Streuobstwiese ist zum Beispiel gleichzeitig eine Wiese und ein Obstbaumbestand. In anderen Gegenden, wo nicht jeder Quadratmeter Erde zugeschnitten und mit deutscher Gründlichkeit verwaltet wird, gilt das noch viel mehr. Wieso nicht, man kann die Informationen doch getrennt erfassen. Aus der Kombination der Informationen ergibt sich dann, dass es eine Obstwiese ist. Nur weil die Welt vielfältiger ist, als man es in Karten abbilden kann, heißt es doch nicht, dass man es gleich lassen soll möglichst einfache Tags zu finden. Einfach heißt in diesem Fall, dass wichtige Informationen möglichst getrennt erfasst werden. Was Du 'Oberflächentypisierung' nennst ist im Grunde vor allem Wunschdenken von Bürokraten, jeder Fläche eine von 20-30 Klassen zuzuweisen. Wie diese Klassen zugeschnitten sind, hängt natürlich von der jeweiligen Zielrichtung ab, immer ist es aber entweder das eine oder das andere und kein Mittelding. Was ist dein Lösungsvorschlag? Man kommt bei einer Datenbank mit geografischen Informationen nun einmal nicht um Abstrahierung herum. Und dort wo man abstrahiert muss man notgedrungen auch klassifizieren. Dazu gibt es keine Alternative. Und wenn es schon keine Alternative gibt, dann sollte man es möglichst in ein handhabbares Schema bringen. Daran fehlt es manchmal bei OSM. In OSM ist das letzendlich nicht anders und natürlich wäre es irgendwie eleganter, das über die Zeit gewachsene System mit seinen inneren Wiedersprüchen durch ein konsistent gestaltetes System zu ersetzen. Das würde aber a) auch nicht perfekt sein und mit der Zeit genauso verkorkst werden wie das jetzige und b) die inherente Problematik einer solchen Klasseneinteilung nicht lösen. Es muss noicht perfekt sein. Gut reicht völlig. Ziel muss es sein, dass jemand der nur Gras eintragen will, sich nicht auch noch mit den verschiedenen Nutzungsarten von Gras auseinandersetzen muss (Weide, Zierrasen, Heuwiese, Parkwiese). Was ist deiner Meinung nach die inherente Problematik einer Klassifizierung? Die Abstrahierung der uns umgebenden Umwelt? Was sehr schön wäre ist, wenn es möglich wäre, die gröbsten Inkonsistenzen durch gezielte und ggf. auch radikale Änderungen an den im Wiki dokumentierten Regeln und entsprechend im Standard-Rendering-Stil zu ändern. Ob das jeweils dann als landuse-, landcover- oder natural-key läuft, ist denke ich egal - die meisten Mapper interessieren sich eh nicht für die Feinheiten der Semantik. Deswegen ist es auch so Wichtig nicht mehrere wichtige Informationen in einem Tag zu verstecken. Eine einfach Semantik im Sinne von nur eine Hauptinformation pro Tag wäre wünschenswert. Es gibt ja immer wieder vernünftige Ansätze in der Richtung, die sich aber meist im Sand verlaufen. Zuletzt wenn ich mich recht erinnere zum Beispiel zum natural=wood/landuse=forest-Chaos, woraus dann aber auch wieder nichts geworden ist (warum eigentlich?). Woran machst du fest, dass sich nichts entwickelt. An welchen Kriterien würdest du erkennen, dass sich etwas ändert oder eben nicht? Nur weil man nicht gleich los zieht und alle natural=wood löscht heißt das doch nicht, dass sich nichts entwickelt. Gruß Falk Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 6. April 2014 14:44 schrieb Christoph Hormann chris_horm...@gmx.de: On Sunday 06 April 2014, Falk Zscheile wrote: [...] Was ist deiner Meinung nach die inherente Problematik einer Klassifizierung? Die Abstrahierung der uns umgebenden Umwelt? Nein, sondern die Notwendigkeit, in jedem Fall eine entweder-oder-Entscheidung zu fällen. Mit einem allgemeinen landcover-Schema gäbe es halt ein landcover=grass und ein landcover=trees und man müsste sich bei der Streuobstwiese unsinnig entscheiden, was man nimmt. Das wäre gegenüber der derzeitigen Situation, wo man zumindest teilweise natural- und landuse-Tags kombinieren kann, nochmals verschärft. Auch wenn man in der gerenderten Karte am Ende vielleicht nur entweder das eine oder das andere darstellt, sollte man das nicht schon bei der Erfassung vorbestimmen. Man soll durch das Zerlegen eines Tags in seine Hauptbestandteile ja gerade eine differenzierte Entscheidung treffen können. Eben zwischen Bewuchs und dessen Nutzung. Das kann ja durchaus redundant zueinander sein: landcover=trees und landuse=park. Landcover kann man vom Luftbild zeichnen, landuse muss einer mit Ortskenntnis ergänzen. Und beim Streit um landuse=park ginge es dann nicht mehr um die Frage ob da Bäume stehen, sondern nur noch um die Frage was einen park sonst noch auszeichnet. Dann wäre landcover=trees und landcover=grass jeweils mit landuse=park. Ich gebe zu kein perfektes Beispiel, aber ich denke man erkennt, was ich meine. Was sehr schön wäre ist, wenn es möglich wäre, die gröbsten Inkonsistenzen durch gezielte und ggf. auch radikale Änderungen an den im Wiki dokumentierten Regeln und entsprechend im Standard-Rendering-Stil zu ändern. Ob das jeweils dann als landuse-, landcover- oder natural-key läuft, ist denke ich egal - die meisten Mapper interessieren sich eh nicht für die Feinheiten der Semantik. Deswegen ist es auch so Wichtig nicht mehrere wichtige Informationen in einem Tag zu verstecken. Eine einfach Semantik im Sinne von nur eine Hauptinformation pro Tag wäre wünschenswert. Ich denke, da sind wir uns weitgehend einig, ich denke aber auch, dass dies eher durch klarere Eingrenzungen bestehender Tags als durch Schaffung vollkommen neuer gelingen könnte. Generell scheint es mir von primärer Bedeutung, dass der Mapper für das, was er sieht, die passenden Tags findet. Dafür ist es oft sehr hinderlich, wenn die Tags in ihrer Bedeutung viele Aspekte kombinieren, wie es ja leider oft vorkommt. Da sind wir uns in der Tat vollkommen einig. Gleichzeitig ist es aber auch erschwerend, wenn der Mapper für die exakte Beschreibung von dem was er sieht ein halbes Dutzend Tags kombinieren muss und der Renderer dann trotzdem nur eines davon für die Darstellung nutzt. Sieht der Mapper zum Beispiel einen Park, ist es durchaus recht praktisch, dass er das leisure=park taggen kann und damit fertig und nicht eine Kombination von landcover=grass trees=yes access=public purpose=recreation sitting=yes walking=yes running=no bike=no children=yes ballsport=no verwenden muss, um das zu umschreiben und der Renderer es dann trotzdem genau wie eine Viehweide darstellt. Ideal ist es natürlich, wenn beides möglich ist, es also fein granulierte Tags gibt sowie shortcut-Tags für gängige Kombinationen. Das würde aber vor allem von den Renderern eine intelligentere Tag-Auswertung erfordern. Ja, ich erkenne das Problem, wenn man ein Tag zu stark in einzelne Informationen zerteilt. Deswegen sprach ich auch von Hauptelementen. Es wäre vielleicht mal ein Hackingweekend ganz anderer Art, wenn man mal einen Workshop zu der Frage veranstalten würde. Meine Idee ist bisher mehrere Hauptkategorien zu bilden, in der Art: Oberflächenbewuchs, Nutzung, Vegetationsform, ???. Dann müsste man schauen, ob sich daraus alle wichtigen OSM-Tags einfach und verständlich wiederfinden. Anhaltspunkt könnten die wichtigsten Kartendarstellungen sein. Dann wäre eine Aufgabe des Wikis eben auch zu sagen, welche wesentlichen Elemente getaggt werden müssen, wenn es ein Park sein soll. Drei Elemente wären da schon die äußerste Grenze. Gewisse Redundanzen können ja durchaus hilfreich sein landuse=park landcover=trees. Wie gesagt, könnte ein interessantes Workshop-Wochenende werden ... Allein schon die Frage, ob es überhaupt möglich ist, wäre spannend ... Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 5. April 2014 06:24 schrieb Andreas Labres l...@lab.at: On 04.04.14 20:24, Tobias Knerr wrote: wenn die Fläche als area:highway getaggt ist - also das Gegenstück zum Riverbank-Modell. Klingt gut, aber das Proposal ist doch tot... Man könnte es wiederbeleben. ein Phänomen von OSM ist ja auch, dass manche Mapper bzw. Communitys aufgrund ihrer Spezialisierung oder mangels anderer Objekte ein Problem schon so früh entdecken, dass alle anderen Mapper nur mit den Schultern zucken. Es kann durchaus sein, dass diese früher schulterzuckenden Mapper früher oder später auf die gleiche Problematik stoßen und dann genug Mapper vorhanden sind, um einem Taggingvorschlag zum Durchbruch zu verhelfen. Es kann daher nie schaden, ein Problem immer wieder auf die Mailingliste zu bringen und auf einen Durchbruch zu hoffen. :-) Stand heute ist, dass Flächenmapper highway=footway (z.B.) Wege entfernen und durch pedestrian areas ersetzen. Und damit das Routing kaputten. Und wenn ein anderer Mapper footways zeichnet (durchaus in sinnvollem und anschaubarem Ausmaß), werden die wieder entfernt. Das ist natürlich nicht in Ordnung, weil es dem OSM-Grundsatz von leben und leben lassen. Zumal Straßenvektorenmapping und Straßenflächenmapping sich nicht wirklich widersprechen bzw. gegenseitig behindern. Hier wird scheinbar so verfahren als gebe es bereits eine allgemein akzeptierte Lösung. Straßenflächen habe ich auch schon einmal gemappt (natürlich unter Belassung der Straßenvektoren), weil mich die auf einen Straßenvektor gepappten Flächennutzungsgebiete (landuse) gestört haben. Der Straßenvektor wurde also als Grenze genutzt und alles miteinander verbunden -- sehr unschön. Also habe ich die Straßen als Fläche eingetragen und diese Straßenfläche mit den angrenzenden Flächennutzungen verbunden. Sieht besser aus und lässt sich auch im Editor viel besser handhaben. Und natürlich entspricht es auch eher der Realität. Ist status quo sehr unbefriedigend. In der Tat, insbesondere wenn sich die Mapper gegenseitig auf die Füße treten und sich gegenseitig bei ihrem Hobby behindern. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Mapnik-de: Schöneres Rendering von Sportplätzen
Am 5. April 2014 15:22 schrieb Sven Geggus li...@fuchsschwanzdomain.de: am französischen Stil gefällt mir das Rendering von Sportplätzen besonders gut. [...] Deashalb habe ich das mal in die klassische xml Syntax von Mapnik konvertiert und in den deutschen Stil eingebaut. [...] Sehr schön! Vielen Dank! Sieht toll aus! Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 4. April 2014 14:23 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 3. April 2014 20:52 schrieb Falk Zscheile falk.zsche...@gmail.com: 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. Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da eine Lösung: access:traffic_sign=DE:value und parking:traffic_sign=DE:value und maxspeed:traffic_sign=DE:value @Falk: Siehe oben, ich würde Verkehrsschilder immer dort mappen, wo sie stehen (nicht am Ende der Sackgasse). Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. wie ist denn der tag für ein Straßennamen-schild? In den name-tag des highway gehört der Name der Straße, das ist nicht zwangsläufig was auf dem Schild steht. Dass überhaupt Straßennamenschilder getaggt würden ist mir neu, macht aber vielleicht schon Sinn, vor allem in den Fällen, wo die Beschriftung vom Namen abweicht (wobei ich da noch ein note zusätzlich anbringen würde um den anderen Mappern mitzuteilen, dass es sich um eine geprüfte Abweichung und nicht um einen Tippfehler handelt). Ich würde in dem Fall aber auch auf einem Node taggen. Ok, lass uns Haarespalten :-) Da es bei Verkehrsschildern nur eine Bedeutung gibt, Verkehrsschilder sind nämlich immer richtig geschrieben, kann es hier schon von Anfang an keine differenzierung zwischen old_name, official_name, short_name etc. geben. Damit läuft dein Argument hier völlig ins leere. Und im übrigen bleibt es dabei: Erste Quelle für einen Straßennamen ist das Straßenschild und den trägt man nicht dort ein, wo das Schild steht, sondern als Namen auf dem Straßenvektor. Ich erinnere mich noch gut an die Klagen, von Leuten, die versucht haben die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das hat bei Stoppschildern nicht funktioniert, das funktioniert bei Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen Augen falsches Konzept übernehmen. [...] Die Frage ist, was man durch die Angabe des Schild-tags erreichen will. Mit Deinem System taggst Du Deine Interpretation / Kenntnisstand auf den gesamten Way für den Fall, Falsch! Ich trage das ein, was vor Ort ausgeschildert ist. Das schöne an einem Verkehrsschild ist ja gerade, das es eine feste Definition hat und einer Uminterpretation durch OSM-Nutzer, das OSM-Wiki oder was auch immer unproblematisch widersteht. dass die OSM-tags nicht eindeutig sind, bzw. um anzugeben, aufgrund welcher Schilder diese tags gewählt wurden. Was aber trotzdem passieren kann ist, dass Du ein oder mehrere Schilder übersiehst, oder dass das Schild nur für eine Richtung gilt oder so. Und, das ist ein Problem der Erfassung und nicht des Taggingschemas. Das problem besteht bei maxspeed in genau dieser Form und wird durch foreward: backward: gelöst. Wer dann danach kommt und an anderer Stelle der Straße Unstimmigkeiten findet (d.h. z.B. ein anderes Schild mit anderem Inhalt als dem getaggten) hat dadurch keine Hilfe, (z.B. Dein Schild zu finden), und wenn er ein Schild findet, das Klar, er geht aufmerksamer die Straße ab und schaut ob es eine Erklärung für das falsche mapping gibt. Dann korrigiert er oder setzt einen Bug. so arbeiten wir ... Du übersehen hast, (z.B. ein Maxspeed), dann weiss er nicht genau, von wo bis wo das neue Schild gilt. Wenn man hingegen alle Schilder taggt und danach noch weitere findet, muss man nicht unbedingt eine komplette Neubegehung machen um die Informationen zu ergänzen, weil sich das neue Schild in die vorhandenen einfügt. Sorry, aber du musst schon so viel vertrauen haben, dass ich in der Lage bin, Dinge richtig einzutragen. Mir wegen potentiellem Fehlmappens von meinem Schema abzuraten ist etwas eigenartig. Wenn das ein Grund wäre, dann müssten wir die ÖPNV-Schemas erst recht verbieten ;-) Es ist sozusagen näher an der Realität und erfordert keine oder kaum Interpretation, um ein Schild als Node einzutragen, während das Übertragen eines Straßenschildes auf einen linearen way bereits eine Abstraktion / Interpretation ist, die auch mal (z.B. für einen Teil des ways) fehl liegen kann. Naja, wir werden uns nicht einig werden, wie so oft :-) Gruß Martin Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de: 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. Nein, entweder ist es redundant oder klarstellend. Aber jedenfalls keine Förderung von Doppelbedeutungen, denn im Gegensatz zu noexit=yes hat access:traffic_sign=DE:397 einen festen Bedeutungsinhalt, den du in der StVO nachschlagen kannst. 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. Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da eine Lösung: access:traffic_sign=DE:value und parking:traffic_sign=DE:value und maxspeed:traffic_sign=DE:value 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. Ich bin optimistisch, dass die Vorteile meines Taggingingvorschlags auch andere zu würdigen wissen und sie vermehrt auftreten werden. Zur Not kann sich der Auswerter damit begnügen den value auszuwerten und zu schauen, ob der für seine Zwecke relevant ist. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. Aha? Übrigens heißt access nicht Zugangsbeschränkung sondern Zugang und darüber trifft traffic_sign=DE:397 sehr wohl eine Aussage. PS.: So handhabe ich es auch bei der Radweg-/Fußweg-/-kombinations-/Poblematik. Aber hoffentlich nicht mit access-Tags. s. o. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 15:20 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de: 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. +1, ich würde wenn ich Schilder erfassen würde (was ich derzeit nur für Ortseingangsschilder und Geschwindigkeitsbegrenzungen, und Höhen-, Breiten- und Gewichtsbegr. mache), das nicht an den Weg taggen, sondern an einen node, eben so, wie man es auch antrifft. Dabei setze ich das Schild in Fahrtrichtung rechts des Wegs in einem geringen Abstand, so dass die Richtung normalerweise klar wird (bisher noch keine Ausnahme angetroffen, gibt es aber vielleicht, kann man i.d.R. durch Optimieren der Abstände regeln). Wenn man das Schild an den way setzt, dann führt das hinterher zu ähnlichen Folgefehlern (durch Splitten des ways, Verschieben der Endnodes etc.) wie bei den übrigen tags auch. \begin{Ironie}So wie wir die Straßennamensschilder auch dort eintragen wo sie stehen, aber keinesfalls den Namen an der Straße selbst, denn da steht ja kein Namen auf den Asphalt gemalt?\end{Ironie} Die Information gehört dorthin, wo sie sinnvoll ist und dass ist am highway=value! So machen wir das bei oneway, maxspeed, maxweight/hight etc. Also warum nicht auch bei allen anderen Verkehrsschildern, die sich auf ein Wegstück und nicht auf einen Punkt (Fußgängerüberweg, Ampel) beziehen? Diese Schilder sehe ich als ggf. hilfreich für andere Mapper an, aber ich erwarte davon nicht, dass deren Aussage von Datenkonsumenten wie Router etc berücksichtigt wird, von daher setze ich das zusätzlich zu den entsprechenden Auswirkungen / Interpretationen, die mit den entspr. osm-tags auf den Weg-segmenten getaggt werden. Ich trage die die Verkehrsschilder auf dem weg ein für den sie gelten -- fertig. Was andere damit anfangen interessiert mich nicht, freue mich aber natürlich, wenn es jemand nützlich findet. Und mir persönlich hilft es klarzustellen, was genau für StVO-Eigenschaften der Weg hat. aus vielen OSM-Tags geht das ja leider nicht klar hervor, man denke nur an die Fuß-/Radwegproblematik ... Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 20:30 schrieb Tobias Knerr o...@tobias-knerr.de: Am 03.04.2014 20:16, schrieb Falk Zscheile: Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Der Wert von traffic_sign kann ausdrücklich eine Semikolon-getrennte Liste von Schildern und Schildergruppen enthalten. Was genauso wenig ausgewertet wird, wie mein System. Mit Aufzählungen im value-Bereich tut man sich meines Wissens auch sehr schwer, oder? Bei mir ist nur klarer (für den Mapper), in welchem Bereich das Verkehrsschild eine Regelung trifft. Ich nehme eine Kategorisierung vor, indem ich access, parking, maxspeed dazu nehme. Am deutlichsten wird es bei maxspeed: maxspeed=30 und maxspeed:traffic_sign=DE:274-53. Da ist beim ersten lesen klar, um was es geht. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 20:39 schrieb Florian Schäfer flor...@schaeferban.de: Am 03.04.2014 20:16, schrieb Falk Zscheile: Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de: Am 01.04.2014 10:14, schrieb Falk Zscheile: 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. Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da eine Lösung: access:traffic_sign=DE:value und parking:traffic_sign=DE:value und maxspeed:traffic_sign=DE:value @Stefan: Nein, siehe oben. Das Schild beschreibt, wie ausgeschildert ist, noexit, wie die Realität aussieht. @Falk: Siehe oben, ich würde Verkehrsschilder immer dort mappen, wo sie stehen (nicht am Ende der Sackgasse). Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. Ich erinnere mich noch gut an die Klagen, von Leuten, die versucht haben die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das hat bei Stoppschildern nicht funktioniert, das funktioniert bei Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen Augen falsches Konzept übernehmen. Zum Schildertagging würde ich sagen, ich tagge traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab. Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder, die mancher in parking, ein anderer in access einordnen würde. Was genauso wenig ausgewertet wird, wie mein System. Mit Aufzählungen im value-Bereich tut man sich meines Wissens auch sehr schwer. Kennst du eine Anwendung, die das mittlerweile auswertet? Ich nehme eine Kategorisierung vor, indem ich access oder maxspeed dazu nehme. Gerade bei der zunehmenden Flut von tags an Straßen finde ich das sehr hilfreich. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. Aha? Übrigens heißt access nicht Zugangsbeschränkung sondern Zugang und darüber trifft traffic_sign=DE:397 sehr wohl eine Aussage. @Falk: Es könnte sein, dass Stefan meint, dass das Schild neben dem Weg am Anfang der Sackgasse steht und dort kein noexit=yes hinkommt. Guter Hinweis! Danke :-) Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 21:13 schrieb Florian Schäfer flor...@schaeferban.de: Am 03.04.2014 20:52, schrieb Falk Zscheile: Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. Ich erinnere mich noch gut an die Klagen, von Leuten, die versucht haben die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das hat bei Stoppschildern nicht funktioniert, das funktioniert bei Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen Augen falsches Konzept übernehmen. Aber Du möchtest doch wie ich das verstanden habe auch punktförmige Schilder mappen, oder? Nein, das möchte ich nicht. Zum Thema mit den Straßennamen, siehe meine andere Mail zum Unterschied zwischen Aussage eines Schilds und Schild. Zum Schildertagging würde ich sagen, ich tagge traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab. Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder, die mancher in parking, ein anderer in access einordnen würde. Was genauso wenig ausgewertet wird, wie mein System. Was weder ein Argument für das eine, noch für das andere System ist. Absolut richtig. Meines gefällt mir nur besser :-) Mit Aufzählungen im value-Bereich tut man sich meines Wissens auch sehr schwer. Kennst du eine Anwendung, die das mittlerweile auswertet? Ich habe vor einiger Zeit mal eine gebaut (zwar nicht im Zusammenhang mit Straßenschildern, sondern mit POIs) ;-P. Und so schwer wäre das auch nicht umzusetzen. Gut zu wissen. Und schön zu hören, dass es Fortschritte gibt. Ich nehme eine Kategorisierung vor, indem ich access oder maxspeed dazu nehme. Gerade bei der zunehmenden Flut von tags an Straßen finde ich das sehr hilfreich. Die Kategorisierung ist aber durch den Value für traffic_sign schon impliziert. Du hättest dann Probleme mit so etwas wie maxspeed:traffic_sign=DE:250 Das würde dann in etwa bedeuten: Die Höchstgeschwindigkeit ist, dass hier kein Fahrzeug durchfahren darf. Ich gebe zu, dass Problem hätte man nicht, wenn man alles in eine Aufzählung von traffic_sign packt. aber für sotewas gibt es ja keep it right und ähnliches (falls sich meine Idee jemals durchsetzen sollte). Mit meinem System des kategorisierenden Taggens von Verkehrsschildern hat man aber zumindest die Chance Fehler bei der Eintragung zu erkennen. Bei einer Aufzählung aller an der Straße vorhandenen Verkehrsschilder sind die Möglichkeiten, um fehler zu erkennen, ungleich geringer, weil der key hier nicht die Richtung für den value angibt. Dies führt zu einem generellen Problem bei so abstrakten Angaben wie die StVO-Nummer von Verkehrsschildern. Bei amenity=secondary wird jeder stutzig bei traffic_sign=DE:4711 nicht unbedingt. Übrigens, nur um es klarzustellen: Ich bin eigentlich kein Fan vom Tagging von Verkehrsschildern. Das ist mir nicht entgangen :-) Wenn das aber gemacht wird, dann sollte die Art und Weise möglichst einheitlich sein und ein gewisser Konsens dazu herrschen, sonst wird es niemals ausgewertet werden. Ich nehme die hier vorgebrachten Einwände mit Interesse zur Kenntnis, auch wenn sie mich im Augenblick nicht überzeugen. Man muss ja auch mal was ausprobieren und schauen, ob man damit mehr bestehende OSM-Probleme löst als neue schafft :-) Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Hallo Florian, vielen Dank für die Zusammenfassung. So etwas gibt es hier viel zu selten. Am 31. März 2014 20:56 schrieb Florian Schäfer flor...@schaeferban.de: Am 30.03.2014 13:57, schrieb Florian Schäfer: A: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357) B: Durchlässige Sackgassen auf öffentlichen Straßen (Zeichen 357-50 oder 357-51) C: Privatwege auf Privatgrundstücken (z.B. Hausauffahrten), die an dem einen Ende unverbunden sind D: Wege, die an Hauseingängen enden (Endnode ist Teil eines building-ways und hat entrance=main/yes) E: Wege, die Zufahrten zu Garagen sind (Endnode ist Teil eines building=garage-ways) Bei dieser Zusammenfassung wird wieder einmal das Grundproblem von OSM deutlich: Ein Tag wird mit viel zu vielen verschiedenen Informationen belegt (siehe A-E), obwohl man die auch in unterschiedlichen Tags erfassen könnte. In der Belegung eines Tags mit zu vielen unterschiedlichen Informationen liegt meines Erachtens auch ein wichtiger Grund für die vielen ergebnislosen Diskussionen in Threads. Die wenigsten machen sich klar, dass es sich faktisch um Doppelbedeutungen eines Tags handelt. Um diese herauszuarbeiten ist ein Thread hilfreich, allerdings nur, wenn man das Ergebnis am Ende auch zusammenfasst. Zusammenfassungen wie du sie gerade gemacht hast sind daher sehr hilfreich, auch für künftige Diskussionen. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 1. April 2014 09:51 schrieb NopMap ekkeh...@gmx.de: Hi! Deiner Darstellung muß ich einem wesntlichen Punkt deutlich widersprechen. Florian Schäfer-2 wrote Bei C habe ich herausgehört, dass dort das noexit=yes-Tag akzeptiert ist, aber nicht unbedingt von allen aktiv gesetzt wird. D und E waren noch nicht so ganz klar, insbesondere hat sich da gezeigt, dass das entrance-Tag an manchen Stellen präzisiert oder um Hilfstags ergänzt werden könnte Allgemein kann man glaube ich sagen, dass dieses Tag (ähnlich dem fixme=continue oder note=*) ein Tag nur zur Kommunikation unter den Mappern und zur Signalisierung von false-positives an die QA-Tools ist. noexit ist *kein internes Tag für Mapper* sondern stellt eine wertvolle Information dar, deren Anzeige auf Karten im Offroad-Bereich absolut nützlich ist. 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. Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Damit ist jedem klar, dass es sich nicht um eine interne Mappinginformation handelt, sondern um eine echte Information. Leider funktioniert das nur wenn es explizit ausgeschildert ist. Außerdem besteht das Problem, dass es mehrere Accessinformationen auf Straßenschildern geben kann, die sich so nicht abbilden lassen, weil es dann access:traffic_sign:#1 und access:traffic_sign:# geben müsste. Access habe ich davor gesetzt, weil es auch andere Verkehrsinformationen für die straße geben kann, z.B. maxsspeed:traffic_sign=value Gruß Falk PS.: So handhabe ich es auch bei der Radweg-/Fußweg-/-kombinations-/Poblematik. Mit einem ausdrücklich am Weg gemappten Verkehrsschildinformation wird alles etwas klarer. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS-Konferenz: Lightning Talks
Moin Frederik, falls noch Platz ist und niemand sonst möchte, dann könnte ich sicher auch etwas sagen :-) Gruß Falk Am 19.03.14 schrieb Frederik Ramm frede...@remote.org: Hi, falls jemand auf der FOSSGIS ist und das hier liest - bitte bei mir melden, wenn ihr einen Lightning-Talk halten wollt. Der OSM-Lighting-Talk-Slot ist am Donnerstag 13:30. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ 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] Hochsitze / Bitte um Entfernung von Daten
Am 14. März 2014 08:56 schrieb Andreas Schmidt schmidt-postf...@freenet.de: Die Herren Hobbyschlachter müssen sich halt damit abfinden, dass ihre Freizeitbeschäftigung bei einem Teil der Bevölkerung nicht besonders hoch angesehen ist. Das widerrechtliche Beschädigen von Leitern, das ich ablehne, kann nicht mit Geheimhaltung verhindert werden. Ebenso wie Spaziergänger darauf achten müssen, nicht gegen Stahlseile ( http://abload.de/img/absperrung1ljsqy.jpg ) zu laufen, die von einem Jäger quer über den Weg gespannt wurden, sollten Letztgenannte im eigenen Interesse die Stabilität ihrer Schießstützpunkte vor dem Erklettern prüfen. Das hat nichts mit OSM zu tun, das ist so. Also bevor das jetzt hier zum Jägerbashing verkommt sollten wir aufhören. Die Sachargumente wurden vorgetragen und haben breite Zustimmung gefunden. In den letzten Beiträgen treten aber vermehrt (also nicht in allen) Argumentationslinien wie (Alle) Jäger sind schlecht, deshalb erst recht nicht auf. Das haben wir nicht nötig, um unseren hier gefundenen Standpunkt zu vertreten. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Am 13. März 2014 12:06 schrieb Frederik Ramm frede...@remote.org: Hallo, die DWG war vor einiger Zeit mal in einen Edit-War involviert, in dem ein Nutzer Waldwege und ähnliches gelöscht hat, was er für schädlich hielt (nach dem Motto: da ist gar kein richtiger Weg, nur ein Trampelpfad, und das Wild wird durch die Wanderer verjagt usw.usw.). Die DWG hat den Nutzer damals gebeten, das eigenmäctige Löschen von solchen Daten zu unterlassen und einige Löschungen revertiert. Nun erhalte ich (als der User, der den Revert gemacht hat) eine Nachricht von dem, der damals die Löschungen vorgenommen hat: == Sehr geehrter Nutzer, Sie haben bei OSM jagdliche Hochsitze im Bereich des Velber Holzes (südlich Harenberg) kartiert. Ich möchte Sie hiermit bitten, diese Punkte wieder zu entfernen, da es dadurch zu erheblichen Problemen kommt. Es gab bereits erfolgte Straftaten, die durch eine anonyme Organisation dort verübt wurde. Somit danke ich Ihnen für das kurzfristige entfernen. Bei Rückfragen danke ich Ihnen für eine Kontaktaufnahme. MfG, Fidibus21 == Ich weiss nicht ganz, wie ich darauf reagieren soll. Einerseits nervt es mich, dass er nicht locker lässt. Diese Hochsitze sind nunmal da, also können sie auch gemappt werden. Andererseits ist es ja eigentlich gerade erwünscht, wenn man mit Daten unzufrieden ist, dass man dann mit den anderen Mappern darüber spricht, statt alles gleich zu löschen. Ich finde das aber mit den Straftaten ein bisschen komisch, das klingt, als wollte man den Mapper unter Druck setzen und ihn zum Mittäter machen, wenn er nicht freiwillig seine Hochsitze löscht... Bei Hochsitzen handelt es sich um jagdliche Einrichtungen. Deren rechtlicher Status ist in den Landesjagdgesetzen geregelt. Im niedersächsischen LJagdG heißt es in § 2 Abs. 2: Die jagdausübungsberechtigte Person kann anderen das Betreten der jagdwirtschaftlichen Einrichtungen verbieten und sie zum Verlassen dieser Einrichtungen auffordern. In § 41 Abs. 1 nds LJagdG heißt es: (1) Ordnungswidrig handelt, wer 1. entgegen § 2 Abs. 2 einem Verbot zuwiderhandelnd jagdwirtschaftliche Einrichtungen betritt oder diese entgegen einer Aufforderung nicht verlässt; [...] Es handelt sich also um eine Ordnungswidrigkeit, wenn an dem Hochsitz ein Schild Betreten verboten steht und man es zum Mappen trotzdem betritt. Eine Straftat ist es nicht. Die Regeln sind von Bundesland zu Bundesland etwas verschieden. Manchmal ist das Betreten generell verboten, manchmal nur wenn ein Schild angebracht ist. Ein Verbot solche Hochsitze zu erfassen und in einer Karte darzustellen ergibt sich meines Erachtens nicht, so lange man sie nicht betritt. Worauf die betreffende Person aber vermutlich hinaus will: Radikale Tierschützer nutzen die Daten unter Umständen, um die jagdlichen Einrichtungen zu beschädigen. Die Beschädigung ist eine Straftat (§ 303 StGB). Für einem Mapper aber durch Erfassung der Daten eine Beihilfe (§ 27 StGB) zur Sachbeschädigung zu konstruieren, halte ich für sehr weit hergeholt. Generell ist das bei Jägern ein heikles Thema. Da sie für ihr Jagsausübungsrecht Geld bezahlen setzt sich leicht ein Anspruchsdenken der Wald gehört mir durch. Das ist aber nicht bei allen Jägern so. Je intensiver die Freizeitnutzung eines Waldes ist und je höher die Jagdpacht, desto dünnhäutiger reagieren die meisten Jäger. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Am 13. März 2014 13:20 schrieb Richard Z. ricoz@gmail.com: On Thu, Mar 13, 2014 at 12:51:22PM +0100, Falk Zscheile wrote: Worauf die betreffende Person aber vermutlich hinaus will: Radikale Tierschützer nutzen die Daten unter Umständen, um die jagdlichen Einrichtungen zu beschädigen. Die Beschädigung ist eine Straftat (§ 303 StGB). Für einem Mapper aber durch Erfassung der Daten eine Beihilfe (§ 27 StGB) zur Sachbeschädigung zu konstruieren, halte ich für sehr weit hergeholt. wäre mir nicht so sicher mit den Tierschützern - mindestens genauso oft kommt es wohl vor, daß da Konkurenz am Werk war. Die meisten Wilderer haben einen Jagdschein, aber dass sich Jäger die Hochsitze gegenseitig zersägen, davon habe ich noch nichts gehört. Nun ist so ein Hochsitz in der Regel eine Art lnadmark, wenn man die löscht oder zerstört kann die Orientierung erschwert sein. Sicher, aber wenns dem lieben Frieden dient kann man zumindest einmal darüber nachdenken, ob man dem Jäger einen gefallen tun möchte. Man muss es vielleicht auch nicht gleich in der Datenbank löschen, sondern kann die Daten mit einem Tag versehen, dass normalerweise nicht ausgewertet wird. Wenn es kein eigenjagdbezirk ist besteht zumindest die Hoffnung, dass der Jagdausübungsberechtigte irgendwann wechselt. Jedenfalls haben wir das Recht Hochsitze zu mappen. Wie man auf die wünsche der Jagdausübungsberechtigten reagiert muss vor Ort entscheiden werden. OT: Wer das jagdliche Thema vertiefen will, dem empfehle ich die filmische Satire: Halali oder der Schuss ins Brötchen. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Ich denke alle hier im Thread sind sich einig, dass Jäger keinen Anspruch darauf haben, dass wir ihre Jagdeinrichtungen aus der Datenbank nehmen. Aber bitte -- blicken wir doch ein wenig über den Tellerrand. Wem ist geholfen wenn wir auf dieser Meinung beharren und einen endlosen Editwar bekommen und Frederik dann jede Woche Hochsitze wiederherstellen muss, damit sie dann wieder gelöscht werden können ... Vielleicht kann eine teporäre Herausnahme (z.B. durch Änderung des Keys) den Jäger davon überzeugen, dass seine Hochsitze auch ohne OSM beschädigt werden und die Leute auch so in den Wald gehen. Immerhin hat der Jäger angefragt, wenn auch nicht sehr höflich, und nicht gleich Hand an die Daten gelegt. Aber man kann das Löschen-Wiederherstell-Spiel natürlich auch spielen, bis eine Seite die Lust verliert. Wir haben das Recht dazu! Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Am 13. März 2014 17:34 schrieb malenki o...@malenki.ch: On 13.03.2014 15:42, Falk Zscheile wrote: Vielleicht kann eine teporäre Herausnahme (z.B. durch Änderung des Keys) den Jäger davon überzeugen, dass seine Hochsitze auch ohne OSM beschädigt werden und die Leute auch so in den Wald gehen. Immerhin hat der Jäger angefragt, wenn auch nicht sehr höflich, und nicht gleich Hand an die Daten gelegt. Ehe man an so etwas denkt, würde ich um Raum-Zeit-Koordinaten zerstörter Hochsitze bitten und nachschauen, ob diese überhaupt oder zu welchem Anteil zum Zeitpunkt der Zerstörung in OSM eingetragen waren. Das würde dich und mich überzeugen, aber niemanden, der schon fest daran *glaubt* OSM sei die Wurzel seines Übels. Da helfen rationale Argumente leider oft nicht weiter. Da müssen esoterischere Lösungen gefunden werden ... oder eben auch nicht. Die Mehrheit geht hier ja sehr eindeutig in Richtung drin lassen und gut. Seis drum, ich wollte nur ein paar andere Lösungsstrategien aufzuzeigen. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reihenhäuser / 3D-Tagging // Re: 1000 Hausnummern
Am 9. März 2014 10:45 schrieb Peter Wendorff wendo...@uni-paderborn.de: Hallo Ralf, Selbst tagging NUR für den Renderer wäre im Grunde doch okay. Problematisch wird es, wenn NUR für den Renderer, aber GEGEN korrekte Daten oder GEGEN andere Anwendungen getagged wird. Das, wo taggen für (und natürlich insbesondere NUR für) den Renderer, kritisiert wird, betrifft vor allem falsche Tags, um richtige Darstellungen zu erzielen, also: [...] Sehr schön erklärt. Das hätte ich auch so schreiben sollen. Leider hatte meine polemische Seite die Regie bei der Antwort auf Ralfs Posting übernommen. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reihenhäuser / 3D-Tagging // Re: 1000 Hausnummern
Am 9. März 2014 00:18 schrieb Ralf GESELLENSETTER r...@gmx.de: Und schließlich: 3D-Tagging ist Tagging NUR für den Renderer, oder? Habe ich hier Ironie übersehen? Bei dir mag die Erde eine Scheibe sein. Bei mir in der Gegend stehen auf der Scheibe immerhin noch dreidimensionale Gebäude. Wieso sollen Tags, die versuchen die dreidimensionale Wirklichkeit abzubilden, tagging für den Renderer sein? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Visualisierung von (notwendigen) Postdienstleistungen
Hallo Liste, wir ärgern uns in meinem Wohnort gerade über die Deutsche Post AG. Sie hat (nach den bisher bekannt gewordenen Informationen) sehr spontan ihre Filiale bei einem privaten Betreiber abgebaut, so das der Ort nun ohne Filiale dasteht. Gibt es die OSM-Karte noch, mit der Postniederlassungen und Briefkästen bzw. deren Einzugsradius visualisiert werden? Nach der Post-Universaldienstleistungsverordnung werden hierfür sehr präzise Vorgaben gemacht, die sich anhand einer Karte gut überprüfen lassen. Falls es die Karte nicht mehr gibt -- kennt jemand Alternativen? Danke Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Visualisierung von (notwendigen) Postdienstleistungen
Am 7. März 2014 13:02 schrieb Benjamin Lebsanft benja...@lebsanft.org: Hallo Falk, so wie es aussieht, war der Betreiber der Seite des Postboxguesstimators ne Weile nicht aktiv: http://toolserver.org/~mazder/pboxguesstimator/?lat=48.72521lon=9.32674zoom=13layers=BTT Schade eigentlich. Alternativen kenne ich keine, die Postkarte ist ja auch schon ne Weile offline: http://post.openstreetmap.de/ Hallo Benjamin, vielen Dank für die Info. Der Name Postboxguesstimator war mir entfallen -- obwohl er eigentlich ziemlich originell ist. Schade, dass es nichts fertiges mehr in der Richtung gibt. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Visualisierung von (notwendigen) Postdienstleistungen
Am 7. März 2014 [beschrieben Johannes Kröger und Stephan (User SB79) einen Weg etwas Postboxguesstimatorartiges zu erzeugen/wiederzubeleben.] Oha, ich glaube da wage ich mich als NichtGISler und Nichtinformatiker nicht allein heran. Ist vielleicht jemand auf der FOSSGIS und könnte mir einer ruhigen Minute die Benutzung der Werkzeuge zeigen? Danke Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Natural Wood = Forest Landuse
Ich finde auch, dass die Unterscheidung von natural=wood und landuse=forest wie wir sie jetzt haben ziemlicher Unfug ist. Das war meiner Meinung nach auch nur eine Notlösung, weil man feststellte, dass man schon beides in der Datenbank hat. um nicht in das richtig oder falsch Schema zu verfallen hat man den Kompromiss ersonnen, das eine sei ein Naturwald, das andere ein forstwirtschaftlich genutzter Wald. Für das Grau dazwischen bleibt kein Raum. Auch lässt sich mit diesem Tagging das Problem nicht wirklich lösen, das der eine nur Wald sieht, ein anderer aber deutlich mehr. Das ist bei natural=wetland geschickter gelöst: Da sieht einer nur sehr feuchte Erde und trägt natural=wetland ein. Ein anderer erkennt aber, dass in dieser feuchten Erde Bäume stehen und ergänzt wetland=swamp, ein anderer sieht, das in der feuchten Erde Schilf steht und ergänzt wetland=reedbed. Logisch gesehen ist für Schilf und sumpfiger Wald die übergeodnete Kategorie waserdurchdrungenes Land. Es ermöglicht also sowohl Laien als auch Profis etwas zum Datenbestand beizusteuern. Bei natural=wood und landuse=forest habe wir diese Möglichkeit nicht, da muss man sich gleich, wenn man einen grünen Flecken Erde auf dem Luftbild sieht entscheiden ob das ein Naturwald ist oder ein Forst. Eigentlich ein Ding der Unmöglichkeit außer man Kategoriesiert ganz grob: Dschungel immer Naturwald, alles in Mitteleuropa Nutzwald (Forst) -- dann kann mans aber auch gleich sein lassen, denn so eine grobe Unterteilung nutzt niemandem wirklich. Und auf normalen Landkarten (Jehova) sind sowieso alle Wälder nur grün ... Dabei gibt es da so viele unterscheidungsmöglichkeiten: Nach Nutzung- oder Bewirtschaftungsart (Hochwald, Mittelwald, Niederwald), nach Vegetationsform (Laubwald, Mischwald, Nadelwald), Vegatationszonen (Gebirge, Bergland, Hügelland, Tiefland), Bewuchshöhe/Altersklassen (Dickung, Stangenholz, Baumholz, Altholz) ... Kurzum ich sehe einen langfristigen Reformbedarf. Die Reform wird aber wohl nicht ohne Mithilfe der OSM-Mapnikkarte zu haben sein. Ich höre schon die Stimmen auf allen Kanälen: Mein Wald wird nicht mehr gerendert, weil ihn irgendein nichtsnutziger, unwissender, bösartiger und gemeiner User von landuse=forest zu natural=forest geändert hat. Der hat doch gar keine Ahnung, mein tagging ist natürlich richtig, es wird ja in der Mapnikkarte dargestellt [...] ansonsten kann man natürlich auch versuchen das Schema nach unten aufzubohren, ohne gleich natural=wood und landuse=forest zu verdammen. Vermutlich die erfolgversprechendere Variante, da es der Mehrheit ja reicht, das ein Wald grün ist :-) Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintrag von Gewann-Namen
Am 27. Februar 2014 23:16 schrieb Bernhard Weiskopf bweisk...@gmx.de: Hallo an alle, wie trägt man in OSM die Namen von Gewannen ein, dass sie in Mapnik angezeigt werden? Wenn das Gewann nicht noch in einzelne Felder unterteilt ist, so würde ich es einfach an das entsprechende Feld als name-Tag setzen. Andernfalls hilft vielleicht auch eine site-Relation (?). Schließlich gibt es noch place=locality name=value. Letzteres wird auch für Fälle wie deinen gebraucht. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]
Am 28. Februar 2014 11:59 schrieb Markus liste12a4...@gmx.de: OSM sammelt Geo-Daten welche die Wirklichkeit da draußen beschreiben. OSM ist eine *Weltkarte*. /Dafür/ werden Geo-Daten erhoben und in einer DB abgelegt. Nein, OSM ist eine Datenbank, die geographische Informationen sammelt. *Karte und Daten* ist eine systemische Einheit. Nein, Daten und Karte sind systematisch getrennt. Man kann aus den Daten alles mögliche machen. Von Statistik bis Routing, ist alles möglich. Karten sind nur ein kleiner, wenn auch der eingänglichste, Anwendungsbereich. Das erfordert eine gezielte Zusammenarbeit zwischen denen die Daten sammeln und denen die sie anzeigen, bzw denen die die Karte nutzen :-) nein, die Zusammenarbeit muss zwischen Datensammlern und Datennutzern erfolgen. eine der großen Herausforderungen von OSM ist es, ein Datenschema zu entwickeln, das mehr taugt, als eine Karte zu malen. Das Problem ist: man kennt die konkrete Anwendung der Daten nicht. Wenn man sich immer nur auf Karten fixiert (welche eigentlich -- Papierkarten, Onlinekarten, Routingfähig oder nicht) verbaut man sich vielleicht andere Anwendungsmöglichkeiten. Man kann sollte das Datenschema nicht unter dem Gesichtspunkt Kann man damit eine schöne Karte malen? sehen sondern Bilde ich damit die Wirklichkeit eindeutig und verständlich ab? eine mögliche Benutzung dieser Daten ist das Rendering mit Mapnik Mapnik ist /die Karte/ :-) Nein, Mapnik ist ein Renderer und und die Karte auf openstreetmap.org das Ergebnis einer Renderanweisung. Ich mag das Renderergebnis, wie es auf opentopomap.de erscheint viel mehr :-) Die Karte auf openstreetmap.org ist eine gute (!) Standartanwendung, aber nicht das maß der Dinge. Selbstverständlich /kann/ man aus den Daten auch noch viele und tolle Spezialanwendungen machen: Spezialkarten, Routing, Statistik, ... genau Und selbstverständlich brauchen Anwendungen sinnvolle Datenschemen als Grundlage. Deshalb sind Daten(-Struktur) immer als Einheit mit der geplanten Anwendung zu betrachten und zu verstehen - und zu entwickeln und zu verbessern. Du meinst für jede Anwendung ein eigenes Datenschema? Übertrieben würde das heißen, man muss Wege nicht verbinden, wenn man nur eine Karte braucht. Die Leute, die Routing betreiben sollen möchten dann bitte ein eigenes Schema haben, bei dem sie ihre Straßen verbinden. Das kann es nicht sein. Ziel sollte schon die universelle Nutzbarkeit der Daten sein ... Gruß Falk Stil Ein einheitliches Erscheinungsbild hilft OSM als Marke zu etablieren. Dabei sind Ziele zu erfüllen wie schnelles Orientieren und Erkennen, schnelles präzises Finden, sinnvolle Verknüpfung von Information, etc. Iterativ und gemeinsam ist das Optimum zu finden. Dabei kann man gute Fremd-Beispiele nutzen und die besten Ideen daraus übernehmen. Es macht aber m.E. wenig Sinn, diese nur deshalb nachzuahmen, weil man sie gewohnt ist. Bei den iterativen Suchprozessen macht es auch Sinn, immer mal wieder etwas ganz anderes auszuprobieren - um die gefundenen Essenzen dann synergetisch in das Produkt zu integrieren. Es macht aber m.E. wenig Sinn, viele Skins zu haben. - - - - Zur Frage nach dem Rendering von Gewann-Namen: Namen von Gegenden helfen bei der Orientierung. Solche Namen auf der Karte zu haben ist ein sinnvolles Anliegen. Solange wir dafür kein brauchbares Konzept haben, werden Benutzer immer wieder versuchen, die Namen irgendwie so in die DB zu schreiben /damit/ sie gerendert werden. 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