Hallo Zusammen,
wir werden die Tags wieder entfernen.
Viele Grüße
Tracy
Am 24. April 2015 um 12:00 schrieb <
openrailwaymap-request(a)openrailwaymap.org>:
> Send Openrailwaymap mailing list submissions to
> openrailwaymap(a)openrailwaymap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
> or, via email, send a message with subject or body 'help' to
> openrailwaymap-request(a)openrailwaymap.org
>
> You can reach the person managing the list at
> openrailwaymap-owner(a)openrailwaymap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Openrailwaymap digest..."
>
>
> Today's Topics:
>
> 1. Re: priority-Tag (danmey(a)web.de)
> 2. Re: priority-Tag (Rolf Eike Beer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Apr 2015 23:17:17 +0200
> From: danmey(a)web.de
> To: openrailwaymap(a)openrailwaymap.org
> Subject: Re: [openrailwaymap] priority-Tag
> Message-ID: <5539615D.5040500(a)web.de>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Hallo!
> Ein altes Thema ein bisschen anders: In Ostwestfalen-Lippe gibt es
> reihenweise *nodes* mit priority=primary: http://overpass-turbo.eu/s/82J
> Fl?chendeckend an alle nodes von railway=rail.
> Kann das weg? Oder steckt Sinn dahinter?
> VG, Daniel
>
>
>
>
> Am 06.11.2014 um 10:00 schrieb Merle Ro?ner:
> >
> > Hallo,
> >
> > inzwischen ist wieder einiges bei uns passiert:
> >
> > Wir werden jetzt die Relationen an den Schienen auswerten und
> > dementsprechend nicht mehr den Tag priority setzen.
> >
> > Viele Gr??e
> >
> > Merle von MentzDV
> >
> >
> >
> > _______________________________________________
> > Openrailwaymap mailing list
> > Openrailwaymap(a)openrailwaymap.org
> > http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
>
>
Hello everybody,
for rendering, it would be nice to have any information about the
importance of a station/halt. With this information, the renderer could
render captions in different zoom levels or font sizes or decide which
label is rendered in cases of collision.
Currently we have the tag railway:station_category=1-7 for mapping the
German railway station category [1]. But this is very german-specific,
so we should think about a way to tag the importance of a station using
generic rules that are independent from any country-specific categories.
Should we use the existing tag railway:station_category=* and translate
the German definitions, so that they can be applied internationally?
This would have the advantage that German stations, that are already
tagged with the existing tag, do not require any retagging. But using
just numeric values is not so
Or should we create a new tag a tag like railway:station_importance=*
with some category values such as local/regional/international/... and
leave the existing railway:station_category=* tag for mapping
country-specific categories?
Any ideas?
Regards
Alex
[1] http://en.wikipedia.org/wiki/German_railway_station_categories
Hallo,
in Roßlau Gbf (ex-Reichsbahn-Gebiet) hängt (noch) am Signal K ein Zs 103
"Rautentafel" an einem Formhauptsignal. Die Ril 301, Modul 301.0301
schreibt hierzu:
> Das Halt zeigende Hauptsignal gilt nicht für Rangierabteilungen.
> Eine rechteckige schwarze Tafel mit weißen Rauten.
> Die Rautentafel ist am Hauptsignal angebracht.
http://eisenbahntechnik-fotos.de/signale/02_zs_signale.php#zs103
Für die Wessis: Das ist kein Bahnübergangssignal!
Aber wie tagge ich das? Es gehört vermutlich zu den ganz wenigen
Signalen (oder ist es das letzte?) der Ril 301, das noch nicht im Wiki
dokumentiert ist. Mein Vorschlag:
railway:signal:minor=DE-ESO:zs103
railway:signal:minor:form=sign
Bisher habe ich das Signal nur an Formhauptsignalen ohne Ra 12 (im
Westen Sh 1 genannt) gefunden. An Hl-Signalen braucht man es nicht, die
haben Sh 1-Lampen.
Viele Grüße
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
Hallo,
in der Ril 301, Modul 301.1501, Abschnitt 3, Absatz 4 steht, dass ein
Überwachungssignal in Ostdeutschland zwei Mastschilder hat, wenn es für
mehrere Bahnübergänge gilt:
> Gilt das Überwachungssignal im Geltungsbereich der DV 301 für mehrere#
> Bahnübergänge, so sind zwei Mastschilder nebeneinander angebracht;
> dies gilt nicht bei einer Kennzeichnung gemäß Abschnitt 8.
Ich habe auch selber schon solche Überwachungssignale gesehen, das ist
also keine theoretische Frage. Daher stellt sich mir die Frage des
Taggings. Bei Läute- und Pfeiftafeln haben wir mit
railway:signal:ring:only_transit=yes ein Tag, um kennzuzeichnen, dass
das Signal nur für durchfahrenden Züge gilt. Sollten wir analog dazu
railway:signal:crossing:multiple_crossings=yes/<Zahl>/no einführen?
Viele Grüße
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
- Need an English version? Just scroll down -
Hallo zusammen,
in diesem OSM-Wiki-Änderung wurde der Tag usage=freight mit dem Kommentar "removed deprecated usage=freight" weggenommen:
http://wiki.openstreetmap.org/w/index.php?title=Key:usage&diff=1211438&ol...
Ich habe nichts dagegen, ich möchte nur die Ursache wissen. Vielleich habe ich Diskussion darüber darchgelassen.
Viele Grüße
Eduard <edward17>
---
Hi there,
in this OSM-Wiki-Change usage=freight tag had been deleted:
http://wiki.openstreetmap.org/w/index.php?title=Key:usage&diff=1211438&ol...
I'm not opposed, but I only want to know the reason. Probably I missed the discussion.
Best regards
Eduard <edward17>
[No German version, I'm too lazy.]
You may know it or not, I have been quite busy in the last month hacking on
OpenRailwayMap code. I have introduced automated testcases to spot syntax
errors and dangling icon references and much stuff like this. In fact, also the
automation to build the new JavaScript stylesheets from the MapCSS ones was
done by me.
I've also done a lot of things to improve the stylesheets, as well as the
underlying software that drives them. Which usually resulted in me begging
Alexander to put that stuff on the server so I can actually see if it works.
Testing on a live system isn't a good idea anyway, and given the fact that
every update has to go through another person doesn't make this solution scale
anywhere.
So once I sat down and tried to set up a local server, but not a full-featured
database one. I have only the frontend rendering code on my machines, happily
using the vector tiles of the "real" server. This resulted in me fixing even
more stuff. Since the important parts of that are already merged I'll now write
down how to get there so you can hack on your own stuff.
My machines use openSUSE, so I will stick to those package names. And I don't
list the dependencies explicitely here to keep things short. So, let's start
installing:
zypper in git-core apache2-mod_php5 php5-ctype php5-gettext python-ply python-
rsvg python-cairo libxml2-tools zip
Now get the actual code
git clone https://github.com/rurseekatze/OpenRailwayMap.git
cd OpenRailwayMap
git submodule init renderer
Now build the JavaScript stylesheets
cd styles
make
That's pretty much it. Now tell your webserver where your OpenRailwayMap
directory is and that it should be served, or put the whole directory in your
~/public_html. Put "php5" and maybe also "userdir" (if you use ~/public_html)
in your /etc/sysconfig/apache2 in the APACHE_MODULES line, (re)start apache:
systemctl start apache2.service
You may want to make canvas.php the directory index, otherwise you always have
to type it. The bitmap layer is of course also taken from the "real" instance,
so you can't change how that looks.
And you should basically be done. Now you can e.g. hack on styles/*.mapcss to
get different styling, just "make -C styles" afterwards and reload the page.
I hope some cool new pull requests will come in now, e.g. for signalling
systems outside of central Europe. In case I have forgotten some thing just
ask either on this list or in #OpenRailwayMap on irc.oftc.net.
Greetings,
Eike
P.S.: want to have a proof that this works? http://orm-dev.der-dakon.net, this
usually runs a combination of most of my own branches that are waiting for
upstream integration. I may or may not pick other peoples branches there, too,
this is more or less random if I have an interest in them.
(German version below)
Yesterday night a force push to the master branch of the OpenRailwayMap
repository at GitHub took place. Only very few commits were removed from the
history, and those only for technical reasons (i.e. they had no contents
afterwards). But what we really did is to filter out foreign software that was
included in the repository in the early stages of development. The whole
reason for this was a technical one: this included some huge binary files, so
cloning the repository downloaded (literally) hundreds of megabytes of dead
sutff. In fact the download size reduced from ~900MB to barely 7MB.
During the process all open pull requests were closed (GitHub automatically
did this, it was not intentional), but all of them were from only 2 users
(Michael Reichert and me), so no real harm was done using this as we were
aware of the force push and had to rebase our branches anyway.
If you have a clone of this repository and want to contribute a new patch then
please base anything on the current master branch and not the old one:
# assumption: rurseekatze/OpenRailwayMap is the remote called "upstream"
git checkout master
git fetch
# warning, the next command will throw away any local modifications you
# have on the master branch
git reset --hard upstream/master
git push --force
Now you are ready to create new branches and start PRs.
(German version)
Gestern Abend hat wurde eine force push im OpenRailwayMap-Repository auf
GitHub durchgeführt. Es wurden einige wenige commits aus der Geschichte des
Repositories entfernt, allerdings nur aus technischen Gründen (sie enthielten
schlicht keine Änderungen mehr). Der eigentliche Grund für die Aktion war die
Entfernung von einigem Fremdcode, der in der Anfangsphase der Entwicklung in
das Repository eingecheckt wurde. Auch hierbei war der Grund ein rein
technischer: mit dabei waren einige große Binärdateien, die später alle wieder
gelöscht wurden. Wenn man sich das Repository im alten Zustand klonen wollte
hat man (buchstäblich!) hunderte Megabyte and unnützem Zeug heruntergeladen.
Das ist nun Geschichte, und der Download hat jetzt statt ~900MB nur noch knapp
7MB.
Durch den force push wurden alle offenen Pull Requests geschlossen, allerdings
war dies ein unbeabsichtigter Automatismus von GitHub. Da die PRs ohnehin nur
von 2 Benutzern stammten (Michael Reichert und mir) ist dabei letztlich auch
kein wirklicher Schaden entstanden, da wir im an der ganzen Aktion ja
mitgearbeitet haben und unsere branches sowieso hätten rebasen müssen.
Wenn jemand einen lokalen clone des Repositories hat und jetzt einen neuen PR
erstellen möchte, so muss dieser auf dem neuen master-Branch aufsetzen.
# Annahme: rurseekatze/OpenRailwayMap ist der remote "upstream"
git checkout master
git fetch
# Warnung: der nächte Befehl wird alle ggf. gemachten Änderungen am
# branch master verwerfen!
git reset --hard upstream/master
git push --force
Jetzt ist der master-Branch im eigenen fork auf dem gleichen Stand wie das
Hauptrepository und neue PRs können von hier ausgehend erstellt werden.
Eike
Hallo,
die Rechtsabteilung der DB hat jetzt ihr OK dazu gegeben, dass für OSM
eine Ausnahme zur CC-BY gilt. Die CC-BY ist nämlich an sich keine mit
OSM kompatible Lizenz, da OSM von seinen Datennutzern keine Nennung
anderer Quellen als OSM verlangt.
An vielen Datensätzen auf data.deutschebahn.com findet sich jetzt
folgende Klausel:
> Wenn die Daten der Deutschen Bahn (DB) Bestandteil des OpenStreetMap-
> Datenbankwerkes werden, genügt eine Nennung der Deutschen Bahn AG in
> der Liste der Beitragenden. Eine Nennung der DB bei jeder Verwendung
> der Daten auch durch Lizenznehmer des oben genannten Datenbankwerks
> ist dann nicht mehr erforderlich. Eine indirekte Nennung (Verweis
> auf Herausgeber des Datenbankwerks, der wiederum auf die DB verweist)
> genügt.
Das heißt jetzt aber nicht, dass ihr blind wie die Wilden, die Daten in
OSM übertragen sollt. Die Daten der DB sind nicht fehlerfrei und in
einigen Fällen generalisiert/vereinfacht. Beispiele:
(1) Die Höhen- und Längenangaben der Bahnsteige sind zwar ziemlich
aktuell (ich habe es anhand von Weinheim, wo derzeit die Bahnsteige
erhöht werden, und Crivitz geprüft), aber in komplizierten Fällen
falsch. Wenn ein Bahnsteig nur in Teilen 76 cm hoch ist, wird 76 cm als
Höhe und die Gesamtlänge (inkl. niedriger Teil) als Länge angegeben.
Beispiele hierfür sind in Osterburken oder Karlsruhe-Durlach.
(2) Namen der Stationen lauten anders als vor Ort. Bei OSM zählt, was
vor Ort steht. Abweichend "offizielle" Namen gehören in official_name=*.
Dort werden Abkürzungen wie b., Hbf, Württ., Rheinl., Anh. usw.
ausgeschrieben.
(3) Adressen der Bahnhöfe sind – sorry – Murks, denn sie stammen aus
Geocoding und haben nichts mit der Realität zu tun.
(4) Streckennetz ist 2 Jahre alt. Seid also mit den
Elektrifizierungsangaben vorsichtig. (Ich weiß auf Anhieb eine Strecke,
deren Oberleitung dieses Jahr abgebaut wurde)
Weitere Details zu den obigen Fehlern findet ihr unter
https://www.openstreetmap.org/user/Nakaner/diary/36323
Bitte übernehmt also nicht wie die Wilden Daten von dort, sondern tut
das nur, wenn ihr vor Ort gewesen seid und gesehen habt, dass der
Bahnsteig z.B. noch alt und niedrig ist und die Angabe "38 cm" daher
aktuell ist. Das massenhafte Übernehmen für ganze Landstriche wäre ein
Import.
Viele Grüße
Michael
- Need an English version? Just scroll down -
Hallo zusammen,
ich habe eine Frage über den service=crossover Tag, nähmlich über die Nutzung davon für Gleisen, die schon anderen service=* Tag besitzen (z. B. service=yard).
Also, muss ein Überleitgleis zwishen zwei service=spur-Gleisen als service=crossover oder auch als service=spur getaggt werden?
Muss ein Überleitgleis zwishen zwei service=yard-Gleisen als service=crossover oder auch als service=yard getaggt werden?
Beispiele:
Überleitgleis zwishen zwei service=spur: http://www.openstreetmap.org/way/332450082
Überleitgleis zwishen zwei service=yard: http://www.openstreetmap.org/way/302031524 , http://www.openstreetmap.org/way/289392209
Diese Frage habe ich, seit ich diesen Kommentar gelesen habe: https://github.com/gravitystorm/openstreetmap-carto/issues/1971#issuecomm...
Und überhaupt, was denkt ihr über rendering von crossover-Gleisen in Standart Stil? Müssen sie als andere service-Gleise (d. h. hellgrau und nur in hohen Zoomstufen ) gerendert werden? Siehe dazu: https://github.com/gravitystorm/openstreetmap-carto/issues/1971
Viele Grüße
Eduard <edward17>
---
Hi there,
I have one question about using of service=crossover tag for crossover rails between two rails which already have other service=* tag (for example, service=yard).
So, should crossover rail between two service=spur rails have service=crossover tag or also service=spur?
Should crossover rail between two service=yard rails have service=crossover tag or also service=yard?
Examples:
Crossover between two service=spur: http://www.openstreetmap.org/way/332450082
Crossover between two service=yard: http://www.openstreetmap.org/way/302031524 , http://www.openstreetmap.org/way/289392209
I have this question since I've read this comment: https://github.com/gravitystorm/openstreetmap-carto/issues/1971#issuecomm...
And generally, what do you think about rendering of service=crossover rails in Standart Layer? Should they be rendered as other service=* rails (gray and only in large zooms visible)? See: https://github.com/gravitystorm/openstreetmap-carto/issues/1971
Best regards
Eduard <edward17>
