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

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] 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

[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] 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

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] 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] 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

[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] 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

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] 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] 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] 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] Ä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] 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 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] 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] 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] 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] landuse-Tag bei Sozialeinrichtung

[Tom Pfeifer]

Ich empfehle für das Grundstück
amenity=social_facility
social_facility=nursing_home

landuse halte ich in dem Fall für entbehrlich, da die Nutzung durch das flächige amenity-Tag bereits 
hinreichend beschrieben ist.


tom

On 11.06.2018 08:54, goegeo wrote:

Hallo Liste,

wie seht Ihr das? Ich bin gerade auf ein Grundstück mit bereits erfasstem amenity-Tag "nursing_home" 
gestoßen, bei der die Landnutzung noch nicht erfasst wurde. Dies wollte ich nun ergänzen. Habe mich 
im Wiki bei den Landnutzungen umgesehen und bin mir nicht sicher, ob wir es als residential oder 
doch commercial taggen sollen. Kann jemand bei der Entscheidungsfindung helfen?


Danke im voraus. Grüße, goegeo



___
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 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] 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] 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] Bemerkenswerte Relation

[Tom Pfeifer]

On 10.11.2017 17:51, Simon Poole wrote:

Am 10.11.2017 um 17:34 schrieb Tom Pfeifer:

Die Rollen "level_N" sind seit dem 14 March 2015 in type=building
dokumentiert [3]


Das war zu dem Zeitpunkt schon veraltet und wenn ich nicht wüsste wer es
da reingeschrieben hat, würde ich mich wundern.


SIT ist jetzt erstmal auf der Seite hinzugefügt. Sollte man dann die Ausführungen zu IndoorOSM als 
veraltet kennzeichnen?

Ganz löschen würde ich sie nicht, damit man bei Fragen wie hier die Herkunft 
des Taggings klären kann.

tom

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

Re: [Talk-de] Bemerkenswerte Relation

[Tom Pfeifer]

On 10.11.2017 16:35, dktue wrote:
> ich bin gerade auf diese bemerkenswerte Relation [1] gestoßen. Hier scheint 
mir einiges an
> Member-Rollen und Tagging-Schema erfunden zu sein.

Es handelt sich um eine Building-Relation [2], dabei wurden per Indoor-Mapping 
einzelne Etagen erfasst.

Das dabei entstehende Chaos sollte durch Strukturierung beherrscht werden, wozu eine Relation für 
das Gebäude weitere Relationen pro Etage enthält.


Die Rollen "level_N" sind seit dem 14 March 2015 in type=building dokumentiert 
[3]

> Wie würde die vereinfachte Form aussehen die nur auf übliches Mapping 
aufsetzt?

Was ist "üblich"? Indoor-Mapping ist üblich.

Bei der Level-Relation wurden "buildingpart" und "shell" verwendet, das habe ich bisher nur in einem 
Proposal [4] gefunden. Ob das auch durch die in der building-Relation gebräuchlichen "part" und 
"outline" ersetzt werden kann, müsste man prüfen.


On 10.11.2017 17:06, Simon Poole wrote:
> Das ist ein Gebäude das nach dem veralteten IndoorOSM Schema erfasst wurde,
> [...] http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging entwickelt

Aha, danke, werde mal auf [2] drauf verweisen.

On 10.11.2017 16:52, Scholtes, Martin wrote:

Finde das tagging etwas zu ausführlich.
Warum sollte man jede Etage Einzel taggen?!


Damit man sie voneinander unterscheiden kann.


  Würde das gesamte Gebäude in einen Way räumen.


Wie meinst du das genau? Was räumen?

[1] http://www.openstreetmap.org/relation/2513418
[2] https://wiki.openstreetmap.org/wiki/Relation:building
[3] 
https://wiki.openstreetmap.org/w/index.php?title=Tag:type%3Dbuilding=prev=1149162
[4] https://wiki.openstreetmap.org/wiki/Proposed_features/IndoorOSM

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

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] Deutsche Namens-Tags in Polen

[Tom Pfeifer]

On 25.10.2017 16:58, Martin Koppenhoefer wrote:

Ist old_name eine Liste?


Eine Semikolon-Liste? Eher nicht, aber grade bei old_name bietet sich an, die 
Jahreszahlen anzugeben:

old_name:[]-= bzw. old_name:de:[]-=
bzw. auch mit genauem Tag.

Dann sortiert sich die Umbenennungspraxis schön in den historischen Kontext.

Hm, ich dachte das wäre besser dokumentiert :-( Die Wiki-seite ist nur ein 
Redirect auf name.

Beim blick auf
https://taginfo.openstreetmap.org/keys/old_name#similar
sind bei genauem Datum Varianten mit einem oder zwei Bindestrichen gebräuchlich:

old_name:1969-10-18-1970-01-01
old_name:1962-03-21--1965-02-11

On 25.10.2017 18:44, Markus wrote:
> Vielleicht kann ja die DWG prüfen, wer diese Einträge macht, und ggf. entsprechende Massnahmen 
ergreifen.


Das hat sie in offenkundigen Fällen ja auch bereits gemacht.

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

Re: [Talk-de] landuse=residential an Node

[Tom Pfeifer]

Fein.
Habe mir die Restposten angeschaut, es sind dort urbane bzw. ländliche Siedlungsstrukturen zu 
erkennen, zu denen der Name gemappt wurde, da eignet sich place=hamlet bzw. place=neighbourhood,

insbesondere wenn der landuse ohnehin schon als Fläche gemappt war.

Repariert.

On 22.09.2017 20:30, dktue wrote:

Hallo,

ich habe die Fälle nun bundesweit händisch und einzeln korrigiert, benötige aber Unterstützung für 
die letzten fünf verbliebenen Nodes [1].


Kann das mal jemand gegen prüfen und gegebenenfalls korrigieren?

Viele Grüße
Daniel

[1] http://overpass-turbo.eu/s/rTx



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

Re: [Talk-de] zwei ref´s an einer Bundesstraße

[Tom Pfeifer]

On 08.09.2017 10:39, Scholtes, Martin wrote:

Es ging mehr mehr drum, welche Quelle ist vertrauenswürdiger: Die hundert 
Leitpfosten mit einem ref oder ein,zwei Straßenschilder mit zwei ref ?


Wenn die zwei Bundesrouten ein Stück über das selbe Asphaltband geführt werden, muss sich das ja 
nicht zwangsläufig auf den Leitpfosten widerspiegeln. Die sind ja eher für die Notfallkommunikation 
oder Wartung gedacht.


Gegebenfalls kann man ja auch das Bundesfernstraßengesetz und die entsprechenden Widmungen der 
Straßen zu Rate ziehen, diese finden sich offenbar auch in den Amtsblättern der Länder, Beispiel [1].


[1] https://bravors.brandenburg.de/br2/sixcms/media.php/76/Amtsblatt%2038_06.pdf

tom

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

Re: [Talk-de] landuse=residential an Node

[Tom Pfeifer]

@Martin - er hatte eine Overpass-Abfrage beigelegt.

Ja, ich habe Einwände.
landuse=residential gibt es 5026x auf einer Node, im Vergleich zu 4,2 Mio 
Flächen.
Die Nodes sind weltweit verteilt.

All diese Nodes beinhalten die Aussage, dass sich dort ein Siedlungsgebiet 
befindet.
Für ein Löschen dieses Tags gibt es überhaupt keinen Grund, schon gar nicht "auf einen Rutsch" 
(=mechanical edit[1]).


Wenn du etwas verbessern möchtest, lade das Gebiet einer solchen Node, in einer Gegend, in der du 
den Bebauungs-Stil von Wohngebieten kennst und anhand des Luftbildes einschätzen kannst, und zeichne 
den Umriss des Wohngebiets. Die Node kannst du im Umring verwenden. [2]


https://wiki.openstreetmap.org/wiki/DE:Automated_edits
https://wiki.openstreetmap.org/wiki/DE:Good_practice#Erhalte_die_Chronik

On 07.09.2017 18:04, Scholtes, Martin wrote:

hast du ein Beispiel?
-Ursprüngliche Nachricht-
Von: dktue [mailto:em...@daniel-korn.de]
Gesendet: Donnerstag, 7. September 2017 11:03
ich habe bemerkt, dass es vereinzelt Nodes gibt an denen landuse=residential getaggt 
wurde [1]. Ich möchte gerne in einem Rutsch das Tag "landuse=residential" von 
diesen Nodes entfernen, aber dies vorher hier diskutieren.

Hat jemand Einwände?

Viele Grüße
dktue

[1] http://overpass-turbo.eu/s/rwC


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

Re: [Talk-de] Krankenhaus - Eingang

[Tom Pfeifer]

On 26.08.2017 12:14, Martin Koppenhoefer wrote:

On 23. Aug 2017, at 14:34, Markus  wrote:
Im Wiki steht, man solle das Gebäude bezeichnen mit:
http://wiki.openstreetmap.org/wiki/DE:Tag:amenity=hospital


ich würde das gesamte Krankenhaus damit taggen, z.B. wenn es mehrere Gebäude 
sind oder Aussenflächen dazugehören dann würde ich die in mein 
Krankenhauspolygon miteinschließen


+10, das Wiki war etwas diffus in der Rangfolge, sollte jetzt klarer sein.

tom

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

Re: [Talk-de] OSM-Karte mit anderer Projektion auf unteren Zoomstufen

[Tom Pfeifer]

On 07.07.2017 17:27, Frederik Ramm wrote:
[...]

ihrer Bachelor-Arbeit Gedanken darüber gemacht, ob man auf den unteren
Zoomstufen nicht eine andere Projektion einsetzen könnte. [...]
im Rahmen einer Bachelorthesis („Die WebMercator-Verzerrung: Prototyp
einer optimierten Weltkartendarstellung für Webkartendienste“) 


Coole Sache, habe bereits den survey positiv gemonkeyed.

Welche Projektion wurde denn nun verwendet?
Könnte ruhig noch eine Zoomstufe so weitergehen.
Vielleicht sollte man in der neuen Projektion, sowie in der ersten Mercator-Stufe, auch die 
Meridiane rendern, dann wird der Projektionswechsel auch dem Laien verständlicher.


tom

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

Re: [Talk-de] Massenedit bei living_street

[Tom Pfeifer]

Jeder Massenedit [1] bügelt über lokale Ausnahmen sowie mögliche vorhandene Fehler hinweg und ist 
daher vorher zu diskutieren und hat nach den Richtlinien [2] zu erfolgen.


Wenn der Nutzer unkooperativ ist, wird die DWG [3] informiert, der Nutzer wird geblockt und die 
Edits revertiert.


[1] https://wiki.openstreetmap.org/wiki/DE:Automated_edits
[2] https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
[3] https://wiki.openstreetmap.org/wiki/DE:Data_working_group

Mögliche Ausnahmen sind hier lokale spezifische Geschwindigkeitsfestlegungen, mögliche Fehler z.B. 
Tempo-30-Zonen, die versehentlich als living_street getaggt wurden.


tom

On 23.05.2017 11:22, Stephan Martens wrote:

Hier z.B.: wurde eine Tempo-30 Zone bei der sogar die Schilderart DE:274.1 
(Tempo-30-Zone) katrografiert wurde zu maxspeed:walk
https://www.openstreetmap.org/way/305956789/history

Ist das Vandalismus Deutschlandweit?


Mit freundlichen Grüßen
Stephan
aka smarties




Gesendet: Dienstag, 23. Mai 2017 um 11:05 Uhr
Von: smart...@gmx-topmail.de
An: talk-de@openstreetmap.org
Betreff: [Talk-de] Massenedit bei living_street

Hallo,

was sagt Ihr dazu das der User:Graf Westerholt in ganz Deutschland bei mehreren 
zehntausenden living_street ein maxspeed:walk setzt, egal ob da vorher ein 
maxspeed:30, 7 oder garnichts dranstand? Er ist da auch schon reichlich mit 
anderen Usern zusammengestoßen und weigert sich sein tun aufzugeben. Ca. 10% 
seiner Changesets wurden auch bereits komplett zurückgesetzt, er macht aber 
munter weiter.

Es gibt ein Proposal zu maxspeed:walk das allerdings 2008 (vor 9 Jahren) nicht 
zu Ende geführt wurde (ja eigentlich noch nicht mal richtig angefangen wurde). 
http://wiki.openstreetmap.org/wiki/Proposed_features/maxspeed_walk

Ich habe Ihn angeschrieben, er meint jede Zahl wäre falsch und nur "walk" wäre 
richtig und er höre nicht damit nicht auf.


https://www.openstreetmap.org/changeset/47980360
https://www.openstreetmap.org/changeset/47980908
https://www.openstreetmap.org/changeset/47980016
https://www.openstreetmap.org/changeset/47978442
https://www.openstreetmap.org/changeset/47977546



Mit freundlichen Grüßen
Stephan
aka smarties



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

Re: [Talk-de] Geschwindigkeitsbegrenzungen protokollieren

[Tom Pfeifer]

Ich glaube, das weiß Flo, es ging ihm wohl mehr um das Erfassen als das Mappen.

Beim Erzeugen von Wegpunkten in einem GNSS-Logger sollte man auch den 'time lag' im Gerät 
berücksichtigen, wenn man selbst in Bewegung ist.
Wenn man beim Passieren eines Schildes den Knopf drückt, zeichnet das Gerät eine bereits vom 
Prozessor verarbeitete Position auf, diese liegt dann typischerweise 5-50 m vor dem Schild.


Macht man das aus beiden Fahrtrichtungen z.B. an einem Ortsschild, kann man den Wert in der Mitte 
nehmen. Bei asymmetrischen Beschränkungen wird das halt schwierig, auch weil man nur die Rückseite 
sieht.


tom

On 22.05.2017 11:15, Toni Erdmann wrote:

Für unterschiedliche Werte pro Richtung gibt es z.B.

maxspeed:forward=60   und
maxspeed:backward=100

Am 22. Mai 2017 10:52:01 MESZ schrieb Florian Lohoff :


Ich sehe die Schilder zu taggen als ganz großes Hilfsmittel
zwischen den Mappern zu kommunizieren. Und nach meiner Erfahrung
ist es nahezu unmöglich asymmetrische Geschwindigkeitsbeschränkungen,
d.h. je Fahrtrichtung unterschiedlich, ohne die Schildpositionen
zu mappen.


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

Re: [Talk-de] Liste mit Händleradressen hinzufügen

[Tom Pfeifer]

On 12.04.2017 11:46, Martin Trautmann wrote:

wie kann ich am einfachsten eine Liste von Händlern hinzufügen?


Kurze Antwort: tu es nicht.


Konkretes Beispiel: hier in Freiburg haben sie die Gasabfüllstation am 
Güterbahnhofgelände
abgerissen.


Die abgerissene Station darft du in OSM löschen, gib im Changeset-Kommentar bitte an, was wann 
passiert damit ist.



Damit ist auch der dortige Händler verschwunden. Jetzt gibt es nur noch die 
Baumärkte
als naheliegende Bezugsquelle.


Wenn du im konkreten Baumarkt gesehen hast, dass dort abgefüllt wird, kannst du 
das einzeln eintragen.


Auf www.basigas.de fand ich aber eine ganze Händlerliste. Wie kann ich deren 
Informationen nun unter
der Kategorie Flüssiggas am einfachsten der openstreetmap hinzufügen?


Die dortige Liste (http://www.basigas.de/kontakt/gasecenter.php) wurde vom Betreiber der Webseite 
für seine Zwecke zusammengestellt, und ist mit dem Vermerk "Copyright 2017" gekennzeichnet. Damit 
hat sie der Seitenbetreiber nicht unter eine freie Datenbanklizenz gestellt, man darf nicht einfach 
dahergehen, die Liste kopieren und in eine andere Datenbank (hier OSM) einpflegen. Kurz, die Lizenz 
ist nicht mit der ODbL [1] kompatibel.



Zur besseren Verarbeitung habe ich sie bereits in eine Tabelle übertragen:



Das solltest du wieder löschen, da du bereits hier ein fremdes Werk kopiert und zur Verbreitung im 
Internet bereitgestellt hast. Es sei denn, du hast eine schriftliche Erlaubnis des Urhebers, dies zu 
tun.


Des weiteren wäre das Einpflegen einer solchen Liste ein Import, für den in OSM strenge Maßstäbe 
gelten. [2]


Schließlich haben solche Listen erfahrungsgemäß viele Fehler. 5% der Firmen wurden geschlossen, 5% 
habe andere Öffnungszeiten, 5% sind umgezogen, 5% wurden von einer Kette geschluckt, und ein paar 
Adressen waren schon bei der Eingabe fehlerhaft. OSM will solche Daten daher vor Ort erfassen, da 
machen wir nur unsere eigenen Fehler.


Was du also machen kannst, du packst dir die Liste in deine Satteltasche, und wenn du an einer 
solchen Station vorbeireitest, prüfst du die Daten und trägst dann diese Station ein.


[1] https://wiki.openstreetmap.org/wiki/Open_Database_License
[2] https://wiki.openstreetmap.org/wiki/Import

Viele Grüsse
Tom

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

Re: [Talk-de] Ankündigung der Entfernung von landuse =farm im Standardstil

[Tom Pfeifer]

On 23.03.2017 14:20, Stefan Martinek wrote:

Hy hab da als Neuling eine blöde Frage: Also gehören jetzt hier nur die rot
gekennzeichneten Felder von =farm auf =farmland oder =farmyard umgestellt?


Gute Frage, richtige Frage!

Ja so sieht das aus. Und was von beiden es ist, oder vielleicht inzwischen mit einer Siedlung 
bebaut, solltest du mit Ortskenntnis, oder mindestens mit einem aktuellen Luftbild entscheiden, und 
nicht nur der Grösse nach vermuten.



Am 23. März 2017 um 13:45 schrieb Walter Nordmann :

Die Farben dürften klar sein, ich empfehle als Hintergrund OSM Gray und
hab das auch voreingestellt.


Kurioserweise sehe ich beim Nachladen von Kacheln immer erst farbige, die dann zu Grau mutieren. In 
der Page-Info sehe ich nur die grauen Kacheln.



Der Lag der Live-DB wird unten rechts angezeigt und beträgt normalerweise
1-2 Minuten.


tickt bei mir etwas wie 04:39:14

vg Tom


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

Re: [Talk-de] Wie am besten Uploaden

[Tom Pfeifer]

On 8 Mar 2017, at 06:41, Stefan Martinek  wrote:

Ich meine sollte man eher jede kleine Änderung einzeln
hochladen oder doch zusammenwarten und grosse Pakete hochladen? Wie kommen
die Server damit zurecht beim rendern und einpflegen? Wie macht ihr das so?


On 08.03.2017 10:04, Martin Koppenhoefer wrote:

für die Server spielt es keine so große Rolle, aber für die Nachvollziehbarkeit 
durch andere Mapper ist es m.E. besser, kleinere Änderungssätze zu machen, die 
am Besten thematisch zusammengehören (mit passendem Changeset Kommentar was Du 
und ggf. weshalb Du es gemacht hast). Außerdem verringerst Du dadurch die 
Wahrscheinlichkeit von Konflikten und kannst letztere falls sie doch auftreten 
einfacher lösen (Konflikte gibt es, wenn andere Mapper gleichzeitig wie Du 
dieselben Objekte ändern).



Der thematische Zusammenhang ist auch für Korrekturmöglichkeiten sinnvoll.

Wenn ich zweihundert Häuser zeichne, geht dabei wenig schief.

Wenn ich z.B. eine Grenz- oder Nahverkehrsrelation anfasse, mir ein 
Fehler unterläuft, und das Changeset revertiert werden muss, ist es gut, 
diese kompliziertere Arbeit separat hochgeladen zu haben, auch wenn es 
"nur" die eine Relation ist, dann sind beim Revert nicht die 200 Häuser 
futsch.


tom


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

Re: [Talk-de] Entfernen von wheelchair_toilet Tags

[Tom Pfeifer]

Ich hatte den Thread damals angestossen, und stimme mit Holger überein, 
dass sich das sauber mit overpass-Abfragen und JOSM lösen lässt.


Das Konzept, das sich seitdem bei mir geformt hat, sähe vor, die 
verschiedenen Fälle vorzusortieren (gleichlautende, widersprüchliche, 
unknown) und dann schrittweise umzuwandeln.


Die Ursache waren ja nicht, wie in anderen Fällen, veraltete Tags oder 
verschiedene Meinungen von Mappern, sondern ein Softwarebug. Ich kann 
mir bei Tageslicht nochmal die Verteilung der Tags anschauen und eine 
Reihenfolge vorschlagen.


tom

On 21.02.2017 20:20, Holger Jeromin wrote:

Jan Schulte  Wrote in message:

Hallo talk-de,

ich bin Jan und arbeite derzeit an der wheelmap. Derzeit kümmern wir uns
darum, POIs zu bereinigen, die das wheelchair_toilet Tag haben. Ich habe
bereits diesen Thread gelesen
https://lists.openstreetmap.org/pipermail/talk-de/2016-July/113238.html
wo das Thema diskutiert wurde. Wir haben uns bereits Gedanken gemacht,
wie wir diese POIs in der wheelmap selbst bereinigen
(https://github.com/sozialhelden/wheelmap/issues/400). Im Thread wurde
empfohlen, dies in OpenStreetMap über einen Mechanical Edit zu lösen.
Bevor wir dies starten, möchten wir nachfragen, ob das immer noch
gewünscht ist. Falls ja, dann würden wir unsere Migration so anpassen,
dass sie die Änderungen via Rosemary auch direkt an die OpenStreetMap
überträgt.

Was denkt ihr dazu?



Ich bin immer noch dafür das in OSM anzupassen. Danke dass du das
 nochmal ansprichst und auch machen willst.


Wobei ich mich frage ob das über rosemary ein schlauer Weg ist.
 Ich würde es eher mit JOSM machen. Da habe ich das Gefühl, dass
 man das fehlerfreier reinbekommt als über eine Zusatzfunktion bei
 euch.





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

Re: [Talk-de] Da ist mir etwas aufgefallen

[Tom Pfeifer]

Ist behoben. Das war wohl versehentlich hochgeladen worden. Auf 
vermutlich der gleichen Mappingparty war wohl auch noch ein anderer User 
mit dem gleichen Problem.


Das erste liess sich schnell mit dem JOSM-reverter beheben, beim zweiten 
waren aber auch noch sinnvolle Edits drin, so dass man selektiv löschen 
musste, und aufpassen nicht die Null-Boje zu erwischen :-)


Gruesse
Tom

On 15.02.2017 08:42, gmbo wrote:

Bin gerade über den Änderungssatz eines neuen Benutzers gestolpert.
Sieht aus wie Tests an Pos 0/0
https://www.openstreetmap.org/changeset/46097003#map=13/-0.0349/0.0334

User: faisalhandal87

vor 19 Std.  angemeldet

MASIH ADA KESALAHAN
ES GIBT IMMER NOCH FEHLER

ist da in Malaisch angegeben.



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

Re: [Talk-de] Fussgänger Routing durch Anlagen in denen Eintritt verlangt wird.

[Tom Pfeifer]

On 09.02.2017 15:05, Martin Koppenhoefer wrote:

Am 9. Februar 2017 um 14:57 schrieb chris66 :


Ein Router kann nicht feststellen auf welcher Seite des Nodes
das fee=yes gilt.


ist ja auch egal, das Passieren des nodes kostet.


Oder wenn der Themenpark als Polygon fee=yes hat, könnte der Router das 
auswerten. Das hilft auch bei der Richtungsbestimmung.


Apropos Drehkreuze, es gibt doch entrance=exit und entrance=emergency,
beide spezifizieren einen richtungsabhängigen Ausgang aus einem Polygon.

tom


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

Re: [Talk-de] Quelle von GPX-Track finden

[Tom Pfeifer]

On 31.01.2017 09:14, Markus wrote:

Wie kann ich den Ersteller eines GPX-Tracks finden?
Track wird in JOSM angezeigt als "GPS-Rohdaten".


Das hängt sicher von der privacy-Einstellungen des Tracks ab.

Im Layer-Fenster erscheint "Downloaded GPX Data", dort, rechte 
Maustaste, siehst du ein Trichtersymbol "Choose visible tracks". Das 
öffnet eine Tabelle mit den Details der geladenen Tracks, u.a. die URL 
mit dem Usernamen drin. Falls der Track öffentlich ist.


Hier kannst du auch nach einem Zeitfenster filtern, praktisch bei neu 
gebauten Kreisverkehren.


Ausserdem kannst du das InfoMode-Plugin installieren, da bekommst du 
links ein Tracksymbol mit "info", wenn du das aktivierst siehst du die 
Details auch mit Mouseover auf den _Punkten_ im Hauptfenster.

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/InfoMode

tom

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Tom Pfeifer]

Tom Pfeifer wrote on 2016/09/07 18:57:

Martin Koppenhoefer wrote on 2016/09/07 12:02:

name auf dem highway Objekt oder auf der Route Relation? M.E. gehört sowas wie 
Berliner Ring eher in eine Route Relation, weil es sich ja z.B. mit Berliner 
Ring überlappt.



Mitteldeutsche Schleife:

Keine eigene Routenrelation
Highway-Segmente:
name=Mitteldeutsche Schleife, gesetzt von SennaHB, Nov 2015
auf den Teilstücken der A14, A9, A38, A143
A 38 auch mit reg_name=Südharzautobahn
A143 stückweise reg_name=Westumfahrung Halle


Es gibt jetzt eine Route:
https://www.openstreetmap.org/relation/6572024

War ziemlich fummelig, spannenderweise trugen keine der Brücken bzw.
Tunnelprojekte den Namen, und die Relation lässt sich natürlich nicht
fix mal automatisch als Rundroute sortieren.

Damit ist die Schleife jetzt als Einzelobjekt auffindbar.

"loc_name" ist auf allen Einzelsegmenten noch unbelegt
(Teile der A38 und A143 belegen bereits "reg_name"),

Nächster Plan wäre, "name" auf den Segmenten auf
"loc_name" zu ändern bzw. wo es fehlt anzulegen.

Oder nur "name" von den Einzelsegmenten entfernen...

tom

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/09/07 12:02:

name auf dem highway Objekt oder auf der Route Relation? M.E. gehört sowas wie 
Berliner Ring eher in eine Route Relation, weil es sich ja z.B. mit Berliner 
Ring überlappt.


Status quo:

Berliner Ring:
==
Routenrelation 5485500, name=Bundesautobahn 10, ref=A 10
Highway-Segmente:
name=Östlicher...etc Berliner Ring
reg_name=Berliner Ring

AVUS:
=
Teilstrecke der Routenrelation 5485765, name=Bundesautobahn 115, ref=A 115
Highway-Segmente:
name=AVUS (auf dem relevanten Teilstück)

Autobahn der Freiheit:
==
Routenrelation 548, name=Bundesautobahn 12, ref=A 12
Highway-Segmente:
name=Autobahn der Freiheit, gesetzt von miko101
Wikipedia: Ehrenname "Autobahn der Freiheit", seit 9. Okt 2014

Mitteldeutsche Schleife:

Keine eigene Routenrelation
Highway-Segmente:
name=Mitteldeutsche Schleife, gesetzt von SennaHB, Nov 2015
auf den Teilstücken der A14, A9, A38, A143
A 38 auch mit reg_name=Südharzautobahn
A143 stückweise reg_name=Westumfahrung Halle


Am sinnvollsten scheint mir eine Routenrelation für die Schleife, die im
Gegensatz zu den anderen Beispielen keinen Streckencharakter hat. Das
kollidiert dann auch nicht mit den streckenbezogenen reg_name der A38/A143.


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

Re: [Talk-de] Liegenschaften des Bundesnachrichtendienstes

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/09/06 07:56:

Il giorno 06 set 2016, alle ore 00:56, Tom Pfeifer  ha scritto:

Wenn es denn eine Regierungsbehörde ist:
Es gibt ja die noch offenen Diskussionen im Bereich
- landuse=civic_admin
- landuse=institutional



ich fände es besser, etwas spezifischer zu taggen, damit man auch semantisch 
suchen kann und nicht nur über den Namen. So was wie 
amenity=intelligence_service


Ja bitte, das ist dann die Einrichtung, nicht die Landnutzung.
Trag doch die Idee zur Tagging-Liste.

tom


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

Re: [Talk-de] Liegenschaften des Bundesnachrichtendienstes

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/09/02 22:48:

Mir ist beim Lesen dieses Artikels  der mit einer OSM Karte illustriert ist

> [...] zufällig aufgefallen, dass die Liegenschaften des BND den tag 
landuse=military tragen.
> Das ist vermutlich nicht korrekt, da es sich beim BND um eine nachgeordnete 
Behörde des
> Bundeskanzleramtes handelt, und keinesfalls um eine militärische Einrichtung.
> Der militärische Nachrichtendienst ist der MAD.


Z.B. hier:
http://www.openstreetmap.org/way/239950443

Wie könnte man das besser taggen?


Wenn es denn eine Regierungsbehörde ist:
Es gibt ja die noch offenen Diskussionen im Bereich
- landuse=civic_admin
- landuse=institutional

https://wiki.openstreetmap.org/wiki/Proposed_features/Civic_admin
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dinstitutional

wobei wohl jemand ersteres grade zementieren will:
- https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dcivic_admin

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

Re: [Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Tom Pfeifer]

"Christian Müller" wrote on 2016/09/05 23:23 + 2016/09/06 00:00

Von: "Tom Pfeifer"
Daher plädiere ich dafür, das Tagging mit dieser Bezeichnung in
reg_name oder loc_name [4] zu überführen, da ich es für einen
regional und nicht allgemein genutzten Namen halte.


Da schieben wir doch am besten gleich die regionalen
Bezeichnungen in anderen Ländern ebenfalls in reg_name
und schreiben brav die deutschen Namen als die allgemein
Benutzten hinein.  Klar, das wir dazu allgemein deutsche
Quellen anführen und die regional fremdländischen brav
ignorieren.


> Da der Verkehrsfunk [...] Ein "allgemeiner Name" lässt
> sich mit seiner Hilfe weder nachweisen noch widerlegen.

Danke dass du die Diskussion aufnimmst.

Der Ironie kann ich aber nur bedingt folgen. Für deutschsprachige Namen
im Ausland gibt es name:de, darum geht es hier nicht.

Vielmehr wollte ich sondieren, ob die Bezeichnung, wenn sie schon
nicht ausgeschildert wurde, wenigstens allgemeiner Sprachgebrauch ist.

Die von dir zitierten Dokumente stützen aber eher das Gegenteil,
es erscheint als eine Meinung eines ehemaligen Verkehrsministers und eine
Radio-PR-Aktion, alles im Jahre 2003, und gelegentlich taucht die
Bezeichnung noch in Gänsefüsschen in politischen Dokumenten zum
Weiterbau der A143 auf.

Der Berliner Fernsehturm sollte auch mal unbedingt "Telespargel" genannt
werden, sagte und sagt aber keiner.

Also machen wir die Gegenprobe:

- Wenn du jemand von Grimma nach Löbejün zum Klettern lotst, empfiehlst
  du ihm "Nimm die Nördliche Mitteldeutsche Schleife" oder "Fahr die A14"?

- Möchtest du, dass dir dein Navi am Schkeuditzer Kreuz empfiehlt,
  "Biege jetzt ab auf die Mitteldeutsche Schleife"? Wohin fährst du dann?

Mangels Fertigstellung der A143 ist die Schleife ja noch nicht mal eine.

Mit einer Routenrelation könnte ich mich ja noch anfreunden, aber
auf den Einzelautobahnen finde ich es irritierend.

tom


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

[Talk-de] Mitteldeutsche Schleife -> reg_name ?

[Tom Pfeifer]

Beim Befahren der A9 Berlin-München fiel mir im Bereich Halle/Leipzig
in OSM das Tagging name=Mitteldeutsche Schleife für Teile der A9/14/38/143 auf.

Laut Wikipedia [1] entstand dieser Name als Hörer-Wettbewerb eines
Radiosenders.

Eine Beschilderung mit diesem Namen habe ich bisher nicht gefunden,
auch kein offizielles Dokument, in dem er erwähnt wird. Auch im
Verkehrsfunk ist habe ich die Bezeichnung nicht gehört, im Gegensatz
z.B. zum Berliner Ring.

Reiseführer und selbst andere Wikipediaartikel sprechen von der
"sogenannten Mitteldeutschen Schleife".

Daher plädiere ich dafür, das Tagging mit dieser Bezeichnung in
reg_name oder loc_name [4] zu überführen, da ich es für einen
regional und nicht allgemein genutzten Namen halte.

Anderenfalls bitte ich um das Aufzeigen von Quellen, die einen
offiziellen Charakter dieses Namens belegen.

[1] https://de.wikipedia.org/wiki/Mitteldeutsche_Schleife
[2] Bernd Görne: Baedeker Reiseführer Leipzig, Halle, 2015, S. 26
[3] https://de.wikipedia.org/wiki/Bundesautobahn_143
[4] https://wiki.openstreetmap.org/wiki/DE:Key:name

tom



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

Re: [Talk-de] Help needed for mapping missing navigation data in Germany

[Tom Pfeifer]

Nikhil,
thanks for discussion your remote mapping plans in advance.

However, what I miss from the analysis on your diary page is the
analysis how much in need the named cities are for a remote mapping
approach, i.e. when you count existing turn restriction, what is your
estimate of missing ones or wrong ones?

My guess is that there are very few missing in Berlin, and the motorways
are quite complete with exit numbers and destination tagging.

Berlin is well covered with local mappers who are quite responsive to
constant changes in restrictions, lane layout and construction sites.
Relying mostly on mapillary, which covers about 3 years now, you would
get in trouble with these things having changed meanwhile.

tom

Nikhil Prabhakar wrote on 2016/08/12 14:33:

Hello Everyone,

In an effort to improve the navigation data in Europe, we are planning to
add/verify turn restrictions, exit numbers and destination names in the
cities of Europe starting with Berlin, Stuttgart and Wolfsburg in Germany.
We will be using Mapillary images as a source for adding these data. We
have shared our initial analysis, workflow and tagging system we are going
to follow in OSM diary[1]. We would like your support and involvement in
this endeavour and also, it would be great to hear about any questions or
feedbacks that you all may have regarding the workflow and tagging system
that we are following before taking this forward.

[1] Diary post - http://www.openstreetmap.org/user/nammala/diary/39255



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

Re: [Talk-de] Mobile Verkaufsstände

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/07/14 14:19:

Dass intermittent ...

ich hätte das gerne etwas granularer. Es ist schon ein ziemlicher
Unterschied, ob da ein Weihnachtsmarktstand gemappt ist, der 1 Woche im


Für Weihnachtsmärkte/bäume gibt es doch schon ein Tagging, und
sogar eine Weihnachtsmarktkarte?

Vielleicht kann man das aufgreifen? Mir fehlt grad die Zeit zum Nachlesen.

tom


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

Re: [Talk-de] Mobile Verkaufsstände

[Tom Pfeifer]

Sven Geggus wrote on 2016/07/14 10:02:

Das bedeutet wenn man das nicht rendern möchte, dann braucht man eine
Postgresql funktion die opening_hours parsen kann?!  Dann doch besser
intermittent.

Der Unterschied zu Wochenmärkten ist, dass die ihr eigenes Tag
amenity=marketplace haben, das derzeit gar nicht gerendert wird.


Es spricht doch nichts dagegen, beide Tags zu verwenden,
opening_hours und intermittent.

Dass intermittent schon für Wasserwege benutzt wird, ist ja auch kein
Hindernis. Ich nehme capacity ja auch für Fahrradstellplätze und Kindergärten.

Und schon kann man den Burger gestrichelt zeichnen ;-)

tom


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

Re: [Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!

[Tom Pfeifer]

Holger Jeromin wrote on 2016/07/09 08:19:

Tom Pfeifer <t.pfei...@computer.org> Wrote in message:

Dazu kommt noch ein neuer Tag 'wheelchair_toilet=*' (4600x), hier gibt es mehr
'unknown' als 'yes' und 'no' zusammen (53%). Undokumentiert.


Das falsche Tag war mir auch schon mal aufgefallen und habe es den
  sozialhelden gemeldet. Daraufhin haben sie den Fehler im backend
  innerhalb von wenigen Tagen behoben. Das ganze ist ein zwei Jahre
  her.

Neue sollten nicht mehr rein kommen. Ich wäre für einen mechanical
  edit zur Korrektur.


Danke Holger für den Hinweis, ich habe daraufhin mal das Zeitverhalten
analysiert:

Über den Sammeluser 'wheelmap_android' kamen noch bis vor 7 Monaten
die 'wheelchair_toilet' herein. In jüngeren Changesets nicht mehr,
allerdings wird dann zusätzlich ein 'toilets:wheelchair' aufgeklebt,
ohne das alte zu löschen.

'unknown'-Werte sind mir in jüngeren Changesets auch nicht mehr aufgefallen.
Leider sieht man den Fix nicht an der Softwareversion, alt wie neu kommt mit
'rosemary v0.4.4'.

Für einen mechanischen Edit wäre ich auch, insbesondere da der fehlerhafte
Key nun auch von anderen Mappern übernommen wird.

Kriterien wären aus meiner Sicht:
- Löschen von {wheelchair_toilet|toilets:wheelchair}=unknown
- Wenn beide vorhanden sind, vergleichen, bei Gleichheit wheelchair_toilet 
löschen
- bei Ungleichheit die Anzahl ermitteln, ob man sich die einzeln ansehen kann,
  ggf. den zeitlich neueren Wert übernehmen, meist wird das toilets:wheelchair 
sein
- wenn nur wheelchair_toilet={yes|no} vorhanden, auf toilets:wheelchair ändern
- verbleibende Werte ausserhalb von {yes|no} manuell prüfen.

Unschön bleiben noch das mehrfache Hochzählen der Versionsnummern im
gleichen CS für jeden geänderten Tag, und das *toilet*=no an Objekten,
an denen man ohnehin keine Toilette erwartet, z.B.

amenity=drinking_water
highway=bus_stop
natural=cave_entrance
historic=memorial
tourism=artwork

tom

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

[Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!

[Tom Pfeifer]

Vermutlich bin ich ja politisch völlig inkorrekt, aber ich finde es
eigentlich ganz gut, dass eine Skulptur im Park keine rollstuhlgerechte
Toilette aufweist.

https://www.openstreetmap.org/node/258485628
tourism=artwork
artwork_type=sculpture
wheelchair=no
toilets:wheelchair=no

Warum sie mit Rollstuhl nicht zugänglich ist, kann ich angesichts eines
vorbeiführenden Fuss/Radweges nicht ganz nachvollziehen.

Das ist nur ein Beispiel, aber ich finde es befremdlich, an was für
unplausiblen Objekten immer mehr solche Tags aus der Wheelmap auftauchen.

Bushaltestellen und Supermarktparkplätze pflegen insgesamt wenig Toiletten
zu haben, dann natürlich auch keine für wheelchair.

Auch hat toilets:wheelchair fast 4000x den Wert 'unknown' (10%) [1],
kann man das nicht weglassen? Steht auch so im Wiki [3].

Dazu kommt noch ein neuer Tag 'wheelchair_toilet=*' (4600x), hier gibt es mehr
'unknown' als 'yes' und 'no' zusammen (53%). Undokumentiert.

Liest ein Sozialheld hier mit? Hochachtung für das Projekt als solches,
mir geht es um die technischen Details, die Vereinheitlichung des Taggings,
und die sinnvolle Steuerung des Mappings.

Sollten wir aufräumen wollen, dann gibt es noch recht häufig
'wheelchair:toilets=*' (472x) [4], vorwiegend im Ruhrgebiet offenbar aufgrund
eines alten Imports aus ruhr2010-barrierefrei.de und dessen Abfärbungen,
undokumentiert.

[1] https://taginfo.openstreetmap.org/keys/toilets%3Awheelchair#values
[2] https://taginfo.openstreetmap.org/keys/wheelchair_toilet#values
[3] https://wiki.openstreetmap.org/wiki/Key:toilets:wheelchair
[4] https://taginfo.openstreetmap.org/keys/wheelchair%3Atoilets

tom

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

Re: [Talk-de] place=square

[Tom Pfeifer]

Florian Lohoff wrote on 2016/06/28+29

Entsprechend brauchen dann Adressen an dem Platz auch kein addr:street
sondern addr:place.


Ich befand mich bei meiner Kritik an addr:place im Irrtum, es handele sich
um einen neuen Vorschlag. addr:place ist aber 5.5 Mio mal im Einsatz,
etwa 10% von addr:street 56 Mio. Alles gut.

> Und was ist wenn es eine Straße und ein Place gibt die gleich heissen?

Ja, was empfehlen wir insbesondere wenn es den Schlossplatz gibt, der
auch von einem highway=* durchzogen wird, der auch mit Schlossplatz
beschildert ist?

addr:place oder addr:street an die Häuser?

(Als konkretes Beispiel hätte ich den Molkenmarkt in Berlin zu bieten.)

tom



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

Re: [Talk-de] place=square

[Tom Pfeifer]

Florian Lohoff wrote on 2016/06/28 14:04:

Falsch - addr:street brauch dann eine Straße die so heisst in der Nähe.
Wenn es keine gibt dann funktioniert die Adresse nicht weil Nominatim
keine Hierarchie bauen kann.

Deshalb - place node anlegen für den Platz und auf den Adressen die
dazu gehören entsprechend das addr:street zu einem addr:place machen.
Dann ordnet Nominatim the Adresse einem entsprechenden place node
zu.

http://nominatim.openstreetmap.org/details.php?place_id=123389138


Dann sollte doch besser Nominatim lernen, dass es ein addr:street
auch einem place=square zuordnen kann, als allen neuen Mappern beizubringen,
dass sie den Schlossplatz 27 mit einem anderen Adresstag mappen müssen
als die Schlossstrasse 47 ?

tom


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

Re: [Talk-de] place=square

[Tom Pfeifer]

Florian Lohoff wrote on 2016/06/28 12:35:

On Tue, Jun 28, 2016 at 11:25:27AM +0200, Martin Koppenhoefer wrote:

http://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare


Entsprechend brauchen dann Adressen an dem Platz auch kein addr:street
sondern addr:place.


Der Platz selbst braucht kein Adresstag, so wie eine Straße ja auch
kein addr:street bekommt, sondern die angrenzenden Häuser.

Für die Häuser reicht auch addr:street=Alexanderplatz, da brauche ich
auch kein extra Tag dafür.


Leider wird der Name nicht gerendert -


Daher ja Martins Werbung, wenn mehr Tags benutzt werden, kommt auch der
Renderer vorbei

tom

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

Re: [Talk-de] breite Wassergräben

[Tom Pfeifer]

Lilienthaler wrote on 2016/06/22 13:53:

Manuel Reimer wrote

Folglich fände ich "Drain" für einen breiten Abwassergraben nicht ganz
falsch.


Es ist aber kein Abwasser, es sind Meliorationsgräben, die eine Niederung
entwässern. Deshalb finde ich ditch doch passender.


"Drain" heisst ja auch nicht Abwasser, sondern in diesem Kontext 
(Langenscheidt):

- als Verb:
  Land entwässern, dränieren, trockenlegen
  drain off, drain away: (Ab)Wasser etc. ableiten, -führen, -ziehen
  kanalisieren;
- als Substantiv
  Ableitung f, Abfluss
  Abflussrohr n, Abzugskanal m, Entwässerungsgraben m; Gosse
  Kanalisation

Das passt sehr wohl für Melioration.

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

Re: [Talk-de] das Buch von J. Bennett über OSM heute kostenlos als eBook

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/06/07:
> Rückmeldung hierzu gerne

"Der Vollständigkeit halber" ist diese Information sicher relevant.


ja, hätte ich wahrscheinlich dazuschreiben sollen, der Preis ist es eine Email 
Adresse,

> wobei die ja nicht echt sein muss, falls man packt publishing nicht gut 
findet.

Wegwerfadressen gibt es an jeder 2. Ecke ;-)


anonbox wurde als invalid abgelehnt, ein bei einem Freemailer erzeugte
Wegwerfadresse angenommen (und musste auch nicht mal bestätigt werden).

Unklar sind die Lizenzbestimmungen, ob ich den freien content nun auch
weiterverteilen darf (das hängt davon ab, wo ich das Komma in den T setze). 
Wenn sie
aber nur alte Schinken als free raushauen, ist das dann auch wieder 
uninteressant.

vg tom


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

Re: [Talk-de] massenhaftes Löschen von Adressknoten / Tags auf Umringe

[Tom Pfeifer]

chris66 wrote on 2016/05/12 11:50:

Wurden die Formalien für einen mechanical Edit eingehalten?


Habe keinerlei Ankündigung oder Diskussion gefunden, weder auf talk-de,
der Berliner Liste noch im Forum.

Nicht einmal die Changesets selbst haben einen Kommentar, auch die
Quelle für die geometrischen Korrekturen fehlt.


Am 11.05.2016 um 19:04 schrieb Tom Pfeifer:

Mir ist ein Mapper aufgefallen, der grossflächig durch die Lande reitet
und jeweils im Tausenderpack Addressknoten löscht und deren Inhalt auf
Gebäudeumringe legt.

Aus meiner Sicht sind sowohl Einzelknoten als auch Taggen des Umrings
gebräuchliche Mappingstile, die kein grossflächiges Umtaggen erfordern.




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

[Talk-de] massenhaftes Löschen von Adressknoten / Tags auf Umringe

[Tom Pfeifer]

Mir ist ein Mapper aufgefallen, der grossflächig durch die Lande reitet
und jeweils im Tausenderpack Addressknoten löscht und deren Inhalt auf
Gebäudeumringe legt.

Aus meiner Sicht sind sowohl Einzelknoten als auch Taggen des Umrings
gebräuchliche Mappingstile, die kein grossflächiges Umtaggen erfordern.

Nebenbei geht die Historie der Objekte verloren, und es wird im konkreten
Fall offenbar nicht geprüft, ob betroffene Geschäfte und Büros tatsächlich
das Gebäude ausfüllen und nicht nur einen Raum.

Auch wenn die Edits vermutlich mit Sichtkontrolle eines Luftbildes erfolgen
und wohl auch Geometrien korrigiert und Umringe hinzugefügt werden, hat
die ganze Vorgehensweise Merkmale eines mechanischen Edits.

Mich interessiert eure Meinung dazu, man starte die Betrachtung bei
CS 39039628.

Tom

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

Re: [Talk-de] Neuer User, der viel loescht und auf Nachfrage nicht reagiert

[Tom Pfeifer]

Fazit: Die Löschungen sind nun revertiert, und Markus schaut sich
die Existenz der Pfade gelegentlich vor Ort im Wald an.



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

Re: [Talk-de] Neuer User, der viel loescht und auf Nachfrage nicht reagiert

[Tom Pfeifer]

Ich bin jetzt alle 13 CSs mit Achavi und JOSM durchgegangen,
sie sind weitgehend plausibel und korrekt bzw. korrigiert.
Im allerersten ist noch eine einzelne unbegründete Weglöschung.

Tom Pfeifer wrote on 2016/04/17 19:50:


Sollte unsere Diskussion zu einem Revert führen, dann wäre das derzeit
konfliktfrei möglich wenn man alle 3 CS zugleich lädt.


Ich bin dort für einen Revert, wer macht es?

tom


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

Re: [Talk-de] Neuer User, der viel loescht und auf Nachfrage nicht reagiert

[Tom Pfeifer]

malenki wrote on 2016/04/17 17:36:

malenki schrieb:


Die massiven Löschungen betreffen nur Pfade in einem begrenzten
Waldgebiet.


Die Dichte der Pfade ist sicher recht hoch, aber ich kann etliche
von ihnen an Waldrändern bzw. Schneisenmustern im Baumbestand auf
Bing erkennen. Öffentliche GPS-Traces haben sie leider nicht.

Eine solche Menge Trampelpfade ist in einem gut von Spaziergängern
heimgesuchten Wald aber durchaus möglich.

Eine Löschung als "Unsinn" ist jedenfalls unsachgemäss.

Vielleicht fühlte sich der User ja von dem derzeit etwas quietschroten
Rendering im Wald gestört.

Leider fällt der Urheber der Pfade auch nicht gerade durch einfallsreiche
CS-Beschreibungen oder Angabe von Quellen auf.

> Die microwave_links sind vermutlich Kollateralschaden.

Das bezweifle ich, da sie systematisch in allen 3 CS der Gruppe
(37796118 37799474 37806646 )
gelöscht wurden, im dritten ein ganzes Bündel.
Das spräche für einen unerfahrenen User, der etwas löscht was er
nicht kennt.


PS: Die Grenze natürlich auch


Ja, hier wurde nur ein Knoten aus einer gerade Linie gelöscht.

Sollte unsere Diskussion zu einem Revert führen, dann wäre das derzeit
konfliktfrei möglich wenn man alle 3 CS zugleich lädt.

tom



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

Re: [Talk-de] Radeln, rollern, schieben / Talk-de Nachrichtensammlung, Band 117, Eintrag 7

[Tom Pfeifer]

Bernhard Kuisle wrote on 2016/04/05 13:43:

Fußgängerzonen: Radfahren erlaubt - unerlaubt?
Die nächsten Zeilen sind unter Vorbehalt meines Gedächtnisses   .^)

1. Das Radfahren und auch das Radschieben sind wenn nicht ausdrücklich erlaubt 
in einer Fußgängerzone verboten.


https://dejure.org/gesetze/StVO/25.html
(2) Wer zu Fuß geht und Fahrzeuge oder sperrige Gegenstände mitführt, muss die 
Fahrbahn benutzen,
wenn auf dem Gehweg oder auf dem Seitenstreifen andere zu Fuß Gehende erheblich 
behindert würden.

Solange also keine erhebliche Behinderung vorliegt?


2. Das Rollern ist nach Gerichtsurteilen erlaubt. Rollern ist aber nur, wenn 
der Fuß auf dem Pedal ist, der beim Rollern auch auf dem Roller stehen würde.
D.h. für jemanden, der das Rad üblicherweise rechts schiebt, muss der rechte 
Fuß auf dem Pedal stehen. (Steht der linke Fuß drauf, ist er Radfahrer, da er 
jederzeit richtig aufsteigen könnte).


Vermutlich meinst du nicht rechtes oder linkes Bein (warum sollte ein 
Linksfüssler
nicht auf seinem rechten Pedal stehen?), sondern ob das Bein über den Rahmen
geschwungen ist oder nicht.

tom


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

Re: [Talk-de] bicycle=dismount von Routern ignoriert?

[Tom Pfeifer]

Carl von Einem wrote on 2016/04/04 16:00:

"§ 39 (3) Auch Zusatzzeichen sind Verkehrszeichen. Zusatzzeichen zeigen
... Aufschriften,..."

Eine Einschränkung, was in der Aufschrift stehen darf, finde ich dort
nicht.


Dann blättere bitte weiter bis § 41 Vorschriftzeichen, da findest du den Bezug 
auf die Anlage 2, [...]
Hier ist das konkrete Schild nicht aufgelistet.


Das hatte ich schon angesehen, auch dort steht nicht, dass es keine weiteren 
Aufschriften
geben kann.

Ausserdem mappe ich die Fakten wie ich sie vorfinde. In der StVO stehen auch 
keine
Blumenkübel. Wenn diese aber mitten auf der Strasse stehen, mappe ich eine
entsprechende barrier=* mit passenden access=* tag, Schild oder nicht Schild.


Zusatzzeichen [...] verkehrsrechtlich keinen Bestand und ist damit unwirksam,

> zumal der Verstoß gegen die Anordnung auch nirgends mit einem Verwarnungsgeld 
belegt ist.

Muss denn alles "verkehrsrechtlich wirksam" sein und mit Bußen belegt?
Darf man auch aufeinander Rücksicht nehmen, ohne das es durch rechtssichere
Schilder geregelt ist?


... keinen relevanten Tatbestant im Bußgeldkatalog, eine Ahndung ist
damit nicht möglich. (OLG Celle Az VRS 30,232)"


Man muss also kein Bußgeld zahlen, darf sich aber dennoch danach richten.
Die zitierten Urteile sind ja nur Reaktionen auf Einsprüche gegen Bescheide,
keine Verhaltensnormen.


ob die STVO Autofahrer bei irgendeiner Gelegenheit zum Schieben zwingt. Das 
wäre genauso absurd.


Die StVO nicht, aber vielleicht das Leben. Wenn die Karre im Dreck feststeckt,
bin ich für ein paar schiebende Zeitgenossen sehr dankbar, auch wenn sie nicht
durch Schilder dazu verpflichtet sind. :-)


[unter 6-9 Monaten] nicht als highway=construction erfasst werden sollten.


Sehe ich auch so, deswegen ist das immer noch ein highway=secondary mit
access-Tags. Conditional-Tags auch gerne, wenn sie denn vom Router auch 
ausgewertet
werden. Wobei dann die Evaluierungs-Reihenfolge wichtig wird, insbesondere
wenn für verschiedene Verkehrsarten verschiedene Bedingungen gelten.

tom

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

Re: [Talk-de] bicycle=dismount von Routern ignoriert?

[Tom Pfeifer]

Graphhopper kennt die Idee des Schiebens, es definiert für bikes 
"PushingSections"
für path, footway, pedestrian und steps, das passt zu meiner Beobachtung.
bicyle=yes/designated werden ausgewertet, =dismount aber nicht.

Ticket aufgemacht: https://github.com/graphhopper/graphhopper/issues/695

Carl von Einem wrote on 2016/04/04 11:05:

Das vom OP erwähnte Baustellen-Szenario würde ich aus zwei Gründen nicht mappen:
[...] "Fahrradfahrer absteigen" Zusatzschild ist nicht Teil der STVO


"§ 39 (3) Auch Zusatzzeichen sind Verkehrszeichen. Zusatzzeichen zeigen auf 
weißem
Grund mit schwarzem Rand schwarze Sinnbilder, Zeichnungen oder Aufschriften,..."

Eine Einschränkung, was in der Aufschrift stehen darf, finde ich dort nicht.


- zusätzlich werden Baustellen normalerweise nicht eingetragen [...];

> das müsste schon eine recht langwierige Baustelle [...] sein,

Ja, ein halbes Jahr Sperrung mit mehrkilometriger Umleitung ist für mich 
langwierig genug.

Die Formulierung "werden normalerweise" funktioniert in OSM nicht. Auch gibt
es verschiedene Vorschläge, eine befristete Sperrung zu taggen.

tom

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

Re: [Talk-de] bicycle=dismount von Routern ignoriert?

[Tom Pfeifer]

Bernhard Weiskopf wrote on 2016/04/03 22:19:

Bahnübergang für Fußgänger, ca. 20 m lang.
highway = footway mit bicycle = dismount:
GraphHopper, Mapzen und OsmAnd routen Fahrradfahrer über das Stück.
-> Alles in Ordnung.


Dann wird vielleicht highway=footway anders behandelt.

Mein Fall ist eine Baustelle auf highway=secondary,
wo nur noch Fussgänger und schiebende Radfahrer durchdürfen, daher
access=no, foot=yes, bicycle=dismount.

> Bei GraphHopper und Mapzen dauert das erfahrungsgemäß etwa 1-2 Tage und bei 
BRouter 1-2 Wochen.

Das ist berücksichtigt, insbesondere kennen die beiden Router ja die Sperrung 
schon
und schicken Autos und eben die Fahrräder weg, während Fussgänger durchgeroutet 
werden.

Brouter schickt mich noch durch, aber wohl erstmal wegen alter Daten 
('car-test' geht auch noch durch).

Liegt wohl wirklich am highway-tag, wenn ich mir zum Vergleiche den Spreetunnel 
anschaue, da werden
highway=footway+bicycle=dismount von GraphHopper und Mapzen genutzt, die beiden
highway=steps+bicycle=dismount aber nur von GraphHopper, nicht von Mapzen.

GraphHopper scheint ohnehin highway=footway ohne bicycle-tag zu nutzen, während 
Mapzen
dann einen weiten Bogen macht.

Frederik Ramm wrote on 2016/04/04 00:41:
> Klappe ---<
> so dass man als Fussgänger durchpasst, aber als Fahrradfahrer sein Rad

Ja, oder diese Teile:
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dfull-height_turnstile

Aber bei mir ist ja bicycle=dismount, das soll ja ausdrücken, solange ich 
absteige,
komme ich mit dem Rad auch durch.

tom

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

[Talk-de] bicycle=dismount von Routern ignoriert?

[Tom Pfeifer]

Obwohl bicycle=dismount mit 4 uses sehr populär ist,
https://taginfo.openstreetmap.org/keys/?key=bicycle#values
scheint es von Routern ignoriert zu werden.

Ich habe hier eine Baustelle getaggt, die so ausgeschildert
ist (Fussgänger ja, Radfahrer absteigen), aber sowohl
Mapzen als auch Graphhopper schicken mich lieber auf die 3.3.km-Auto-Umleitung,
als die 50 m durch die Brücke zu schieben...

(getested mit dem Routingangebot direkt auf https://www.openstreetmap.org).

tom


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

Re: [Talk-de] In JOSM tauchen Hinweise auf,

[Tom Pfeifer]

Heinz-Jürgen Oertel wrote on 2016/03/24 14:33:

Am Donnerstag, 24. März 2016, 14:17:28 schrieb Rolf Eike Beer:

Am Donnerstag, 24. März 2016, 14:08:20 schrieb Heinz-Jürgen Oertel:

die ich nach Bearbeitung gern löschen würde, weiß aber nicht wie?
DEL/Entf funktioniert nach Anwahl jedenfalls nicht.


Wenn es um den Validator geht: wenn etwas über die "Reparieren"-Funktion von
JOSM behoben wird, dann wird es sofort aus der Liste entfernt. Ansonsten den
Validator einfach nochmal aufrufen, dann baut er die Liste neu auf.

HTH

Eike




Nein, nicht der Validator
es sieht so aus
http://www.oerte-halle.de//files/Hinweis.png


http://www.oertel-halle.de//files/Hinweis.png geht besser.

Das sind offenbar Notes. Dazu habe ich links im Sidebar ein Symbol,
das so aussieht wie die roten Notes-Marker. Wenn ich das aktiviere, habe
ich ein Panel für die Notes, da kann ich sie kommentieren, beantworten,
und mit dem grünen Häkchen-Marker schliessen.

tom

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

Re: [Talk-de] Güllegruben

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2016/02/11 08:08:

 *  covered=no
 *  man_made=storage_tank"



bin nicht 100% sicher ob das im englischen auch so ist, aber ein Tank ist 
geschlossen, eine Grube offen, von daher würde ich keins der beiden Tags 
verwenden.
covered=no würde ich darauf beziehen, ob der Tank im Freien steht oder 
überdeckt ist, nicht ob es überhaupt ein Tank ist.


Kann offen oder geschlossen/gedeckelt sein:

Oxford (BrE + AmE):
1. a large receptacle or storage chamber, especially for liquid or gas.
- the container holding the fuel supply in a motor vehicle, aircraft, etc.
- a receptacle with transparent sides in which to keep fish; an aquarium.

Wikipedia/Storage tank
... The term can be used for reservoirs (artificial lakes and ponds), and
for manufactured containers. ... Reservoirs can be covered

Ich denke daher die obige Anwendung im Tag ist sinnvoll, insbesondere
die Spezifizierung mit covered=yes/no.

tom

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

Re: [Talk-de] Biogasanlage

[Tom Pfeifer]

Helmut Kauer wrote on 2016/02/10 13:05:

Griaß eich,
die Gärbehälter bei einer Biogasanlage sehen aus wie runde, geschlossene
Lagertanks, sind aber streng genommen keine. Wie sie also tagen?

Gruß Helmut



Das sind ja Anlagenteile eines Biogas-Generators, schau dir mal das an:

https://wiki.openstreetmap.org/wiki/DE:Tag:power%3Dgenerator

Beispiele

Um eine 15-MW-Biomassekraftwerke mit Kraft-Wärme-Kopplung und Biomassevergasung 
zu beschreiben, werden folgende Auszeichnungen gesetzt:

power=generator
generator:source=biomass
generator:output:electricity=5 MW
generator:output:hot_water=10 MW
generator:method=gasification

Das würde ich aber nur 1x für den Umriss der ganzen Anlage verwenden.
Wenn die Tanks sehr prominent sind, kann man sie ja noch einzeln zeichnen
und z.B. man_made=tank vergeben (taginfo: 4729).

tom

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

Re: [Talk-de] Güllegruben

[Tom Pfeifer]

building=* beschreibt ja den Typus eines Gebäudes, nicht die Nutzung.
"yes" ist der catch-all, alles andere eine Verfeinerung.

Wenn die Anlage also als Gülletank errichtet wurde, ist es
building=slurry_tank (taginfo: 5134) [1], die Wiki-Seite
hast du heute selbst nach DE übersetzt.

Auch wenn es z.B. leer steht, bleibt es building=slurry_tank

Deine anderen Tags beschreiben die Nutzung. Zum Inhalt ist es uneinheitlich:

664 content  = manure [3]
571 contents = manure [nicht dokumentiert]
und diversen Kleinkram, [2]

würde daher die erste Version bevorzugen.
tom

Helmut Kauer wrote on 2016/02/10 13:13:

Griaß eich,

Güllegruben, also Lagerstätten für tierische Exkremente, sind oft
mit
  *  building=yes
  *  content=manure
  *  covered=no
  *  man_made=storage_tank"
getagt. Im englischen Wiki gibt es aber auch building=slurry_tank.
Was ist also richtig?

Gruß Helmut



[1] http://taginfo.openstreetmap.org/tags/building=slurry_tank
[2] http://taginfo.openstreetmap.org/search?q=manure#values
[3] https://wiki.openstreetmap.org/wiki/Key:content

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

[Talk-de] Überprüfung AmE community_center -> BrE community_centre

[Tom Pfeifer]

Durch einen Fehler in einem Wheelmap-Preset, der inzwischen behoben ist [1],
ist die Zahl der als ..._center fehlgetaggten Gemeinschaftszentren deutlich 
angestiegen,
in DE 135 der weltweit 300 [2] (AT=1, CH=0), http://overpass-turbo.eu/s/e4r

Daher bitte ich um Überprüfung vor Ort und Korrektur nach ..._centre,
aber bitte nur manuell und nicht mechanisch, insbesondere auch aus folgenden 
Gründen:

- Die Wheelmap bringt neue Mapper in die Gemeinschaft, die noch nicht immer
  zielsicher bei der Kategorisierung sind.

  Ich habe auch Turnhallen, Restaurants und soziale Hilfseinrichtungen
  (--> amenity=social_facility) in den Daten gesehen.

- viele Einrichtungen sind nur als Knoten eingetragen, diese können oft
  zur Fläche ergänzt, bzw. auf Dubletten geprüft werden.

- Die Art des Zentrums kann mit community_centre=* und die Zielgruppe mit
  community_centre:for=* spezifiziert werden [3]

Tom

[1] https://github.com/sozialhelden/wheelmap/pull/94
[2] https://taginfo.openstreetmap.org/tags/amenity=community_center
[3] https://wiki.openstreetmap.org/wiki/Key:community_centre

https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dcommunity_centre#Zielgruppen

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

Re: [Talk-de] DB-Bahnhöfe und OSM

[Tom Pfeifer]

Sven Anders wrote on 2016/01/16 09:34:


Super spannendes Tool. Für große Haltestellen, wie Hamburg-Harburg mit
ich  ca. 5  Ebenen:

Brücke über Fernbahn,
Fernbahn,
S-Bahn Zwischenebene beim Phönix Center,
zweite Zwischenebene
S-Bahn Gleis

würde ich mir eine Landkarte auf Level-Ebene wünschen. Gibt es da evtl.
etwas?


Daran baut ja Roland Wagner von der Beuth-Hochschule Berlin:
http://www.openrailwaystationmap.org

Das hatte er auf dem Wherecamp und dem DB-Hackaton vorgestellt, hier einige 
Links:
Barcamp: Vorstellung DB AG OSM Pilot Railway Station Indoor Mapping:
https://www.youtube.com/watch?v=Ymtaatq7_b4
http://de.slideshare.net/WhereCampBerlin/wherecamp-navigation-conference-2015-db-ag-osm-pilot-railway-station-indoor-mapping

Ich weiss nicht ob er hier auf der DE-Liste mitliest, dort finden sich seine 
Kontaktdaten: http://www.beuth-hochschule.de/people/detail/1034/

tom

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

Re: [Talk-de] Autobahnkilometer

[Tom Pfeifer]

Martin Reß wrote on 2016/01/05 20:47:

wie leg ich das an ich brauch die km um bereiche einzugrenzen z.b Abschlepper 
A96 km 0.0 - 7.5 zuständig der nächste von km 7.5 - 28.0  usw.


Ich versuche noch zu verstehen was du eigentlich machen willst?
- willst du die Kilometertafeln mappen, die alle 500m an der Autobahn stehen?
- willst du in einem Editor, z.B. JOSM, die Weglängen messen und ggf.
  entsprechend splitten?
- willst du eine Auswertung schreiben, die anhand von OSM-Daten die 
Zuständigkeiten
  ermittelt?

All das könnte hinter der Frage stecken...

tom


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

Re: [Talk-de] Private Schwimmmbecken

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2015/11/29 15:05:

es gibt da klar mehrere Stufen: der private Pool im Garten eines Wohnhauses ist 
anders als der private Pool eines Hotels und wieder anders als ein öffentliches 
Schwimmbad oder ein privates allgemein zugängliches Schwimmbad.


Dann gibt es noch die runden Kinderplanschen, gern auch aufblasbar, die halt
auf dem Luftbild grade mal drauf sind. Das sind aber eher mobile Objekte, die
man beim Mappen vielleicht doch bitte aussparen sollte (aber schon gesehen).
Wenn die Auflösung für die kleinen Planschen reicht, erkennt mal meist auch ob 
es
ein stationärer Pool mit Wegplatten drumrum ist.

tom


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

Re: [Talk-de] OSM bei Polizei?

[Tom Pfeifer]

Nur wenn du vorher beim Mappen siebenmal den Blitzer auslöst, um
zu testen ob es sich um ein enforcement device oder eine fake_camera
handelt...

Andreas Schmidt wrote on 2015-11-17 11:01:

Internet ist ja auch Neuland.
Es ist übrigens die Bußgeldstelle. Ob man die um eine Spende für OSM
bitten könnte? So als pauschale Lizenzabgeltungsgebühr? :-)



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

Re: [Talk-de] Neue Farben im osm.org Kartenstil?

[Tom Pfeifer]

Christian Pietzsch wrote on 2015-11-02 15:59:

Was mir jetzt aufgefallen ist, ist das die Engländer die Verkehrsbdeutung
vieler ihrer Straßen höher einordnen, als das in Deutschland der Fall ist.


Umgekehrt wird ein Schuh daraus, wenn man die Entstehung der highway-Tags
betrachtet. Die sind ja auf die hierarchische Klassifikation auf der britischen
Insel zugeschnitten, und da sind die 'trunk' roads halt die grün beschilderten
A-Roads, die das überregionale 'Stamm'-Netz für alle Verkehrsteilnehmer
bilden. Die haben mit schnell oder langsam nichts zu tun.

Wir Deutschen haben hingegen die Hierarchie umdefiniert und nutzen das
Schema entsprechend der Verkehrsbedeutung, wobei die 'trunk'-Roads halt
als kreuzungsfreie Schnellstraße definiert wurde, die es dann aber nur
an Stellen mit hohem Verkehrsaufkommen gibt, und die daher kein Netz bilden.


Man muss nur mal Berlin mit London vergleichen. In London sind viele
Straßen "Schnellstraße" (in Deutschland hauptsächlich autobahnähnliche
Straße) getaggt. Wohingegen Berlin relativ wenige primarys hat und viele
secondarys. Dadurch wirkt natürlich die Londoner Ecke deutlich chaotischer,
als bspw Berlin.
Das liegt an der völlige unterschiedlichen Definition der Wikiseiten.
http://wiki.openstreetmap.org/wiki/DE:Key:highway



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

Re: [Talk-de] Platzobjekt

[Tom Pfeifer]

zu place=square
schrieb Martin Koppenhoefer am 2015-10-27 10:43:

ich finde place auch OK. "plaza" gefällt mir weniger gut, würde "square"
nehmen.

prima.


Wir sollten noch eine Empfehlung zum typischen Zeichnen haben,

brauchts nicht. Das kommt noch aus der Anfangszeit von OSM, dass man
Renderempfehlungen oder -wünsche abgibt, aber das wird zumindest vom


Mit Zeichnen war mappen gemeint, hättest meine Erläuterung stehen lassen
sollen: "vermutlich alles was offener Platz ist, also ausschliesslich der
umgebenden Gebäude, aber die zentralen Gebäude auf dem Platz
umschliessend?"

Also alles was _auf_ dem Platz steht umschliessen, alles was _am_ Platz
steht, vom Polygon ausschliessen.


Die Empfehlung zum Rendern wäre zumindest der Name des Platzes,
ggf. proportional zur Grösse, wobei das Label des Platzes vor
gleichnamigen Verkehrswegen Priorität haben sollte.



+1


Siehst du, doch eine Idee zum Rendern. Ideen darf man doch immer
noch haben.


Da das place=*-Schema auch den Routern schon bekannt ist, sollten
sich Plätze auf die Weise auch leicht finden lassen.



jeder Value muss eigens definiert werden (und eingefügt), automatisch wird
da nichts passieren vermute ich. Man braucht aber im Router diese Plätze
eher nicht, da ja die entsprechenden highway-Stücke auch den Platznamen
tragen werden.


Ja schon klar, gemeint war, es sollten den Programmierern der Router
leicht fallen, auch den Square einzubeziehen, da sie den "place=" key schon
in ihren Datenbasen haben.

Nicht alle Plätze haben gleichnamige highway-Stücke, manchmal ist nur eine
Grünanlage nach dem Platz benannt, manchmal hat der Mapper den Kopf in den
Sand gesteckt weil er nicht wusste an welches Feature er den Namen kleben
sollte, weil die Strasse mit anderem Namen durchläuft ;-)


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

Re: [Talk-de] Platzobjekt

[Tom Pfeifer]

Joachim wrote on 2015-10-26 19:28:

Mein Favorit: Ein Polygon mit place=square. Ist schon dokumentiert und
39x verwendet.

> http://wiki.openstreetmap.org/wiki/Tag%3Aplace%3Dsquare

Gefällt mir. Der Dinamik war's, aber an den Roten Platz hat sich
sich noch nicht rangemacht :-)  Leider halten ein paar Leute
einen Platz für eine amenity.

Wir sollten noch eine Empfehlung zum typischen Zeichnen haben,
vermutlich alles was offener Platz ist, also ausschliesslich der
umgebenden Gebäude, aber die zentralen Gebäude auf dem Platz
umschliessend?

Die Empfehlung zum Rendern wäre zumindest der Name des Platzes,
ggf. proportional zur Grösse, wobei das Label des Platzes vor
gleichnamigen Verkehrswegen Priorität haben sollte.
(Für die Grössenbestimmung ist ein Polygon besser als ein Node.)

Da das place=*-Schema auch den Routern schon bekannt ist, sollten
sich Plätze auf die Weise auch leicht finden lassen.

Und dann müssen wir halt im Dreieck Moskau-Berlin-Rom alle Plätze
mappen, bis Carto uns ernst nimmt :-)

tom


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

Re: [Talk-de] Platzobjekt

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2015-10-26 12:29:


Eigentlich bräuchte man für sauberes Mapping ein eigenes Platzobjekt,

> das alles dazugehörige einschließt. Bei einer Kirche könnte man ja vielleicht
> noch diskutieren, aber z.B. bei einem Denkmal oder Blumenbeeten nicht
> (trotzdem sollte man diese aus der pedestrian Fläche ausschließen). Manche
> Plätze sind vielleicht sogar überhaupt nicht betretbar.

Ja so etwas habe ich auch schon des öfteren vermisst. Manche Plätze sind eine
Grünanlage mit Strassen drumrum, manchmal sind sie sehr zergliedert mit
Blumenrabatten und kleinteiligen Fussgängerbereichen.

Fragt sich, ob das ein umschliessendes Polygon sein sollte, oder eher eine
Relation mit den zugehörigen Elementen. Falls Relation, wäre eine Site-relation
hinreichend?

tom


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

Re: [Talk-de] Parkplätze Autobahnen ohne u. mit W C

[Tom Pfeifer]

Albrecht Mehl wrote on 2015-10-13 09:44:

   - Kann jeder, der sich dazu berufen fühlt, an den Karten ändern, oder
 muss man - ich? - diesen Wunsch irgend welchen Oberen Zehntausenden,
 sprich Admins, melden, damit entschieden wird, dass so etwas kommen
 wird?


Ja, jeder kann sich mit einer gültigen E-Mail-Adresse anmelden, und
Aktualisierungen eintragen. Die Adresse wird nicht veröffentlicht,
ist aber wichtig wenn man dir über das System eine Nachfrage schicken will.

Es gibt dann verschiedene Werkzeuge, um die Änderungen vorzunehmen.
Auf der Webseite stösst man als erstes auf den Editor "iD", sehr beliebt
ist auch JOSM, mit etwas höherem Lernaufwand dann sehr leistungsstark.

Wichtig sind aber die Quellen, aus denen du die Informationen für deine
Änderungen nimmst. Am besten ist die eigene Beobachtung, "ja ich habe am
Rastplatz ABC ein WC gesehen". Nicht übernommen werden dürfen die Informationen
aus urheberrechtlich geschützten Werken, also z.B. eine Autobahnkarte
vom XYZ-Verlag. Neben dem Urheberrechtsproblem sind die auch oft nicht
aktuell.


   - Falls die Anregung überhaupt aufgegriffen wird: würden dann die
 erbetenen Buchstaben P und WC automatisch beim Aufruf der Karten
 zu sehen sein, oder müsste man dann eine zusätzliche 'Folie' -
 vielleicht nicht der richtige Fachausdruck - aufrufen, damit
 die Information über die Grundkarte gelegt würde?


Es gibt sehr viele verschiedene Karten und Datenauswertungen, im konkreten
Fall könnte z.B. ein Navi diese Informationen auswerten. Welche Symbole in
einen bestimmten Kartenstil aufgenommen und "gerendert" werden, entscheiden
die Leute, die an dem Stil arbeiten. Da OSM inzwischen sehr viele Details
enthält, kan nicht alles in allen Karten dargestellt werden, sondern es
entwickeln sich viele Spezialkarten für bestimmte Interessenguppen.

Die in der Diskussion bereits genannten Overpass-Abfragen bieten die
Möglichkeit, auch sehr spezielle Anfragen sehr schnell visuell darzustellen.

tom


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

Re: [Talk-de] Elbsandstein: natural=peak oder natural=rock

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2015-10-09 09:48:



> (Davon abgesehen ist Peak für die Spitzen mE ok)

Ja das war ein positives Ergebnis der Diskussion, auch auf der
Talk-Seite, den peak als immateriellen, höchsten Punkt zu
präzisieren, unabhängig von der Art des physischen Objekts.


natural=rock ist soweit ich mich erinnere ein Synonym für bare_rock und bedrock,

> jeweils als area, evtl meinte der mapper natural=boulder?

Ja, jetzt sollte man reviewen wie sich stone, boulder, rock, bare_rock, bedrock
abgrenzen bzw. ueberlappen, das sollte man vielleicht in die Tagging-Liste 
tragen.

tom


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

Re: [Talk-de] Elbsandstein: natural=peak oder natural=rock

[Tom Pfeifer]

Der User hat sich an der CS-Diskussion beteiligt (33834511), und seine 
Änderungen
selbst reverted (34491237). Zur weiteren Präzisierung von peak vs. rock siehe
Talk-Page auf natural=peak.

tom


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

Re: [Talk-de] Weitere Gipfel-Tags / Elbsandstein: ...

[Tom Pfeifer]

Martin Koppenhoefer wrote on 2015-10-07 08:04:

Am 07.10.2015 um 03:59 schrieb Tom Pfeifer:

  summit:register = yes
  damit ist vermutlich die Existenz des Gipfelbuchs gemeint, und nicht ein
  Register der Gipfel. Etabliert hat sich hier bereits:
  climbing:summit_log = yes


laut taginfo gibt es ca. 10x mehr summit:register


Das mag sein, und kann an der Art der Importe liegen.
summit:register ist semantisch mehrdeutig, hier aber nur ein Nebenschauplatz.


Und
  difficulty = III
sollte man auch man anpassen auf das heute übliche Schema
  climbing:grade:saxon:min = *


difficulty und vor allem das ähnliche piste:difficulty ist allerdings weit 
verbreiteter.

> Macht es wirklich Sinn, da eine eigene Skala zu verwenden?

Ja, da es weltweit etwa 10 verschiedene Skalen gibt, die alle aktiv
in den entsprechenden Gebieten verwendet werden.

difficulty ist nicht dokumentiert, hier mischen sich in den Werten
die römischen Ziffern aus Sachsen mit verbalen Beschreibungen, die
offenbar aus dem Pistentagging herüberschwappen.

piste:difficulty ist gut, da es sportartspezifisch ist.

Das soll aber nicht Teil des Reverts sein, daher spalte ich die Diskussion
mal ab.

tom


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

Re: [Talk-de] Liste aller Kirchen in Deutschland

[Tom Pfeifer]

Florian Lohoff wrote on 2015-10-06 19:21:


sein ... Damit kann man das auch "self-contained" trennen. D.h.
ein Gebäude mit building=church und innerhalb einen node
der eben den amenity trägt.

Oder vergallopier ich mich da gerade?


Ich glaube ja. Es gibt doch einen weitgehenden Konsens,
wenn ein Gebäudeeine einheitliche Funktion hat, diese auch auf
dem Umring zu taggen, sei das ein Hotel, ein Supermarkt oder
die Kirche.

Wenn es sich um eine untergeordnete Funktion in dem Gebäude
handelt, also das Restaurant im Hotel, der Backstand im
Supermarkt, oder der Gebetsraum im Flughafen, plädiere ich
für Node.

Unsere Kartenmaler sehen das auch so, und geben einem Gebäude
mit place_of_worship ein hervorgehobenes Rendering.

tom


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

[Talk-de] Elbsandstein: natural=peak oder natural=rock

[Tom Pfeifer]

Es fiel mir gerade auf, dass ein User den Elbsandstein gerade massiv
und flächendeckend umtaggt, von natural=peak auf natural=rock.

Man arbeite sich von https://www.openstreetmap.org/changeset/33834511
weiter, mindestens ein Dutzend Changesets seit einem Monat.

Das führte auch bei Datennutzern schon zu Irritation [1], und auch
ich würde die Klettergipfel bei der nächsten Sachsenreise gern
wiederfinden.

Das flächenhafte Vorgehen hat Anzeichen eines 'mechanical edits',
zu dem ich weder in dieser oder der Dresdner Mailingliste, noch im
Forum eine vorhergehende Diskussion fand.

Da die Wiki-Definitionen zu Peak [2] und Rock [3] durchaus schwammig sind,
sollten wir über eine klare Abgrenzung nachdenken. Die Beispielbilder
zu Rock vermitteln nicht das Bild eines sächsischen Gipfels.

Da die Felsen im Elbsandstein oft freistehend sind, traditionelle
Namen tragen und in der Höhe einzeln vermessen sind, plädiere ich
für die Beibehaltung von "peak".

tom

[1] 
https://help.openstreetmap.org/questions/45693/removal-of-climbing-rocks-in-saxon-switzerland-elbsandsteingebirge-germany
[2] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dpeak
[3] https://wiki.openstreetmap.org/wiki/Tag:natural%3Drock

Klettern: http://forum.openstreetmap.org/viewtopic.php?id=15152=5
Felsen: http://forum.openstreetmap.org/viewtopic.php?id=30229


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

Re: [Talk-de] Elbsandstein: natural=peak oder natural=rock

[Tom Pfeifer]

Am 07.10.2015 um 00:41 schrieb Christian Pietzsch 
:

Ich halte es schlicht für falsch.


Martin Koppenhoefer wrote on 2015-10-07 00:59:

+1, ohne Diskussion massenhaft Änderungen durchführen ist auch nicht OK,

> ich würd's gleich reverten solange es noch einfach geht...

Einfach wird es wohl nicht mehr, ich habe schon entsprechende Changesets
gefunden, die 6 Monate alt sind. Auch sind die peak=>rock-Änderungen mit
anderen vermutlich sinnvollen Verbesserungen vermischt.

Im Kerngebiet der Edits gibt es 532 nodes (und nur nodes) mit natural=rock,
von denen 523 einen Namen haben:
http://overpass-turbo.eu/s/bSo

Das Durchblättern der Liste liest sich wie der Kletterführer, daher könnte
man den Revert auf overpass-Basis angehen, mit manuellem Plausibilitätscheck.

Unabhängig davon fielen mir auf:

  summit:register = yes
  damit ist vermutlich die Existenz des Gipfelbuchs gemeint, und nicht ein
  Register der Gipfel. Etabliert hat sich hier bereits:
  climbing:summit_log = yes

Und
  difficulty = III
sollte man auch man anpassen auf das heute übliche Schema
  climbing:grade:saxon:min = *

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

Re: [Talk-de] Gemeindehaus / Liste aller Kirchen in Deutschland

[Tom Pfeifer]

Sven Anders wrote on 2015-10-06 16:31:


Was wäre denn ein Gemeindehaus? amenity=place_of_worship und
amenity=parish_hall oder amenity=church_hall siehe [1] ?!?

Oder lassen wir das "amenity=place_of_worship" weg? Welche Tags sind
sinnvoll an das Gemeindehaus zu schreiben?


Wenn dort kein Gottesdienst stattfindet, ist es auch kein
"amenity=place_of_worship".

"amenity=community_centre" ist passend, wobei der Typ mit
"community_centre=*" noch verfeinert werden kann, z.B. mit
"community_centre=parish_hall", gern auch mit "religion=*".

Die Beispiele aus der 2012er help-question
(amenity=[parish|church]_hall) haben seitdem kaum Verbreitung
gefunden (je ca. 150), und eine weitere Fragmentierung des
amenity-tags ist nicht wünschenswert.

"amenity=community_centre" wird in carto gerendert.

tom



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

Re: [Talk-de] Peilung

[Tom Pfeifer]

Thorsten Alge wrote on 2015-09-24 23:16:

Hallo Liste,

gibt es einen OSM basierten Dienst auf dem eich die Peilung von einem
Punkt zu einem anderen ablesen kann?


Hallo Thorsten,

mir ist noch nicht ganz glar was du eigentlich machen willst.
Willst du auf einen realen Fernsehturm steigen und zur Kirche rüberpeilen,
und brauchst dazu "irgendwie" OSM?

Oder willst du von vorhandenen OSM-Nodes A und B wissen, in welcher
Kompass-Richtung A von B liegt?

Letzteres macht das Measurement-Plugin in JOSM. Einfach beide Nodes
anklicken, und Entfernung und Winkel werden im Fenster berechnet,
entsprechend der Auswahl auch Flächen und Pfadlängen.

tom


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

Re: [Talk-de] Doppenhaushälften mappen

[Tom Pfeifer]

Harald Hartmann wrote on 2015-09-01 16:57:


Nachtrag: ich will es nicht verschweigen, aber der Standardfall ist
wohl eher, dass man "zwei" Gebäude zeichnet. Aber das wirft dann in
der Tat eben genau die Diskussion hervor, die du selbst angesprochen
hast: es ist physisch meist nur "ein" Gebäude


Nicht unbedingt. Eine Doppelhaushälfte ist ja das zum Zweiergespann "verkürzte"
Reihenhaus, bei dem auch Brandmauer an Brandmauer grenzt.

Insofern sind zwei verklebte Gebäude durchaus gerechtfertigt.

Zur Frage extra Addressnode oder Addresse auf dem Umring gehen die
Meinungen auseinander, schön ist zumindest wenn ein Wohnviertel
einheitlich ist.

t.


Am 01.09.2015 um 16:50 schrieb Harald Hartmann:

Also ich bin ein Verfechter davon, in diesem Fall die Hausnummer
ganz klar als extra Node und zwar am besten am Eingang/Haustür
(entrance=yes) zu mappen.



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

Re: [Talk-de] 3D-Mapping: Wie Dachausrichtung richtig angeben?

[Tom Pfeifer]

Hallo Manuel,

Das 3D-Tagging steckt noch in den Kinderschuhen, und die Server
aktualisieren ihre Daten auch sehr unterschiedlich.

Was geht denn konkret nicht? Das Haus [1] Erlenbacher Str 27 ist
mit 'across' getaggt, und wird sowohl von F4 als auch von
http://maps.osm2world.org/ auch so gerendert, Dachfirst quer zur
langen Gebäudeseite, und sehen aus wie in Bing.

http://osmbuildings.org/ hat wohl grade Schwierigkeiten mit
Dächern überhaupt.

Manche deiner Häuser sind ja fast quadratisch, da muss man sehr
genau messen welches die längere Seite ist.

Eine Implementierung die ich selbst sehr vermisse ist 'apse_gabled',
für Kirchendächer, definiert hier:
https://wiki.openstreetmap.org/wiki/OSM-4D/Roof_table#Subtype_6

t.

[1] http://www.openstreetmap.org/way/34211104

Manuel Reimer wrote on 2015-08-03 13:04:

Hallo,

ich habe gestern mal rein aus Interesse mitten im Dorf ein paar Bilder
gemacht, aus diesen die Farbwerte entnommen und Dachformen eingetragen.

Das Ergebnis passt aber nicht. Die Dachausrichtung ist bei einigen Gebäuden
um 90° gedreht.

http://demo.f4map.com/#lat=49.9608933lon=9.6548681zoom=19

Ich habe schon versucht hier und da mit roof:orientation = across
nachzuhelfen, aber das scheint nichts zu bringen.

Wie bekomme ich die Dachausrichtung in f4map korrigiert? Welche Tags
interpretiert f4map?

Danke im Voraus

Gruß

Manuel



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

[Talk-de] hour_on/off / Re: MeckPomm ...

[Tom Pfeifer]

Joachim Kast wrote on 2015-06-29 21:24:


[3] http://www.openstreetmap.org/way/5011198


Worauf bezieht sich eigentlich das hour_on/off [1], auf den Zugang,
die Geschwindigkeit, oder die Einbahnstrasse?

Ich würde empfehlen, beim entsprechenden Wert das Schema
key:conditional=value @ (22:00-06:00) [2] zu verwenden...

[1] deprecated: https://wiki.openstreetmap.org/wiki/Key:hour_on
[2] https://wiki.openstreetmap.org/wiki/Conditional_restrictions

Hm, interessant,
367 Nodes tragen hour_on/off=automatic, das sind offenbar viele 
highway=street_lamp
in Sachsen, die diesen Tag ohne Dokumentation adoptiert haben.

tom

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