Hi SuGri,

no, you don't have to add points of interest to OSM a second time to make them appear on Wheelmap.

Wheelmap has a few bugs relating the usage of OSM data. In general, Wheelmap also supports points of interest which are mapped as areas (closed ways) but many recent (last modified or created less than two years ago) objects are missing their. It is their fault. See https://github.com/sozialhelden/wheelmap/issues/690 for further information.

Wheelmap does not display all points of interest which are mapped in OSM. However, you must not add wrong or misleading tags to objects in order to make them appear on wheelmap.org. That's called tagging for the renderer. osm.wiki/Tagging_for_the_renderer

OSM is not the backend of Wheelmap. It is used by thousands of other applications and millions of users. Adding wrong or duplicated data to OSM in order to make a buggy application work, harms all of them. It is the responsibility of the operator of Wheelmap to provide a good application. Having an event tomorrow is no excuse.

Btw, please keep in mind that organised edits should be announced in advance to the local community and the community should have a reasonable time to discuss. This is quite important if the event involves lots of new users. There are no fix rules for these kinds of acitivities but a consensus among the community (especially in Germany). See osm.wiki/Directed_Editing_Policy for details. If your activity is against the will of the community, introduces a lot of errors into OSM and you (and your team) don't fix them within the following hours, the community might decide to revert all contributions because it is easier then investing hours of volunteer time to separate the good from the bad contributions.

I would like to ask you not to use Wheelmap for an mapping event. The app contains multiple bugs:

(1) Some features mapped as areas in OSM are not shown there (see above). These makes users to add them again.

(2) Sometimes features are added hundreds of kilometers away from their correct location because the app has a bug and uses the last known location (or a default location).

(3) The app invites users to add features at the location returned by the geocoder. This leads to multiple objects stacked on top of each other which is not good editing practice.

Please use the online editor iD on www.openstreetmap.org instead.

This message does not sound positive but I don't want to see you running into the same issues as a similar acitivity in Offenbach am Main a few weeks ago. https://lists.openstreetmap.org/pipermail/talk-de/2018-October/115378.html Their edits have been reverted due to too much quality issues.

Best regards

Michael

Hi Lathifah AI,

welcome to OpenStreetMap.

I have reverted this changeset (and therefore deleted your additions and restored your deletions). Please do not add fake data (e.g. roads in the Atlantic Ocean) to OpenStreetMap. OSM is a serious project, not a sandbox. Your contributions go live immediately and millions of users rely on it.

Best regards

Michael

Hallo Christoph,

gescheite Such-/Geocodingdienste wie Nominatim werten alle name-Tags aus, also nicht nur name=*, sondern auch short_name=*, long_name=*, official_name=*, loc_name=*, alt_name=* und die Sprachvarianten davon name:en=*, short_name:en=* usw.

Viele Grüße

Michael

@samguer

Please look at the tag list of every OSM object before you start modifying it. The iD editor you use is not suitable for your task because it hides the list of tags in the bottom left of the window.

The way in question had razed:highway=* without highway=* which is a sign for any mapper that this way only exists to couchmappers to "correct" it to match the so-called "Bing reality".

Please keep in mind that I have reverted all changesets of your company in Europe in the past due to quality issues. That revert was supported by users on the German OSM forum.

Hallo RBG CUP LMU,

Abkürzungen gehören bei uns nicht in name=*, sondern in short_name=*.

OSM ist keine Werbeplattform. Unsere Datennutzer entscheiden, wie sie was darstellen. Bei OSM handelt es sich um eine Datenbank für Geodaten, die unter anderem, aber nicht nur für die Erstellung von Karten verwendet wird und nicht die Datenbasis für eine spezielle Karte. Eine weitere häufige Verwendungen unserer Daten ist das Geocoding (Suche nach Namen und Adressen). Da ist es wichtig, dass die Namen Namen sind und keine Beschreibungen!

Die Karte auf www.openstreetmap.org ist nur ein Beispiel, was mit den Daten gemacht werden kann. Wenn du Daten gezielt so (falsch) erfasst, dass sie in einer bestimmten Art und Weise auf einer bestimmten Karte erscheinen, handelt es sich um sogenanntes Tagging für den Renderer.

Deshalb sind in meinen Augen folgende Namen falsch: "BioSysM Bayerisches […]", "Haus C Pforte, Pharmazeutische Chemie", "Haus B Pharmazeutische Biologie, Pharmazeutische Technologie", "Haus D Anorganische Chemie" u.v.a.m.

Wenn das Gebäude "Haus D" genannt wird, ist sein Name "Haus D". Die Einheiten, die darin ansässig sind, müsstes du separat erfassen, z.B. als Nodes mit university=institute + name="Institut für Pharmazeutische Biologie".

Viele Grüße

Michael

Hallo staytuned,

könntest du bitte künftig, Multipolygon-Relationen nur noch anlegen, wenn die Fläche mehr als einen äußeren Ring mit mehr als 1000 Nodes [1] hat oder mindestens einen inneren Ring hat?

Ich habe beobachtet, dass du systematisch als geschlossene Ways gemappte Fläche in Multipolygonrelationen umwandelst, die genau einen äußeren Ring haben und genauso gut mit einem geschlossenen Way abgebildet werden können. Diese Mappingweise schadet mehr als dass sie nützt:

1. Multipolygone neigen dazu, kaputt zu gehen, weil nicht alle Editoren vor dem Hochladen die Multipolygone auf Gültigkeit prüfen. Bei geschlossenen Ways passiert das seltener.

2. Zwar mag es auf den ersten Blick sinnvoll erscheinen, sich überlappende Ways zu vermeiden, weil man dann "doppelte Daten" vermeidet. Die Praxis ist aber eine andere. Relationen sind für Datennutzer aufwendiger zu verarbeiten. Um die OSM-Rohdaten in die für das Rendering verwendeten PostGIS-Datenbank zu importieren, muss man die OSM-Datei mehrfach einlesen oder aufwendige temporäre Zwischenspeicher anlegen. Das kostet RAM und/oder Zeit und erschwert die Nutzung unserer Daten. Das ist nicht im Sinne des Projekts.

Wenn man hingegen geschlossene Ways verwendet, genügt es die OSM-Rohdatendatei ein einziges Mal einzulesen, um daraus Linienzüge, die aus einer Liste an Koordinaten bestehen, zu erzeugen (die Art und Weise, wie im GIS-Sektor Geometrien gehandhabt werden und mit der PostGIS, Mapnik & Co. arbeiten).

3. Es fällt nicht nur Neulingen, sondern auch vielen erfahrenen Mappern schwer, in Gegenden mit intensivem Multipolygoneinsatz (manche sprechen dann von "Multipolygonteppichen" oder "Multipolygonitis") Landnutzungsdaten zu ändern. Stattdessen lassen sie die Änderungen bleiben. OSM ist ein Gemeinschaftsprojekt und sollte daher der breiten Masse an Mitwirkenden zugänglich bleiben. Schließlich sind es auch diese, die Fehler korrigieren.

Falls du anderer Ansicht bist, steht es dir frei, obiges in einem geeigneten Forum oder auf einer geeigneten Mailingliste zu diskutieren oder dich über mein Verhalten bei der Data Working Group der OSM Foundation zu beschweren.

Viele Grüße

Michael

[1] Ways können maximal 2000 Nodes haben. Es ist daher legitim, geschlossene Ways mit sehr vielen Nodes durch Multipolygone zu ersetzen.

Hallo,

dir ist schon bewusst, wie alt dieser Änderungssatz ist? Ich begrüße es ausdrücklich, wenn du die Mitteldeutsche S-Bahn von light_rail auf train umstellst. Das ist so richtig und anerkannt für sämtliche Wechselstrom-S-Bahn-Netze der DB in Deutschland.

Als Autor des Public-Transport-Teils des OSMI kann ich dir sagen, warum light_rail dort angemeckert wird. light_rail ist nicht Teil von PTv2 und der OSMI erlaubt nichts, was der Standard nicht erlaubt.

Viele Grüße

Michael

One week is appropriate for the discussion but one day only is just a joke.

Wenn du etwas revertierst, hast du dafür zu sorgen, dass wertvolle und erhaltenswerte Beiträge anderer Benutzer, die später erfolgt sind, erhalten bleiben. Wenn du das nicht leisten willst oder kannst, sind Reverts, bei denen Konflikte auftreten von dir zu unterlassen. Einen derartig unsorgfältigen Umgang mit den Leistungen anderer Mapper widerspricht dem Communityprinzip und rechtfertigt einer Benutzerkontensperre, um ein friedliches und produktives Zusammenwirken der Community sicherzustellen.

Hi Glassman,

could you please pause this import and give the community on the Imports mailing list a reasonable time to discuss the import before you continue it? You posted to the imports mailing list on 2018-10-14 18:29 UTC and started importing on 2018-10-15 17:27 UTC (22 hours and 58 minutes later).

https://lists.openstreetmap.org/pipermail/imports/2018-October/005737.html changeset/63550100

Urgency is no justification to skip a import discussion.

Best regards

Michael

Hallo,

die GTFS-Daten stehen unter CC-BY. Hat OSM jemals eine Befreiung von der Namensnennung und den anderen inkompatiblen Bedingungen der CC-BY erhalten?

Viele Grüße

Michael

Hallo johndoe,

könntest du mir bitte die obige Frage beantworten, bevor du weitere Änderungssätze hochlädst?

Viele Grüße

Michael

Hallo,

der Reisendenübergang in Forchheim (b Karlsruhe) ist vor etwa einem Jahr zurückgebaut worden. Ich habe ihn soeben wieder gelöscht. Der Zugang zu Gleis 2 erfolgt durch die Unterführung.

https://www.karlsruhe-basel.de/aktuelles/aenderung-der-fussgaengerwege-am-bahnhof-forchheim.html

Ich kenne mich dort recht gut aus, da ich dort regelmäßig vorbeikomme.

Viele Grüße

Michael

Jedes Nebengleis ist service=yard, außer es ist ein Anschluss- oder Ladegleis, dann ist es service=spur. Wenn du eine bessere Formulierung hast, dann darfst du das Wiki gerne ändern.

Hallo Negjana,

danke für die Antwort.

Arrrgh, das genau dassselbe Begriffsproblem, das wir vor drei Jahren in Deutschland entdeckt hatten. Rurseekatze hat damals im Januar 2014, als er die von dir verlinkte Wikiseite angelegt hat, den Begriff "Nebengleis" nicht verwendet, wie es im Bahnsektor üblich ist, sondern die laienhafte Sichtweise, dass alles, was kein durchgehendes Hauptgleis ist ein Nebengleis ist.

Auf den Wikiseiten DE:Key:service, DE:Key:usage und DE:OpenRailwayMap/Tagging sowie DE:OpenRailwayMap/Tagging_in_Germany habe ich das damals korrigiert. Die österreichische Seite hatte ich vergessen und jetzt nachgeholt.

Viele Grüße

Michael

Hallo Negjana,

das ist in Deutschland genau gleich.

Du schreibst:

"Laut Taggingschema ist service=siding sowohl für 'nicht-durchgehende-Hauptgleise' sowie Nebengleise, welche nicht yard oder spur sind, zu verwenden. Wo bleibt da die Eindeutigkeit?"

Von welcher Wikiseite hast du das denn?

Viele Grüße

Michael

Hallo Negjana,

dein Ziel kannst du auch mit usage=* und service=* erreichen. service=siding sind nicht duchgehende Hauptgleise (also Hauptgleise, die nicht die Verlängerung der Gleise der freien Strecke sind), service=yard sind Nebengleise, die keine Anschlussgleise oder Ladegleise sind. service=crossover sind Überleitgleise zwischen durchgehenden Hauptgleisen, service=spur sind Lade- und Anschlussgleise.

Die falsche Verwendung eines bestehenden Tags ist kein Grund, extra ein neues zu erfinden. Stattdessen ist die Zeit sinnvoller investiert, die falsche Verwendung zu korrigieren und die Benutzer, die das Tag falsch verwenden, per Änderungssatzkommentar auf die falsche Verwendung hinzuweisen.

Du machst in diesem Punkt fast denselben Fehler den Mentz schon einmal gemacht hat: Sich nicht über die korrekte Verwendung und die Existenz eines bestehender Tags bewusst sein und deshalb ein neues erfinden bzw. ein uraltes aus einem gammligen, historischen Proposal von vor zehn Jahren ausgraben. Mentz hat damals priority=* mit der Gießkanne verteilt, du jetzt railway:track_type=*.

Ich möchte dich daher bitten, railway:track_type=* durch richtig verwendete usage=* und service=* zu ersetzen.

Viele Grüße

Michael

@freebeer I reverted the two other changesets adding a shop=supermarket called "L***** E***** F********".

This changset has been reverted by changeset/63395792.

Hallo erde23,

wo ist denn dokumentiert, dass das OpenStreetMap-Projekt das ALKIS des Landes Brandenburg als Quelle verwenden darf? Meines Wissens nach ist das nicht der Fall, ich lasse mich aber mit einem entsprechenden Beleg überzeugen.

Am 20. September habe ich dich schon einmal nach der Freigabeerklärung des Liegenschaftskatasters in Mecklenburg-Vorpommern gefragt. Eine Antwort hatte ich auf diese Frage nicht bekommen und deshalb die dortigen Änderungen zurückgesetzt. changeset/60813860

Viele Grüße

Michael