User talk:Marqqs

OSMChange Programm

Hallo, ich nehme an du hast das OSMChange programm geschrieben? (Zumindest hast du die Wiki-Seite dazu geschrieben).

Gibt es den Sourcecode irgendwo? Unter welcher Lizenz ist das Programm zu benutzen?

Gruß

Sven Anders 17:05, 1 January 2011 (UTC)

Hallo! Sorry für die Verspätung. Hab inzwischen einen Link eingefügt, unter dem du den Sourcecode downloaden kannst. Grüße --Marqqs 22:48, 9 January 2011 (UTC)

Small error in Osmconvert

I saw an error working with the "--fake-history" command. Actually, is exactly the same as "--fake-version".

Here is the diff file to correct it:

--- osmconvert.c.orig   2011-06-06 16:58:12.000000000 +0200
+++ osmconvert.c        2011-06-06 23:38:12.947834755 +0200
@@ -5806,7 +5807,7 @@
       }
     if(strzcmp(argv[0],"--fake-his")==0) {
         // user wants faked history information
-      global_drophistory= true;
+      global_drophistory= false;
       global_fakehistory= true;
   continue;  // take next parameter
       }

-- Lolo 32 22:48, 6 June 2011 (BST)

Thank you! :-)

Fixed it and uploaded new versions. --Marqqs 11:32, 7 June 2011 (BST)

pbftoosm

I asume it is you who wrote pbftoosm? I just wanted to tell you that it is a great tool, the speed is fantastic! Even on my netbook (Intel Atom 450) it only took a minute or so to get a regional bounding box (31MB) in osm/xml from the italy pbf (currently 268MB). -- Dieterdreist 18:35, 9 June 2011 (BST)

Hi Dieterdreist, thanks for the good news! I usually develop and test my software on a 9" netbook with Atom N270. :-) Therefore, the programs have to be as effective as possible. Have fun with them! --Marqqs 21:50, 10 June 2011 (BST)

JOSM guide

Hi Marqqs,

See Talk:JOSM/Advanced editing. I don't think the section you added to the JOSM guide really fits very well there, although osmconvert and osmfilter look pretty neat. We should look at some better places around the wiki to describe and link to them.

-- Harry Wood 15:39, 25 June 2011 (BST)

Yes, the place isn't ideal. I just answered at Talk:JOSM/Advanced_editing. --Marqqs 01:26, 26 June 2011 (BST)

osmconvert enhancement

Hi Marqqs,

first thanks a lot for osmconvert and osmupdate they are very good software and they can give me the possibility to don't use to much java software :-)

I would ask you an enhancement in osmconvert: my request it is to add possibility to osmconvert to write also pbf, is it possible?

Thanks Luca

-- lucadelu 7:20, 26 October 2011 (UTC)

Oh, then you're in luck: about two weeks ago, a PBF write module has been added to osmconvert. :-) osmupdate has been extended as well. Just osmfilter sill cannot operate on PBF files. --Marqqs 14:28, 26 October 2011 (BST)

Fähren im ÖPNV

Hallo Marqqs,

du schriebst mir über http://openptmap.org/?zoom=16&lat=45.43093&lon=12.32111&layers=B0000TFT.

Ein super Link! Alle genannten Linien sind sichtbar! Natürlich, die Engländer sind in punkto Schiffe schon weiter und umsichtiger als wir...

--Gpermant 12:11, 12 November 2011 (UTC)

Ja, die Engländer insbesondere dann, wenn sie Deutsche sind. Die Karte ist von mir. ;-) Allerdings gefällt mir die Darstellung der Fähren in der originalen ÖPNV-Karte etwas besser als das Rosa in meiner Karte, z.B.: Fähren in Zürich. Leider scheint aber dort die Aktualisierung nicht korrekt zu laufen, sonst würden die Linien in Venedig angezeigt werden, das ist echt schade. --Marqqs 12:37, 12 November 2011 (UTC)

Aha, ja, das sieht gut aus. allerdings müssen die Züricher Ihre Bootslinien anders getaggt haben als diejenigen, die in Venedig die ersten Linien angelegt haben. Denn ÖPNV-Karte zeigt rein gar keine der Bootslinien in Venedig... liegt vielleicht daran, dass dort ways mit route=ferry getaggt wurden, anstatt relations? Ich schau mir den Zürichsee mal näher an. Gpermant 12:46, 12 November 2011 (UTC)

Openptmap validator

You do the Openptmap right? Someone here is asking about the validator: Talk:Quality Assurance#Public transport validator. -- Harry Wood 16:20, 27 February 2012 (UTC)

Hi Harry, thanks for relaying the message! The validator is still running, but the domain name has moved to a different server. I will try to contact the maintainer of the Validator. --Marqqs 18:11, 27 February 2012 (UTC)

See mapnik_pt.xml on Openptmap/installation

Hello,

In the section Openptmap/Installation#Mapnik_Initialization, I can see that the file mapnik_pt.xml is a copy of osm.xml and need some additional layer. But i can't see these layers.

It is it possible to see the diff with osm.xml?

Thank you.

Hi PierreYvesBl, you are right. This is because there is still work in progress. If you are interested in the current state of the file, please send an email to the address shown in openptmap's imprint. --Marqqs 11:39, 20 June 2012 (BST)

Basiskorrekur der Koordinaten Region Shandong Shanghai, Qingdao etc.

Hallo Marqqs!

Ich wende mich an Dich, weil Du scheinbar gute Kenntnisse zum OSM-System hast und Deine Diskseite genutzt wird.

In der gesamten Region Shangdong scheint es eine Verschiebung der Grundkoordiaten um zu ca. 500 Meter WO und pi mal Daumen 50 Meter NS zu geben. Aufgefallen ist es bei Arbeiten für Wikipedia. Dort nutzte ich dieses Tool[1] zum Koordinatenabgleich. Wie umfangreich der fehlerhafte Datenbestand ist, kann ich nicht sagen. Massgebliche Deviationen habe ich für Shanghai und Qingdao festgestellt. Da ich mit OSM-Daten bisher relativ wenig zu tun hatte ist es wohl sinnvoller wenn sich ein Könner um die Sache kümmert.

BTW wenns möglich ist ... ich habe vor ein paar Tagen zuerst hier den Account "noto" angelegt und danach bemerkt das der Nick im Kartenwerk von osm.org bereits von jemand anderem[2] belegt wurde. Dort habe ich dann den Account "notox" angelegt und Kleinigkeiten [3] editiert . Wäre schön wenn man das synchronisieren kann und hier mein Account auf "notox" umbenannt wird, damit es kein Durcheinander gibt. Ich kenne hier sonst niemanden - vielleicht kannst Du das in Gang setzten?

Bis denne --Noto 10:03, 8 January 2013 (UTC)

Hallo Noto, zuerst mal danke für deine aufmerksamen Beobachtungen! Wurden bei Shangdong tatsächlich die Objekte in OSM verschoben (ist das in der Objekthistory zu erkennen)? Oder vergleichst du mit einem der Luftbilder? Diese sind oft nicht korrekt eingemessen. Egal wie – ich hab von der Region leider viel zu wenig Ahnung, als dass ich mich da einmischen könnte. Gleiches gilt auch für die Accountverwaltung. Auch ich finde es eher unpraktisch, dass die Benutzernamen getrennt verwaltet werden, aber mich hat es bisher nicht so sehr gestört, dass ich nach den zuständigen Entwicklern recherchiert hätte.

Falls "noto" unter OSM noch aktiv oder erreichbar ist, könntest du ihn auch direkt anschreiben. Er freut sich vielleicht über den Wiki-Account noto – oder er tauscht seinen OSM-Account-Namen mit dir. Theoretisch müsste sowas möglich sein, weil die User-Nummer trotzdem konstant bleibt.

Zu beiden Themen kriegst du aber im OSM-Forum kompetentere Auskunft, ich kann hier leider nicht wirklich helfen, weil ich zu weit weg von Shangdong bin und auch sonst nicht für Organisatorisches verantwortlich bin, sondern für OSM fast nur Software schreibe. --Marqqs 18:28, 8 January 2013 (UTC)

• Zu den Kartendaten: Es handelt sich nach meiner Analyse um eine Verschiebung des Grundgitters. Dieses habe ich mit Kartendaten mehrer anderer Kartenanbieder gegengeprüft. Du weisst das in Wikipedia-Artikeln nach und nach alle Möglichen Koordinaten zur Denkmälern, Einrichtungen etc. gesammelt werden? Und zwar in Massen. Gerade weil Du Entwickler hier bist könnte man überlegen ob man ggf. per Bot dazu einen Abgleich machen könnte.
• Das Problem: je mehr falsche Daten im Laufe der Zeit eingetragen werden umso größer der Nachbesserungsaufwand. Zu Shangdong gibt es bereits etliche Inhalte in diversen WP-Sprachversionen die Georeferenzierung nutzten. Die jeweiligen Inhalte der nationalen Sprachversionen lassen sich am besten über die Kategorien auffinden: [4][5][6] etc. Es ist nicht überraschend, das gerade in der chinesischen Wikipedia zahlreiche Einträge dazu vorhanden sind: [7]. Auch wenn man kein chinesisch kann findet man sich dort durch - Geokoordinaten haben glücklicherweise nicht zu viele "Sprachversionen". Wikipedia präferenziert Kartendaten von OSM[8] weil quasi ein Schwesterprojekt. Daher ist es besonders wünschenswert wenn erkannte Fehler per Qualitätssicherung abgearbeitet werden. Weil es hier um eine echten "QS-Brocken" für das OSM-Projekt geht, wäre es besser wenn das von einem Kollegen mit entsprechender Reputation in diesem Projekt eingebracht würde - also besser von Dir als von mir ;-)
• Zum Accounthandling: Der Einfachheit halber habe ich "notox" hier als weiteren Account angelegt. Grundsätzlich ist aber Accountumbenennung möglich, weil dieses Wiki auf Mediawiki-SW basiert. Zur Verwaltung von Mediawikis kenne ich mich aus, weil ich in verschiedenen anderen Wikis Zugang zu solchen Optionen habe (Admin, Bürokrat, Check-User etc.) Mit dem "noto-account" ists kein Beinbruch ich werde den Account bei Gelegenheit dem (nach den Edits vermutlich dänischem) User anbieten.
• Freundlichen Gruß vom --Notox 10:01, 9 January 2013 (UTC) P.S. Es ist wirklich angenehm gleich einen fachlich versierten Ansprechpartner hier zu haben. Vermutlich kennst du auch diesen Herrn[9] und den Uploader des Bildes ;-)

Hallo Noto, klar kenne ich Wikipedia, du brauchst mich gar nicht davon zu überzeugen, dass die von dir vorgeschlagenen Arbeiten sinnvoll und wichtig sind, ich glaube dir das sofort. :-) Nur leider kann ich selbst diese Arbeiten nicht leisten. Warum kommst du auf Steve Coast? Kennt er sich in Shangdong aus? Zu ihm habe ich keinen Kontakt, ich weiß nur, dass er seit einiger Zeit für Microsoft arbeitet, aber ob er dir dort helfen kann? Vielleicht war das auch ein Missverständnis zwischen uns: ich entwickle zwar Software, aber keine Software, die auf einem der OSMF-Server läuft. Ebenso betreibe ich keinen OSM-Bot, mit dem das Verschieben der Daten einer ganzen Region bewerkestelligt werden könnte. Für dein Anliegen wäre wahrscheinlich die Data working group die richtige Adresse. --Marqqs 17:48, 10 January 2013 (UTC)

Danke guter Tipp. Hab mir dort einen ausgepickt und angefragt.[10] Besten Gruß --Notox 13:43, 15 January 2013 (UTC)

Removing untagged, unconnected nodes

Hello. Do you know a way to remove untagged, unconnected nodes from a .osm file by using a command-line application? I have tried osmosis and osmfilter but I think it's not possible. I cannot use a GUI application like JOSM. Thanks. (Jldominguez)

Hi ‎Jldominguez, I am not sure if it is possible to do this with osmfilter alone. However there is a way to remove untagged nodes using grep command:

grep -v -e "<node .*/>" input.osm >output.osm

This is not as fast as osmfilter because it operates on .osm XML files and not on optimized .o5m files. To exclude all nodes which are not used by any ways or relations, osmfilter can do the job:

osmfilter --keep-nodes= input.o5m -o=output.o5m

Hopefully these two steps can be combined somehow... --Marqqs (talk) 10:35, 14 May 2014 (UTC)

osmconvert --all-to-nodes , how to keep tags for ways and relations that are distilled down?

Hey Marqqs,

I couldn't find your email address anywhere, so I'm using this.

When I use the --all-to-nodes option it seems that any tags (like name=, etc.) are removed from the way or relation that is being distilled down.

I'm looking to use your program to distill ways and relations that really should be more like nodes (like small businesses with names, there's a surprising number of them). Your program keeps the tags for nodes, but for some reason it throws them away for ways and relations that are distilled down.

Any commentary on this? Thank you so much for your contributions.

Best, David Gross

Hello David, thanks for bringing this to my attention. osmconvert should not dispose of any tags when running --all-to-nodes. If it does, it's a bug. Do you have an example where the tags are lost? --Marqqs (talk) 09:42, 26 November 2014 (UTC)

--all-to-nodes keeps nodes of converted ways

I have downloaded and compiled the version 0.8.5 and compiled via the one-liner, but the --all-to-nodes function seems to be working differently from the last time I tried: it (additionally) keeps the nodes of the ways that get transformed into a node at their centre. Or has the syntax changed? Have tried like this: "osmconvert input.osm --all-to-nodes -o=output.osm" --Dieterdreist (talk) 16:04, 21 October 2016 (UTC)

Hi Dieter, that's normal behaviour of osmconvert, as far as I recall. Nodes stay in the file. This really has been different? I'm confused a little... --Marqqs (talk) 17:13, 21 October 2016 (UTC)

It requires now an additional step to be executed: delete the nodes without tags. IMHO it doesn't make a lot of sense to keep them: you can already have the extent as a new tag (optionally), and with just the way objects removed but all their node members (now unconnected) remaining, the file doesn't get much smaller --Dieterdreist (talk) 23:18, 21 October 2016 (UTC)

Which version of osmconvert were you using before? I would like to run a diff between the source files. I am not sure but I think most people need keeping the nodes. A usual use-case is to get all objects with a specific tag, for example "shop=bakery" which can be found at nodes and ways. The required filtering can be done with osmfilter. Then you take osmconvert with --all-to-nodes option to extract a list of all that geopositions. --Marqqs (talk) 08:58, 22 October 2016 (UTC)

Before the last update I have used 0.8.a but I am not sure about the behaviour of all-to-nodes in this version, it is some years ago that I used this function the last time, I'm a long-term fan of your software ;-) --Dieterdreist (talk) 09:10, 22 October 2016 (UTC)

Thanks. :-) I've just looked into the source code. You might get the desired result when using the --drop-nodes option in addition to --all-to-nodes. Did you try this? --Marqqs (talk) 09:48, 22 October 2016 (UTC)

Unfortunately I have a dataset with node and area features mixed (typical osm extract), and with --drop-nodes the node features get dropped. My workaround was to use Josms search function to remove the unwanted part of the nodes, but this only works up to a certain amount of features. --Dieterdreist (talk) 06:47, 23 October 2016 (UTC)

You are right of course. The problem is, osmconvert works strictly sequential. For this reason it must have processed all the nodes before it starts processing the ways. That is why an additional filtering step usually will be required. Here is a work flow I've implemented lately. --Marqqs (talk) 17:00, 23 October 2016 (UTC)

I see, I could introduce an additional filtering step after all-to-nodes where I remove all nodes without the relevant tags, that is doable (indeed, they only reason I have used JOSM for this is that I had it already open to check the result of the first conversion). Anyway, I don't think anyone dropping the ways and requesting the centre node of areas will be interested in having the nodes of these former, now dropped, areas in his dataset, because they are "floating" around with no tags attached and not connected by any way, i.e. you can see as a human looking at them that they likely come from a polygon, but to make use of them you would have to reconnect them by a way (which makes no sense, as you just removed this way). --Dieterdreist (talk) 08:28, 25 October 2016 (UTC)

Offener Stationsbereich?

Hallo Marqqs,

erst einmal finde ich es gut, dass Du Dich mit den Modellierungsvorschlägen von Mentz (von uns) auseinandersetzt. Nun verstehe ich aber noch nicht, was genau mit "offener Stationsbereich" gemeint ist?

Viele Grüße,

Roland

Hallo Roland, sorry, dass ich mich da eingemischt hab. Die Ergänzung sollte klarstellen, dass es hier nicht nur um Bahnhofsgebäude geht, sondern auch um Eingänge zu Stationen, zu denen es kein Empfangsgebäude im eigentlichen Sinn gibt. Die Problematik wurde hier diskutiert und vor allem von User BeKri kritisiert: OSM-Forum, Umtaggingaktion light_rail=yes des Münchner Verkehrsverbundes. Er bezog sich auf "Eingänge" wie zum Beispiel hier: Station Leienfelsstraße.

Nach Ansicht von BeKri wird der Schlüssel "entrance" in solchen Fällen falsch eingesetzt. Ich teile diese Ansicht nicht, da es in der Realität durchaus Punkte gibt, die man als Zugangspunkt zu einer Station wahrnimmt. Oft sind sie auch durch entsprechende Schilder oder aufgestellte Ticket-Entwerter gekennzeichnet. Gerade fürs intermodale Routing sind solche Punkte wichtig und müssen irgendwie erfasst werden.

Wenn meine Wiki-Änderung unangebracht oder unkorrekt ist, revertiere sie bitte einfach. Trotzdem sollte zur diesen Stationen ohne Gebäude irgendeine Aussage rein, finde ich...

Grüße Marqqs (talk) 09:21, 21 March 2016 (UTC)

C script too long

Hi! The osmconvert script consists of one whole script which is extremely long. It is not that legible.

Can you please separate the script into several so that we can read it more easily? Thanks Wetitpig0 (talk) 08:56, 15 March 2017 (UTC)

Hello and yes, the monolithic C source file could be split into about 20 smaller files, just use cut command. The module borders are marked by ----- lines. I for myself prefer to have all the modules in one file. That has a few reasons:

• One source code version = one file. No packaging needed.
• No makefile required.
• The source can be downloaded and compiled in one run (see osmconvert Wiki page).
• Compilers can easily do intermodule speed-optimisations.

--Marqqs (talk) 15:20, 15 March 2017 (UTC)

It could be done without makefile by including all the content as headers, right? Also, you can create a directory for each program. Wetitpig0 (talk) 11:24, 17 March 2017 (UTC)

Here is an example. Wetitpig0 (talk) 01:22, 18 March 2017 (UTC)

Create directory list for m.m.i24.cc

Hi! Would it be better to list all files in your website in the form of a directory tree? Then we can more easily find the osmctools source code. Thanks! Wetitpig0 (talk) 11:23, 17 March 2017 (UTC)

Stehst du irgendwie mit openfiremap in Verbindung?

Hi, ich habe gesehen, dass du der letze Editor von DE:OpenFireMap warst. Gehörst du zum Entwicklerteam oder weißt, wie man das erreichen kann? Beste Grüße --MoritzM (talk) 13:29, 12 March 2018 (UTC)

Hallo Moritz, User:Wankmann kümmert sich normalerweise um das Feuerwehr-Fachliche. Bei technischen Fragen kannst du dich aber auch gerne an mich wenden, ich betreue den Server. Grüße --Marqqs (talk) 13:57, 12 March 2018 (UTC)

Ah super, meine bisherigen Kontaktversuche über eine Mail an info@ bzw. per OSM Nachricht an Wankmann schlugen bis jetzt fehl. Es geht um das geänderte Tagging-Schema für Hydranten und Löschwasserentnahmestellen.

Ende November gab es ein Proposal (Proposed_features/Fire_Hydrant_Extensions_(part_2)), was zum Ziel hatte Hydranten mit mehr Details zu mappen, das Mapping zu vereinfachen und außerdem Löschwasserbrunnen und Hydranten nun unter emergency=fire_hydrant zusammenzufassen. Das Proposal wurde angenommen und zumindest die englische Wikiseite wurde schon aktualisiert.

Könnt ihr das neue Schema in der Openfiremap berücksichtigen?

Tut mir Leid, dass das mit der Kommunikation schief ging. Warum User:Wankmann nicht geantwortet hat, kann ich mir grad nicht erklären. Wenn ich das aber richtig sehe, ist das Wesentlich, das die openfiremap betrifft, dass nun "pipe" als Typ eingeführt wurde. Ich komm zwar nicht gleich dazu, aber werd das sicher irgendwann auf die Reihe bekommen und mit aufnehmen. :-) --Marqqs (talk) 14:27, 12 March 2018 (UTC)

Genau, Unter- und Überflurhydranten bleiben so, da kommt nur water_source=main hinzu. Außerdem kann jetzt die Farbe und Art und Anzahl der Abgänge getaggt werden. Das ist für die Karte wahrscheinlich nicht so wichtig. Interessanter ist dann das Tagging von geschl. Löschwasserbehältern und Löschwasserentnahmestellen (letzten beiden Spalten in der Tabelle DE:OpenFireMap#Darstellung_auf_der_Karte). Die können anhand von fire_hydrant:pressure=suction von unter Druck stehenden Hydranten unterschieden werden, da gib's dann auch Tags für das Volumen und Durchflussmenge.

Geschl. Löschwasserbehälter: emergency=fire_hydrant fire_hydrant:type=pipe fire_hydrant:pressure=suction water_source=water_tank water_volume=200 (in m³). Zumindest für das Saugrohr an dem Tank/Zisterne. Tank kann wie bisher ja weiter mit emergency=water_tank gemappt werden.

Löschwasserentnahmestelle: emergency=fire_hydrant fire_hydrant:type=pipe fire_hydrant:pressure=suction water_source=pond (oder river etc)

Löschwasserbrunnen: emergency=fire_hydrant fire_hydrant:type=pipe fire_hydrant:pressure=suction water_source=groundwater flow_rate=600 l/min (wenn die Durchflussrate bekannt ist)

fire_hydrant:type=pond ist jetzt deprecated (durch water_source ersetzt). emergency=suction_point ist jetzt nur noch als "Platz für die Pumpe am Gewässer" gedacht ("can be intended as a place where to park the fire engine to easily take water with your pump from a river, pond, lake... But a separate refinement proposal will be needed for it." aus Proposed_features/Fire_Hydrant_Extensions_(part_2)#Dry_hydrants)--MoritzM (talk) 12:00, 13 March 2018 (UTC)

Ping. Gibt's Neuigkeiten, ob die Openfiremap das neue Tagging-Schema unterstützen wird? --MoritzM (talk) 09:20, 17 October 2018 (UTC)

Hallo Moritz, "fire_hydrant:type=pipe" sollte eigentlich seit März funktionieren... hoffentlich. :-) --Marqqs (talk) 15:37, 19 October 2018 (UTC)

Hallo Marqqs, dann gibt's glaube ich ein Missverständnis bei mir oder es funktioniert nicht so wie gedacht. Dieser Knoten https://www.openstreetmap.org/node/4497223104 ist ein Löschwasserbrunnen ( emergency=fire_hydrant fire_hydrant:type=pipe fire_hydrant:pressure=suction water_source=groundwater). Ich habe jetzt erwartet, dass er auf der OFM als dargestellt wird. Tatsächlich wird er aber als Hydrant ohne Angaben dargestellt. Permalink: http://m.openfiremap.org/?zoom=17&lat=52.39063&lon=13.57738&layers=B0000T--MoritzM (talk) 16:56, 24 October 2018 (UTC)

Ah, jetzt begreif ich die Verwirrung: Die Karte verarbeitet immer nur Datenänderungen. Das heißt, erst dann, wenn sich die Daten einer Kachel ändern, wird dort neu gerendert. Ich habe das an der fraglichen Stelle mal künstlich veranlasst, jetzt ist das Symbol für "pipe" zu sehen. --Marqqs (talk) 08:13, 29 October 2018 (UTC)

Hi Marqqs, jetzt passt's vom Symbol her, dankeschön. Drei Kleinigkeiten habe ich noch:

# Fragezeichen und Volumen bei Pipesymbol

Das Fragezeichen macht in meinen Augen keinen Sinn, da es darauf hindeutet, dass da eine Angabe fehlt oder nicht korrekt ist. Solange emergency=fire_hydrant fire_hydrant:type=pipe fire_hydrant:pressure=suction vorhanden ist, ist eigentlich alles Notwendige beschrieben. Falls fire_hydrant:pressure=* fehlt, könnte man das mit dem Fragezeichen darstellen. Ebenso wenn es nicht fire_hydrant:pressure=suction ist.

Es gibt ja das Tag water_volume=*, was bei Pipes an Zisternen und Teichen den Inhalt (in m³) angibt. Könntest du das mit darstellen (analog zu fire_hydrant:diameter=*? Das wäre z.b. ein Node mit water_volume: https://www.openstreetmap.org/node/4408286120 http://www.openfiremap.org/?zoom=17&lat=52.4065&lon=13.57178&layers=B0000T

# Water_tank:volume

Bei emergency=water_tank zusammen mit water_tank:volume=* soll laut DE:OpenFireMap#Darstellung_auf_der_Karte das Volumen unter dem Symbol dargestellt werden. Das scheint nicht zu funktionieren. Z.B. hier https://www.openstreetmap.org/node/4805627972 http://www.openfiremap.org/?zoom=17&lat=52.39064&lon=13.80578&layers=B0000T

Hast du was dagegen, wenn ich die Tabelle auf DE:OpenFireMap#Darstellung_auf_der_Karte um Pipe erweitere?--MoritzM (talk) 17:37, 1 November 2018 (UTC)

Ich habe nochmal über water_tank:volume=* bei Tanks nachgedacht. Das ist als Tag ja nicht dokumentiert, water_volume=* zumindest bei Hydranten schon. Ich würde darauf hinarbeiten, dass auch beim emergency=water_tank das Tag water_volume=* den Inhalt angibt (über ein Proposal). Daher wäre es sinnvoll, wenn auf der Karte bei emergency=water_tank entweder water_volume=* oder water_tank:volume=* angezeigt wird. Je nachdem welches Tag vorhanden ist und default water_volume=*. --MoritzM (talk) 10:06, 2 November 2018 (UTC)

Hallo und danke für den Fehlerhinweis! Das kleine blaue Fragezeichen hab ich übersehen, weil es sich an der betreffenden Stelle mit dem Straßennamen getarnt hat. Wegen eines Fehlers in der Render-Vorlage wurden zwei Symbole gleichzeitig generiert: das für Pipe und das für "unbekannt". Die Vorlage ist korrigiert, aber das falsche Bild natürlich noch drin.

Die anderen Änderungen habe ich wahrscheinlich nicht vollständig begriffen. Was hältst du davon, wenn ich dir die aktuelle Vorlage (mapnik.xml) zukommen lasse, und du editierst die Änderungen rein, die du brauchst? Vielleicht wird es mir dann klarer. --Marqqs (talk) 20:28, 3 November 2018 (UTC)

Openptmap

Hi Marqqs,

Openptmap.de and openptmap.org are not functioning anymore. Has it moved or is the project abandoned? --Mdeen (talk) 09:22, 29 March 2021 (UTC)

Hi Mdeen, unfortunately the server is down since a few weeks. The project still exists but as far as I know there is currently no server serving openptmap tiles. :-( --Marqqs (talk) 11:54, 29 March 2021 (UTC)