Hallo,
ich habe soeben auf meinem Server einen FTP-Account eingerichtet, über
den wir die Bilder von gestern sammeln können. Damit kann jeder, der
seine in Mainz-Bischofsheim erhobenen Daten in OSM eintragen möchte,
auch auf die Fotos der anderen Teilnehmer zugreifen.
Da uns keine Erlaubnis zur Veröffentlichung der Fotos vorliegt, sende
ich die Zugangsdaten für den FTP-Zugriff nicht einfach per Mail an die
Mailingliste. Wer Zugriff haben möchte (es ist ein Benutzerkonto für
alle), schreibe mir bitte eine Mail.
Hinweis für die Benutzer von vernünftiger Kameras: Bitte komprimiert
eure Fotos nicht zu stark. Ansonsten kann man Beschriftungen in der
Ferne nicht mehr lesen. :-)
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)
English see below.
Hallo,
meine WMS-Dienste sind auf einen neuen Server umgezogen. Oder besser:
Einer ist umgezogen, den anderen werde ich in den kommenden Tagen
abschalten. Der WMS-Dienst mit dem Streckennetz der DB [1] hat jetzt
eine andere Domain, nämlich wms.michreichert.de und unterstützt HTTPS.
In JOSM müsst ihr dazu unter Hintergrund → Hintergrund-Einstellungen die
URL in der unteren Fensterhälfte anpassen. Bislang steht da:
wms:http://michreichert.de/vzg-strecken…
Neu:
wms:https://wms.michreichert.de/vzg-strecken…
Alternativ könnt ihr auch einfach den alten Eintrag löschen, denn ich
habe den neuen WMS im JOSM-Wiki eingetragen, d.h. er taucht jetzt bei
Änderungen in Deutschland von allein im Menü "Hintergrund" als "Deutsche
Bahn VzG-Strecken Nov. 2013" auf.
Die Schrift habe ich vergrößert und den Bug bei den
Bahnübergangsbeschriften behoben.
Der Dienst nutzt noch die alten INSPIRE-Daten (als GeoJSON) vom November
2013, seid also bitte umsichtig beim Umgang und denkte an
Streckenverlegungen (auch länger zurückliegende).
Der Dienst mit den niederländischen Hektometertafeln wird nicht auf den
neuen Server umziehen und in ein paar Tagen abgeschaltet werden. Den
Logfiles zufolge gab es seit Mitte Dezember keinen Zugriff mehr (außer
ein paar Bots, die den Link im Archiv dieser Mailingliste finden). Das
rechtfertigt den Aufwand nicht.
Viele Grüße
Michael
[1]
http://lists.openrailwaymap.org/archives/openrailwaymap/2016-March/000434...
PS Bitte nicht auf dieses Posting verlinken, sondern stattdessen auf
https://wiki.openstreetmap.org/wiki/User:Nakaner/WMS verlinken, denn das
kann ich aktuell halten, falls sich die URL mal wieder ändert.
==================
Hi,
my WMS services (or better: one of the two) has been moved to a new
server and got a new domain.
If you use my WMS service showing the railway lines of Deutsche Bahn AG,
please change the URL in JOSM (Imagery → Imagery Settings) from
wms:http://michreichert.de/vzg-strecken…
to
wms:https://wms.michreichert.de/vzg-strecken…
Or you just remove the old entry because the Imagery menu now lists it
if you are editing in Germany. The entry is called "Deutsche Bahn VzG
lines Nov 2013".
In addition, I increased the font size and fixed a bug with overlong
labels for level crossings. I still use the data from the November 2013
release (as GeoJSON), so please be careful if you use it (relocated
railway lines etc.).
The WMS service rendering milestones of ProRail will not turned off next
week. According to the log files, nobody apart from some bots
(like Yandex) has been using it since mid of December 2016. (Those bots
only follow a link to the GetCapabilities in the archive of this mailing
list).
Best regards
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
Hello,
together with Nakaner, we discussed about vector tiles at the FOSSGIS
2017 conference in Passau, Germany. We came to the conclusion, that
vector tiles have a lot of disadvantages and are far away from
productive use and decided to remove them from OpenRailwayMap.
One major problem is the speed. HTML5 Canvas rendering is still too
slow, that is why OpenRailwayMap never used tiles rendered on client
side in production. WebGL would be the better technology, but has some
disadvantages:
* Writing an own WebGL renderer is too much work for a small project
like this
* There are no WebGL-based renderers that are established, using
standard formats and not from Mapbox. All available solutions are
relatively new and it is not clear how their development will continue
(except from Mapbox Vector Tiles).
* WebGL can be either not supported or slow on older systems and mobile
devices
* Clientside rendering will always be slower than serverside rendering.
The fast map of openstreetmap.org is a cause why some people prefer it
over Google Maps.
The main problem is the data of the vector tiles: Vector tiles are just
fast if you filter and generalize the data, but this reduces the
flexibility and decreases the quality of the data. In our case this is
the main problem that makes it difficult to reduce the amount of data
in the tiles. In low zoom tiles, railway tracks are split up in a lot
of very short ways. Reducing the number of features is only possible by
merging these ways. But merging features is just possible by ignoring
tags. And the decision which tags are more important than other tags
depends on the rendering style.
Also there is a general difficulty with vector tiles: It is not
possible to drop bitmap tile support completely without dropping the
possibility of embedding OpenRailwayMap layers in OsmAnd, QGIS, etc.
That is why we will always need a bitmap tile interface.
The question is how we should continue now:
* Clean up node-tileserver and remove the vector stuff from the code,
moving to node-mapnik for tile rendering in a longer perspective
* Drop node-tileserver completely and move to Mapnik, mod_tile,
renderd, Tirex, ...
In both cases there is the problem that Mapnik (and node-mapnik) do not
support MapCSS styles. Therefore it would be necessary to develop a
converter from MapCSS to Mapnik XML first.
If we would choose the first way we would have to decide if we either
should apply these changes to node-tileserver or create a fork?
Personally I prefer own code over being dependent from other projects,
but on the other hand I do not want to invest much work to reinvent the
wheel.
Regards
Alex
