Re: [Talk-de] Deutsche Namens-Tags in Polen

[Tom Pfeifer]

On 26.10.2017 14:56, Richard wrote:

Vielleicht mal als name:1939-1944 


Nein, als old_name:-, jetzt auch ordentlich dokumentiert.

https://wiki.openstreetmap.org/wiki/DE:Key:old_name

tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen Radweg gelöscht: Relation 6889944 - [6] Egerradweg

[Tom Pfeifer]

On 29.01.2018 08:01, osm_ww wrote:

Jetzt muss ich erkennen, dass die von mir erstellten Relationen zum Teil 
vollständig von einem anderen User (Glogi) gelöscht worden sind.
https://www.openstreetmap.org/changeset/55019975
Als Begründung wird nur kurz „add part of route 6“ angegeben.


Das ist für das Löschen von 7 Relationen keine sinnvolle Begründung. Wie Volker schon empfahl, nimm 
über die CS-Diskussion Kontakt auf. Glogi arbeitet aber offenbar auch an Routen, da wuare besinders 
wichtig zu wissen was er vorhat. Vielleicht war es ja ein Versehen, mit 200 CS fehlt vielleicht noch 
Erfahrung.


In dem Changeset hat er aber auch Relationen verändert, insbesondere eine mit name=6 in Version 91, 
die solltest du dir anschauen, vielleicht hat er die Routen ja nur anders zusammengebaut?



Was kann man in solch einem Fall machen?
Kann ein anderer User einfach solche Löschungen vornehmen?
(Insbesondere, wenn das Ergebnis der Änderung schlechter ausfällt als der 
Anfangszustand?)


Können schon, die Absichten müssen halt geklärt werden, siehe oben.


Kann ich den von mir erstellten Radweg (Relation 6.889.944) wieder vollständig 
herstellen?


Ja. Eine gelöschte Relation ist ja nicht wirklich weg, sondern nur als gelöscht 
markiert.
Da du mit JOSM arbeitest, wäre hier das https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Undelete zu 
empfehlen, mit dem du gezielt einzelne Objekte reaktivieren kannst. Es empfiehlt sich, das erstmal 
als Trockenübung zu machen und zu schauen ob die enthaltenen Wege noch da sind.


tom


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wie nennt man diese geo-statistische Funktion

[Tom Pfeifer]

Markus, meinst du Isochronen? Das ist die Visualisierung, welche Orte mit einem bestimmten 
Reisemodus in gleicher Zeit erreichbar sind.

https://wiki.openstreetmap.org/wiki/Isochrone

Tobias, ist das eine Implementierung von Skoda selbst oder von dir selbst?

tom

On 27.08.2018 10:04, Tobias Wolter wrote:



On August 27, 2018 8:47:05 AM GMT+02:00, Markus  wrote:

Wie heisst die entsprechende Funktion?
(sowas wie "Dominanz" bei Gebirgen)


In der Graphentheorie nennen wir das einfach nur "kürzester Pfad/Weg"-Probleme, aber das 
ist in der Umgangssprache etwas misverständlich, da das "kürzeste" sich nicht eindeutig 
auf Strecke oder Zeit bezieht, sondern welche Metrik man auch immer gerade anwenden will.

Navis implementieren das dann üblicherweise mit einer Gewichtung nach 
Entfernung oder nach Fahrzeit. (Mein Skoda versucht ein Mapping nach 
ökologischer Auswirkung auf Basis einer selbstentwickelten Kostenfunktion.)

-towo




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Vandale

[Tom Pfeifer]

Helipads auf der Kirche,
military=nuclear_explosion_site : Achtung! Gefahr von Stolli´s Fürze
privater Biergarten,
gelöschter Bäcker,
keine Antworten auf CS-Diskussionen.

Revert ist im Gange.


On 23.07.2018 17:15, dktue wrote:

Hallo,

ich bin zufällig über einen User [1] gestoßen der anscheinend in mehreren Changesets [2, 3] 
vandaliert hat.


Vielleicht könnt ihr mich unterstützen alle seine Changesets durchzuschauen (sind nur 34 Stück) um 
gegebenenfalls aufzuräumen.


Gruß
dktue

[1] https://www.openstreetmap.org/user/Fipspilot/history
[2] https://www.openstreetmap.org/changeset/48852784
[3] https://www.openstreetmap.org/changeset/53591859


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] building:levels, Altbau/Neubau

[Tom Pfeifer]

On 22.07.2018 17:00, Frederik Ramm wrote:

wenn man building:levels erfasst - das ist ja doch ein bisschen
einfacher als eine echte Höhenmessung - macht es ja einen ziemlichen
Unterschied, ob man es mit einem Altbau-Stadthaus mit 3,50m hohen
Stockwerken zu tun hat oder mit einem Neubau mit nur 2,40. Sollte man
das irgendwie mit erfassen?


Du kannst ja problemlos height= des Gebäudes ergänzen, ist nur vor Ort 
schwieriger zu erfassen.
Wenn die Stockwerkhöhe bekannt ist, kann man multiplizieren, wobei allerdings die Beletage auch 
höher sein kann als die Dienstmannwohnung darüber :-)


tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Genauigkeit der Gemeindegrenzen

[Tom Pfeifer]

Im Wiki steht: "Die Genauigkeit der Gemeindegrenzen in OSM ist regional sehr 
unterschiedlich."

Ist das nicht richtig? In Berlin sind wir komplett verwöhnt, weil wir den Senat an der kurzen Leine 
halten, und er uns mehr gibt was wir brauchen. Unter anderem Flurstücksbegrenzungsgenaue Grenzen.


Das mag in anderen Ländern anders sein.

tom

On 31.08.2018 21:55, Markus wrote:

Im Wiki wird die Genauigkeit (Lage und Form) er Gemeindegrenzen als sehr
begrenzt beschrieben, zuletzt 2014, und man solle doch die
Landesvermessungsämter fragen:
https://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze

Wie ist der aktuelle Stand?
Vielleicht kann man ja das Wiki aktualisieren?

Mit herzlichem Gruss,
Markus

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Tom Pfeifer]

Das Taggen der Hilfsorganisationen ist recht chaotisch, daher ist ja seit langem der 
"Emergency-cleanup" im Wiki annonciert, wird aber nur halbherzig betrieben.


Für die Bergrettung würde sich "emergency=mountain_rescue" anbieten, bisher 2 
Verwendungen.

Für den Zivilschutz hatte ein Australier mal "emergency=ses_station" etabliert, was wegen des 
nationalen Acronyms SES ungeeignet ist [1].


Bei den Diskussionen dort, ob emergency=disaster_response geeignet wäre, stieß ich auf die 
derzeitige Verwendung beim deutschen Technischen Hilfswerk (THW) nach dem Schema 
amenity=emergency_service + emergency_service=technical, was einem Proposal von 2008 [2] folgt.


[1] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/Emergency_service

Tom

On 15.04.2018 14:04, Lena Essig wrote:

Hallo zusammen,

mir ist aufgefallen, dass bei der Suche nach "emergency"="ambulance_station"
nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
auch Ortsvereine.
Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
getaggt.
Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst zu tun
haben.
Wie ist denn die allgemeine Regelung für Orstvereine oder
Katastrophenschutzzentren?



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Navads-Tankstellenimport

[Tom Pfeifer]

On 28.03.2018 23:06, Falk Zscheile wrote:

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


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. Nach lokaler Überprüfung sieht das dann nicht mehr aus.


tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tagging von kombinierten Wohn- und Geschäftshäusern

[Tom Pfeifer]

On 04.03.2018 18:38, Harald Hartmann wrote:

aus [1] lese ich z.B. heraus, dass residential auch nur ein sehr
allgemeiner abstrakter Oberbegriff ist, den es eigentlich zu verfeinern
gilt (wie z.B. bei surface=paved)

Mir ist aktuell kein building Wert bekannt der ausdrückt, dass es ein
Wohnhaus ist, in dem auch noch Geschäfte (z.B. eine Bäckerfiliale)
untergebracht ist, deshalb stimme ich wambacher erst mal zu,
building=house und dann noch ein POI fürs Geschäft.

[1] https://wiki.openstreetmap.org/wiki/Tag:building%3Dresidential


Das kommt ja nun auf die konkrete Situation an.

building=residential ist der Oberbegriff für ein Haus vorwiegend zu Wohnzwecken.
Befinden sich mehrere Wohnungen darin, ist es ein building=apartments.

In beiden Fällen wäre ein Laden im EG unschädlich, da der Wohnzweck überwiegt.

building=house ist ein klassisches Einfamilienhaus. In Verbindung mit einem Laden würde ich es nur 
verwenden, wenn der EFH-Charakter überwiegt, und z.B. ein winziger Laden im Souterrain ist.


tom


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tagging von kombinierten Wohn- und Geschäftshäusern

[Tom Pfeifer]

On 05.03.2018 10:59, Martin Koppenhoefer wrote:

Am 4. März 2018 um 22:24 schrieb Volker Schmidt :

Nein, building=house ist ein Einfamilienhaus.


m.E. grundsätzlich nicht ganz klar und hat Potential für Verwechslungen.


Die Verwechslungsgefahr besteht insbesondere im Deutschen wegen der Ähnlichkeit von house und Haus 
mit unterschiedlicher Semantik.


Derzeit ist building=house mit 25 Mill Verwendungen der zweithäufigste Wert 
nach 'yes' [1]
Die Definition "A single dwelling unit usually inhabited by one family" ist 
eigentlich glasklar.


Ich würde eher explizit vorgehen:

building=detached_house Einfamilienhaus


Üblich ist die kompaktere Form, building=detached (1,1 Mill), die im Englischen auch als Substantiv 
gebraucht wird.



building=semi_detached_house Doppelhaushälfte


building=semidetached_house (51 K, no wiki), =semi (16 K, wiki) =semi_detached 
(0.6 K, no wiki)


building=terraced_house  Reihenhaus


sehr wenig getagged. Die zusammenhängende Reihe (building=terrace) sehr viel, 470 K, aber die 
einzelenen Einheiten: =terraced_house, =terraced zusammen weniger als 0.2 K


[1] https://taginfo.openstreetmap.org/keys/building#values

tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Tom Pfeifer]

Ich glaube nicht, dass solch ein Fall mit einem OSM-Eintrag vergleichbar ist.

Es gab schon ähnliche Entscheidungen, ich erinnere mich an ein Arztbewertungsportal, welches Werbung 
der Konkurrenz einblendete, wenn die Ärztin keine Premiummitgliedschaft hatte.


Der entscheidende Unterschied scheint mir zu sein, dass die beklagten Portale/Netzwerke faktisch 
eine Mitgliedschaft erzwingen wollen; während OSM nur Fakten sammelt.


Ich tagge allerdings auch keine natürlichen Personen als operator=*, und es gibt etablierte 
Mechanismen in OSM, solche persönlichen Daten z.B. durch die DWG entfernen zu lassen.


tom

On 31.10.2018 22:30, Günther Zinsberger wrote:

Hallo!

Ich gebe ja bei POIs so viele Details an, wie ich zusammentragen kann. Seit ich diesen Artikel 
gelesen habe, bin ich so am Überlegen, ob das vorteilhaft ist:


https://www.heise.de/newsticker/meldung/Friseur-vs-Facebook-Netzwerk-muss-50-000-Euro-zahlen-4207193.html 



Ein Friseur wollte nicht akzeptieren, dass Facebook für sein Geschäft ungewollt Werbung macht. Er 
zog vor Gericht – und gewann: Facebook muss nun zahlen.
Gezim Ukshini aus Hannover ist nicht bei Facebook angemeldet und trotzdem war sein Friseurgeschäft 
mit einer Seite im sozialen Netzwerk vertreten. Diese ungewollte Werbung mochte der Friseur jedoch 
nicht hinnehmen: Er klagte gegen das US-Unternehmen – und gewann. Facebook muss nun ein 
Ordnungsgeld in Höhe von 50.000 Euro an Niedersachsens Landeskasse zahlen.


Irgendwie trifft das ja auch auf OSM zu (ein Geschäftsinhaber hat keinen OSM-Account und trotzdem 
ist sein Geschäft möglicherweise in OSM ersichtlich).


Klar, wenn sich ein User an uns wendet, dann entfernen wir natürlich den Namen und weitere Details, 
die ihn betreffen. Bloß, auf welche Art meldet sich ein unbedarfter User bei uns? Mit "Einen 
Hinweis/Fehler zu den Kartendaten melden" in der Hauptkarte? Und was, wenn so ein Hinweis nicht 
zeitnahe bearbeitet wird?


Wie ist eure Meinung zu diesem Urteil und seht ihr Auswirkungen auf OSM?


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Abknickende Vorfahrt

[Tom Pfeifer]

On 28.09.2018 21:06, Andreas Schmidt wrote:

Wenn man abbiegt, biegt man ab.
Ob die Vorfahrtsstraße mit abbiegt oder geradeaus geht, ist für die
Frage des Abbiegens irrelevant.

Wenn ich links abbiege, möchte ich eine Ansage haben, dass ich abbiegen
muss, ich muss ja auch den Fahrtrichtungsanzeiger betätigen und das
Lenkrad drehen.


Sehe ich ebenso.
Wir taggen ja derzeit noch nicht einmal die Vorfahrt als solches.
Ergo können wir auch keine abbiegende Vorfahrt taggen.

Lösen könnte man das vermutlich nur über Vorfahrtsrelationen, ähnlich den existierenden 
turn_restrictions.



Am 28.09.2018 um 19:42 schrieb Florian Lohoff:

Hi,
ich glaube ich habe vor 10 Jahren hier schonmal gefragt und damals
gab es nichts zum Thema abknickende Vorfahrt.

Derzeit modelliere ich immer die Topologie so das wenn man der
Vorfahrt folgt es keine Ansage gibt - D.h. das ganze ist halt
von den Winkeln wie eine Kurve in der eben eine Straße abzweigt.


In 'modelliere' lese ich ein 'knete ich die Topologie', damit sich das Navi wunschgemäss verhält. 
Halte ich für einen Fall des Modellierens für den Renderer.


Fällt mir eine Stelle ein, an der ich neulich durchgekommen bin, hat jemand die rechtwinklig 
abbiegende Hauptstrasse zu einem sanften Bogen gestaltet, und die geradeausfahrende Nebenstrasse in 
den Kurvenscheitel gesetzt. Und mich wunderte, warum die klare Abbiegesituation nicht angesagt wurde.


tom


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Abknickende Vorfahrt

[Tom Pfeifer]

On 29.09.2018 00:04, Bernhard Weiskopf wrote:

... Mein Festeinbau meldet "Folgen sie der abknickenden Vorfahrt".
Das kriegen wir Stand heute schon alleine durch die fehlenden Daten
nicht hin.

Hat sich da in den letzten Jahren was dran getan - Wollen wir da was dran
tun? Gibts da proposals?


Wie wär's denn damit:
https://wiki.openstreetmap.org/wiki/DE:Key:priority_road


Halte ich für unzureichend. Das Zeichen "Ende der Hauptstraße" sehe ich sehr selten. Viel häufiger 
ist eine Straße A gegenüber Straße B vorfahrtsberechtigt, gegenüber Straße C aber wartepflichtig. 
Das wird einfach durch ein Vorfahrtsschild ausgedrückt. Mangels "Ende der Hauptstr"-Schild müsste 
man Str A an einer willkürlichen Stelle splitten. Wenn es funktionieren soll, wird man um eine 
Relation nicht umhin kommen.


tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Änderungen highway=living_street / highway=service + living_street=yes

[Tom Pfeifer]

Auch ich würde hier keineswegs im Wiki eine Empfehlung geben, "living_street=yes" zu benutzen, 
insbesondere nicht in der deutschen Situation.


Ja, der Tag ist organisch gewachsen, aber nur mit 20% der 1 Mill 
highway=living_street.
3K davon sind übrigen Doppeltagging.

Ausglöst wurde der Wiki-Edit vermutlich duch das Carto-Ticket
https://github.com/gravitystorm/openstreetmap-carto/issues/3514,
der Wiki-Autor hat dort auch die Idee geliked, einen driveway grau zu färben.

On 16.11.2018 13:11, Martin Koppenhoefer wrote:

Am Fr., 16. Nov. 2018 um 10:31 Uhr schrieb Florian Lohoff :



Hi,
heute morgen wurde der Wiki artikel für die Living Street
ergänzt um den Zusatz:

 Wenn es sich um Zufahrtswege handelt benutze highway=service +
 living_street=yes.

Ich habe keine Diskussion zu dem Thema mitbekommen und ich hätte
mich auch deutlich dagegen ausgesprochen. Das ist in diverser
Hinsicht kaputt.




+1




Eine living_street ist eine living_street und kein service und vice
versa. Highway klasse eins mit der Klasse 2 zu attributieren ist einfach
per definition kaputt.




+1, das macht für mich auch keinen Sinn. Ich verstehe ehrlich gesagt auch
nicht, wie man eine highway-tag-Definition ohne Rücksprache ändern kann.
Außerdem sollten das Übersetzungen der Definitionen im englischen Wiki
sein. Andererseits gibt es 24 living_street=yes in der db, davon 222000
mit highway=service, davon aber nur 3035 service=alley (für die würde ich
es akzeptieren ;-) ).

https://taginfo.openstreetmap.org/tags/living_street=yes#combinations
Laut history ist das zudem ein organisch gewachsener tag, seit 2009 in
Benutzung, wie es aussieht überwiegend in Osteuropa:
https://taginfo.openstreetmap.org/keys/living_street#map




Ich verstehe den Ansatz das highway=service/driveway doof aussieht
in einem Wohngebiet mit living_streets, und das man das gerne
anders rendern möchte, aber das da oben ist eine Verquickung von
Highway klassen und Attributierung die geneigt ist das chaos
nur noch zu vergrößern.




living_street ist eine öffentliche Straße, driveway ist das nicht. (alley
schon).

Gruß,
Martin


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Rein unterirdische Gebäude?

[Tom Pfeifer]

Unsere Mapperkollegen im Geoportal/ALKIS/Berlin unterscheiden jedenfalls "Gebäude" und "Bauwerke", 
die ich in unterschiedlichen ALKIS-Layern aufrufen kann. In "Gebäude" finde ich sichtbare Häuser, 
während "Bauwerke" mir Tunnel, Brücken, flach überdeckte Tiefgaragen und bauliche Straßenanlagen 
liefert.


On 12.12.2018 07:08, sepp1...@posteo.de wrote:

Ich vermute, dass für den Renderer gataggt wurde, weil dieser mit Ebene <0 
nicht klar kommt?


Einer der Renderer diskutiert übrigens grade, wie unterirdische Gebäude/Bauwerke gerendert werden 
sollen:

https://github.com/gravitystorm/openstreetmap-carto/issues/552
https://github.com/gravitystorm/openstreetmap-carto/issues/3506


Also building=yes, building=parking, layer=-1 oder tiefer sind definitiv 
gerechtfertigt.


Der layer=* tag beschreibt ja nur die Lage von überlappenden Objekten 
zueinander.
Interessanter sind hier das Stockwerk level=*, parking=underground, 
location=underground

tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung

[Tom Pfeifer]

On 25.12.2018 11:57, sepp1...@posteo.de wrote:
Keine der bisher von mir besuchten Webseiten und getesteten Routenplaner oder Karten OSM-basierend 
gibt derartige Informationen aus, da diese ausnahmslos für Pkw <2m Höhe ausgelegt sind. 
Spezialkarten hin oder her - reine Lkw-Navisoftware mit entsprechenden Daten ist teuer und im 
privaten Bereich für bspw. 3 Wochen Urlaub mit gemietetem Camper einfach mal unerschwinglich. Da 
mittlerweile selbst normale Hochdachtransporter ausgeschlossen werden, macht das spätestens ab jetzt 
für das normale Routing Sinn, derartige Informationen SICHTBAR zu machen. Es gibt auch genügend 
Anhänger, die hinter einen Pkw hängend die Höhe von 2m überschreiten und das normale Navi macht das 
schlicht und ergreifend nicht! Mir sind auch schon Durchfahrtshöhen von 2,30m unter gekommen - da 
braucht man nicht einmal mehr einen Transporter mit Hochdach um dran hängen zu bleiben. Wie ist das 
beim Besuch im Baumarkt mit dem Miettransporter - Lkw-Navisoftware kaufen oder einfach (vorhandene) 
Daten sichtbar machen?


OsmAnd -> Settings -> Navigation settings -> Height limit.
Gerne auch Weight limit.

Weihnachtliche Grüsse
Tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Tom Pfeifer]

On 23.11.2018 21:37, gmbo wrote:

Regeln einführen wäre meiner Meinung nach gegen das Prinzip von OSM.
Es gibt zwar schon welche wie Urheberrechtsverletzung, 


Es gibt viele Regeln, auch viel grundlegendere:
"Ein Knoten ist eines der grundlegenden Datenelemente in OpenStreetMap. Er besteht aus einem 
einzelnen georeferenzierten Punkt mit Längen- und Breitengrad."



Waldfläche usw., kann ich mir vorstellen, dass da ein Neumapper von
allein in die richtige Richtung läuft und auch erfahrenere Mapper davon
profitieren.


Das Problem sind weniger gutwillige Anfänger, sondern durchaus erfahrene Mapper,
die es aber nicht verstehen, im Team zu spielen, sondern eigene Vorstellungen von Datenmodellen auf 
Kosten der Arbeitszeit aller durchdrücken wollen.


On 23.11.2018 21:54, Florian Lohoff wrote:
> 2 Multipolygone die auffällig sind im Regierungsbezirk Detmold. (Mehr
> als 20 Outer)
> Dagegen stehen insgesamt 3742 Multipolygone die in Ordnung sind.
> Das macht 0.05% oder 0.5 Promille. Dafür brauchen wir Regeln?

Deine Statistik geht von der Hypothese aus, dass die Problemfälle 
gleichverteilt sind.
Sie sind aber eher auf die Stellen konzentriert, an denen sich die genannte Kategorie von Mappern 
gerade aufhält.


Auch sind MPs mit vielen Outern nur das eine Problem; grundlos aus Linienstücken zusammengesetzte 
kleine Objekte das andere.


tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Tom Pfeifer]

On 23.11.2018 20:14, Florian Lohoff wrote:


Mit Problem meine ich: Haben wir community Member die die von dir
angesprochenen Dinge bewusst und absichtlich Produzieren obwohl sie sich
der Implikationen bewusst sind?

Ich bezweifle das - Nur mal so ein Beispiel.

- Niemand erzeugt Multipolygone von vorneherein mit mehreren Outer
   rings. Die entstehen erstmal ganz klein. 

Ja, haben wir, und etliche krasse Beispiele sind in dem Forumsthread zitiert.

Es gibt die "Teppiche" der bewussten Zusammenfassungen von beziehungslosen Teilflächen, um sie im MP 
einmal zu taggen, und ich bin auch auf Mapper gestossen, die ganz bewusst Reihenhäuser aus 
Legoblöcken einzelner gerader Wandstücken zusammensetzen.


tom

___
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?

[Tom Pfeifer]

Die Wiki-Seite wurde auf Ein- und Auffahrten fokussiert.

Ich hatte vor einiger Zeit mal auf 'tagging' angeregt, ein service=* subtag für die übergeordneten 
Servide-roads zu definieren, die in Carto als 'major' gemappt werden, damit die 
Vollständigkeitsfanatiker etwas zu taggen haben, wenn es eben keine untergeordnete (minor) 
Service-road ist.


tom

On 28.11.2018 10:44, Volker wrote:



Am 28.11.2018 um 10:21 schrieb Martin Koppenhoefer:


sent from a phone


On 28. Nov 2018, at 08:35, Falk Zscheile  wrote:

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).


ich sehe das driveway auch für private Zufahrten, bei einem Ikea sähe ich den Weg der Anlieferung 
(sofern da nur Bedienstete und Lieferer fahren) evtl. als driveway, die Hauptzufahrten zum 
Parkplatz als nur service und die kleinen Stichstraßen, die nur dem Zugang zu Parkplätzen dienen, 
als parking_aisle


Der og. Wikiedit von 2016 ist problematisch.


Gruß, Martin



+1 Dem ist nichts hinzuzufügen



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fwd: Adressmapping auf Building-Relationen oder Outline

[Tom Pfeifer]

Die type=building-Relation ist ja eine Erweiterung für 3D-Mapping.

Eigenschaften, die das ganze Gebäude betreffen, sollten daher auf dem Gebäudeumring liegen, der auch 
ohne 3D-Mapping da wäre. Also auch die Adresse.


Dann sieht ein Datenkonsument, der sich nicht für 3D interessiert, diese 
Eigenschaften in jedem Fall.

tom

On 10.03.2019 17:14, Martin Scholtes wrote:

Hallo,

doku hab ich grade nicht zur Hand, aber so auf die schnelle ist das ok,
da es sich ja um EIN Gebäude handelt.

mfg

Am 10.03.2019 um 17:10 schrieb MonkZ:

Moin,

Ich habe eine Adresse auf hier auf die Outline einer type=building
Relation gepackt:
https://www.openstreetmap.org/relation/9376367

Bin mir aber nicht sicher, ob diese nicht eher auf die Relation selbst
gesetzt werden sollte oder nicht?
Wie ist eure Einschätzung? Gibt es da belastbare Doku?

MfG
MonkZ


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Berliner Geoportal unter Datenlizenz Deutschland / Zusatzvereinbarung erfolgreich erneuert

[Tom Pfeifer]

Per 6.6.2019 stellte das Land Berlin [1] die bisher selbstformulierten Nutzungsbedingungen von 2013 
[2] auf die Datenlizenz Deutschland Namensnennung - Version 2.0 DL-DE-BY [3] um.


Dank der guten Kommunikation unseres Behörden-Ansprechpartners Joachim Kast wurde die seit 2013 
vorliegende Zusatzvereinbarung, im Fall OSM den geforderten Quellenvermerk an anderer geeigneter 
Stelle anzubringen, erneuert.


Sie liegt uns nunmehr als Briefbogen vor [4].

Dieses Schreiben sollte auch in der Kommunikation mit anderen Bundesländern  als Mustervorlage 
hilfreich sein, die sich dieser Zusatzklausel zur DE-Lizenz noch verweigern.


Auch Benutzer, die bisher die Problematik der DL-DE-BY hartnäckig noch nicht 
verstanden haben,
können auf dieses Dokument verwiesen werden.

Tom

[1] Amtsblatt für Berlin Nr. 21 / 17. Mai 2019 / Seite 3231
[2] 
https://web.archive.org/web/20140409103912/http://www.stadtentwicklung.berlin.de/geoinformation/download/nutzIII.pdf

[3] https://www.govdata.de/dl-de/by-2-0

[4] 
https://wiki.openstreetmap.org/wiki/File:2019-06-03_Datenlizenz_Deutschland_Berlin_OSM.pdf

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mainnav MG-950d - Software

[Tom Pfeifer]

On 14.09.2019 19:37, Markus via Talk-de wrote:

Liebe Mapper,

wer kann mir von obigem Datenlogger die Auswertungs-SW schicken?


Auf der OSM-Wikiseite zu dem Gerät [1] ist eine Software auf code.google.com 
[2] verlinkt.

[1] https://wiki.openstreetmap.org/wiki/DE:Mainnav
[2] https://code.google.com/archive/p/mainnav-reader/wikis/ReadMe.wiki

tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] GPX-Track nutzen und hochladen

[Tom Pfeifer]

On 15.09.2019 10:15, Markus via Talk-de wrote:

habe ich beim OSM-Daten runterladen auch GPX angekreuzt.
Nun sehe ich zwar magenta Linien, aber die laufen waagrecht bzw. in
engem ZickZack - eine Spur kann ich nicht erkennen.


Sehe ich auch manchmal, ich vermute dass sind Punkte, deren Zeitstempel fehlt oder nicht öffentlich 
ist, so dass dort der Zusammenhang zum Track fehlt und verschiedene vermischt werden.



Wie kann ich mit JOSM meinen GPX-Track zur Nutzung für Dritte hochladen?


Beim Suchen in den Plugins fuur JOSM habe ich das gefunden, aber keine 
Erfahrung damit:

DirectUpload Plugin in JOSM
https://wiki.openstreetmap.org/wiki/User:Subhodip/GSoC_Doc#DirectUpload_Plugin_in_JOSM_:

tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gültigkeit von Verkehrsschildern nur in eine Fahrtrichtung?

[Tom Pfeifer]

On 08.09.2019 00:17, SteMo via Talk-de wrote:


Moin zusammen,

ich konnte nach einigem Suchen bisher nichts dazu finden. Gibt es für
das folgende eine Mappingmöglichkeit:

Ich bin inzwischen auf mehrere Straßen und Wege gestoßen bei denen ich
von einer Seite Durchfahrtsbeschränkungen der Art "Durchfahrt verboten,
Land- & Forstwirtschaftlicher Verkehr frei", von der anderen Seite aber
keinerlei Schilder die Durchfahrt beschränken. Ja, absurd, aber ist nun
mal so, nur wie mappe ich das jetzt? insbesondere, wenn ich keine
eigenen Linien je Fahrtrichtung, wie bei Autobahnen, habe.


Nein absurd ist das nicht, ich habe solche Situationen gesehen, dass man die Einfahrt in eine 
Wohnstrasse von der Hauptstrasse aus verbietet, die Wohnstrasse selbst aber nicht zur Einbahnstrasse 
erklären will. Z.B. um Stauumfahrung durch das Wohngebiet zu vermeiden.


Lässt sich fürs Routing lösen, indem man an der verbotenen Einfahrt ein paar Meter Einbahnstrasse 
deklariert (in deinem Fall mit Zusatztag für den Traktor).


tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wegstücke Emscher Region (NRW)

[Tom Pfeifer]

Hallo Nora,

etwas Sorgen bereitet mir noch diese Aussage:

> Die shp-File selbst dürfen wir nur Projekt-Intern benutzen, also nicht an 3. 
weitergeben.

Hier muss unbedingt geklärt werden, ob der Rechteinhaber der Dateien der Ableitung von Inhalten nach 
OpenStreetMap zustimmt, in einem solchen Fall bitte schriftlich, und die Genehmigung veröffentlichen.


Bitte lies zuerst hier: https://wiki.openstreetmap.org/wiki/Copyright
und dann hier hinsichtlich der Offenlegung der Genehmigung:
https://wiki.openstreetmap.org/wiki/Contributors#Germany

tom

On 09.08.2019 11:27, chris66 via Talk-de wrote:

Hallo Nora,


a) Auf welche Art und Weise könnte man die vorliegenden Daten am
zeiteffizientesten UND im Sinne von OSM zielführendsten einarbeiten?
Import von shp-Dateien (??), manuelles Einarbeiten? 

Manuell, da ein Import bestehende Daten doppeln würde.


b) Welches Browser-Format (zb JOSM?) sollte man dafür nutzen? Im
beginners' guide steht als Schritt 2: upload data und in schritt 3: mit
josm bearbeiten. ist das hierfür auch zutreffend?


Als Editor sei JOSM empfohlen.

c) Wäre ich als unerfahrene Person diejenige, die das am besten einfügt oder würde das 
üblicherweise jemand anders tun, der sich damit bereits auskennt um fehler zu vermeiden? Oder 
hängt das von der Vorgehensweise ab?


Am besten wäre natürlich selber machen. Nach den ersten Edits
diese durch die Community begutachten lassen.

d) was wäre der tag für die Straßen, die noch nicht öffentlich sind, vermutlich sowas wie "special 
road type/service“?


Als Wegeklassen (highway=*) kommen in Frage: footway/cycleway/path/service mit passenden 
access-Tags, zB. access=no / private.


e) gibt es zur Diskussion dessen eine kleinere lokale zuständige Gruppe für NRW oder das 
Ruhrgebiet ... oder eine thematisch passendere ... oder bin ich hier richtig?


Es gibt lokale Usergruppen / Stammtische.

Chris


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Daten über Restriktionen und Vorrangrouten für den Schwerlastverkehr in NRW

[Tom Pfeifer]

Hallo Herr Spitzley,
es wird sich bestimmt noch jemand aus NRW zu Wort melden, ich mache mal den Anfang zu den 
allgemeinen Fragen.


On 21.11.2019 11:30, Spitzley, Bennedikt wrote:

Kommunen in NRW tragen auf der web-basierten Plattform SEVAS auf OSM Kartenwerk zum einen Lkw-Vorrangrouten ein. 


Die Nutzung von OSM-Material, z.B. als Hintergrundkarte, ist grundsätzlich ohne Einschränkung 
möglich. Einzige Voraussetzung ist die korrekte Attributierung, wie sie hier beschrieben ist:

https://www.openstreetmap.org/copyright


Zum anderen erfassen sie Lkw relevante Restriktionen: Lkw Durchfahrtsverbot 
(basierend auf Verkehrszeichen 253), Verbot für Gefahrgut (VZ 261), 
Beschränkungen in der Masse (VZ 262), Achslast (VZ 263) Breite (VZ 264, Höhe 
(VZ 265), Länge (VZ 266) und Verbot für wassergefährdende Ladung (VZ 269).
Diese Daten werden auf dem Mobilitätsdatenmarktplatz MDM bereitgestellt, wo Sie 
von Navigationskartenherstellern heruntergeladen werden können und so ihren Weg 
zunächst in die Navigationskarten und dadurch dann in die Lkw-Navigationsgeräte 
finden. Auch der Download über WFS- und WMS-Server ist möglich.
Gerne möchten wir diese Daten auch auf OSM veröffentlichen. Ob und wie dies 
möglich ist, möchte ich gerne hier diskutieren.


Das Einpflegen dieser Restriktionen in OSM ist grundsätzlich erwünscht, und in vielen Fällen auch 
schon durch die Community entsprechend der Ausschilderung vor Ort erfasst.


Es existieren folgende etablierte Attribute:

- hgv=no  Lkw Durchfahrtsverbot,
  https://wiki.openstreetmap.org/wiki/DE:Key:hgv

- hazmat=no  Einschränkung für Gefahrguttransporte,
  https://wiki.openstreetmap.org/wiki/DE:Key:hazmat

- hazmat:water=no Verbot für Fahrzeuge mit wassergefährdender Ladung
  s.o.

- maxweight=* juristische Gewichtsgrenze für die Benutzung der Wege
  * in Tonnen wenn ohne Einheit angegeben
  https://wiki.openstreetmap.org/wiki/DE:Key:maxweight

- maxaxleload=* beschreibt die maximal zulässige Achslast in Tonnen.
  https://wiki.openstreetmap.org/wiki/DE:Key:maxaxleload

- maxwidth=* maximal zulässigen Breite eines Fahrzeuges, in Metern
  https://wiki.openstreetmap.org/wiki/DE:Key:maxwidth

- maxheight=* Beschränkung der Durchfahrtshöhe auf Straßen, in Metern
  https://wiki.openstreetmap.org/wiki/DE:Key:maxheight

- maxlength=* Verbot für Fahrzeuge über tatsächliche Länge, in Metern
  https://wiki.openstreetmap.org/wiki/DE:Key:maxlength

Die Voraussetzung für das Einpflegen der behördlichen Daten ist die Veröffentlichung unter einer 
geeigneten Lizenz, bzw. hilfsweise eine Zusatzgenehmigung durch den Besitzer der Daten.


Ein typisches Problem bei scheinbar freien Lizenzen ist oft wiederum die Attributierung, die bei OSM 
nicht mehr am Endprodukt erfolgen kann, sondern typischerweise am Änderungssatz beim Einpflegen.

Gute Beispiele für notwendige Zusatzklauseln findet man hier:
https://wiki.openstreetmap.org/wiki/Contributors#Germany

Wenn Sie die Daten der Community z.B. per WFS/WMS anbieten, wird dies sicher gern angenommen, und 
die Mitglieder vor Ort können die behördlichen Daten mit der Ausschilderung vor Ort und der bereits 
erfolgten Erfassung in OSM abgleichen.


Interessant wäre hier ein Rückkanal. Da auch behördliche Daten Fehler aufweisen, könnte so darauf 
hingewiesen werden, dass die Situation z.B. vor Ort anders ausgeschildert ist als im WMS dargestellt.


Das manuelle oder automatische Einpflegen eines kompletten fremden Datensatzes in OSM gilt als 
Import, hierzu gibt es Richtlinien zur sorgfältigen Planung und Zustimmungspflicht seitens der 
Community, insbesondere damit Daten nicht gedoppelt oder verschlechtert werden:

https://wiki.openstreetmap.org/wiki/Import

Ich hoffe, das hilft zunächst zur Orientierung...
Ich habe Sie zunächst in CC genommen, typischerweise sollten Sie die Mailingliste aber bereits 
abonniert haben.


Tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage zu OSM-IDs

[Tom Pfeifer]

Insbesondere wird ein Element nicht physisch gelöscht, sondern in seinem XML-Code das Attribut 
'visible' auf 'false' gesetzt. Es wird quasi nur unsichtbar. Daher ist es möglich Löschungen 
rückgängig zu machen, also zu revertieren.


Siehe https://wiki.openstreetmap.org/wiki/Elements
Common attributes -> visible

Tom

On 10.10.2019 11:43, Martin Scholtes wrote:

Hallo,

die ID´s werden hochgezählt und nicht neu vergeben, da sonst ja die
history i-wann kaputt geht.

Gruß

Am 10.10.2019 um 11:40 schrieb Hövelmann, Marcel:

Hallo in die Runde,
folgende Frage meinerseits in die Runde:
Wenn ein Objekt gelöscht wird, z.B. mit der ID „node:4571570286“ – wird diese 
node-ID irgendwann nochmals neu vergeben oder neue nodes immer nur 
„hochgezählt“?


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Brandenburg ist frei!

[Tom Pfeifer]

Steige hoch, du roter Adler!

Die Brandenburger Geobasisdaten, die von der Landesvermessung und 
Geobasisinformation Brandenburg
(LGB) seit Januar unter der "Datenlizenz Deutschland 2.0 Namensnennung 
dl/de/by-2.0" bereitgestellt
werden, können ab sofort für OpenStreetMap genutzt werden.

Die notwendige Zusatzvereinbarung war bereits in der BbgGeoNutzV "angedacht". 
In einem konstruktiven
Gespräch am 26.2. mit Vertretern der OpenStreetMap-Community in der LGB in 
Potsdam wurden die
letzten Details besprochen sowie Wege für künftige gegenseitige Kooperationen 
geebnet.

Die LGB hat sich nun im April 2020 dazu entschlossen, die notwendige Klausel 
allgemeingültig in
ihren Allgemeinen Geschäfts- und Nutzungsbedingungen (AGNB) aufzunehmen.

Damit muss der Quellenvermerk nicht im unmittelbaren optischen Zusammenhang zur 
Datendarstellung
eingebunden werden, wenn die LGB-Daten im Folgeprodukt nur einen 
untergeordneten Anteil haben und
dem Folgeprodukt mehrere Ausgangsquellen zugrunde liegen. Es genügt in diesem 
Fall, den
Quellenvermerk an anderer geeigneter Stelle beizugeben.

Das Neue an der Brandenburger Lösung zur DL/DD/by-2-0 ist, dass die 
Formulierung allgemein in die
AGB aufgenommen wurde. Dies, so schrieb Joachim Kast...
> könnte auch eine Anregung für weitere Bundesländer sein, die bisher ein 
> spezielles "Lex
OpenStreetMap" vermeiden wollten.

Damit auch noch einen dicken Dank an Joachim für seine Unterstützung auch in 
dieser
Behördenkommunikation.

Bei der Nutzung der Daten denkt bitte daran, dass auch amtliche Daten Fehler 
haben und stellenweise
nicht aktuell sind - gerade das weiß auch die LGB und würde hier gern mit OSM 
kooperieren.

Es ist eine Stärke von OSM, jegliche Daten, amtlich oder von wem auch immer, 
vor Ort prüfen zu
können, und mit vielen andere Quellen zu vergleichen und zu plausibilisieren. 
Pauschale Importe sind
in Brandenburg sicherlich nicht erforderlich bzw. unterliegen den bekannten 
Richtlinien.

Links für Details:

https://geobasis-bb.de/lgb/de/agnb/
https://wiki.openstreetmap.org/wiki/Brandenburg/Geoportal mit weiteren 
Rechtlichen Grundlagen
https://wiki.openstreetmap.org/wiki/Contributors#Brandenburg
https://forum.openstreetmap.org/viewtopic.php?pid=783554#p783554

Viele Grüsse
Tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gewichtung der Straßen im Routing

[Tom Pfeifer]

On 28.04.2020 14:44, Florian Lohoff wrote:
> Nachdem ich dann die neue grünen teil mit lanes=1
> versehen habe ist soeben die route zurück geschwenkt.

Entspricht denn lanes=1 der Realität?
Also der Verkehr in beiden Richtungen teilt sich eine Spur?

tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gewichtung der Straßen im Routing

[Tom Pfeifer]

On 28.04.2020 17:35, Florian Lohoff wrote:
> On Tue, Apr 28, 2020 at 03:17:16PM +0200, Tom Pfeifer wrote:
>> Entspricht denn lanes=1 der Realität?
>> Also der Verkehr in beiden Richtungen teilt sich eine Spur?
> 
> Wenn du aneinander vorbei möchtest muss einer auf die Bankette - ja -
> Mindest wenn die ein Trecker oder was breiteres entgegen kommt.

Gut, dann bin ich bei dir, was lanes=1 betrifft.

In England/Irland sind häufig noch engere Straßen anzutreffen, da hast
du statt eines Seitenstreifens hohe Trockensteinmauern oder Hecken.
Da muss einer zurückstoßen, bis irgendwo eine Feldeinfahrt oder Ausweichstelle
kommt.

On 28.04.2020 17:57, Volker Schmidt wrote:
> lanes=1 ohne oneway=no|yes wird von einigen (auch von mir als moeglicher
> Fehler) betrachtet, und ist daher keine gute Idee.

Nein warum - siehe oben.

On 28.04.2020 17:35, Florian Lohoff wrote:
> Die Frage war wie ihr das mit der relativen Gewichtung von
> Routingalternativen bearbeitet und fixed.

Es gibt den Tag "maxspeed:practical", der angibt, wie schnell man
realistischerweise auf einer Strasse vorankommt.
https://wiki.openstreetmap.org/wiki/Key%3Amaxspeed%3Apractical

Auch hierzu das Beispiel Irland - bei der Umstellung der Geschwindigkeiten
von Meilen auf Kilometer pro Stunde hatte man überall, wo das formale
Limit wechselt - typischerweise innerorts 50 und ausserorts 80 - die
rotumrandeten Schilder aufgestellt. Wenn also oben beschriebene
Straße, die sich auch alle paar Meter windet, und gleich der Trecker
um die Ecke kommen konnte, steht da 80 dran, obwohl man sich nur mit
15 vorsichtig vorantasten kann. Da hilft maxspeed:practical dem Router
zu mehr Realismus.

tom

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] oneway = no

[Tom Pfeifer]

Sicherlich kommt es vor, dass in Presets in Editoren gedankenlos
Default-Werte angekreuzt werden.

Wenn ich also auf der Autobahn ohnehin grade die maxspeed aktualisiere,
werde ich solch ein horse=no oder foot=no sicherlich stillschweigend entfernen,
wenn sich aus dem Kontext kein besonderer Grund für diese Werte ergibt.

Für oneway=no hatten sich in der Diskussion hier etliche Fälle ergeben,
in denen die explizite Betonung dieses Fakts sinnvoll ist.

Eine massenweise Entfernung von 2500 solcher Tags entbehrt aber die
Selektion nach sinnvollen und redundanten Situationen, insofern
sehe ich für den eingangs diskutierten mechanischen Edit keinen Konsens.

tom

On 23.05.2020 19:04, Volker Schmidt wrote:
> Aus welchem Grund siehst du das bei Radwegen anders als bei Strassen?
> Das Problem ist genau das gleiche.
> Dummerweise gibt es keinen tag value "positivly yes".im Gegensatz zu dem
> Ansatz missing tag fehlt = tag with default value.
> 
> Ich wuerde dich dringend bitten, wenigstens  in Zukunft keine Loeschungen
> von "vollkommen redundanten" tags mehr vorzunehmen. Danke im Voraus.
> 
> Volker
> 
> On Sat, 23 May 2020 at 17:07, Bernhard Kuisle via Talk-de <
> talk-de@openstreetmap.org> wrote:
> 
>> Ich verfahre in der Regel! auch so, dass ich oneway=no lösche, weil es
>> in meinen Augen oft vollkommen redundant ist.
>> Z.B. in ganz normalen Wohnstraßen in Wohngebieten.
>> Auf Radwegen in der Stadt kann es aber durchaus Sinn machen.
>>
>> Bernhard

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de