OpenStreetMap
highflyer74's Comments
| Changeset | When | Comment |
|---|---|---|
| 74494984 | almost 3 years ago | Da keine Rückmeldung erfolgte, habe ich den Node jetzt entfernt. Nach https://www.wikidata.org/wiki/Q67584367 müsste der Stein wohl in Mainz statt in Verden liegen. |
| 127740886 | almost 3 years ago | Moin und willkommen bei OSM! Eine wichtiger Punkt, den wir bei OSM beherzigen ist, dass wir Objekten nur Namen geben, wenn sie auch wirklich einen Namen haben. Beispielsweise ist "Allerhaus" ein Eigenname, "Kapelle" aber nicht. Letzteres ist lediglich eine Beschreibung (diese wird durch andere Tags abgebildet, hier: building=chapel für die Art des Gebäudes und amenity=place_of_warship für die religiöse Nutzung). Auf einem zusammenhängenden Gelände wie dem Jugendhof ist das nicht ganz so schlimm, aber ich wollte dich nur kurz auf den Unterschied hinweisen. Weitere Informationen dazu, wie wir Dinge mappen, findest du u.a. hier: - osm.wiki/DE:Good_changeset_comments - osm.wiki/File:Osm-tutorial.pdf Wenn du noch Fragen hast, melde dich gern! |
| 130764607 | almost 3 years ago | Moin! Beim Hinzufügen der Parkplätze und anderer Flächen sind SEHR viele Geometriefehler entstanden: (obiges ist nur noch einige Stunden sichtbar, da ich die Fehler gleich repariere) Eigentlich sollte JOSM dir dies auch als Fehler anzeigen. Insofern wäre es gut, wenn du dir diese Meldungen noch einmal anschaust, bevor du die Daten hochlädst. Generell: - versuche, Überlappungen zu vermeiden. - ein Stellplatz sollte aus vier Nodes bestehen, mehr sind nicht notwendig. - es gibt für JOSM entsprechende Tools, um viele gleich große Flächen zu erzeugen. Dies verbessert die Qualität der Geometrien. - achte darauf, ob Nodes miteinander verbunden sind, oder nicht, und ob sie es sein sollten, oder nicht. Wenn du noch Fragen hast, melde dich gern! |
| 130514966 | almost 3 years ago | Danke :-) |
| 130514966 | almost 3 years ago | Moin! Ich hab aus Neugier mal mit Every Door einen mir bekannten POI angesehen, welcher das disused:*=* Präfix trägt (dies wird für leerstehende Geschäftsräume genutzt). Dort wird der Node auch angezeigt und in den Daten darunter als "durchgestrichen" dargestellt. So richtig intuitiv ist das nicht. Am Ende ist es immer am besten, wenn man sich die Rohdaten anschaut. Generell zum Lifecycle Präfix: wenn etwas nur kurz nicht geöffnet hat, würde ich es gar nicht ändern. Nur langfristige Dinge sollten in OSM erfasst werden. Und: dann am besten alle Tags, die nicht mehr zutreffen löschen. Das vermindert die Gefahr, dass alte Daten am Objekt verbleiben, wenn ein neuer POI dort einzieht. Mir fiel das türkische Restaurant in der 129 auf, wo nur das Haupt-Tag geändert wurde. Ist der Laden komplett ausgebrannt, oder wird nur nach einem Brand etwas renoviert? Davon würde ich das Tagging abhängig machen. Gruss aus HB! |
| 130256731 | almost 3 years ago | Moin! Noch ein kleiner Tipp hier: wenn du mit StreetComplete Dinge editierst, schau bitte immer genau nach, für welches Objekt die Frage gestellt wird und wie dieses aussieht. Mir fiel z.B. hier way/134236087 auf, dass das Parken entlang der Straße unterschiedlich zu sein scheint und deshalb die Frage in StreetComplete so nicht zu beantworten ist, da der Weg in OSM dafür nicht richtig aufgeteilt ist. In so einem Fall ist es besser, keine Daten zu habe, als falsche Daten. Alternativ müsste man die Straße in Abschnitte aufteilen und diesen dann die korrekten Tags geben. Viele Grüße! |
| 130334660 | almost 3 years ago | Moin zusammen! Eine kleine Anmerkung hierzu noch: @Winschu eine MP Relation ist nicht notwendig, um ein einfaches Gebäude zu mappen. Ich habe die Relation wieder entfernt und das Gebäude zu einem Gebäude gemacht, welches die Adresse trägt. Viele Grüße und kommt gut ins neue Jahr! |
| 130514966 | almost 3 years ago | Moin nochmal! Hier wurde ein neues Restaurant angelegt (node/10287449619), obwohl in dem Gebäude bereits ein Node sitzt, welcher mal ein Restaurant war und dann auch für das neue genommen werden sollte (node/7843839523). Ich kenne mich mit der Every Door App nicht aus, aber vermutlich solltest du weiter reinzoomen, damit du alle vorhandenen Dinge angezeigt bekommst. Achte bitte auch darauf, Telefonnummern im internationalen Format +49 xxx xxxxxxxx einzugeben, ohne Striche, Klammern etc. Auch sind mehrere Telefonnummern als Wert nicht optimal. Du kannst statt dem klassischen phone=* das Contact-Schema nutzen, um eine Festnetz und eine Mobilnummer zu setzen (contact:phone=* und contact:mobile=*). Ich habe jetzt die Daten vom neuen Node auf den alten Node übertragen (osm.wiki/DE:Good_practice) und die Formatierung angepasst. Viele Grüße! |
| 130320371 | about 3 years ago | Moin Gerd! Danke für deine Rückmeldung. Wenn du es selbst vor Ort gesehen hast, ist das natürlich in Ordnung. Versuche möglichst, das bei deinen Änderungen auch zu dokumentieren. Es muss aber nachvollziehbar sein, soll heißen, es muss eine Adresse am Gebäude sichtbar sein. Leider sind Behörden in Teilen Deutschlands nicht besonders kooperativ, was die Verwendung von amtlichen Daten in OSM anbelangt. In anderen Bundesländern ist das teilweise sehr viel besser. Eine Übersicht über erteilte oder angefragte Datenfreigaben kannst du hier finden: Vor Ort anschauen ist noch immer am sichersten und genauesten :-) Schönen Tag dir! |
| 130320371 | about 3 years ago | Moin! Kurze Frage: was hast du hier als Datenquelle genommen? Die Daten vom LGLN sind für uns als OSM tabu, da wir keine Freigabe für die Nutzung haben. Wenn das also deine einzige Quelle ist, muss dieser Änderungssatz zurückgedreht werden, ebenso alle anderen, die in gleicher Form entstanden sind. Das geht nicht gegen dich, aber es ist immens wichtig, dass wir nur zulässige Quellen verwenden, um juristische Auseinandersetzungen zu vermeiden. Sei so nett, kurz hier zu antworten, damit wir gemeinsam eine Lösung finden können. Viele Grüße aus HB! |
| 130359980 | about 3 years ago | Moin und willkommen bei OSM! Sei so nett, nur einen Namen zu vergeben, wenn etwas auch einen Namen hat. "Trinkwasser" ist kein Name. Versuche bitte auch, deine Änderungen auf einen kleineren Bereich zu beschränken. Dieser Änderungssatz reicht über halb Europa. Wenn du noch Fragen hast, melde dich gern! |
| 130258918 | about 3 years ago | Danke! Ich habe da jetzt nochmal dran herumgeschraubt, da es sich ja nicht um viele kleine Parkplätze handelt, sondern um einen großen. Den habe ich jetzt hinzugefügt und die kleinen Inseln in Stellplätze umgebaut. Schönen Tag! |
| 130239304 | about 3 years ago | Auch hier bitte: keine Namen an Objekte setzen, welche keinen haben. Diese Ladestation heisst nicht "Ladestation DC 50kW / AC 22kW", sondern es handelt sich um eine Ladestation, was sich durch die entsprechenden Tags ergibt. Schau dir dazu bitte den passenden Wikiartikel an: osm.wiki/DE:Tag:amenity%3Dcharging_station Danke! |
| 49766111 | about 3 years ago | Moin! Ist schon etwas her, aber bei dem von dir hier in eine MP-Relation umgemappten Parkplatz stellt sich die Frage, warum du ein MP gewählt hast. Kannst du dich da noch dran erinnern? Das Wiki sieht so etwas nicht vor (amenity=parking) und nach meinem Verständnis handelt es sich bei dem südlichen Teil um einen Parkplatz, den man auch einfacher als Fläche mappen kann. Viele Grüße aus HB! |
| 130191281 | about 3 years ago | Moin und danke für deine Rückmeldung! Ja, "outer" wäre richtig(er), aber grundsätzlich ist es sehr fragwürdig, warum der Parkplatz so gemappt ist. Offensichtlich ist es ein Parkplatz und den kann man ganz normal als Fläche und ohne Relation mappen. Ich schreibe nachher mal den ursprünglichen Mapper an. Mal gucken, was der Beweggrund ist. Vielleicht kann man das gemeinsam lösen. Schönen Tag dir! |
| 130239227 | about 3 years ago | Moin und willkommen bei OSM! Sei so nett, darauf zu achten, nur Namen zu vergeben, wenn etwas auch wirklich einen Eigennamen hat. "LPG-Tankstelle" ist kein Name, sondern beschreibt die Eigenschaften eines Objekts. Dies ist nicht notwendig, da bereits über amenity=fuel und fuel:lpg=yes alles gesagt ist. Mir fiel auch auf, dass hier jetzt drei Tankstellen auf kleinstem Raum gemappt sind. Einmal die von dir hinzugefügte, dann am Gebäude (bereits seit 2011) und dann noch einmal als Node im östlichen Teil des Gebäudes. Da ich vermute, dass eigentlich alles eine Tankstelle ist: hast du gesehen, dass diese Tankstelle (way/102578217) bereits fuel:lpg=yes trägt? Wenn die von dir eingetragene auf dem Gelände der Tankstelle steht, sollten wir die Daten dort halten. Den Node im östlichen Teil habe ich jetzt entfernt und die Daten mit obiger Tankstelle zusammengeführt. Gruss aus HB! Anbei noch ein wenig interessanter Lesestoff: |
| 130183143 | about 3 years ago | Danke für die Rückmeldung! Die Nutzung des osm.wiki/DE:Lifecycle_prefix deinerseits ist völlig korrekt gewesen, da das Gebäude auf allen akutellen Luftbildern noch vorhanden ist. Nur die Art und Weise, wie es gemacht wurde, ist nicht ganz richtig, da es sich um ein komplexes Gebäude handelt, dessen Einzelteile in einer Relation zusammengefasst sind. Ich passe das eben entsprechend an. Danke! |
| 130191281 | about 3 years ago | Moin! Sei so nett, nicht pauschal die Verbesserungsvorschläge des Online Editors iD zu übernehmen. Das funktioniert oft nicht gut: Hier wurden automatisch Bestandteilen einer Relation Rollen vergeben. Man sollte sich eher fragen, ob diese Relation(en) so sinnvoll ist / sind. Kannst du dir das bitte einmal ansehen? Danke! Wenn du Hilfe brauchst, melde dich gern! |
| 130183143 | about 3 years ago | Moin! Ich wollte mal fragen, was hier genau beabsichtigt war. Ist das gesamte Gebäude abgerissen worden? Viele Grüße! |
| 130024162 | about 3 years ago | Moin und vielen Dank für deine Rückmeldung! Meine Empfehlung wäre, es so zu lassen, wie es aktuell ist. Die Idee dahinter will ich kurz darlegen: wie du richtig erkannt hast, ist eine "Verschachtelung in der Verschachtelung" recht unübersichtlich für diejenigen, die dort in Zukunft mappen. Das sollte man nicht unterschätzen. Gerade neue User haben kein Verständnis für Relationen bzw. wie sie in OSM funktionieren. Der Wikiartikel zum Thema Schutzgebietsgrenzen (osm.wiki/DE:Tag:boundary%3Dprotected_area) lässt einem die Wahl zwischen einer einfachen Fläche und einer Relation. Grundsätzlich möchten wir immer alles so einfach wie möglich mappen, aber in diesem Fall kommen wir nicht um die Nutzung von Relationen herum. Generell werden Grenzen in OSM gern losgelöst von sonstiger Geometrie gemappt. In diesem Fall geht das meines Erachtens nach auch nicht anders, da die Flächen nicht deckungsgleich sind. Die Ausschnitte im Osten und der Teil im Westen unterscheiden sich von der vorhandenen Moorlandschaft. Du sprachst davon, erreichen zu wollen, dass "das Hochmoor wieder "über" dem Wald liegt". Grundsätzlich kümmern wir uns ja nicht darum, was ein spezieller Renderer aus den Daten macht (osm.wiki/DE:Taggen_f%C3%BCr_den_Renderer). Das Rendering auf osm.org ist in Ordnung (man muss nur sehr genau hingucken, um das Moor von dem Moor mit Wald zu unterscheiden), in der App OsmAnd ist die Unterscheidung deutlicher zu sehen. Die Schutzgebietsgrenze sollte eigentlich daran nichts verschlechtern. Die Frage die sich stellt ist: stellt das Tagging die Realität dar? Aktuell trägt trägt die Relation selbst die Tags für Moor und Wald und das Inner des MPs nur die Moortags. Da ich keine Ortskenntnis habe, kann ich nicht beurteilen wie es vor Ort aussieht. Wenn die gesamte Fläche ein Moor ist, welches außen herum Bäume hat und im inneren Bereich keine, ist alles in Ordnung. Hat jemand von euch Ortskenntnis? |