I have set up an OpenRailwayMap tile server on Ubuntu via this page:
https://github.com/rurseekatze/OpenRailwayMap/blob/master/INSTALL.md
I am no trying to test it via requesting a tile with a URL like:
http:/mysever.com/standard/2/3/1.png
This just returns a blank page, with no features drawn.
I can see the request come into node-tileserver
[2016-10-13 17:21:41.054] [INFO] [default] - Request for
/standard/2/3/1.png received.
I can also see the folders and *.json files being created here:
/home/www/sites/194.245.35.149/site/orm/tiles
However, the *.json files only look like this:
{"features":[],"granularity":10}
I have successfully imported the data into PostgeSQL, and can see the data
in all the tables.
Any idea what I am missing?
-- Matt
Hallo,
am Samstag, den 12. November findet auf dem Rangierbahnhof in
Mainz-Bischofsheim eine Mappingparty statt, zu der die DB einlädt. Im
Rahmen der Mappingparty sollen Eisenbahndetails (Signale, Gleisdetails,
Höchstgeschwindigkeiten) und was sich sonst noch vor Ort mappen lässt,
auf diesem Rangierbahnhof erfasst werden. Nach dem Mappen geht es zum
Eintragen der Daten ins Skydeck von DB Systel im Silberturm in Frankfurt.
Die DB (in diesem Fall DB Cargo) möchte wissen, wie sie das Mapping der
Eisenbahninfrastruktur in OSM unterstützen kann.
https://wiki.openstreetmap.org/wiki/Eisenbahn/Mappingparty_Rangierbahnhof...
Da es sich um Bahngelände handelt, das nur von Bahnbediensteten betreten
werden darf, ist eine vorherige namentliche Anmeldung bei per E-Mail bei
dbopendata(a)deutschebahn.com erforderlich. Die Teilnehmerliste im Wiki
dient nur der öffentlichen Information, die E-Mail ist wichtig und
verbindlich.
Viele Grüße
Michael
PS Recht neu bei der DB in Sachen OSM-Nutzung ist strecken.info von DB
Netz, welches Baustellen und aktuelle Betriebsstörungen (Quelle sind die
regionalen Betriebszentralen von DB Netz) anzeigt.
http://db-livemaps.hafas.de/bin/query.exe/dn?tpl=fullscreenmap&L=vs_baust...
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
I wonder if we should retire the "deelectrified" tag entirely. I think it's
simply a bad idea. There is the abandoned-namespace that we already use for
the type of rail and similar things, so why not use abandoned:electrified=*?
This has the advantage that we can also use e.g. abandoned:voltage and
abandoned:frequency. Taginfo shows that deelectrified has slightly more usages
than abandoned:electrified: 514 vs. 466. Changing this now isn't that hard I
guess…
Greetings,
Eike
I am sorry if this question is repeated, but I posted before being
accepted into the list.
I set up an OpenRailwayMap tile server on Ubuntu via this
page:https://github.com/rurseekatze/OpenRailwayMap/blob/master/INSTALL.md
I am now trying to test it via requesting a tile with a URL like:
http:/mysever.com/standard/2/3/1.png
This just returns a blank page, with no features drawn.
I can see the request come into node-tileserver as such:
[2016-10-13 17:21:41.054] [INFO] [default] - Request for
/standard/2/3/1.png received.
I can also see the folders and *.json files being created here:
/home/www/sites/194.245.35.149/site/orm/tiles
However, the *.json files only look like this:
{"features":[],"granularity":10}
I have successfully imported the data into PostgeSQL, and can see the data
in all the tables.
Any idea what I am missing?
-- Matt
ENGLISH PART BELOW
Liebe ORM-Community,
[Kurzform: Was ist optimaler geografischer Ort für Tags von Weichen o.ä.
Vorschläge und Diskussion siehe V* weiter unten.]
Hochgenaue und gleisgenaue Streckenarten sind u.a. für die Lokalisierung
von Schienenfahrzeugen notwendig. Für (experimentelle!) Anwendungen sind
die Daten aus OSM hilfreich, insbesondere wenn (noch) keine
Informationen vom Netzbetreiber vorliegen.
Bislang gibt es m.E. kein einheitliches Vorgehen, auf welches Bauteil
einer Weiche man den Ort (lat, lon in node) des zugehörigen Tags setzt
(z.B. railway=switch oder railway:switch=default). Besonders schwierig
wird es bei komplexen Weichen, da sie mehrere Funktionen vereinen.
Möglicherweise hängen die Anforderungen und Wünsche auch von
(zukünftigen) Anwendungsfällen. Deshalb folgen einige Ideen, die
einerseits auf die Realisierbarkeit in der derzeitigen Praxis abzielen
und andererseits den Blick in die Zukunft bei Verfügbarkeit von noch
genaueren Vermessungen der Strecke lenken. Mein Wunsch ist die
Festlegung eines einheitlichen Vorschlages für zukünftiges Tagging.
V1. Vorschläge für Tag-Position für einfach Weichen (EW, IBW, ABW):
V1(a) Weichenzungenspitze (Ort der Fahrwegänderung, ungefähr erkennbar
am Ort des Weichenantriebs in Luftbildern o.ä.)
V1(b) Herzstückspitze ("massives" Bauteil, ungefähr erkennbar am
Schnittpunkt der inneren Schienen)
V1(c) anderer Vorschlag?
V2. Vorschläge für Tag-Position an Kreuzungen (Kr):
V2(a) Mitte der Kreuzung, d.h. Schnittpunkt der beiden Gleismitten
V2(b) anderer Vorschlag?
V3. Vorschläge für Tagging von komplexen Weichen (EKW, DKW, DW):
V3.1 Wo immer möglich in Einzelbestandteile zerlegen, d.h.:
- EKW = 2x EW + 1x Kr
- DKW = 4x EW + 1x Kr
- DW = 2x EW
(damit ist auch eindeutig festgelegt, welche Fahrbeziehungen
insbesondere an EKWs möglich sind)
V3.2 Tags für Einzelbestandteile wie für V1 und V2 festgelegt setzen.
_Mein favorisierter Vorschlag_ ist: V1(a) + V2(a) + V3.1 + V3.2, der
sowohl die Position von Weichen und Kreuzungen als auch die
Fahrbeziehungen an komplexen Weichen eindeutig festlegt.
Fragen (hinsichtlich Tagging, Eisenbahnbezug etc.):
- An welchen Ort habt ihr bislang das Tag von Weichen und Kreuzungen
gelegt?
- Was spricht für diesen Vorschlag?
- Was spricht gegen diesen Vorschlag?
- Welche weiteren Anwendungen neben den Fahrbeziehungen würden von
diesem Vorschlag ebenfalls profitieren?
- Welche Bauteile mit ähnlichen "Problemen" wurden nicht berücksichtigt?
Ich danke schon mal im Voraus herzlich für Ihr/euer Feedback.
Viele Grüße aus Karlsruhe,
Denis Stein.
(steindcom)
####################################################################
GERMAN PART ABOVE
Dear all,
[Briefly: The geographical position of railway tags, such as switches,
is currently ambiguous. Please, find proposals P* and discussion below.]
Applications, e.g. train localization, require precise and
track-selective maps of the railway network. For experimental issues OSM
data is useful, especially if these maps are not (yet) available from
the operator.
Currently, there is no common definition, which part of a switch shall
be used as the (unique) position (with regard to lat, lon of the node)
of the corresponding tag (e.g., railway=switch or
railway:switch=default). Furthermore, complex switches fulfill several
"tasks" and one position is obstructive therefor.
The requirements may depend also on future applications. However, my
intention is to propose a common scheme for tagging those railway
elements considering both the current practice and future potentials of
the availability of measurements with higher accuracy.
P1. Proposals for the position of tags for single turnouts
(abbreviation: ST; including both straight as well as curved ones):
P1(a) Tip of the switch blade (i.e., the position where the route
changes; might be also recognized by the point machine in aerial
images)
P1(b) Tip of the frog ("massif" part; can be approximated from the
intersection of both inner rails)
P1(c) another proposal?
P2. Proposals for the position of tags for diamond crossings
(abbreviation: DC):
P2(a) Center of DC, i.e. intersection of both track centerlines
P2(b) another proposal?
P3. Proposals for tagging of complex switches:
P3.1 Decompose them whenever applicable:
- diamond crossing with ... slips:
* single = 2x ST + 1x DC
* double = 4x ST + 1x DC
- three-way switch = 2x ST
(solves also the route ambiguity problem in single slip case)
P3.2 Tag those parts according to P1 and P2.
_My favorite_ is: P1(a) + P2(a) + P3.1 + P3.2, which considers the
position of turnouts and diamond crossing and clearly defines the
drivable routes on them clearly.
However, some questions arise (regarding current practice, tag meaning
with regard to railway "theory"):
- Which positions are you currently using for the corresponding switch
and diamond crossing tags?
- What are the arguments in favor of my proposal?
- What arguments are opposing my proposal?
- Are there further applications (besides the branching relations) that
might also benefit from my proposal?
- Are there further elements that share the same "problems" as switches?
I am looking forward to receiving your helpful comments. Many thanks in
advance!
Kind regards,
Denis Stein.
(steindcom)
--
.........................................................
Dipl.-Inf. Denis Stein
Research Scientist
Research Division ISPE | Research Department MPS
FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10–14
76131 Karlsruhe, Germany
Tel.: +49 721 9654-276
stein(a)fzi.de
www.fzi.de/mitarbeiter/stein
.........................................................
FZI Forschungszentrum Informatik am Karlsruher Institut für Technologie
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Prof. Dr. Andreas Oberweis, Prof. Dr. Ralf Reussner,
Jan Wiesenberger, Prof. Dr.-Ing. J. Marius Zöllner
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
.........................................................
Dear all,
when checking several maps in Germany, I found an area containing
remnant after reconstruction (node [1] and adjacent ways; find attached
also a sketch in a PDF file) where the tagging is not yet ideal
(besides, e.g., railway:switch=default vs. 4 edges; upper right track is
not rendered on openstreetmap.org due to tagging), but I do not have
enough local and temporal knowledge.
I subsequently assume that the Bing aerial image shows the current state
with a probably removed diamond crossing with slips (einfache/doppelte
Kreuzungsweiche) and some rails nearby.
Probably, this is no problem for routing since tracks, which are tagged
as abandoned or disused, might be ignored.
Considering the use of the map for environment perception and
localization (for research purposes; using OSM where one can quickly
obtain a map from any space) the train can use neither the lower left
nor the upper right track without derailment, since there is no physical
connection any more. But, both ways are still connected to this centre
node. Infering non-existence of switches from missing switch-tags is not
a proper solution, since in most case there is a switch, but not yet a
corresponding tag.
For such special places I would prefer the lower tagging in my sketch
splitting both unusable ways in a shorter abandoned part and a disused
part taking also into account the past (using correct life cycle tags).
How would you tag this scenario (assuming time and attention to detail)?
What arguments are opposing my proposal?
I am looking forward to receiving your helpful comments. Many thanks in
advance!
Kind regards,
Denis.
[1] <https://www.openstreetmap.org/node/1238528586>
--
.........................................................
Dipl.-Inf. Denis Stein
Research Scientist
Research Division ISPE | Research Department MPS
FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10–14
76131 Karlsruhe, Germany
Tel.: +49 721 9654-276
stein(a)fzi.de
www.fzi.de/mitarbeiter/stein
.........................................................
FZI Forschungszentrum Informatik am Karlsruher Institut für Technologie
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Prof. Dr. Andreas Oberweis, Prof. Dr. Ralf Reussner,
Jan Wiesenberger, Prof. Dr.-Ing. J. Marius Zöllner
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
.........................................................
Hallo zusammen,
könnte sich bitte jemand mit entsprechender Ortskenntnis Node-ID
564688104 und dessen Umgebung anschauen? Falls ich mit der Vermutung
eines Fehlers falsch liege, bitte mich entsprechend belehren. ;-)
Insbesondere ab diesem Knoten liegen teilweise zwei Ways (224275527,
224272709) übereinander, zudem mit unterschiedlichen Detailangaben.
Danke und viele Grüße,
Denis.
--
.........................................................
Dipl.-Inf. Denis Stein
Research Scientist
Research Division ISPE | Research Department MPS
FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10–14
76131 Karlsruhe, Germany
Tel.: +49 721 9654-276
stein(a)fzi.de
www.fzi.de/mitarbeiter/stein
.........................................................
FZI Forschungszentrum Informatik am Karlsruher Institut für Technologie
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Prof. Dr. Andreas Oberweis, Prof. Dr. Ralf Reussner,
Jan Wiesenberger, Prof. Dr.-Ing. J. Marius Zöllner
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
.........................................................
