Re: [Talk-de] Kostenlose OSMF-Mitgliedschaft für Aktive - Craftmapper in die OSMF ;)

[Rolf Eike Beer]

Am Samstag, 22. August 2020, 10:42:00 CEST schrieb Rolf Eike Beer:
> Am Donnerstag, 20. August 2020, 10:17:18 CEST schrieb Frederik Ramm:
> > Hallo,
> > 
> > Michael Spreng von der Membership Working Group der OSMF hat gerade
> > geschrieben
> > (https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/007162.ht
> > ml ), dass die schon länger geplante Regel "aktive Mapper kommen kostenlos
> > in die OSMF" jetzt umgesetzt ist.
> > 
> > https://join.osmfoundation.org/active-contributor-membership/application-f
> > or m-for-active-contributor-membership-mapping/
> 
> Ganz toll wäre es, wenn man die Eingabefelder durch URL-Parameter vorbelegen
> könnte.

Und wenn man jetzt noch das Formular hinter eine OSM-OAuth-Anmeldung steckt, 
dann kennt man sogar schon den Benutzernamen _und_ man kann sich die Nachfrage 
beim Benutzer sparen: win-win!

Eike


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kostenlose OSMF-Mitgliedschaft für Aktive - Craftmapper in die OSMF ;)

[Rolf Eike Beer]

Am Samstag, 22. August 2020, 22:49:07 CEST schrieb michael spreng:
> Hallo Eike
> 
> On 22.08.20 10:42, Rolf Eike Beer wrote:
> > Ganz toll wäre es, wenn man die Eingabefelder durch URL-Parameter
> > vorbelegen könnte.
> 
> Kannst du das etwas ausführen, was da der usecase wäre?

Das wäre für einen automatischen Erinnerungslink z.B. eine 
Implementierungsvariante. Gekommen ist mir das ganze gestern, bei einer IRC-
Debatte mit Pascal:

[10:36:30]  pascal_n: du könntest für Benutzer, die per OSM angemeldet 
sind und ihr eigenes Profil betrachten, ja einen Link zur OSMF-Mitgliedschaft 
anbieten wenn sie mehr als 42 Mapping days haben

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kostenlose OSMF-Mitgliedschaft für Aktive - Craftmapper in die OSMF ;)

[Rolf Eike Beer]

Am Donnerstag, 20. August 2020, 10:17:18 CEST schrieb Frederik Ramm:
> Hallo,
> 
> Michael Spreng von der Membership Working Group der OSMF hat gerade
> geschrieben
> (https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/007162.html
> ), dass die schon länger geplante Regel "aktive Mapper kommen kostenlos in
> die OSMF" jetzt umgesetzt ist.
> 
> https://join.osmfoundation.org/active-contributor-membership/application-for
> m-for-active-contributor-membership-mapping/

Ganz toll wäre es, wenn man die Eingabefelder durch URL-Parameter vorbelegen 
könnte.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kostenlose OSMF-Mitgliedschaft für Aktive - Craftmapper in die OSMF ;)

[Rolf Eike Beer]

Am Donnerstag, 20. August 2020, 10:17:18 CEST schrieb Frederik Ramm:
> Hallo,
> 
> Michael Spreng von der Membership Working Group der OSMF hat gerade
> geschrieben
> (https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/007162.html
> ), dass die schon länger geplante Regel "aktive Mapper kommen kostenlos in
> die OSMF" jetzt umgesetzt ist.
> 
> https://join.osmfoundation.org/active-contributor-membership/application-for
> m-for-active-contributor-membership-mapping/ ist das Spezial-Formular für
> "Mapper mit mindestens 42 Mappingtagen im letzten Jahr". Details zum
> Programm hier:
> https://join.osmfoundation.org/active-contributor-membership - der
> kleine Wermutstropfen ist, dass man das Formular jedes Jahr wieder neu
> ausfüllen muss, aber sonst würden sich halt zu viele Karteileichen
> ansammeln, die sich längst nicht mehr für OSM interessieren.

Ich fände da halt ein Service der folgenden Art ganz toll:

Hey, deine Mitgliedschaft läuft in 2 Wochen aus. Du erfüllst das 42-Tage-
Kriterium immer noch, also klick einfach hier und alles wird verlängert: 


Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Vereinheitlichung Tagging Aufzug-ID und Rolltreppen-ID aus Operator-Sicht

[Rolf Eike Beer]

Am 2020-03-23 12:08, schrieb Stefan Kaufmann:

Am 21.03.20 um 22:15 schrieb Rainer:

darauf bei ref die Seriennummer des Herstellers einzutragen wäre ich 
gar

nicht gekommen. Das halte ich nur für die Thyssens, Otis und fürs
SAP-System des Verkehrsbetriebes, der die Rolltreppen bzw. Lifte
betreibt, für relevant. In M sind, soweit ich sehe, mit ref=* die
Kennungen der MVG erfaßt. Siehe http://overpass-turbo.eu/s/RNt

Aber einverstanden, ref:elevator_operatorid=* würde diese Unklarheit
beseitigen. Wäre nur zu klären, ob irgendeine Anwendung oder Karte,
evtl. auch nur in einem einzelnen Verkehrsverbund, diese refs 
auswertet.


Die Geschichte ist eventuell noch etwas komplizierter m)

Ich musste erst mal nachgraben, wie das damals zustande kam, dass ich
das im OKF-Blog so vorgeschlagen hatte, und ich kann es offen gestanden
nicht mehr nachvollziehen.
Wir hatten damals durch die Datenspende der DB jeweils zwei Schluessel
pro Aufzug:
* Einmal die am Aufzug direkt ablesbare und vom Hersteller zugewiesene
Nummer
* und die interne ID der Bahn, die _nicht_ zwangslaeufig die
Herstellernummer war (konnte aber sein, oder so aehnlich sein).

Ich weiss leider wirklich nicht mehr, wie die Diskussion damals lief,
aber Quintessenz war der _Vorschlag_, ref:elevator_machineid fuer die 
am

Geraet ablesbare Herstelleridentifikation zu verwenden, und
ref:elevator_operatorid fuer die interne ID des Betreibers (sofern sie
unter freier Lizenz nachvollziehbar ist).

Das war damals ganz ausdruecklich nur ein Vorschlag – insofern sehr
schoen, dass die Diskussion nun stattfindet ;) Ich bin da vollkommen
emotionsfrei.


Hier gibt es scheinbar auch etwas zur Seriennummern: 
https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Ddefibrillator
Allerdings taucht das nur auf der französischen Seite auf, was auch 
wieder super-konsistent ist.


Ansonsten würde ich das "elevator_" aus den refs eher rauslassen, dann 
kann man das nämlich einfacher auf andere Objekte übertragen.


Eike

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

Re: [Talk-de] Vereinheitlichung Tagging Aufzug-ID und Rolltreppen-ID aus Operator-Sicht

[Rolf Eike Beer]

Am Samstag, 21. März 2020, 18:02:56 CET schrieb Dietmar Seifert:
> Hallo,
> 
> vorab: es geht hier um das umtaggen von Objekten, daher wäre evtl. die
> tagging-Mailingliste auch sinnvoll, aber der betroffene Key wird nur in
> Deutschland verwendet.

Ich bin zufällig vor einigen Tagen auch über diese Keys gestolpert und möchte 
an dieser Stelle nur einen anderen Punkt mit aufführen: "ref".

So wie ich das sehe ist "ref" bei Aufzügen die Seriennummer des Aufzugs, bzw. 
des Herstellers. Das widerspricht irgendwie meinem Bauchgefühl dessen, was ich 
sonst unter "ref" erwarte.

Ganz praktisch ist mir das aufgefallen, weil ich wusste, dass die Seriennummer 
bei Aufzügen irgendwie erfasst wurde. Bei einer Elektroladesäule stand die 
auch dran, und ich dachte, die könnte man miterfassen. Aber da ist "ref" eher 
die Nummer des Betreibers, siehe z.B. auch Parkautomaten.

Spaß...

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Eisenbahnbrücken

[Rolf Eike Beer]

Am Freitag, 6. September 2019, 14:08:14 CEST schrieb i...@plennert.eu:
> Hallo zusammen,
> 
> ich wollte mal alle Brücken in einer Stadt zählen. Ich nahm die unter
> DE:Key:bridge hinterlegte overpass-turbo Abfrage. Im Ergebnis sah ich mir
> folgende Brücke genauer an:
> 
> Node: 97223943
> https://www.openstreetmap.org/way/97223943/history#map=19/47.75685/8.83666
> Mapillary:
> https://www.mapillary.com/app/?lat=47.75728421451801=8.836361404117434;
> z=18.550316863317572=aNToFOg6b0fFEQlons6sGw=photo
> 
> In der Realität ist dies eine Brücke mit vier Gleisen. Gemappt und
> ausgewertet werden vier Brücken mit je vier Lanes, also gesamt 16 Gleisen.

Mit "lanes" meinst du vermutlich passenger_lines, richtig? Das gibt an, wie 
viele der Gleise zu einer Bahnstrecke gehören, die Brücke hat laut Karte derer 
5: eines ist ein Nebengleis des Bahnhofs und gehört nicht zur Strecke. Das 
Äquivalent für "lanes" ist eben nicht "passenger_lines", sondern "tracks". Das 
wird in Deutschland kaum noch verwendet (zumindest nicht mit anderen Werten 
als 1), da die einzelnen Gleise i.d.R. getrennt voneinander erfasst sind.

Es gibt dann da noch ein Proposal für Relationen mit type=bridge, die sowas 
zusammenfassen können, aber das ist inaktiv.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Änderungen im Wiki: Tag:public transport=platform

[Rolf Eike Beer]

Am Mittwoch, 7. August 2019, 20:18:56 CEST schrieb KvMP via Talk-de:
> Hallo!
> 
> Aufgrund von (sehr vielen) ??nderungen eines Nutzers in meiner Umgebung der
> von allen Bushaltestellen im name-Tag konsequent den eigentlichen Namen der
> Haltestelle entfernt hat und so den Namen auf die Plattform-Nummerierung
> verst??mmelt hat, ist mir nach Pr??fung des Wikis aufgefallen, dass
> Wiki-Benutzer _Famosm_ recht gravierende ??nderungen an der Dokumentation
> der Tags gemacht hat [1]. So wurde bei name=* - frei ??bersetzt - von "Name
> der Station, Nummer kommt in ref=*" ge??ndert in "Nummer der Station" und
> bei ref=* von "Nummer der Station" ge??ndert zu "Bedienende Buslinien".
> Diese ??nderungen finde ich h??chst fragw??rdig und kontrovers, unter
> anderem mit Blick auf local_ref=* und route_ref=*. Eine ??hnliche ??nderung
> gab es im deutschen Artikel [2].

Abgesehen von deinen kaputten Umlauten bin ich ganz deiner Meinung.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] fire_hydrant:pipe_diameter

[Rolf Eike Beer]

Am Donnerstag, 4. April 2019, 14:10:29 CEST schrieb Martin Scholtes:
> > Grundsätzlich geht es AFAIK beim "diameter" von Rohren um den
> > Nominalinnendurchmesser, wenn das irgendwie aus dem tag hervorginge wäre
> > es
> > nicht schlecht. "diameter" ist in OSM normalerweise der Aussendurchmesser
> > (dachte ich), aber vielleicht kommt es auch einfach auf den Kontext an.
> > Vor
> > diesem Hintergrund wäre fire_hydrant:pipe_diameter evtl. besser.
> 
> Da ich aus dem FW-Wesen komme, kann ich dir versichern, das die
> eingetragenen Wert immer den Rohrdurchmesser der angezapften Leitung
> wiedergeben. Somit muss kein neuer Key erfunden werden.

Es gibt tatsächlich einen Fall, an dem beides interessant sein könnte: 
Überflurhydranten haben einen eigenen Durchmesser (steht meist auf dem Schaft, 
DN100 oder so) und einen davon völlig unabhängigen Durchmesser der 
Wasserleitung unten drunter. Für diese Hydranten gibt es Mindestmengen, was 
der Hydrant leisten muss, und die hängen vom Durchmesser des _Hydranten_ ab. 
Der Rohrdurchmesser ist in der Regel sowieso nicht ersichtlich, da 
Überflurhydranten i.d.R. kein Schild haben.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] fire_hydrant:pipe_diameter

[Rolf Eike Beer]

Am Mittwoch, 3. April 2019, 20:42:08 CEST schrieb Rolf Eike Beer:
> Am Mittwoch, 3. April 2019, 20:23:19 CEST schrieb Martin Scholtes:
> > Hallo,
> > 
> > habe wiedermal einen doch merkwürdigen key gefunden. Scheinbar soll der
> > fire_hydrant:pipe_diameter => fire_hydrant:diameter sein. Laut Taginfo
> > gibt es da neu "Ding" 215 mal in der DB. Kann man das per Massenedit
> > umtaggen?
> > 
> > Für mich ist das nämlich in OSM das selben und im Wiki gibt es nur das
> > fire_hydrant:diameter.
> 
> Ich habe beim Herumklicken zumindest einen Fall gefunden, in dem es auch ein
> widersprüchlichen Eintrag für fire_hydrant:diameter gibt. Bei den Fällen,
> bei denen die Einträge identisch sind oder es nur einen gibt, würde ich
> mich dem ansonsten anschließen.
> 
> Betrifft das nur einen Benutzer oder ist nachvollziehbar, wo das herkommt?
> Evtl. gibt es da eine fehlerhafte Vorlage oder Anleitung?

Bei der Gelegenheit hätte ich gerne auch noch einen Edit. Wir haben da einen 
(!) Benutzer, der fire_hydrant:diameter immer mit dem Zusatz " mm" taggt, was 
nicht nur den Vorlagen und dem Wiki widerspricht, sondern die Auswertung der 
Daten in meinen Augen unnötig erschwert. Können wir das bitte gleich mit 
entsorgen?

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] fire_hydrant:pipe_diameter

[Rolf Eike Beer]

Am Mittwoch, 3. April 2019, 20:23:19 CEST schrieb Martin Scholtes:
> Hallo,
> 
> habe wiedermal einen doch merkwürdigen key gefunden. Scheinbar soll der
> fire_hydrant:pipe_diameter => fire_hydrant:diameter sein. Laut Taginfo
> gibt es da neu "Ding" 215 mal in der DB. Kann man das per Massenedit
> umtaggen?
> 
> Für mich ist das nämlich in OSM das selben und im Wiki gibt es nur das
> fire_hydrant:diameter.

Ich habe beim Herumklicken zumindest einen Fall gefunden, in dem es auch ein 
widersprüchlichen Eintrag für fire_hydrant:diameter gibt. Bei den Fällen, bei 
denen die Einträge identisch sind oder es nur einen gibt, würde ich mich dem 
ansonsten anschließen.

Betrifft das nur einen Benutzer oder ist nachvollziehbar, wo das herkommt? 
Evtl. gibt es da eine fehlerhafte Vorlage oder Anleitung?


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Weihnachtskarten

[Rolf Eike Beer]

Am Montag, 17. Dezember 2018, 16:25:17 CET schrieb Frederik Ramm:

> Um das mal gehörig auszunutzen, möchten wir allen Leserinnen und Lesern
> hier auf der deutschen Mailingliste und im deutschen Forum anbieten,
> dass wir Euch kostenlos eine große Karte von einem Gebiet Eurer Wahl
> ausdrucken und zuschicken.

Ich habe heute dieses selbst bestellte Weihnachtsgeschenk in den Händen 
gehalten und finde es total Klasse. Vielen Dank an euch für die Mühe!

Aus eigener Neugier: wie viele Karten habt ihr denn verschickt? Habt ihr ein 
spezielles Setup verwendet oder ist das ein Standardsetup, das ihr für sowas 
habt?

Frohes Restjahr

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Illegale Feuerstelle

[Rolf Eike Beer]

Am Montag, 3. Dezember 2018, 18:05:45 CET schrieb L. Rose:
> On 3 December 2018 11:18:17 CET, Florian Lohoff  wrote:

> >Vielleicht brauchen wir einfach ein Tagging schema wie die Lifecycle
> >tags die Objekte "Unbrauchbar" macht. Denn es hilft meistens
> >ja nicht es zu entfernen. Der nächste Armchair mapper trägt
> >es ja wieder ein. Wenn es aber im Editor sichtbar ist als
> >deaktiviertes, unbrauchbares, illegales Objekt und auch
> >in der Karte nicht auftaucht wäre das ja in Ordnung.
> 
> Sehe ich genauso! Ich denke, wir sind uns alle einig, dass wir als
> OSM-Community nicht möchten, dass an einer illegalen Feuerstelle Feuer
> gemacht wird. Wenn die Feuerstelle entfernt wird, liegt es für den nächsten
> Nahe, sie wieder hinzuzufügen (vielleicht kennt er die Rechtslage auch gar
> nicht). Wenn wir sie dagegen dalassen und als illegal markieren, kommt
> keine auf die Idee, neue, "schlechte" Daten in die Datenbank einzutragen.
> Und sie dient kann als Orientierungspunkt etc. dienen.
> 
> Wenn die Karte die Illegalität nicht deutlich macht, ist das Problem der
> Darstellung, nicht der Datenlage. Durch Löschen bekämpfen wir sonst nur die
> Symptome, nicht das Problem. Das ist zumindest meine Meinung :)

Die Meinung teile ich. Wir sollten die Tags in einer Art und Weise mit einem 
Prefix "unbrauchbar" machen, so dass es nicht gerendert wird. Im Editor wird 
der Punkt dann sichtbar, auf der Karte verleitet er niemanden zu irgendetwas.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Boundary Kreise und Kreisfreie Städte

[Rolf Eike Beer]

Am 2018-11-27 21:20, schrieb wambac...@posteo.de:
Hi, das ist ganz einfach: Der Amtliche Gemeindeschlüssel von Kreisen 
und

Kreisfreien Städten ist unterschiedlich lang.

Der AGS von Kreisen hat die Länge 8 und der von Kreisfreien Städten ist
exakt 5 Zeichen lang. Das gilt für ganz Deutschland.


Nach deiner Tabelle ist es genau andersherum.


 name  | admin_level |
de:amtlicher_gemeindeschluessel
---+-+-
 Halle (Saale) | 6   | 15002000
 Munich    | 6   | 09162000
 Kreis Groß-Gerau  | 6   | 06433
 Kreis Euskirchen  | 6   | 05366
 Landkreis Peine   | 6   | 03157
 Landkreis Neustadt an der Aisch-Bad Windsheim | 6   | 09575
 Landkreis Neunkirchen | 6   | 10043
 Landkreis Neumarkt in der Oberpfalz   | 6   | 09373
 Landkreis München | 6   | 09184
 Landkreis Mühldorf am Inn | 6   | 09183
 Landkreis Miesbach    | 6   | 09182
 Landkreis Neu-Ulm | 6   | 09775
 Landkreis Neustadt an der Waldnaab    | 6   | 09374
 Passau    | 6   | 09262000
 Landkreis Eichsfeld   | 6   | 16061
 Landkreis Ebersberg   | 6   | 09175
 Landkreis Dingolfing-Landau   | 6   | 09279
 Landkreis Dillingen an der Donau  | 6   | 09773
 Landkreis Diepholz    | 6   | 03251
 Landkreis Deggendorf  | 6   | 09271
(20 Zeilen)


Eike

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

Re: [Talk-de] Gehen OSM-Editoren unterschiedlich mit Multipolygonen um?

[Rolf Eike Beer]

Am 2018-11-26 09:32, schrieb Bernhard Kuisle:

Bei der momentan laufenden Diskussion über Multipolygone und ihre
Handhabbarkeit habe ich noch eine Frage bezüglich der OSM Editoren:
Ich verwende JOSM und lege ein MP eigentlich immer nur mit einem
äußeren Ring (in einer Linie) und mehr oder weniger vielen inneren
Ringen an. Dadurch ist es mir später leicht möglich, das MP mit dem
Werkzeug "splitten" in zwei kleine aufzuteilen. Ich muss dann nur noch
dafür sorgen, die ich die inneren Ringe richtig zuzuordne.
Nun ist mir aufgefallen, dass bei den mir angelegten MPs später der
einelne äußere Ring eben in viele Wege zerstückelt wurde (vermutlich
um die Wege nicht mehrfach in der Datenbank zu halten). Dadurch ist es
bei großen MPs eine "Sauarbeit", diese richtig
zu teilen. Wer (Mensch oder Maschine) teilt diese einzelne äußere
Linie eigentlich auf? Ich habe den Verdacht, dass dies durch
Potlatch geschieht, stimmt das?


Moin,

zumindest beim Deister (#66210) habe ich das mal irgendwann händisch 
gemacht. Der äußere Ring hat gerade nur so um die 1000 Punkte, aber das 
war irgendwann extrem nervig: jemand hat an irgendeiner Stelle "hinterm 
Deister" was verschoben und dann bekommt man vorne Kollisionen, weil es 
der selbe Weg ist. Ein großes Problem war auch, dass ein User 
versehentlich den outer komplett gelöscht hatte und dann anfing 
reparieren zu wollen. Ein anderer hat den Fehler auch gesehen und auch 
angefangen… Schmerzen. Siehe die edit-history. Ich habe den Kram 
seinerzeit erst reverted und hinterher den outer willkürlich aufgeteilt, 
so dass die Wege eine für mich handhabbare Größe hatten. All das manuell 
und mit JOSM.


Ich sehe gerade das irgendein Scherzkeks jetzt in der Mitte eine Insel 
gebaut hat, die selbst wieder ein outer ist. :/


Eike

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

Re: [Talk-de] CS 62001645 abgesprochen?

[Rolf Eike Beer]

Am 2018-08-27 11:57, schrieb Martin Scholtes:

Hallo,

gestern ist mir ein CS mit der Nummer 62001645 aufgefallen, das
scheinbar deutschlandweit an alle Bahnhöfe ein railway=train gesetzt
hat. Mir kommt das etwas komisch vor, da solche Aktionen doch in der
Regel vorher im Forum oder Maillingliste bekannt/besprochen werden.
Hatte gestern, während seiner Bearbeitung, ihn angeschrieben, keine
Reaktion. Anschließend im CS kommentiert und bis jetzt auch keine 
Reaktion.


Weiß einer mehr?


Ich nicht. Aber so weit ich das sehe sind das nicht "Bahnhöfe" 
(railway=station), sondern die public_transport=stop_position nodes, 
denen zum korrekten ÖPNV-Tagging das train=yes wohl tatsächlich gefehlt 
haben.


Eike

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

Re: [Talk-de] Challenge accepted?

[Rolf Eike Beer]

Am Montag, 19. Februar 2018, 22:06:59 schrieb Max:
> Wenn man von der Adresse ausgeht, könnte man auch den Standpunkt
> einnehmen, dass die Straßen in jeder Richtung eine anderen Namen hat,
> und nicht, dass die Straßen gar keinen Namen haben. So scheint es ja
> auch vor Ort ausgeschildert zu sein im Video.

Du übersiehst, dass jede Straße dann 2 Namen hätte, da sie ja an 2 Blocks 
angrenzt.

Die Challenge ist wohl die Darstellung der korrekten Adressen und nicht nur 
der Hausnummern auf der OSM-(Haupt-)Karte.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Krankenhaus - Eingang

[Rolf Eike Beer]

Am 2017-08-23 15:44, schrieb Walter Nordmann:

schau mal bei https://wiki.openstreetmap.org/wiki/Key:entrance

Auf "der Karte" wirst du das sicher nicht so gerendert bekommen, aber
hier hätte ich was im Angebot:

https://wambachers-osm.website/emergency/#zoom=16=50.07244=8.23272=OpenStreetMap.org=TFFF

Kann auf die Stelle kein vernünftig erfasstes Hospital finden, aber
das wirst du mir sicher sagen. Ansonsten ist das "Entry/Exit"-Layer
noch ausbaufähig.


So? 
https://wambachers-osm.website/emergency/#zoom=18=52.303825=9.597979=OpenStreetMap.org=TFFF


Eike

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

Re: [Talk-de] Rettungsleitstellen

[Rolf Eike Beer]

Am Montag, 10. April 2017, 05:33:21 schrieb gmbo:
> Am 09.04.2017 um 22:58 schrieb Rolf Eike Beer:
> >> Aber woher käme die Information für einen Mäpper daß es sich bei dieser
> >> Einrichtung um eine Rettungsleitstelle handelt. Diese Funktion sollte in
> >> allen Rettungswachen installiert sein, aber von der Besetzung hängt ab
> >> ob es eine Leitstelle ist.
> > 
> > Nein. Eine Rettungswache ist ein Aufenthaltsraum, ein Klo und eine Garage.
> > Alles weitere ist optional. Notrufe werden da grundsätzlich _nicht_
> > angenommen (wenn jemand mal spontan vor der Tür steht vielleicht schon).
> > Wenn da der Pieper klingelt setzt man sich ins Auto und fährt los, zu
> > diesem Zeitpunkt ist die Wache dann durchaus auch mal völlig leer, das
> > wäre mit den Notrufen dann schon arg unpraktisch.
> > 
> > Wo sich die Leitstellen befinden ist kein wirkliches Geheimnis, wenn du es
> > nicht weißt einfach mal den nächstbesten Polizisten/Feuerwehrmann/Sani
> > fragen wenn man mal ins Gespräch kommen. (Hint: es gibt für jede Fraktion
> > i.d.R. maximal eine pro Landkreis).
> 
> Es mag in ländlicheren Gegenden so einfache Wachen geben, die eine
> solche Funktion nicht haben, aber es wird in größeren Wachen mit
> Sicherheit die Technik dafür installiert.

Nein, zumindest nicht in Deutschland. Das bedingt nämlich u.a. spezielle 
Schaltungen in der Telefonvermittlung, und die müssten ja dann im Problemfall 
erst aktiviert werden.

> So ein System funktioniert nicht ohne Redundanz. und die ist nicht an
> den Ort gebunden.

"Bitte rufen Sie die Leitstelle über Amt an." Der vorgesehene Fallback ist 
meist die Umschaltung auf eine Nachbarleitstelle.

> Es wird auch im Landkreis Fallbacksysteme geben um In Notfällen
> reagieren zu können.

Bei großflächigem Telefonausfall werden die Feuerwehrgerätehäuser besetzt bis 
das Problem behoben ist.

> Die Frage nach der Sichtbarkeit für Mapper ging auf die Sichtbarkeit
> hin, an was könnte man also per Auge feststellen, wo sich eine solche
> Institution befindet.

Steht meist draußen am Gebäude dran, die Standorte sind wie gesagt nicht 
geheim.

> In eine solche Leitstelle kommen nur berechtigte Personen.
> Was würde also eine Information für die Daten einer Karte nutzen?

Da hast du im Prinzip recht, aber wir mappen ja auch Eisenbahnsignale ;)

> Für meine Begriffe würde das nur dann Sinn machen, wenn die offizielllen
> Stellen dieses zur Darstellung nutzen wollen und da würde dann nicht der
> Punkt der Leitstelle benötigt sondern eher die Fläche die die Leitstelle
> betreut.
> Und auch das unterliegt Änderunngen, die nur Insider kennen.

Die wiederum sind recht einfach: da das kommunale Angelegenheiten sind ist die 
Fläche identisch mit der einer größeren Gebietskörperschaft, d.h. einem 
ehemaligen oder aktuellen Landkreis, einer kreisfreien Stadt oder in seltenen 
Fällen einer größeren kreisangehörigen Stadt (meist mit Berufsfeuerwehr oder 
ständig besetzter Feuerwache). Es können auch mehrere Landkreise auf einmal 
sein. Die einzige mir bekannte Ausnahme in die andere Richtung in Deutschland 
ist Berlin, das AFAIK 3 Feuerwehrleitstellen hat (die jeweils auch 
Rettungsdienst mit erledigen).

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Rettungsleitstellen

[Rolf Eike Beer]

> Aber woher käme die Information für einen Mäpper daß es sich bei dieser
> Einrichtung um eine Rettungsleitstelle handelt. Diese Funktion sollte in
> allen Rettungswachen installiert sein, aber von der Besetzung hängt ab
> ob es eine Leitstelle ist.

Nein. Eine Rettungswache ist ein Aufenthaltsraum, ein Klo und eine Garage. 
Alles weitere ist optional. Notrufe werden da grundsätzlich _nicht_ angenommen 
(wenn jemand mal spontan vor der Tür steht vielleicht schon). Wenn da der 
Pieper klingelt setzt man sich ins Auto und fährt los, zu diesem Zeitpunkt ist 
die Wache dann durchaus auch mal völlig leer, das wäre mit den Notrufen dann 
schon arg unpraktisch.

Wo sich die Leitstellen befinden ist kein wirkliches Geheimnis, wenn du es 
nicht weißt einfach mal den nächstbesten Polizisten/Feuerwehrmann/Sani fragen 
wenn man mal ins Gespräch kommen. (Hint: es gibt für jede Fraktion i.d.R. 
maximal eine pro Landkreis).

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging

[Rolf Eike Beer]

Am Donnerstag, 30. März 2017, 14:18:58 schrieb Martin Koppenhoefer:
> Es gibt mehrere Standards und ein paar weitere Alternativen, um 30er Zonen
> zu taggen.
> 
> Dazu hier im wiki:
> https://wiki.openstreetmap.org/wiki/Key:source:maxspeed
> 
> Aktuelle Zahlen von heute:
> maxspeed=30 and zone:maxspeed=DE:30 - 32952 uses
> maxspeed=30 and source:maxspeed=DE:zone30 - 32018 uses
> maxspeed=30 and source:maxspeed=DE:zone:30 - 21832 uses

Also generell: immer feste drauf.

Ich persönlich halte source*= für Freitext-Felder, die das Verständnis der 
Daten erleichtern, wenn man es sich im Editor anguckt, aber ansonsten völlig 
irrelevant sind. Ja, das darf hier auch gerne vereinheitlicht werden, aber 
IMHO ist das für die maschinelle Auswertung völlig irrelevant.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wann ist das Eintragen von POIs ein IMPORT.

[Rolf Eike Beer]

[…]
> Ab wann wäre das ein Import?

IMHO: definiv nein, das ist manuelles hinzufügen.

Bitte für solche Diskussionen nicht auf eine vorherige antworten, sondern eine 
neue Mail an die Liste schicken, ansonsten kommt das Threading im geeigneten 
Mailprogrammen unnötig durcheinander.

Gruß

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tagging Zuführung zur Autobahn

[Rolf Eike Beer]

Am Sonntag 11 Dezember 2016, 12:24:02 schrieb Robert:
> Hallo zusammen!
> 
> Ich habe eine kurze Frage. Wie würdet ihr eine Straße (800 m lang,
> eine Spur je Richtung, keine bauliche Fahrbahntrennung) taggen, welche
> zur Autobahn zuführt? Zu Beginn der Straße, also an der letzten
> Kreuzung, steht das Zeichen 330.1 (Autobahn), im Gegenverkehr wird
> erst dort per 330.2 die Autobahn beendet. Die Straße selbst ist eine
> Landesstraße.
> 
> Aktuell ist sie als trunk+motorroad=yes getaggt, wobei motorroad=yes
> dann bei Navis die Ansage "fahren Sie auf die Kraftfahrstraße"
> auslösen könnte, was vor Ort mangels Zeichen 331 so ja nicht
> vorgefunden werden kann.

Eine völlig unrepresentative Stichprobe, die ich gerade entlang der A2 und A7 
gemacht habe, zeigt, dass das "nur der baulich je Fahrtrichtung getrennte 
Teil", über den du im Wiki vermutlich auch gestolpert bist, allgemein 
ignoriert wird. Ansonsten hätte ich nämlich auch gesagt, dass das definitiv 
trunk_link ist. Allerdings kenne ich den Hintergrund für die gegenteilige 
Festlegung nicht. Wenn ich mir die Talk-Seite zu 
https://wiki.openstreetmap.org/wiki/Highway_link ansehe scheint es mir jedoch, 
als wollte man das "ausfließen" der Farbe in die querende Straße damit 
verhindern.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] China, Provinz Sechuan

[Rolf Eike Beer]

> Wahrscheinlich wird es bei meiner Reise kaum Probleme geben, wenn ich
> die Zoll- bzw. Sicherheitskontrollen passieren kann. Wir haben eine
> private, familiäre Einladung. Damit fällt der obligatorische Aufpasser
> bei Gruppenreisen weg und wir können uns freier bewegen. In der Stadt
> werde ich mir wohl hauptsächlich Wegpunkte setzen um wieder heim zu
> finden. Mappen möchte ich vor allem im Gebirge.

Sie wissen jetzt, dass du kommst…

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Koordinaten in China, Lagegenauigkeit

[Rolf Eike Beer]

* Ich vermute, OSM unterliegt - anders als Google - nicht chinesischen
Zwängen? Oder gibt es bei uns ebenfalls solche Vereinbarungen?


Richtig, OSM nimmt einfach weltweit das gleiche Koordinatensystem, 
weshalb es in China selbst illegal ist.


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

Re: [Talk-de] China, Provinz Sechuan

[Rolf Eike Beer]

Bei einigen Gebieten und Karten habe ich den Eindruck, dass Google
bessere Luftbilder hat (die wir nicht nutzen, aber die zuhause manchmal
das Erinnerungsvermögen stützen können, da wo Fotos und Tagebuch nicht
weiterhelfen).


Da kann ich dir aus dem Stand auch ein paar Dutzend Fälle in Deutschland 
nennen.



Unklar ist mir, woher der Versatz bei den Gewässern zwischen OSM-Karte
und Google-Street kommt:
http://sautter.com/map/?zoom=14=30.63712=103.92189=B000TTTF

Bei den Luftbildern von Bing und Google erkenne ich keinen Versatz.


Das liegt höchstwahrscheinlich daran, dass die für Bilder innerhalb 
Chinas auch deren verqueres Koordinatensystem nutzen müssen, siehe z.B. 
https://polastre.com/2013/02/what-the-map/


Eike

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

Re: [Talk-de] China, Provinz Sechuan

[Rolf Eike Beer]

> Hat jemand Erfahrung wie man in China mit Europäern umgeht, die sich für
> ihre Geografie interessieren? Gibt es Verbote in dieser Hinsicht? (ich
> möchte ungern unter Spionageverdacht geraten und letztlich die
> Innenarchitektur eines chinesischen Gefängnisses erkunden ;-) )

Ja, gibt es, und in China darf nur deren eigenes Koordinatensystem verwendet 
werden. OSM ist da schlicht illegal. In wie weit das praktische Relevanz hat, 
kann ich jedoch nicht sagen.

https://en.wikipedia.org/wiki/Restrictions_on_geographic_data_in_China

HTH

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

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

[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

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] alte Bahnlinie Frensdorf - Burgebrach

[Rolf Eike Beer]

Am 11.02.2016 08:03, schrieb Markus:

Liebe Bahn-Spezialisten,

habe eine alte Bahnlinie entdeckt ab Frensdorf.
Bis Burgebrach (Bhf) konnte ich sie weiterverfolgen und eintragen.
Ab dort weiss ich nicht, ob und wie sie weiterging.


Wo hast du sie denn eingetragen, ich sehe da nichts? In Frensdorf ist 
ein kleiner Stummel der Strecke, der aber schon seit 2014 da ist. Im 
weiteren Verlauf würde ich vermuten, dass sie im Wesentlichen mit dem 
Radweg dort identisch ist.


Angucken kannst du dir das hier, Aktualisierung etwa 1x täglich: 
http://www.openrailwaymap.org/canvas.php?lang=de=49.8191575437357=10.695276260375977=13=standard


Eike

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

[Talk-de] Desaster-Mapping in Bad Aibling?

[Rolf Eike Beer]

Moin,

auch bei mir regen sich gerade die üblichen Instinkte: es ist was passiert, 
die Karte ist nicht vollständig, und los. Ich habe gerade mal ein paar 
bahntechnische Details gefixt, aber viel mehr geht aus der Ferne denke ich 
nicht.

Mapillary gibt da momentan nichts her, aber z.B. die Bahnhöfe Bad Aibling und 
Kolbermoor bzw. auch der Haltepunkt Bad Aibling Kurpark könnten genug Details 
enthalten, z.B. die Signale für die Strecke dazwischen sowie Angaben zu 
Geschwindigkeitsbeschränkungen.

Es gibt auch schon die erste Eintragung an der Unglücksstrecke, die ein 
maxspeed=100 einträgt. Die Quelle ist mir klar, aber ich bin nicht sicher, 
dass das so in der Gesamtheit stimmt. Also, wenn jemand zufällig vor Ort ist 
und da bahntechnisch mithelfen möchte (und sofern man da im Moment überhaupt 
in die Nähe kommt): mappt die Positionen von allen Signalen und Schildern 
entlang der Strecke. Wenn ihr nicht wisst, was das für ein spezielles 
Signal/Schild ist: mappt die Position, ladet ein Bild hoch. Kleiner Hinweis: 
die Signalstandorte werden auf der Gleismitte eingetragen, auch wenn das 
eigentliche Signal daneben steht. Wichtig ist im Übrigen auch die Richtung, in 
die das Signal sichtbar ist, das ist auf den Bildern ja nicht notwendigerweise 
erkennbar.

Wenn jemand da jetzt mappen geht, bitte:

-steht den Rettungskräften und Ermittlern nicht im Weg rum, d.h. wenn ein Weg 
abgesperrt ist, bleibt da erst mal weg
-geht nicht in den Gleisbereich, auch wenn der Zugverkehr eingestellt ist 
können immer noch Hilfszüge oder andere Arbeitsgeräte dort fahren

Gruß

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] HTTPS für openstreetmap.DE

[Rolf Eike Beer]

Am Montag, 1. Februar 2016, 06:11:20 schrieb Manuel Reimer:
> Florian Lohoff  zz.de> writes:
> > Das Problem mit den 3 Monaten ist das man das zwangsweise automatisieren
> > muss. Niemand hat Bock ein Zertifikat alle 3 Monate manuell durch die
> > Gegend zu kopieren.
> 
> Genau das ist auch für mich der Show-Stopper.
> 
> Wenn ich mich recht erinnere war gerade ein Ziel des Projekts, möglichst
> vielen ein Zertifikat zugänglich zu machen.
> 
> Dieses Konzept wird zumindest zum Teil dadurch kaputt gemacht, dass man sich
> in diese "Automatisierungs-Client-Technik" verbissen hat.
> 
> Nicht bei jedem Hoster kann man sowas sinnvoll laufen lassen.

Musst du auch nicht. Da nur die Kontrolle über die Domain kontrolliert wird, 
die sich auch mal schnell ändern kann, ist die Laufzeit eben begrenzt. Der 
Client ist _eine_ Methode an das Zertifikat zu kommen. Du kannst auch eine 
Datei mit dem entsprechenden Challenge in das richtige Verzeichnis legen, dann 
geht das auch völlig ohne den Client, und du musst das Zertifikat nicht mal auf 
dem Server erzeugen (z.B. falls du keinen Shellzugang hast).

Hier gibt es das ganze z.B. als statisches Webinterface: 
https://gethttpsforfree.com/

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] HTTPS für openstreetmap.DE

[Rolf Eike Beer]

Am Samstag, 30. Januar 2016, 23:11:38 schrieb Andreas Neumann:
> Moin,
> 
> ich kenne die Querelen bezüglich SSL-Zertifikate für OpenStreetMap.DE
> von CACert. Die Frage ist nun für mich, ob die selben Probleme für
> Zertifikate von letsencrypt bestehen? (Ich klammere bewusst den
> höheren Ressourcenverbrauch aus und beziehe mich nur auf das
> Beantragungsproblem der Zertifikate)

Let's Encrypt prüft nur, ob du die Domain unter Kontrolle hast, d.h. es ist 
letztlich völlig unerheblich, wer oder was in den whois-Einträgen steht oder 
ob es sich dabei um natürliche Personen handelt oder nicht. Man muss das 
Zertifikat nur alle 3 Monate erneuern.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] HTTPS für openstreetmap.DE

[Rolf Eike Beer]

Am Sonntag, 31. Januar 2016, 17:03:37 schrieb Florian Lohoff:
> On Sun, Jan 31, 2016 at 11:18:39AM +0100, Rolf Eike Beer wrote:
> > Am Samstag, 30. Januar 2016, 23:11:38 schrieb Andreas Neumann:
> > > Moin,
> > > 
> > > ich kenne die Querelen bezüglich SSL-Zertifikate für OpenStreetMap.DE
> > > von CACert. Die Frage ist nun für mich, ob die selben Probleme für
> > > Zertifikate von letsencrypt bestehen? (Ich klammere bewusst den
> > > höheren Ressourcenverbrauch aus und beziehe mich nur auf das
> > > Beantragungsproblem der Zertifikate)
> > 
> > Let's Encrypt prüft nur, ob du die Domain unter Kontrolle hast, d.h. es
> > ist
> > letztlich völlig unerheblich, wer oder was in den whois-Einträgen steht
> > oder ob es sich dabei um natürliche Personen handelt oder nicht. Man muss
> > das Zertifikat nur alle 3 Monate erneuern.
> 
> Das Problem mit den 3 Monaten ist das man das zwangsweise automatisieren
> muss. Niemand hat Bock ein Zertifikat alle 3 Monate manuell durch die
> Gegend zu kopieren. Und bei so verteilter Infrastruktur braucht man das
> Zertifikat relativ häufig auch mal an 20 Stellen und dann wird das
> wirklich hakelig das robust hinzubekommen das nicht alle 3 Monate
> wieder an irgendeiner kleinen Stelle ein altes Zertifikat liegenbleibt.
> 
> Wir reden also schnell über sowas wie cfengine/puppet/ansible/chef.

Ja. Und? Es gibt doch einen vollautomatischen Client von denen, der halt 
exklusiv an Port 80 lauschen muss. Aber man kann den Kram auch an eine 
definierte Stelle im normalen Webroot hinkopieren, ich sehe nicht, warum man 
das nicht genauso automatisieren könnte. Wenn du es ohne Python hinbekommst 
bin ich ganz Ohr. ;)

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] highway=emergency_access_point

[Rolf Eike Beer]

Am Samstag, 7. November 2015, 15:53:07 schrieb Thorsten Alge:
> Die Nummern sind tatsächlich nicht doppelt. Wenn es einen GS-123 gibt,
> gibt es keinen OHA-123. 

Vielleicht nicht in den angrenzenden Landkreisen. Aber selbst innerhalb von 
Niedersachsen gibt es definitiv Wiederholungen.

> Die Frage ist nur, macht man sich jetzt die
> Arbeit die Namen zu korrigieren da ich denke, sie sollten keinen Namen
> haben – als Kompromiss vielleicht die Referenz auch als Namen.

http://wiki.openstreetmap.org/wiki/Name#Name_is_the_name_only

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ÖPNV-Karte / Darstellung historischer Bahnstrecke

[Rolf Eike Beer]

Am Samstag, 17. Oktober 2015, 11:25:39 schrieb goegeo:
> Hallo zusammen,
> 
> mir ist aufgefallen, dass in der ÖPNV-Karte eine historische Bahnlinie
> (blau) angezeigt wird. Es handelt sich um die ehemalige Straßenbahn
> Flensburg, welche nur bis 1973 bestand. Mag jemand bei der Entfernung
> behilflich sein. Bin im Tagging vom ÖPNV noch recht neu unterwegs. Denke
> aber, dass historische Bahnstrecken nicht in der ÖPNV-Karte dargestellt
> werden sollten.

Moin,

geh doch mal bitte etwas ins Detail, z.B. Koordinaten oder oder die id eines 
Weges, dann können wir uns das mal ansehen.

Gruß

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Public Transport - Haltestelle ohne Linie / Austragen oder belassen

[Rolf Eike Beer]

Am Montag 12 Oktober 2015, 20:40:43 schrieb Florian Lohoff:
> Hi,
> mir ist hier ein Changeset aufgefallen in dem eine
> Haltestelle/stop_position entfernt wurde die defakto existiert.
> Also da steht ein Bushaltestellenschild.
> 
> Der User der die entfernt hat sagt das diese Haltestelle nicht mehr
> angefahren wird. Jetzt bin ich eigentlich geneigt die trotzdem
> in den Daten zu lassen - Defakto existiert dort ja eine Haltestelle.
> 
> Die ist dann halt in keiner relation.

Genau so würde ich das auch machen. Diese Haltestellen tauchen ja dann gerne 
1-2 Jahre später wieder im Fahrplan auf, weil sich irgendjemand beschwehrt 
hat.

Sorsum/Waldorfschule (https://www.openstreetmap.org/node/1650543478) ist auch 
so ein Fall, da ist aktuell nur eine Richtung der Haltestellen im Fahrplan, 
die andere wird nicht bedient. Besonders obskur ist, dass die 
Haltestellennummer, die sonst immer auf dem Schild steht, bei der Haltestelle 
fehlt.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

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

[Rolf Eike Beer]

Am , schrieb Albrecht Mehl:

In der Gruppe

  de.etc.fahrzeuge.auto

habe ich unter dem Betreff 'Autobahnkarte gesucht' am 6.10. um
10:25 folgendes geschrieben:

-

Bisher vergeblich suche ich im Netz eine Karte, die man wie z.B. Google
Maps ziehen und verändern kann und die auch die Parkplätze mit
zusätzlicher Kennzeichnung von WC's anzeigt. Sowohl Google Maps als
auch OpenStreet Map haben das nicht.



Jein. Das wird vermutlich auf der Standardkarte nicht explizit 
gerendert. Das heißt nicht, dass die Daten nicht da wären. Hier mal ein 
kurzer Kartenausschnitt, auf dem alle Rastplätze und Raststätten mit WCs 
dargestellt werden:


http://overpass-turbo.eu/s/bVi

Relevant sind hier also die beiden keys highway=services (Raststätte) 
und highway=rest_area (Rastplatz), jeweils in Kombination mit 
toilets=yes. Nun muss nur noch jemand hingehen und daraus was hübsches 
basteln. ;)


Gruß

Eike

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

Re: [Talk-de] OSM routet nicht über neue A71

[Rolf Eike Beer]

Am Samstag, 5. September 2015, 20:00:32 schrieb Garry:
> OSM routet nicht über die neue A71 die dieses Woche freigegeben wurde.
> Sehe ich das richtig, dass die Daten fürs Routing noch nicht übernommen
> wurden (kann man das anstoßen?) oder ist da am Tagging noch ein Fehler?

"OSM" routet gar nicht. Du meinst vermutlich irgendeinen (welchen?) der auf 
OSM-Daten basierenden Router. Und bei denen sind die Datenbestände teilweise 
Monate alt, also: höchstwahrscheinlich ist in den Daten alles in Ordnung.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Abgerissene Gebäude

[Rolf Eike Beer]

Am Samstag, 29. August 2015, 10:12:01 schrieb Heinz-Jürgen Oertel:
> Hallo,
> 
> sollte man ein abgerissenes Gebäude, bisher building=yes, einfach löschen
> obwohl es noch im Bing zu sehen ist?
> Wie verhindere ich, dass es nicht wieder neu aufgenommen wird?
> 
> Hat jemend eine Idee?
> building=no
> note=abgerissen

abandoned:building=yes (oder residential oder was auch immer es mal war)
end_date=...

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bitte um Hilfe/Verbesserung/Kritik Haltestellen-Relation

[Rolf Eike Beer]

Am Dienstag, 7. Juli 2015, 00:09:20 schrieb Jo:
 Ich benutze die stop_area wenn die vorhanden sind, um vom platform, über
 die stop_position die Strasse zu finden die am Route hinzugefügt werden
 sollte.
 
 Wenn nicht vorhanden such mein Skript eine stop_position in der Nähe und
 ohne stop_position sucht es nur einen Weg wo ein Bus entlang fahren kann.
 
 Wenn ich merke dass das Skript Falsche Wege auswählt, füge ich eine
 stop_position zu.
 
 Ich habe also einen Tool programmiert der mich im JOSM helft die Routen zu
 schaffen. Dabei ist es hilfreich stop_positione zu finden die zu Platform
 gehören.
 
 Selbstverständlich funkzioniert der Tool/Skript nur wenn die Fahrplandaten
 vorhanden sind. Sonst ist es nicht möglich automatisch Sequenzen
 zu erfassen für alle Varianten.

Das ist eine abgefahrene Anwendung, um quasi neue Relationen zu generieren. 
Wie gut die Daten hinterher sind weiß ich natürlich nicht. Aber ich würde 
weiterhin alle Richtungen in eine stop_area tun, auch wenn das deine Arbeit 
etwas erschwert.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bitte um Hilfe/Verbesserung/Kritik Haltestellen-Relation

[Rolf Eike Beer]

Am Montag, 6. Juli 2015, 20:03:07 schrieb Andreas Schmidt:
 Hallo Norbert,
 
 danke für deine Anmerkungen.
 Ich habe gestern auch feststellen müssen, dass die Einhaltung der
 aktuellen Mapping„vorschriften“ (und Weglassen der „legacy“ - tags) dazu
 führt, dass die Bushaltestelle in der Karte nicht sichtbar ist.
 Genau das ist unser Hauptziel, da wir unsere neuen Linien bekannt machen
 wollen.

Ich hatte deshalb Andy Allen mal angeschrieben, er hat das auf seiner Todo-
Liste.

 Die von dir genannte Haltestelle kopiere ich mir gerade als Referenzobjekt.
 
 Wie ist das mit der Aufzählung mehrerer Werte für einen Schlüssel?
 
 In der von dir genannten Haltestelle sehe ich z.B.
 „ bus_lines=563, 564, FB-43“

Wirf das weg, das muss sterben. Genauso wie lines=*. ;)

Ernsthaft, wenn das Objekt Teil der entsprechenden PT-Relationen ist reicht 
das meiner Meinung nach völlig aus. Zumal das wie du sieht gerade auch nicht 
mal annähernd einheitlich gehandhabt wird, anderswo wird nämlich lines statt 
dessen verwendet. Wo immer ich eine Haltestelle anfasse, bei der alle 
angegebenen Linien auch über die Relationen erfasst sind, werfe ich das *lines 
weg. Meiner Erfahrung nach werden die nämlich noch weniger gepflegt als die 
Relationen.

 Ich hatte für einen anderen Schlüssel   „operator=CeBus; BürgerBus
 Eschede e.V.“  geschrieben -- mit einem Semikolon getrennt.

Ich würde ds e.V. hier weglassen, da es nichts zur Sache tut. YMMV.

 Jo schrieb dazu
 1. „BürgerBus_Eschede“ (mit underscore statt Leerstelle)

Nein.

 2. „ich würde auch kein Leerzeichen nach ; benutzen.“

Ja.

 zu 1 denke ich, dass Werte (Namen) mit Leerstellen erlaubt sind, es
 heißt ja auch „Eschede Bahnhof“ ohne underscore

Selbstverständlich.

 zu 2 weiß ich nicht, wo das definiert ist. Aufzählungszeichen: Komma
 oder Semikolon oder egal?

Ein Komma könnte auch im Firmennamen vorkommen (Foo, Bar und Söhne), deshalb 
definitiv Semikolon.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bitte um Hilfe/Verbesserung/Kritik Haltestellen-Relation

[Rolf Eike Beer]

Am Montag, 6. Juli 2015, 07:28:51 schrieb Jo:

 Ich würde die auch am stop_area hinzufügen. Angeblich ist das kontroversiel
 (geworden).
 
 Jedenfalls eine stop_area pro Fahrtrichtung, sonnst ist das nutzlos (nicht
 was das Wiki sagt) und stop_area_group hierarchisch um die stop_area zu
 sammeln.

Das verstehe ich nicht. Kannst du das erklären?

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bitte um Hilfe/Verbesserung/Kritik Haltestellen-Relation

[Rolf Eike Beer]

Am Montag, 6. Juli 2015, 23:34:52 schrieb Jo:
 Hier gibt es einen Beispiel mit eine Hierarchie von stop_area_group mit
 stop_area drinn

Sorry, das war missverständlich ausgedrückt. Ich verstehe, wie man sowas baut. 
Ich verstehe nur nicht, warum du meinst, sowas für die verschiedenen 
Richtungen der gleichen Haltestelle bauen zu müssen.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM Merkmale vorherige Auswahl

[Rolf Eike Beer]

Am Freitag, 19. Juni 2015, 23:47:46 schrieb Johannes:
 Genau da war das früher auch bei mir. Aber in den Tastatureinstellungen
 finde ich weder SHIFT + R noch mit dem Suchbegriff Merkmal was
 passendes. Verwende Version 8491.

Meinst du Ctrl-Shift-V?

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Echtzeit-Tracker für Bahn- und Busverbindungen

[Rolf Eike Beer]

Am Sonntag, 14. Juni 2015, 11:15:03 schrieb Nzara:
 Am 11.06.2015 um 13:28 schrieb Nzara:
  Das steckt aber viel Phantasie drin. Gerade konnte ich einen Bus
  beobachten, der in rasendem Tempo durch Quartierstrassen kurvte. Als ob
  der Routenplaner zwischen zwei Haltestellen keinen brauchbaren Weg
  gefunden hat und das nur durch Geschwindigkeit auf dem Umweg wett
  gemacht werden muss. Frei von jeder Realität.

 Seltsame Dinge zu beobachten hat auch was gutes: Die Ursache lag in
 einem falschen oneway=yes. Und wenn dann der Fahrweg über einen
 speziellen Routenplaner zwischen den Haltestellen berechnet wird, wir es
 lustig. Etwas mehr Hintergrund zum Technik unter
 http://geops.ch/blog/worldwide-travic

Ich hatte mir das auch mal angeguckt. Hier mal ein paar Dinge, die mir 
aufgefallen sind:

-diverse ICEs fahren zwischen Hannover und Hamburg über Buchholz i.d.Nordheide 
und Wunstorf, meines Wissens fahren die aber über Lüneburg und die Hasenbahn

-an der Station Gehrden/Steintor wandern die Busse zwischen den stop_positions 
(vermutlich die virtuelle Kante, die den Gleiswechsel erlaubt), anstatt über 
den (auch in den OSM-Relationen vorhandenen) Weg über die Straßenecke zu 
nehmen

-der Verlauf der Linie 540 in Wennigsen (ab Im Lindenfelde Richtung 
Barsinghausen/Schulzentrum, Abfahrt etwa 13:00 Uhr) fährt falsch rum durch die 
Straße Im Lindenfelde, die Bushaltestelle ist nur auf der nördlichen Seite 
der Straße (auch hier hat die OSM-Relation recht)

-die S-Bahnen Richtung Süden nehmen zwischen Hannover HBf und Hannover 
Bismarckstraße das falsche Gleis (auch hier hat die OSM-Relation die richtigen 
Gleise)

-die ICEs (am Beispiel 789) auch, die fahren durch H-Bismarckstraße auf Gleis 
3 (das 2. von Osten), sie S-Bahnen Richtung Süden auf Gleis 1 (westlich), die 
S-Bahnen nach Norden auf Gleis 2 (dazwischen)

-die S-Bahnen aus Richtung Weetzen (S1, S2, S5, S21, S51) fahren hier auch 
durch das falsche Gleis, das scheint nördlich des Bahnhofs das richtige zu 
sein, südlich davon fahren sie über das Gegengleis.

-die ICEs aus Richtung Süden nach Hannover fahren ab Messe/Laatzen über die S-
Bahn-Gleise durch H-Bismarckstraße, eigentlich nehmen sie Gleis 4

Hier scheint mir die Beachtung einer möglichen Regelfahrrichtung angebracht, 
d.h. bei zweigleisigen Strecken wird im Normalfall in Deutschland das rechte 
benutzt. Scheinbar ist die Gewichtung für die virtuellen Kanten zu hoch, 
zumindest rund um Hannover sollten die meisten Bahnstationen passend getaggt 
sein, so dass man hier über die PT-Relation den vollständig korrekten 
Linienverlauf finden können sollte.

Die Züge durch Hannover HBf und wohl auch in Bismarckstraße wollen scheinbar 
alle immer über Gleis 1. Zumindest bei den jeweils dort haltenden Zügen sollte 
doch das korrekte Gleis ermittelbar sein.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM und der Bahnstreik

[Rolf Eike Beer]

Am Dienstag 19 Mai 2015, 08:29:04 schrieb Harald Hartmann:
  *Routen mit route=railway*
  Diese Routen sind Kursbuchstrecken. Diese haben per Definition
  eigentlich keinen Betreiber, denn auf einer KBS können viele
  verschiedene Unternehmen fahren.
 
 Und was ist, wenn in dem von mir angesprochenen Bereich (Südthüringen,
 nordwestliches Oberfranken) an sehr vielen route=train ein name mit
 KBS sonstnochwas steht? Das wäre dann nach obiger Ausführung falsch
 und müsste nach route=railway umgetaggt werden und wäre somit nicht
 mehr für die von Roland gewünschte Karten nützlich?!

Siehe https://github.com/rurseekatze/OpenRailwayMap/pull/181

Überschneidungen bei den beteiligten Personen sind rein zufällig ;)

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Rolf Eike Beer]

Am Donnerstag, 14. Mai 2015, 16:15:35 schrieb Michael:
 Am 14.05.2015 um 11:32 schrieb Martin Koppenhoefer:
  Am 14. Mai 2015 um 11:25 schrieb Michael ohr...@gmail.com:
  Gerade Ortsumgehungen sind ja oft kreuzungsfrei ausgebaut, für mich ist
  das aber noch kein trunk.
  
  warum? Was fehlt denen?
 
 Mir so etwas in Richtung wie übergeordnete Bedeutung (blöder Ausdruck,
 ich weiß, aber mir fällt gerade nichts besseres aus). Ich bin halt eher
 ein Freund davon, nach der Verkehrsbedeutung zu mappen.
 
  Ich fände es nicht schlimm, wenn eine primary auf einem Teilstück das
  kreuzungsfrei / autobahnähnlich ausgebaut ist, zu einem trunk würde.
 
 Bei autobahnähnlich bin ich ja voll dabei. Aber nehmen wir mal an, die
 Umgehungsstraße zwischen Pusemuckel-West und Pusemuckel-Ost ist
 kreuzungsfrei ausgebaut, aber nur zweistreifig. Da wäre da für mich ein
 trunk trotzdem fehl am Platz. Wenn man nur die Höhenfreiheit als
 Argument nimmt, wäre das aber trunk.

Laut dem Wiki ist die Eingliederung als autobahnähnliche Straße machgeblich. 
Dafür braucht es nach meinem Verständnis:

-höhenfreie Anbindung (d.h. keine Ampeln und Kreuzungen)
-keine Fahrten im Gegenverkehr (d.h. aber _nicht_ notwendigerweise baulich 
getrennte Fahrbahnen)

Ein guter Hinweis, aber nicht zwingend überall vorhanden, sind die Ausfahrt-
Schilder. Die sind nur auf solchen Straßen zulässig.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Brunnen : Check tagging near Hannover?

[Rolf Eike Beer]

Am Mittwoch, 6. Mai 2015, 09:17:00 schrieb Bryce Nesbitt:
 waterway=water_point is defined as a place to fill fresh water holding
 tanks.
 There are several marked as Brunnen near Hannover.
 Could someone check that tagging?
 
 http://overpass-turbo.eu/s/9cX

Giving that the area around belongs to Wasserwerk Vlotho, I guess those are 
indeed wells that pump water into the punlic water system. The tagging is 
wrong, as Brunnen just means well, and is no name, and those are probably 
neither publically reachable nor for refilling your caravan.

The proper tagging would probably be something like:

man_made=water_well
drinking_water=yes

But, those would show up on the hiking map, which is equally wrong.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[Rolf Eike Beer]

Am Mittwoch, 15. April 2015, 15:00:40 schrieb fly:
 Fände es ja schön wenn auch alle meine Fragen beantwortet werden.

 Insgesamt scheint ja leider kaum Diskussionsbereitschaft vorhanden zu
 sein und auf meine Vorschläge wird sich gar nicht erst eingelassen

Wie es in den Wald schallt… Für meinen Geschmack nehmt ihr euch da beide 
nichts.

Es sind diverse Gegenargumente gekommen, auf die auch nicht wirklich 
eingegangen wurde. Ich persönlich bin da eher leidenschaftslos, und am 
Tagging-Schema auch nicht beteiligt gewesen, also versuche ich es jetzt 
nochmal von neutraler Seite aus. Wenn hier beiden Seiten die Lust am 
Diskutieren vergeht kann ich es aber vollkommen verstehen, als wirklich 
konstruktiv habe ich nur wenige Teile der ganzen Diskussion empfunden.

 Am 15.04.2015 um 09:27 schrieb Alexander Matheisen:
  On Di, 2015-04-14 at 22:34 +0200, fly wrote:
  Am 14.04.2015 um 21:13 schrieb Michael Reichert:
  Am 2015-04-14 um 19:43 schrieb fly:
  railway:signal:main:state:forward=*
  
  Lass mich raten, das Signal stammt von rayquaza und ist – für
  OpenRailwayMap-Verhältnisse – schon ewig gemappt?
  
  Nein, nur meiner Logik entsprungen.
  
  du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang
  sei, oder wie soll ich das jetzt verstehen?
 
 Naja, war ja ein Volltreffer und wie willst Du es denn anders
 interpretieren ohne die fehlenden Information der Sonderbehandlung ?

Ich kann mich Michaels Verwunderung hier nur anschließen. Warum soll man 
virtuelle Probleme diskutieren, wenn du doch genug echte Probleme ausgemacht 
haben willst? Lasst uns dann doch auch bitte realitätsnahe Probleme 
diskutieren, Streitpunkte gibt es ja scheinbar genug, das man nicht noch 
unnötig neue erfinden muss.

  Das sind Versuche,
  Signale zu mappen, die für verschiedene Richtungen gelten und am selben
  Mast hängen. Es hat sich nie durchgesetzt (das
  railway:signal:TYP:state:forward/backward=* werten wir nicht aus und
  wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz
  nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung,
  der andere für die andere Richtung.
  
  Habe ich das im Wiki überlesen ?
  Welche Gründe sprechen denn dafür ?
  
  Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene
  Richtungen eingetragen werden können, würde die Tags noch komplizierter
  machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns
  entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt
  kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder?
 
 Wie kürzere Tags. Mir geht es um die nutzlose Wiederholung. In
 Sonderfällen wird dann erweitert. Das heißt doch noch lange nicht, dass
 immer die Richtung im Tag benötigt wird.

Die Richtung würde nur dann nicht benötigt, wenn in beide Richtungen das 
gleiche Signalbild gezeigt würde. Das ist so unwahrscheinlich, das man es 
völlig ignorieren kann. Also braucht es immer die Richtung.

  Mapped Ihr dann auch noch den Masten ?
  
  Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher
  komplizierter.
  
  Ich finde es deutlich komplizierter, als zwei Nodes zu mappen.
 
 Wenn es nicht dokumentiert ist, verwirren zwei Punkte. Selbst wenn es
 dokumentiert ist, müß es erst gefunden und gelesen werden. Sonst schlägt
 Ihr ja auch vor alle Signale auf einen Pubkt zu mappen, nur bei der
 Richtung soll dann Schluß sein ?

Es gibt zwei Möglichkeiten:

1) beides an einem Node, dann heißt das jeweil eine Tag-Ebene mehr. Fände ich 
prinzipiell auch gut, weil es z.B. Schneepflug-Signale gibt, die quasi 
ausschließlich im Doppel auftreten: ein Mast, an einer Seite steht hoch, an 
der anderen Seite runter. Wenn man das sinnvoll vereinheitlichen kann: 
gerne, immer her damit. Wie würdest du denn so ein Signal eintragen?

Hier siehst du sowas bildlich:

http://walter-klan.de/signale/08)_ne-signale.html#Ne_7

2) 2 Nodes wie gehabt. Kürzere Tags, dafür liegt das halt nicht direkt 
übereinander.

[Signalrelationen]

 Zumindest Links wären dann wohl angebracht.

Kann ich mir nichts drunter vorstellen, insofern würde ich das auch lesen. 
Nach meiner Erfahrung ist aber alles, was man ohne Relation erschlagen kann, 
ein Gewinn. associatedStreet ist schon schlimm genug, da muss man nicht noch 
mehr von dem Zeug erfinden.

  Was war denn jetzt an meinen Vorschlägen jetzt falsch ?
  
  state:main:forward=* resp. state:main=*
  height[:TYPE][:DIRECTION] resp. height[:TYPE]
  
  Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ?
  (railway:signal:main:state=*)
  
  Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein
  Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor
  du solchen Unsinn schreibst.
 
 Siehe zB :lanes-Tagging
 
 Was ist bitte an folgendem Beispiel Unsinn ?
 
 railway=signal
 signal:main=*
 state=*
 height=*
 ref=*
 direction=95

-es sollte IMHO tatsächlich states und nicht state sein, denn es gibt die 
Gesamtmenge der 

Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[Rolf Eike Beer]

Am Mittwoch, 8. April 2015, 20:36:13 schrieb Martin Koppenhoefer:
  Am 08.04.2015 um 15:17 schrieb fly lowfligh...@googlemail.com:
  
  Warum eigentlich railway: als name space ?
 
 ich finde so einen namespace dort nicht schlecht, wo es um Spezialistentags
 geht. Hauptsignale und Ähnliches wird wohl nicht jeder eintragen, und durch
 den Präfix wird auch demjenigen, der diese Spezialtags nicht alle kennt,
 schonmal ungefähr ein Kontext vermittelt (Eisenbahn in diesem Fall), ohne
 dass er gleich die genaue Bedeutung im Wiki recherchieren müsste

Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig 
namespace-Tags begegnen, dann ist es doch leicht anders:

emergency=fire_hydrant
fire_hydrant:type=underground

railway=signal
railway:signal:...

Das macht die Zuordnung interessiert mich der key für den Benutzer etwas 
einfacher, aber andere Dinge wir ref fallen da trotzdem aus der Reihe[1]. 
Ich sehe nicht, dass der Verzicht auf railway: bei den key-Namen eine große 
Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das 
überblicken kann, zu Kollisionen mit anderen Taggings führen würde.

tl;dr: der Namespace ist nett, aber ich sehe keinen zwingenden Grund dafür 
(oder ihn zu entfernen).

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[Rolf Eike Beer]

  * Warum werden den die Werte als Abkürzungen definiert ? Was spricht
  gegen zB Hauptsignal statt hp ?
  
  Es handelt sich dabei um offizielle Abkürzungen, die durch das
  Signalbuch festgelegt sind (so wie die Verkehrszeichen in der StVO).
  Unter Eisenbahnern sind diese Abkürzungen auch gebräuchlicher als die
  Langnamen.
  
  Ausgeschriebene Bezeichnungen werden z.B. bei den österreichischen
  Signalen verwendet, da dort die Signale keine offiziellen Abkürzungen
  tragen.
 
 Im Sinne der allgemeinen Benutzerfreundlichkeit wären dann immer noch
 Werte ohne Abkürzungen besser.

Das Unterscheidet sich nicht von Verkehrszeichen, auch da wird mit den 
entsprechenden Abkürzungen getaggt 
(http://wiki.openstreetmap.org/wiki/Traffic_sign#Traffic_sign_IDs)

Außerdem sehe ich nicht, was einem Benutzer da groß hilft. Die Funktion wird 
bereits über den key beschrieben, z.B. railway:signal:main, damit ist bereits 
gesagt, dass es ein Hauptsignal ist. Über den key wird dann nur noch die 
genaue Art festgelegt, ähnlich dem Verkehrszeichen. Außerdem sind insbesondere 
im Bereich der DB-ESO die Begriffe wie Hauptsignale nicht eindeutig: es gibt 
mindestens 5 in Deutschland von der DB verwendete Signalsysteme, und alle 
haben ein Hauptsignal. railway:signal:main=DE-ESO:Hauptsignal sagt also in key 
und value das gleiche und lässt die interessanten Details letztlich aus.

  Ansonsten verstehe ich nicht so genau, was du eigentlich kritisierst...
 
 Taginfo zeigt ja schon zehntausende Treffer für  railway:signal* [2]
 jedoch hat kein einziger Schlüssel eine Wiki-Seite.

http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Tagging_in_Germany

Vielleicht sollte man von mal ein paar (Dutzend) redirects einbauen ;)

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de