-karlos-'s diary

Recent diary entries

Mara Ort: A map is a map is a map?

Posted by -karlos- on 28 September 2017 in English (English)

Optimising "OSM go"

Posted by -karlos- on 15 September 2017 in English (English)

A bridge, rendered by OSM building parts

As I wrote last time, “OMS go” will only be used for experiments now. Recently my friend Martin told me about an optimisation, he had done successfully. I implemented it and you may feel remarkable increased control reactions. This is really good if you use the head tracking of Google Cardboard or other stereo devices. To get the best performance, you may need to restart your browser. The 3D interface WebGL is limited and my data handling code is a hack anyway. My new tile handling does have disadvantages: Od shadows ad sunny places. And you can’t select things any more! You may add “&opt=0” to your URL to switch back to the old mode. or switch of shadows by &sha=0

What I did, may only be interesting for codes of 3D renderer:

“OSM go” uses the 3D framework “three.js”. It's, known as slow, causing bad frame rates. And yes, it does. I am not an expert in 3D hardware and interfaces. But I think there is a bottleneck at the interface to the graphic card. So that problem should also be in OpenGL, Direct-X and WebGL. Sending a package of data (points, three angles, etc. ) from the CPU to the GPU is relatively slow. But the amount of data is not that critically. So you should send less packages with much data. And three.js does the opposite, usually. Each mesh, containing a single geometry with points and faces is send separately to the hardware, again and again in every render cycle.

A three of meshes is a good way to define a complex 3D scene. But an extra mesh is only needed, if you want to change visibility, position and so on. “OSM go” creates an extra mesh for each building, street and stuff. So what? Three.js can merge geometries! After I merged all buildings of a “tile” into one “Multi-Geometry”, the speed increased remarkable. Compare the FPS displayed. You also “feel” now if new OSM data are processed. Moving and spinning gets slow. Just wait or spin a little while and you will “feel” the smooth controls again if it’s over.

It wasn’t a big challenge to implement it. Next to the merges, an array of materials (area-, wall- and roof colors) has to be managed dynamically. The first test was odd: If the zero-point of the geometry went out of screen, the whole multi-geometry got invisible. I assume there is a bounding box, I missed to update after the merges. So it had a size of zero. But who does this invisibility? Three.js or the graphic card? And why are there grey shadows on areas, not placed behind other objects?

I could do some more optimising. May be not in “OSM go” but the next project.

  • With “opt=1” you only merge the buildings, streets, landuse etc. Other OSM-Nodes are in an extra mesh for the closer LOD. They don’t take much render time. But you may switch them of by “opt=2”.
  • The use of BufferGeometries in three.js may increase the speed to
  • I could/should define lower detailed LOD for tiles fare away.
  • I should switch off the tiles “behind me”
  • There is an idea, how to reenable selecting, while using opt=1
  • I hope, OSM download could be done in the background
  • OSM tag analysing should be done by a tile server already
  • I could change the whole project to WebAssembly 8-I

I did have an ongoing dispute with Martin about storing 3D data in the graphic card and NOT loading the whole OSM objects and unchanged 3D tiles again and again for each render cycle. I only want to move the camera! And it looks like i will win. There are buffers in the GPU, may be not usable with three.js. I also found good hints, I should not deleting the whole render data in each cycle. This looks interessting:

While I experiment with the geometry optimisations, I see much ways to set up a new cyclic code and timing concept, but I will do that in a future project.

One more thing ;-)


Do you know, "OSM go” offers two control modes: Inspect- and Segway-Mode. Key X switches mode. And if you start it on a smartphone in landscape orientation, you get a direction controls and stereo view, ought to used in a Google Cardboard.

Now you will control the direction, the Segway is driving to. Just turn your head. First you will se your left or right surroundings. Slowly the (virtual) Segway will rotate to. Instinctively you kann turn back your head and still se the new direction. Puzzled by my words? Try it! Or watch that video:


OSM go - and stop - what next?

Posted by -karlos- on 21 August 2017 in English (English)


The development of OSMgo is on hold, may be forever. It was not intended to go that far anyway. I will do small changes now or then. And “support”: If anyone tells me new bugs or a missing feature, I most probably will get active. If you like to use OSMgo with a liddle help, I would be glad to guide you in multiuser mode. My friend Martin is coding a plane control/simulation. Soon you may fly through the virtual 3D world of OSM with/as a model plane. When the intended 3D model server/repository is online, it will be used by OSMgo to.

My whole code is a first shot style, really no clean code and not well structured. It has to be redone from the scratch. And in a way it will. But not by me. There is a project slightly relaying on my work. And I will contribute a bit. In that project, the dead ends of OSMgo may be solved, mostly by analysing the solutions of existing code. Mainly OSM2WORD because it is open source and OSMBuildings with an open source client at last. Are there other good sources? Unfortunely the really good solutions are in commercial products like F4. But they will not support a community project, will they? I would like, not only to have correct and complete code, but also a public description of the functions and algorithms. Yes, in the OSM wiki are pages about multipolygons and more. There are other disasters of complexity in OSMgo: rendering roof types and even roof directions, replacing buildings by building parts. The recursive OSM relations are hell. On the other hand, most of this problems are already solved by the 2D renders. And they are open source!

There are some ugly errors I will not fix. Like my roof typ gabled or the flickering land uses. Some buildings holes or holes in landuses are missing because of an error in ThreeJS. That may be gone in the next version. The frame rate is mostly a mess, mainly because I use ThreeJS. The new project uses Cesium now and so, it will also be limited. But Cesium may partly replace it with “native” code later. A lot of functiionality, like the analysis of OSM tags should not be done by the client but an tile server, a vector tile server of course. There are quite a view such servers already, most of them are commercial. I would be happy, if the OSM community would set up its own independent server and code.

Creating the Houses of Parliament in London etc. in details with building:parts is artwork of it’s own kind. I am always impressed what some OSM user have done. I started the page "” and almost forgot it. There are much more artful places in OSM. Some can be found in the twitter feed “OSM__go”. But I think, creating labyrinthine Objekte as "Simple 3D buildings” is only ok ok for really simple buildings. If I see an artful created fountain in Paris, I don’t think, that should be part of the OSM data base. That’s a job for the model server. Building heights or levels are necessary, roof types and colours are fine. But building:parts only intent do create an exact outer view. And they will interfere with indoor mapping! For objects of a certain complexity, they should be “exported” into a file format for 3D editors and the 3D model should be placed in the model server.

I see OSMgo as a sandbox for experiments. Recently, I added an OBJ file of my favourite space ship Orion ( After “running” around it, I wanted it to fly. That may happen in OSMgo. And it may be my next big project, a "Syfy Space Sip Simulator". Off-course OSM would be used to show the Earth. So that would be a union of my long time hobbies: Raumpatrouille/Science Fiction, OSM and gravity simulation. After a start in Javascript I may change to WebAssembly & Apple Swift and may even use the VR-Kit. (Mabbox is showing some experiments with OSM and VR-Kit already.)

What do you think about this: The OSM community should start an OSM 3D renderer in WebAssembly. Oh, wait a minute! Java can be compiled into WebAssembly. So OSM2WORLD could run as an Web-App. Supported by a good tile server it could make OSM great again (sorry, a spontaneous joke). But not only 3D! A 2D renderer is almost a subset of a 3D one. But in this case, it would be a 2D vector renderer with many advantages. The view of all objects configurable by MapCSS, even the zoom-height it gets lowly visible, or not at all. So you define the content and the layout. We don’t need special maps for horse riding or what ever, but just a new MapCSS. There are many vector renderer already. Except the experiments, sadly they all are commercial. A community 2D(+3D?) vector renderer in WebAssembly could be the future landing page of OSM.


OSM go - und stopp - was nun?

Posted by -karlos- on 21 August 2017 in German (Deutsch)


Die Entwicklung von OSMgo ist angehalten, vielleicht für immer. Das es so weit geht war garnicht angedacht. Ich werde hi und da kleine Änderungen machen. Und “Support”: Wenn jemand neue Fehler meldet oder Funktionen gewünscht werden, werde ich sehr wascheidlich aktiv werden. Wer beim Benutzen von OSMgo etwas Hilfe möchte, den werde ich mit Freuden im Multiuser-Modus begleiten. Mein Freund Martin schreibt gerade Code für eine Flugzeug-Steuerung/-Simulation. Bald kann man mit einem Modellflugzeug durch die virtuelle 3D Welt von OSM fliegen. Wenn der geplante 3D-Server/Service online ist, wird er auch von OSMgo genutzt.

Mein ganzer Code ist nur ein erster Versuch, wirklich kein Clean Code und nicht gut strukturieret. Er müßte komplett neu gemacht werden. Und in gewisser Weise wird er das. Es gibt ein Projekt, teils auf meiner Arbeit aufsetzt. In dem Projekt werden die Sackgassen von OSMgo hoffendlich gelöst, meistens, durch Analysen von vorhandenem Code. Hauptsächlich OSM2WORLD weile es open source ist und OSMBuldings mit einem zumindest offenen Client. Gibt es andere gute Quellen? Die wirklich guten Lösungen sind leider in kommerziellen Produkten wie F4. Aber die werden ein Kommunity-Projekt nicht unterstützen, oder? Ich möchte nicht nur korrekten, kompletten Code sondern auch eine öffentliche Beschreibung der Funktionen und Lösungen. Ja, im OSM-Wiki sind Seiten zu Multipolygonen und mehr. Da sind noch andere Katastropen von Komplexität im OSMgo-Code: Rendern von Dachtypen und sogar Dachrichtungen; Gebäude ersetzen durch Gebäudeteile. Die rekursiven Relationen sind die Hölle. Andererseits, die meisten dieser Probleme sind schon von 2D-Renderern gelöst. Und die sind open soruce!

Einige fiese Fehler werde ich nicht mehr flicken. Wie meinen Dachtyp “gabled” oder das flackern bei Landflächen. Einige Haushöfe oder Lücken in Landflächen fehlen wegen eines Fehlers in ThreeJS. Das könnte in der nächsten Version weg sein. Die Framerate ist meistens schlimm, hauptsächlich, weil ich ThreeJS nutze. Das neue Projekt nutzt Cesium und wird so auch begrenzt sein. Doch Cesium mag später durch nativen Code ersetzt werden. Viele Funktionen, wie die Analyse der OSM-Tags sollten nicht vom Client sondern von einem Server erledigt werden, ein Vektor-Tiel-Server natürlich. Es gibt da schon einige Server, aber meist kommerziell. Ich würde mich freuen, wenn die OSM-Gemeinschaft eigenen Server-Service /- Code erstellt.

Erstellen der Houses of Parliament in London usw. mit building:parts ist eine eigene Art von Kunst. Ich bin immer beeindruckt, was mansche OSM-User geschafft haben. Ich habe die Seite "” angefangen und dann fast vergessen. Es gibt viele kunstvolle Orte in OSM. Einige kann man im Twitter-Feed “OSM__go”. Aber ich denke, verwinkelte Objekte sollten nur mit "Simple 3D buildings” gebaut werden, wenn es wirklich simple Gebäude sind. Wenn ich einen kunstvoll gebauten Brunnen in Paris sehe, denke ich, das sollte nicht Teil der OSM-Daten sein. Das eine Aufgabe für einen Modell-Server. Gebäudehöhen oder Stockwerke sind notwendig, Dachtypen und Farben sind prima. Aber building:parts wollen nur die Aussenansicht von Gebäuden genau darstellen. Und sie beissen sich mit Indoor-Mapping! Objekte mit einer gewissen Komplexität sollten in ein Dateiformat für 3D-Eitoren “exportiert” werden und das 3D-Modell sollte in den Modell-Server gepackt werden.

ich sene OSMgo als einen Spielplatz für Experimente. Kürzlich habe ich eine OBJ-Datei meines Lieblings-Raumschiffs eingebaut ( Nach einem “Spaziergang” ‘drumherum wollte ich , dass es auch fliegt. Das mache ich vielleicht auch noch in OSMgo. Das könnte aber ich mein nächstes großes Projekt geben, einen "SF Raumschiff-Simulator” Natürlich wird OSM genutzt um die Erde darzustellen. So würde das eine Vereinigung meiner Langzeit-Hobbies: Raumpatrouille/Science Fiction, OSM and Gravitationssimulation. Nach dem Start in Javascript wechsle ich vielleicht zu WebAssembly & Apple-Swift und benutze eventuell sogar VR-Kit. (Mapbox zeigt schon einige Experimente mit OSM und VR-Kit)

Was denkst du darüber: Die OSM-Gemeinschaft sollte einen SMO 3D renderer in WebAssembly anfangen. Oh, warte mal! Java kann zu WebAssembly übersetzt werden. So kann OSM2WORLD als eine Web-App laufen. Unterstützt von einem Vektor-Tiel-Server könnte das OSM “make great again” (Sorry, ein spontaner Witz). Aber nicht nur für 3D! Ein 2D-Renderer ist fast eine Untermenge von 3D. Auf diese weise würde es ein 2D-Renderer mit vielen Vorteilen: Das Aussehen von allen Objekten konfigurierbar mit MapCSS, sogar die Zoom-Höhe bei der es langsam sichtbar wird, oder auch nie. So bestimmt man den Inhalt und das Aussehen. Wir brauchen keine extra Karten fürs Reiten oder so, nur eine neue MapCSS. Es gibt schon eine menge Vektor-Renderer. Außer den Experimentellen, sind leider alle Kommerziell. Ein 2d(+3D) Vektor-Runderer in WebAssembly der OSM-Gemeinschaft könnte die zukünfige Landingpage von OSM sein.


OSM go: multiuser mode with chat & new slippy map

Posted by -karlos- on 30 May 2017 in English (English)

Multiuser mode

Now, you may go into the OSM-Data world and visit places 'together with a friend'. As you move around, you will see your company next to you, also moving and watching. If you just start “OSM go”, your user name will be the name of your country. Or call Use a nickname or even better, use your OSM-name. A 2nd-click any place you want to visit and select the icon of “OSM go” to enter. Your friend may follwow you, using the slippy map (see below).


There is a 'chat' implemented in “OSM go”! Press key C and enter text in the popup dialog. The actual chat texts will be shown in the text box at the top left. There you will also see if an other user is dropping in or leaving. If you like to test it with me (-karlos-) just send me a time, I may be there and guide you. So don’t be afraid if you use “OSM go” and see a moving smile. Some visitors and me had already a lot of fun doing this. Some user of “OSM go” may have been shocking surprised, sorry.

Slippy map

The new slippy map is done with Leaflet. You will see it, as you call or if you press the key M while using “OSM go”.


Usually, you will see the OSM default world map with additional layers:

  • A number of city icons, you may mostly know as 'Demo areas' from the wiki page Simple 3D buildings. A klick at one of them will show the map menu. There you may select none of the existing 3D renders. The arrow at right will zoom in to the place or zoom out to the world map.

There are the usual map zoom controls, a search control to find a place on earth by text and a control to zoom to your actual location. The cursor keys, mouse- or touch-drag will slip the map. The keys plus/minus and the mouse weel will zoom. A double-click/-touch will zoom in, a single-click/-touch will zoom out. A 2nd-mouse-click at any place or a long touch will popup the map menu as descripted above.

With the menu top right you may activate some “OSM go” specific layers:

  • “OSM go” shows all users as an icon. Active users will be shown as a smily. A klick on one will show the map menu. If you zoom in by the arrow, you may even see the user move its actual position across the map. If you enter “OSM go” yourselves now, you will arrive next to your OSM-friend. If a user starts “OSM go" or gets passive, you will get an message by the map.

  • Layer “You” will get active, if you klick on the “location” control at bottom left. Your browser will ask you to use your actual location, show an icon and will zoom in to it. Also the location, determined by your IP address will be shown.

  • “Visits” will show a lot of red cycles: Places, other users did visit recently. Form the very last visit, the home of the visitor is shown in blue. Of course, a click on a cycle will bring the map menu to start a 3D renderer.

If you visit the map with an given user name (by adding ?user=myName to the URL) only the layers “OSM go” and “Visits” are active.

The map code/function isn’t final. It would be nice, if someone will help me using Leaflet accurate. Like: how to use the enter key for text search. As avatar I used an creepy human eye first, then a glass eye. There should be a way to select or even download an individual avatar, like the eye of 2001-HAL or whatever. ** 'OSM go' uses a lot of URL parameter. I would like to replace them by a map menu, but I don’t know how to do it - yet.


  • There is a lot of gaps to fill, like more roof shapes.
  • There should be a 3rd person view with an avatar like in “Pokemon GO”.
  • The primary intention, to make a “game” to help OSM is still present. In the last days, I played Pokemon to get inspirations. May be: Find new shops or changed places, take pictures to enable arm chair editing the tags of the places.
  • I consider to recode “OSM go” in C++ (or Shift ) to have native applications - and use WebAssembly to run it in browsers.

OSM go: Multiuser-Mode mit Chat & Neue Slippy-Map

Posted by -karlos- on 30 May 2017 in German (Deutsch)


Jetzt kann man die Welt der OSM-Daten zusammen mit einem Freund besuchen. Während man sich bewegt sieht man neben sich die Begleitung, sich bewegen und umsehen. Startet man “OSM go” bekommt man als User-Name den seines Lands. Oder man nutzt für einen Rufnamen oder noch besser, seinen OSM-Namen. Ein Klick mit der zweiten Maustaste dort, wo man hin will und ein Klick auf das Icon startet “OSM go”. Ein Freund kann folgen, in dem er die Slippy-Map nutzt (siehe unten)


In “OSM go” ist ein ‘Chat’ implementiert. Die Taste C öffnet einen Dialog um Text einzugeben. Die aktuellen Chat-Texte werden oben-links in der Text-Box angezeigt. Dort sieht man auch, wenn ein User erscheint oder verschwindet. Wer es mit mir (-karlos-) testen möchte sende mir einen Zeitpunkt; vielleicht bin ich da als Begreitung. Also nicht überrascht sein beim benutzen von "OSM go” wenn ein Smily herumsaust. Einige user hatten schon einigen Spaß dabei. Mancher mag auch erschreckt worden sein, sorry.

Slippy map

Die neue Slippy-Map wurde mit Leaflet erstellt. Sie wird sichtbar, wenn man aufruft. Or wenn man die Taste M drückt während man “OSM go” nutzt.


Normalerweise sieht man die Standard OSM-Karte mit weiteren Layern:

  • Eine Anzahl von Stadt-Icons, die man von 'Demo areas’ auf der Wiki-Seite Simple 3D buildings kennt. Ein klick auf eines davon zeigt das Map-Menü. Dort kann einer der 3D-Renderer ausgesucht werden. Der Pfeil rechts zoomt hinein zu dem Ort oder ‘raus zur Weltkarte.

Es gibt die üblichen Karten-Zoom-Bedienungen, eine Suche um Orte auf der Erde per Text zu finden und einen “Knopf” um zu seinem eigenen Ort zu kommen. Die Cursor-Keys, Maus-Ziehen oder Touch-Wischen verschiebt die Karte. Die Tasten Plus/Minus und das Mauspad zoomen. Ein Doppelklick zoomt hinein, ein Einfachklick ‘raus. Die zweite Maustaste irgendwo auf der Karte oder ein langer Touch bringt das Map-Menü wie oben beschrieben.

Mit dem Menü oben rechts kann man verschiedene “OSM go” spezifische Layer aktivieren:

  • “OSM go” zeigt alle user als Icon, aktive als Smily. Ein klick auf einen bringt das Map-Menü. Wenn man dann mit dem Pfeil zoomt könnte man vielleicht sehen, wir ein user sich über die Karte bewegt. Wenn man hier selbst “OSM go” startet, landet man neben seinem OSM-Freund. Wenn ein anderer user “OSM go” startet oder verläßt, bringt die Karte eine Nachricht.

  • Layer “You” wird aktiv, wen man den “Location-Knopf” drückt. Der Browser fragt, ob er die aktuelle Adresse nutzen darf, zeigt dort ein Ikon und zoomt hin. Auch die Adresse, aus der IP ermittelt, wird als Icon angezeigt.

  • “Visits” zeigt eine Menge roter Kreise: Orte, die andere user kürzlich besucht haben. Vom letzten Besuch wird der Ort des Besuchers als blauer Kreis angezeigt. Und natürlich bringt ein Klick auf einen Kreis das Map-Menü um einen3 D-Renderer zu starten.

Wenn man einen eigenen Namen angibt (durch ergänzen von ?user=myName zur URL) sind nur die Layer “OSM go” und “Visits” aktiv.

Die Kartenfunktion/der Code ist nicht fertig. Es währe schön, wenn mir jemand helfen könnte, Leaflet richtig zu verwenden. Z.B.: Die Enter-Taste nutzen bei der Textsuche. Als Avatar habe ich erst ein erschreckendes menschliches Auge, dann ein Glasauge verwendet. Es sollte möglich sein, eigene Avatare hoch zu laden; wie das Auge vom 2001-HAL oder was auch immer. ** ‘OSM go’ verwendet einige URL-Parameter. Die sollten auch durch Karten-Menüs ersetzt werden. Nur Ich weis (noch) nicht wie das geht.


  • Es gibt noch viele Lücken zu füllen, wie weitere Dach-Typen.
  • Es soll eine 3rd-Person Ansicht geben mit Avataren wie in “Pokemon GO”.
  • Die ursprüngliche Idee, ein “Spiel” zu machen, das OSM hilft ist noch da. In den letzten Tagen habe ich Pokemon gespielt, zu inspiration. Vielleicht das: Finde neue Läden oder Geänderte, mach Bilder, damit man dann per Schreibtisch-Arbeit die Tags ändern kann.
  • Ich überlege, “OSM go” neu zu erstellen, in C++ (oder Shift ) um native Anwendungen zu erzeugen - und zum starten im Browser WebAssembly zu nutzen.

Der Erd-Umradler Klaus Max Smolka alias "LemLem" nutzt OSM für die Feinplanung

Posted by -karlos- on 15 April 2017 in German (Deutsch)

Laut seinem Blog-Beitrag "Friends de Tour" nutzt er neben Papierkarten OSM für den Feinabgleich und findet manches auch nur bei OSM - Siehe auch: "Landkarte oder GPS?" -

Location: Yeniköy, F.S.M Mahallesi, Sarıyer, İstanbul, Marmararegion, Türkei

Ein Newbie beim OSM Treffen nach der FOSGISS 2017 in Passau

Posted by -karlos- on 3 April 2017 in German (Deutsch)

Passau, das ist doch die Gelegenheit, mal Leute zu treffen. Bisher war ich nur mal war ich beim OSM Treffen in Nürnberg, dagegen war Passau ein Kulturschock. In meinem "vorherigen Leben" hatte ich als Raumpatrouille-Fan schon einige Veranstaltungen besucht. OSM ist mindestens genau so kreativ.

Bei meiner Bastelei an “OSM go” hatte ich ein paar Kontakte geknüpft. Nun hoffte ich, einige Aktive persönlich zu sehen, vielleicht auch User, die Feedback zu OSM go geben. “3D-Rendern” währe doch ein Thema. Kaum getwittert, wurde ich überredet, das im OSM-Wiki vor zu schlagen und auch gleich als “Moderator” uh! In den Wochen danach wurde jeden Tag mehr oder weniger programmiert. “Muss das bis Passau fertig sein” fragte meine Herzallerliebste. Na ja, nicht wirklich; “fertig” gibt es bei sowas ohnehin nicht. Aber halbwegs Fehlerfrei währe schon gut.


Dann war es Freitag, die FOSGISS schon in vollem Gange und ab Mittag wurde ich unruhig, bin bald weg von der Arbeit und zum Zug. ICE ohne Platzreservierung erhöht den Abenteuerfaktor noch. Schließlich saß ich mit einem 2-Jährigen plus Vater an einem Tisch und statt Notebook und Code kneten gab es Gebabbel und Fingerspiele.

Mein erster Eindruck von Passau: Es ist nicht so flach, wie es auf OSM aussieht. Immer muß man über diesen Hügel in der Mitte und es gibt nicht mal einen direkten Fußweg zur Uni. Dort kannte ich zwar die Hörsaal-Nummer und dachte, wenn da überhaupt welche ‘rumlaufen, ist es der OSM-Event. Von wegen. Erst mal war Info-Wochenende für neue Studenten. Gut, die kann man doch von typischen OSM-Mappern unterscheiden: Männlich, älter, rumstehend und Plaudernd. Ich wurde auch schon vor der Tür nett begrüßt; ok war eine Verwechslung. Innen liefen welche mit Ausweisen am Gürtel ‘rum. Ordner? Ich fragte nach OSM und wurde in den Hörsaal gewiesen. Äh? Der Beamer verkündete einen Vortrag von Gregor Gysi! War das geplant? Nein, falsches Gebäude. Weiter laufen!

Das Gebäue IM kam noch, aber alles war ausgestorben. Hm, aus keinem “Kellerloch” schimmerte Licht. Im Untergeschoss in einem Raum voller Steckdosen und Netzkabel waren sie, die Mapper und setzen die Beute vom nachtmittäglichen Ausschwärmen durch die Stadt in Nodes und Ways um: in Gruppen vertieft in Details. Nach einigen Blicken über die Schulter auf Notebooks und Tabletts, meist mit laufendem JSOM, schaute doch mal jemand auf und so ergaben sich schnell ein paar erste Gespräche. Das steigerte sich, da “wir” in die Innenstadt zogen um gemeinsam zu Essen und zu Fachsimpeln. Da flogen mir Themen und Namen von Tools und Personen nur so um die Ohren. Oh man, Insider unter sich! Irgendwann konnte ich mich einhakten und meine Meinung beitragen, auch ein bisschen mit meinem “OSM go” angeben und schließlich auch Kontroversen austragen.

Schon seit Jahren finde ich nämlich, das OSM irgendwo bei Pixelgrafik stehen geblieben ist wo alle Firmen längst Vektor-Maps bieten. Da gab es natürlich Kontra: Das dauert 5 Jahre bis wir wieder das haben wie heute. Was soll das bringen, es gibt doch jetzt schon Layer zum auswählen. Die Dummuser können die Filtermöglichkeiten von Vektor-Renderern sowieso nicht bedienen. Als Plus galt höchstens, dass die OSM-Server entlastet würden, wenn Clients selbst rendern. Ja ok, das kann ich alles nicht beurteilen. Aber ich nutze fast täglich mein Smartphone mit einer OSM-Vektor-App (Pocket Earth) und finde es super, dass ich so lange zoomen kann, bis POIs sichtbar werden, die OSM.ORG nie zeigt. Das ich Bushaltestellen suchen kann, etcetera plus plus. Bitmaps, läuft, bliebt so; denkt man da nicht zu wenig innovativ? Gefühlssachen sind schwer zu diskutieren. Bei OSM hat der recht, der am meisten tut oder dessen Tools am meisten genutzt werden, hm? Also müßte "man" halt mal eine Vektor-Client Web-App angehen. Da ich das in “OSM go” irgendwie so ein bisschen ja schon habe, könnte ich … nein, nicht noch ein Projekt! Oder doch?

Irgendwann ging es um, äh, Area-Routing? Jedenfalls um Flächen, wo sie da und gut sind oder nicht. Der Schelm in mir mußte vorschlagen, doch nach und nach alles, alle Wege usw. nur noch als Flächen zu taggen. Gehsteige einzeln. Alles was als Linie unklar ist, läßt sich als Fläche definieren. Wobei man die Level/Stockwerke getrennt betrachten muss. Da war die Reaktion dann so wie “Utopist”, Streß für Routing aber auch: Dann ist endlich klar, dass man für den Wald die Nodes des Way benutzen kann :-)

OSMler sind Menschen die auch ohne (viel) Alkohol glücklich sein können. Der Abendplausch löste sich noch vor Mitternacht auf, man strebte seinem Hotel zu. Ich war im IBB Hotel (Der Rabat mit der DB-Karte war genau so gut wie der von der FOSSGIS), habe aber dort niemand von OSM bemerkt. Der Weg vom/zum Hotel ist nicht der kürzeste und geht natürlich über/auf diesen Hügel in Passau. Den Fußmarsch hatte ich als Ausgleichssport vorgesehen. Und mit OSM-Karte findet man auch die kürzeste Verbindung durch Seitengassen, and der Brauerei vorbei, oben links die Treppe bis zu der schönen Kirche, leider ohne “building:part", am Orion-Shop vorbei (Jetzt mit Fetisch verkauf) und hinein zum Nachtportier.

Brauche ich WLAN? Aber hallo! Das war überhaupt ein Phänomen bei der Reise: Über all hatte ich WLAN (ausser im Regionalexpress). Am Bahnhof 30 Minuten gratis. Im ICE, im Hotel: frei. Und in der Uni? Auch, na ja, man hätte früher da sein, und ein Formular ausfüllen müssen! Doch schon am ersten Abend wurde mir Hilfe versprochen und Samstags fand sich schnell ein “Reserve Login” für mich: Dank an den Spender. Dabei war die Un-Konferenz so persönlich und kommunikativ, dass WLAN garnicht nötig war. Das nutzte ich dann, zwischendurch und während der ganzen Rückreise, um in "OSM go” einen rudimentären Multi-User-Mode ein zu bauen. Ich hatte die Idee bei Gesprächen erwähnt und viel Zustimmung erfahren. Jetzt kann man andere Nutzer sehen, die an den gleichen Koordinaten die virtuelle OSM-Welt erkunden. Sogar wo andere hin sehen. Klar muss da noch einiges dazu: Chat, eine Einstiegs-Seite/Karte. Natürlich geht uns Freaks da die Phantasie durch. Jemand hat gleich Doom vorgeschlagen. Na ja, gehen würde viel, wenn sich Interesse und Tester melden.


Die Ankunft in der Uni war wieder schräg. Kaum auf dem Gelände plaudere ich mit jemandem. Aber auf OSM reagiert er kaum, hm, er hatte mich für einen Lehrer-Kollegen gehalten :-) Diesmal war das IM nicht verweist. Draußen, das Wetter war super, tippte einer in seinen Klappkomputer, drinnen schwirrte man hin und her. Ein junger Mann mit windigem Bart kam aus dem Hörsaal und rief “Kann hier jemand Kaffee kochen?”. Wie bitte? Er hatte noch nie, auch nicht getrunken. Na ja, Kaffeemaschinenerfahrung hatte ich, also bin ich mit ihm hoch in ein Hinterzimmer mit Doppel-Brüher. Trotz falscher Filtergrößen und fehlendem Messlöffel konnten wir uns auf einen Pulferfüllstand einigen. Mit dem Tipp, zu warten bis es nicht mehr tropft konnte ich dann wieder ‘runter und vor der Tür erst mal die Liste der vorgeschlagenen Themen gelesen. Ich steh’ da drauf, schluck! Zwei andere schleppten zwei Tische in den Saal, und hatten wohl auch sonst eine tragende Rolle. Tür aufhalten kann ich ja auch.

Es gab Butterhörnchen, Müslirigel, Obst; nett. An der Tafel Passau, groß als OSM-Karte, heute bin ich am richtigen Ort. In diesem Gebäude befindet sich die einzige Toilette Passaus, die unterirdisch getagt ist. Dann brach das organisierte Chaos los. Ein bisschen Resümee von Gestern, Mittagessensplanung, und wir das so geht heute. Jeder hat sich kurz mit OSM-Schwerpunkt vorgestellt, dann die Themen. Wer will bei was mitmachen. Die 6 nachgefragtesten Themen/Gruppen wurden auf Räume und Zeitslot verteilt. Ich bin erst zum “Area-Workshop”. Den Unterschied Old-/New-Style - Tags am Outer/Relation hatte ich augenscheinlich erlebt, als “OSM go” nur eins von zwei "gleichen" Gebäuden anzeigte. Tags setzt man ja immer total konsequent, systematisch … ja, ja. Als zweites “Lidar”: Ein 3D-Laserscanner für unterwegs, faszinierend. Am Quadrocopter könnte man Häuser und Dünen erfassen. Leider habe ich bei der Verlosung der Geräte verloren.

Passau WC - level=-1

Mittags gabs überraschenderweise schon wieder Pizza. Die habe ich aber sozusagen verpaßt, da ich total in mein Multi-User-Zeugs fokussiert war. Tagsüber gab es immer wieder spontane Gespräche. Es hat mich gefreut, das Tobias (OSM2World) da war. Wir 3D-Renderer hatten einiges auszutauschen. Ich staune immer wieder, was er da für Lösungen in seinem Code hat. Dann war mein Thema 3D-Rendern dran. Na ja, etwas holprig war ich schon. Wie bekommt man aus OSM-Tags die 3. Dimension herausgelockt? Gibt es Default-Renderebenen? Warum macht jeder seien Code? Wie kommt man am besten an die OSM-Daten. Das Thema Vektor-Tiles hatten wir ja Freitags schon. Das war dann auch mein eigenes spontanes Resümee am Ende: Egal ob 2D oder 3D, ein gemeinsames Tiel-Konzept währe schon gut: Bei Vektor braucht man weniges “Zoom”-Stufen aber alternative Tiles für Wichtige/Alle Daten. Da war doch schon was ...

Der Tag “beruhigte” sich dann. Von allen besprochenen Themen gab es kurze Zusammenfassungen vorbei viele Teilnehmer schon zu ihrer Rückreise aufgebrochen waren. Der Rest einigte sich für ein deftiges Abendessen auf den Bayerischen Löwen. Dazu gab es die letzten Anekdoten. Ja, in Passau kann man zu Fuß nach Österreich spazieren. Das man dabei am Bahndamm ‘rumgeistert um Daten von Signalen zu erfassen ist dann wieder OSM-freaky. Die Bahn-Nerds habe ich dann gleich angebohrt um Hilfe für die 3D-Darstellung von Signalen zu bekommen. Spät wurde es bei mir nicht da ich auch noch am MultiUser-Mode coden wollte.


Auch der Sonntag war ein sonniger. Zum Bahnhof ging es wieder auf direktem OSM-Weg über Hintertreppen. Passau bietet Abwechslung. Ein österreichisches Zollgebäude, viele "Man in Black” am Bahnsteig und im ICE, Grenzgebiet, “Betreten sie den Zug erst, nach dem die Beamten ihre Überprüfung beendet haben". Über den OSM-Event habe ich erst zuhause richtig nachgedacht. Würde ich wieder zu sowas fahren? Nein, zu ineffizient. Aber es war ja das erste Mal, die ersten Kontakte. Freunde wieder zu treffen kann “süchtig” machen. Mal sehen, wo was statt findet. Berlin währe gut.


Location: Innstadt, Passau, Niederbayern, Bayern, Deutschland

This Is How To Create Your Own Nest In Pokemon GO With A Free Tool Called “Open Street Map”

Posted by -karlos- on 13 March 2017 in English (English)

Owen Cun­ningham: "South West Coast Path"

Posted by -karlos- on 30 January 2017 in English (English)

Location: Minehead CP, West Somerset District, Somerset, South West England, England, United Kingdom

OSM go - Nodes und Daten (DE)

Posted by -karlos- on 9 January 2017 in German (Deutsch)


Es macht immer noch Spaß, "OSM go" zu verbessern und neue Funktionen zu ergänzen. Ein paar Zeilen Code dazu und Bäume werden sichtbar; und da sind wirklich viele Bäume in OSM. Die Hauptidee ist immer noch das Darstellen von OSM Daten. Eine echt realistische Darstellung mag möglich sein und kommen (viel) später (Als Teamwork mit OSMBuildings und OSM2WORLD, hoffe ich).

Wir haben ein Experiment gemacht: OSM2WORLD kann ein Gebiet als 3D Format “obj” exportieren. Und OSM go kann das anzeigen, auch Farben. Jan (OSMBuildings) exportierte einige Gebiete um zu Testen, ob sie als 3D-Tiles in einem Thin-Client genutzt werden können. Geht gut: Twitter-Post

Die Bedienung wurde völlig überarbeitet. Jetzt gibt es zwei Wege, sich zu bewegen und umzusehen, den 'Inspection-' und den 'Segway-Mode'. 'Inspection' ist default, Taste “C” wechselt den Mode. 'Inspection' geht so, wie man es von anderen 3D-Renderern wie OSMBuildings gewohnt ist: Mit den Tasten bewegt man seinen Blickpunkt, mit Maus oder Touch bewegt man die 3D-Welt.

Um alle Verbesserungen und Einzelheiten zu sehen kann man bei Twitter @OSM__go ansehen oder abonnieren. Um die neueste Version von "OSM go" zu testen gibt es die neue Web-URL . Da sieht man fast täglich Änderungen. Es ist eine Bastelecke! Es mag gehen oder abstürzen. Es gibt auch ältere Versionen zum probieren bei Und alle Informationen über “OSM go” sind auf der Wiki-Seite

Nodes & Daten

Die ersten Versionen von “OSM go” zeigten nur Wege und Flächen, keine lokalen Objekte. Aber jetzt ist die Oberpass-Abfrage erweitert um auch alle Nodes zu bekommen. Es begann mit einem Studenten der HSR Rapperswil. Er testete, wie schwer es ist, OSM2WORLD zu erweitern und 3D-Modelle von Tischen mit Stühlen zu ergänzen (amenity=="table”). Es lief gut, ich bekam den Code auch und änderte ihn zu Javascript. So wurde das erste OSM-Objekt in "OSM go" sichtbar. Das motivierte mich, eine kleine Lib zum erstellen um 3D-Typen zu schreiben, die von den Tag-Werten abhängig sind. Ich habe auch noch das beliebtere leisure=“picnic_table” eingebaut. Und dann auch "generator:source"=“wind”, der erste animierte Node-Typ. Aufregend einen Windpark zu sehen wo sich alles dreht.


Es gibt so viele verschiedene Node-Typen; viel zu viel Arbeit die alle in 3D zu bauen. Aber trotzdem sind jetzt (fast) alle Nodes sichtbar. Die meisten als rote Tetraeder. Es ist ein großer Schritt für das Ziel von “OSM go”, alle OSM Daten erreichbar zu machen. Ein Klick auf einen “roten Diamanten” listet alle Tags. Da sind jetzt eine menge Nodes zu sehen! Bei manschen ist Darstellen nicht sinnvoll:

  • Wenn es nur ein Level-Tag eines Wegs ist. Auch wenn es nur das tag “created_by” ist.
  • Es macht keinen Sinn "railway- oder highway-crossing” anzuzeigen, nicht war? Man sieht die sich kreuzenden Wege ja schon so. Was ist mit imaginären Objekten wie die Haltestellen von “public_transport”? Da wird ohnehin ein Busshalteschild sein. Mag sein, man will abstrakte “Geister-Objekte” sehen oder nicht. Dazu gibt es den neuen URL-Parameter “&abs=1”, Default ist aus.

Hie und da werden neue Nodes in 3D entworfen. Die Ersten sind da: “natural"==“tree” und “barrier"==“bollard”. Das war eher leicht. Eine Bushaltestelle wird schwieriger weile jedes Land seine eigenen Zeichen haben wird. Klar, die könnte man in einer “Datenbank”. Viel Arbeit. Erst werde ich die gleichen Symbole wie der 2D-Renderer nutzen.

Neulich konnte ich eine “power:substation” nicht finden, die ich schon mal gesehen hatte. Deshalb wurde ein URL-Parameter “&f=“ zum filtern/finden ergänzt. Tag-Namen und Werte und OSM-IDs werden geprüft. Die gefundenen Objekte können mit Nadeln markiert werden oder hervorgehoben durch Verblassen aller anderen Objekte. Schon beeindruckend (versuche “f=!surveillance”!). Und es ist wieder ein Schritt zur OSM-Datenhandhabung. Details stehen im Wiki.


Darstellen der dritten Dimension

Inspiriert von einer Zeichnung der Londoner U-Bahn wollte ich auch ein “in earth mapping”. Jetzt werden U-Bahn-Tunnel als “Röhren” dargestellt. Ich brauchte einige Tage des Versuchens, bis Stufen wirklich richtig im Raum auf und ab gingen. Es steht im Wiki: Stufen brauchen keine Level-Tags. Die sind durch die verbundenen Nodes oder Wege ohnehin festgelegt. Ein großes Problem ist die Bedeutung der Tags level und layer. Das könnte eine größere Diskussion unter uns werden. Um auch unter die Erde zu sehen, ohne per Tastatur “abzutauchen”, an man den experimentellen URL-Parameter “&sub=1” nutzen.


Was ist, wenn für ein Gebäude keine Höhe definiert ist? Es gab einen Defaultwert von 6m. Aber jetzt wird das errechnet; je länger der Grundriss je höher. Das ist immer noch geschummelt, sieht aber viel besser aus als ein einheitlicher Wert. Andererseits: Wie kann man sehen, ob einem Gebäude Höhe und Stockwerke fehlen. Jetzt gibt es noch einen URL-Wert “&hei=“ mit dem man den Wert selbst setzen kann. Probiert man “&hei=0.5”, sieht man den Unterschied deutlich (Sieht aus wie bei "Pokemon GO” :-)

Der Kampf mit der Render-Zeit

Jede Verbesserung pflegt die benötigte Tender-Zeit zu verschlechtern! Mein Wissen zum Optimieren ist begrenzt, will jemand helfen? Glücklicherweise braucht man zum Darstellen von OSM-Daten die Gebäude nicht bis zum Horizont. Weniger Einzelheiten (LOD) bei entfernteren Tiles wird fällig, bei Gelegenheit. Zusätzliche Zeit braucht das Nachladen von Tiles im Hintergrund. Das wurde schon mehrfach überarbeitet und wird es auch weiter.

Wie auch immer, die Bedienung von "OSM go" wird fies, wenn man zu viele Objekte und größere Flächen angezeigt werden.

  • Mit Shift-L wird neu geladen, aber nur die nähere Umgebung.
  • Mit der Taste H werden das dt zwischen Frames und die Frames pro Sekunde (fps) aktuell und geglättet, sichtbar.
  • Die Darstellung von Schatten abschalten kann helfen: “&sha=0”.
  • Um die FPS über 5 zu halten wird die FAR-Plane reduziert, entfernte Gebäude und Straßen verschwinden. Die Grenze von 5 kann man ändern oder auf 0/aus setzen mit dem URL-Parameter “&fps="

Was kommt?

Erste Schritte zu einem echten Tile-Handling; löschen von Tiles ist notwendig. Die fps müssen stabil sein, damit die Tastaturbedienung geht. Vielleicht wird ein “3d Person View” besser verdeutlichen, wie ein Anwender sich in der 3D-Welt bewegen kann. Der Cardboard-Mode ist in Arbeit: Kopfbewegungen sollen Richtung und Geschwindigkeit steuern. Die Datenanzeige muss bei Smartphones größer sein.

Ich bin mir nicht sicher wie ein Anwender sich fühlt. Sollte was geändert werden, verbessert, ergänzt? Ich bin für jeden Kommentar dankbar. Bitte testet, schickt mir Bildschirmfotos von euren Lieblingsplätzen. Sagt mir was euch stört oder gefällt.

OSM go - Nodes and Data (EN)

Posted by -karlos- on 9 January 2017 in English (English)


It’s still fun to improve "OSM go" and add new features. After adding some lines of code, and trees get visible; and there are really a lot of trees in OSM. The main idea still is visualising OSM data. A really realistic view may be possible and may be done (much) later (As teamwork with OSMBuildings and OSM2WORLD, I hope)

We made an experiment: OSM2WORD offers to export an area as 3D format “obj”. And "OSM go" is able to show this, including colours. Jan (OSMBuildings) exported some areas to test, they may be used as 3D-tiles in an thin client. Works fine: Twitter-Post

The controls have been reworked generally. Now there are two ways to move and look around, the 'Inspection-' and the 'Segway-Mode'. 'Inspection' is default, use the key “C” to change the mode. 'Inspection' is what you know from other 3D renderers like OSMBuildings: By keys, you move your point of view, by mouse or touch, you move the 3D world.

To see all improvements and details, drop by or follow Twitter @OSM__go. To test the latest version of "OSM go", use the new web URL There you will see almost daily changes. Its work under construction! It may work or just crash because its also my online test sandbox! You may try older versions at And all information to “OSM go" is on the wiki page

Nodes & Data

The first versions of "OSM go" only showed ways or areas, no POI. But now the Overpass query is extended to get all nodes to. It startet by an student of HSR Rapperswil. He tested how hard it is, to extend OSM2WORLD to add 3D models of ‘’’tables’'' with chairs (amenity=="table”). It worked fine and I got the code to, rewrote it to Javascript and so the first OSM object was visible in "OSM go". It motivated me to write a small library to create 3D types dynamically by the actual OSM tag values. I also also added a more popular OSM node leisure==“picnic_table”. Because I was on holiday at the seaside at that time, I also added "generator:source"=“wind”. This is now the first animated node type. Exiting to visit a wind park and see them all spinning.


There are so many different node types, to much work to build them all in 3D. But anyway, now (almost) all nodes are visible, mostly by a read tetrahedron. It is a big step to the goal of "OSM go", to make all OSM data accessable. Klick on a 'red gem' to get all the tags listet. There are quite a lot of nodes visible now! For some, it is not really useful to show them:

  • If it is only a level tag of a way, it will not be visible. Also if it is only a tag "created_by"
  • It doesn’t make sense to show a railway- or highway-crossing, does it? It is visual by the ways crossing anyway. What about imaginary objects like stop positions of “public_transport”? There may be a busstop sign anyway. You may want to see this abstract “ghost objects” or not. User the new URL parameter “&abs” to decide, default is off.

Now or then, types of nodes will be designed in 3D. The first are realised: “natural"==“tree” and “barrier"==“bollard”. That was rather easy. A busstop will be more difficult because each country may have it’s own sign. Sure, they could all be put in a “database”. Much work. Firstly I will use the same symbols as the 2D renderer.

Reasendly I did not find a power:substation, which I had seen before. So an url parameter “&f=“ for filter/find was added. It checks tag names, values and OSM ids. The found objects may be marked by spikes or exposed by dimming all other objects. Quite impressing to use (try “f=!surveillance”!). And it is again a step to OSM data handling. See the Wiki for details.


Rendering in the 3rd dimension

Inspired by a drawing of the London underground I wanted to make some “in earth mapping”. Now the subway tubes are visible as such. It took me a few days of trying until the steps were really correct going up and down in 3D. It is written in the Wiki: Steps don’t need level tags. Levels are defined by the connected nodes or ways anyway. A big problem is the meaning of the tags level and layer. This could get us into an extended discussion. To see under ground without “diving down" by the keyboard commands you may use the experimental URL parameter “&sub=1"


What if a building height is not defined? There was an default by 6m. But now it is calculated by the footprint of the building, the bigger the more height. This is still incorrect but looks much better than an unique value. On the other hand: How do I see, if a building lacks height and levels? Now there is another URL value “&hei=“ to set your own unique height. try “&hei=0.5” and you will see clearly the difference (looks like in "Pokemon GO” :-)

Fighting the render time

All that improvements used to increase the needed render time! My knowledge to optimize this is limited, anyone like to help? Luckily, to show OSM data, it is not necessary to show Buildings till the horizon. Less level of details will be done for remote tiles eventually. Additional time is needed to download tiles in the background. That has been reworked some times already and will be again.

Anyway, the handling of SOM go may get nasty, if many objects and greater areas are shown.

  • Press Shift-L to reload the scene with only the local area.
  • Hit the key H to see the dt between frames and the frames per second (fps) actual and as less or more average.
  • Switching of the shadows by “&sha=0” may help a bit.
  • To keep the FPS above 5, now the far-plane will be reduced, remote buildings and roads will disappear. You may set this limit even to 0/off by the URL parameter “&fps="


First steps to a real tile handling; deleting tiles is necessary. The fps must be stable to keep the keyboard handling running. May be a "3rd person view” will clarify how a user may move in the 3D world. The Cardboard-Mode is under construction: Head twist should control direction and speed. The data display must be more large for smartphones.

I am not sure about the user experience. What should be changed, improved, added? I would apprichiate any feedback. Please do a test, send me screenshots of your favourite places. Tell me what you dislike or enjoy.

OSM go on - Colours, Models and Shadow (EN)

Posted by -karlos- on 26 November 2016 in English (English)

Work is in progress, features are improved and added. See the OSM Wiki page for more details and read some background infos below.

There is an Twitter-Feed: @OSM__go (two underscores!). You may follow the latest activities, upcoming ideas and related things.

Tile processing

Overpass seemed to be slow but my measurement was wrong because Javascript even delays console.log while callback code is running. A close inspection showed: Overpass is great, my code with a lot of string copy was slow and is now replaced by jQuery.js and getJSON. Much better, much faster but there was still that “wait-cursor”. Again it was me. I had simple linear searches for already existing nodes or ways. I replaced them by arrays with the OSM-ID as index. Odd to debug but fast. Now, the default load radius is set up to 800m and still fast. Or fine, if you are in a dense city. Old hardware devices may have trouble and get slow. Now the download will stop.

Thats was not the end. I move the tile/tag decoding and the 3D object placing (not yet parseJSON) away from the callback into the render cycle, sliced in fast steps. Now, the default load radius is set up to 800m and still fine in a dense city. Old devices may break downloading. And you may even move already during the download. - One more thing: The first load will be more slow than thereafter of curse - because of the just in time compiling.

Overpass gives an array of elements, first all node-types, then all ways etc. “parseJSON" can only convert this to an single array with mixed types. Is this good? Building tags may be placed at ways or relations(multipoligon). Decoding code would be the same. So it may be good to have all types in one array. But OSM does not have ONE set of IDs!

What about an “overparseJSON" ?: It should convert to separate arrays, one for notes, ways, and relations. It shouldn’t be hard to morph the jquery-code. And there could be a callback for each node, way, etc. So I could immediately extend the node- and way-instances to my needs like adding the three-ja-mesh.


Even if the shape of buildings are fine, paint makes them more realistic. Handling the tags building:colour and roof:colour was easy. Chroma.js does convert the color tag strings and Three.js ExtrudeGeometry also handles different colours for the sides and the ends. So after 10 lines of code and 1-2h test it was done. But soon Murphy's law strikes back: There are quite a view named colours, not known form three (see wiki). Tags like light_brown or yellow-brown may be handled automatically. But what about spelling errors and unknown colours? That may be a task for the validators like Keepright.


Jan (OSMBuildings) asked me, how fast Three handles shadows: about 20% more rendering time. When you start now, the place around that point has shadows. To show the effect even more, a big disk flies over you. There are still some shadow options to investigate. In the Code, a virtual camera is placed at the shadow casting light. Mostly the graphic card is doing the hard work. This “camera” analyses the shapes, if they cast shadow and if this shadow is seen by the “real” camera. A greyscale bitmap is generated and placed between before the virtual world. Looks good. Todo: move the virtual with the real camera.

Placing Modells

For quite a view buildings, extruding doesn’t make much sense, especially for famous buildings like churches or monuments like the Eifel Tower. There are 3D-models of many of them. To place them in a virtual 3D OSM world doesn’t help for data visualisation but for an realistic view. And it’s cool anyway, if you move around by mouse or with VR glasses.

What to render: Where to store and get the model files?

  • I like the Idea of, but its offline :-( I got in contact, may be we will have the files and set up them on a new server and even extend the service to other formats.
  • Meanwhile I did the two models, OSMBuildings uses. (They are not perfect yet)
  • OSM2WORD and other 3D-viewer seems to have a lot. Who do the to that?
  • What about Google Scetchup? I will try to get and dynamically convert all the models. Three.js does have loaders for many file types, that seems to be no limit. But I am sure there is a copyright prohibiting a use.

How to place: My first answer to the following questions was an OSM relation for each model to place with special tags.

  • First the model file. The concept of OpenBuildingModels is great. A reference to an external server with the file. (server-code, model-name/ID and may be file type.
  • The model may be directed correctly already or we need a tag to do it, useful if a model is used more than once.
  • There may be a tag for scale to, and even a hight-offset.
  • Now we need the place. if there is no existing node to reference to, it has to be placed.
  • Usually there is one ore more building-ways in OSM, representing the building in a 2D map. They have to be removed/skipped by the 3D renderer. So wee need a reference list to them. The solution used by OpenBuildingModels is simpler: One Tag with Server and Model. No direction, size and height. And this tag is added to each building to be replaced by the model. I like that.

Other changes

  • The debug output now shows the FPS (add &hud=1 to the url) Disappointing: 40 down to 10 FPS with 3D models displayed. Strange: it doesn't feel slow.
  • Added new URL parameter: “&keep=1 or 0 for show/don’t Keepright error markers. Default is don’t
  • Level & Layer: Underground objects shouldn’t be seen above, bridges should be raised. Now the tags level and layer are used.
Location: Holborn, St Giles, London Borough of Camden, London, Greater London, England, WC1B, United Kingdom

OSM go - 3D Render? (DE)

Posted by -karlos- on 24 October 2016 in German (Deutsch)

Die Verbesserungen an “OSM go” gehen weiter. Ich war schon stolz, das der OSM Wochenbericht es erwähnt hat. Die Handhabung and Bedienfunktionen sind jetzt brauchbar. Es gibt Tasten- und URL-Befehle. Das Rendering kennt jetzt building levels und Geleise. Der erste “Layer” ist enthalten: Keepright. Es ist motivierend, alle Fehler zu beseitigen, die in der 3D-Welt markiert sind. Eine Objektauswahl zeigt Tags an.

Und gibt es das in einem anderen Programm oder Service: OSM rendered in Stereo zum Ansehen in Google Cardboard? Mit OSM go kann man durch die virtuelle welt von OSM lauen oder Fliegen.


Alle Details stehen auf der OSM-Wikiseite für OSM go. Da stehen auch alle Einzelheiten zu den enthalten Teilfunktionen und deren Entwicklungsstand. Und am Ende eine ToDo-Liste.

Der 2D render Kode war ja nur ein erster Versuch. Ich wollte einen fertige Komplettlösung einsetzen. In den letzten Wochen suchte ich, fand aber keine Lösung. Da sind wirklich viele 2D-Renderer und durchaus einige für 3D. Nur einige nutzen Javascript und ich fand nur einen der das Framework Three.js verwendet. Unglücklicherweise sind die meisten Rendern kommerziell, auch wenn der Kode open source ist. Der Client zumindest. Oft sind wichtige Funktionen wie die Analyse der OSM Tags auf einem Server versteckt. Die benutzen alle einen 2D-Layer als Grundlage, Brücken sind nicht im 3D raus platziert, wie ich es möchte. Es ist fast unmöglich, alle Webseiten von so vielen Projekten zu lesen, die Werkzeuge und unterstützten Funktionen zu analysieren. Ich würde dazu gerne eine Tabelle als Überblick haben, vielleicht auch machen. Ein guter Anfang ist die Wikiseite für 3D_development.

  • Erst hatte ich ein Auge auf OSM2WORLD geworfen. Es bietet eine immer realistischere Ansicht, weniger Darstellung von Daten, wie ich das beabsichtige. Es verwendet Java. Ich erinnere mich an Etwas, mit dem man das unter Javascript laufen lassen konnte. Vielleicht verwende ich auch einfach die Logik wie die Tag-Analyse.
  • Das Nächste war OSMBuildings. Verwendet Javascript aber nicht Three.js sondern direkt WebGL. Ich hatte gute Gespräche und Mails mit dem Macher, Jan. Wir überlegten sogar eine Neuimplementierung mit Three. Wir suchen weiter einen Weg zusammen zu arbeiten. Aber Malbox scheint die bessere Lösung für Jan zu sein.
  • Dieser Tagen hat Mapbox einen 3D-Service vorgestellt. Deren Renderer nutzt auch direkt WebGL.. Die Tiles sind binär codiert, den Inhalt kann ich nicht sehen.
  • Da ist nur ein 3D-Rendere, der Three nutzt, soweit ich weis: vizicities. Ich sehe nicht viel davon weil die Motzen Tiles, die genutzt werden offline sind. Ich versuche, das zu aktualisieren.

Wegen des kommerziellen Karakters der Projekte habe ich bedenken. Wenn ich was dazu baue können sie es merken und meine Kontrolle darüber weg, sie könnten ihren code inkompatible zu mir ändern. Und wenn der Tile-Server zu viel macht, kann ich nicht tun, was mir im Sinn ist. Letztlich ist es auch schwer in den Haufen Kode einzusteigen. Daher habe ich beschlossen, die Suche zu beenden und meinen einfachen Renderer zu verbessern, solange es Spaß macht. Die Meisten Renderer versuchen eine möglichst realistische Szene zu zeigen. Das Ziel von "OSM go” ist es nicht, perfekt zu sein sondern die OSM Daten als abstrakte, dynamische Ansicht zu präsentieren; mit Zugriff auf alle Tags und Daten. Und Daten zu editieren! Deshalb werden die nächsten Schritte das auswählen von Objekten und erste Edit-Funktionen sein. Um Anfängerfehler zu vermeiden denke ich an Edits zur 3D Visualisierung wie Gebäudehöhe und Dachtype.

Ein anderes Ziel von OSM go ist, mit neuen Funktionen zu experimentieren, z.B. ein Weg, sich durch die virtuelle welt zu bewegen. So hat sich die Bedeutung von “go” geändert, vom “wie Pokemon” zu “gehe umher in OSM und experimentiere mit den Daten”. Ein Expeiment wird ein “Skagway-Mode” für 3D-Brillen sein. Vielleicht Avatar zu andere Anwender virtuell zu treffen um miteinander zu “sprechen” und zu editieren. OSM go begann als ein diffuse Spielende. Die erweiterte sich zu sowas wie “kann alles”. Aber die Idee, die OSM Daten durch Spielende zu verbessern ist noch da. Eine fehlende Hausnummer zu ergänzen, bringt Punkte. Ein Spieler erwartet ein Spielerlebnis mit Highscore, Wettbewerben, Preisen und motivierende animierte Effekte. Ich würde gerne solche Sachen programmieren. Aber ich brauche Hilfe, vielleicht ein Künstler und Designer um das ganze Gameplay zu entwerfen.

Der Code ist noch im Anfangsstadium, manchmal fehlerhaft und nicht mit allen Geräten getestet. Bitte probiert es und berichtet wie es war, was gut war, wars seltsam. Was sollte geändert werden und wie. Fehlen Funktionen oder möchte jemand was spezielles ausprobieren? Betrachtet OSM go als Spielwiese. Macht einen Entwurf und ich baue es vielleicht ein. Gibt es Funktionen, die ihr bei euch einbauen möchtet? Ich würde gerne helfen, es ein zu bauen.


OSM go - 3D Render? (EN)

Posted by -karlos- on 24 October 2016 in English (English)

The improvements of “OSM go” are going on. I was quite proud, as the OSM weekly mentioned it. The handling and the control is usable now. There are keyboard- and URL-commands. The rendering includes building levels and train tracks. The first “Layer” is included: Keepright. It is motivating to clear the errors, marked in the 3D world. A object selector does show its OSM tags.

And did you ever see this in any tool or service?: OSM, rendered in stereo, to see it in a Google Cardboard? OSM go enables you to walk or fly through the virtual world of OSM


Read all details in the OSM-Wiki page for OSM go . There you will also find details to ongoing component states and rendering details. And a todo list at last.

The 3D rendering code was only a preliminary attempt. I wanted to use an existing renderer out of the box. In the last weeks I was no search but did not find a solution. There are really a lot of 2D renderer and even quite a view 3D renderer. Only some use Javascript and I found only one using the framework Three.js. Unfortunately, most of this renders are comertial, even if the code is open source. The client part at last. Often, important functions like OSM tag analysis are hidden in the tile server. They all use a 2D layer as Basis, bridges are not placed in the 3D space as I intend to have. Its almost impossible to read all the pages of so many projects, analyse all the supported features of all tools. I would like to make/have an overview as a table. A good start is the Wiki page for 3D_development.

  • First I had an eye on OSM2WORLD. It offers a more and more realistic view, less data visualisation as I intent. It is written in Java. I remember a framework to run Java in Javascript. May be I just could take the logic like tag analysis.
  • Next was OSMBuildings. Using Javascript but not Three.js but WebGL direct. I had some nice talk and mailing with its creator Jan. We even considered to do a re-implementation with Three. We still try to find a way to work together. But Mapbox seems to be a better place to go for Jan.
  • This days, Mapbox announced its 3D service. Their renderer also uses WebGL directly. The Tiles are binary and kind of a blackbox to me.
  • There is only one 3D render using Three, as far as I know: vizicities. I can’t see much there because the Mapzen tiles it uses are offline now. I will try to update it.

Because of the commercial character of the projects, I do have my doubts. If I add features, they may merge it out of my control, they may change their source incompatible to my code. And if the tile server does to much, I will not be able to do what I have in mind. At last, ist's a hard point to get into a big bunch of code. So I desided to stop my search and improve my simple renderer as much as long as it will be fun. Most renderer try to show a more or less realistic scene. That's not a aim of OSM go to become perfect, but do present the OSM data as a abstract, dynamical view with access to all tags and data. And to edit the data! That's why the next steps will be data and object selection and first edit features. To avoid bad newbie edits, I think about edits, related to the 3D visualisation, like building height and roof type.

Another aim of OSM go is, to experiment mit new features, i.e. a way to move through a augment or virtual world. So the meaning of “go” changed from “as Pokemon" to “go around in OSM and experiment with the data”. One next experiment will be a “Segway-Mode” for 3D glasses. May be avatars to meet other users virtual, chat and edit together. OSM go started as a diffuse gameplay idea and extended to something to “does anything”. But the Idea to improve the OSM data by players is still there. Add missing house numbers to get points, why not. A player will expect an experience with high scores, competitions, batches and motivating optical effects. I would love to code such things. But I need help, may be an artist and designer to develop the whole gameplay.

The Code is still in a beginning state, buggy sometimes, not tested with all devices. Please try it and tell me, how it went, what was nice, what was odd. What should be changed and how. Are you missing a feature or would like to try something special? Think about OSM go as a sandbox. Make a draft and I may implement it. Do you like a feature for your project? I would love to help to include it.


Salt Lake City as trainigs area for "OSM go"

Posted by -karlos- on 1 September 2016 in English (English)

Funny: The Apple Store had one corner with doubble Nodes, causing an error in my software.

Location: Marmalade District, Capitol Hill, Salt Lake City, Salt Lake County, Utah, 84150, United States of America

OSM go Earth - Fragen

Posted by -karlos- on 29 August 2016 in German (Deutsch)

Es gibt auch diese Woche etwa zu berichten ;-) Es geht voran, zu langsam und doch zu schnell: Zu schnell geht es, weil meine Begeisterung mein Restleben und den Nachtschlaf beeinträchtigt. Zu langsam weil das Testen mit Javascript eine Qual ist per „Console.Log“, am Smartphone gar nur „alert“. Gibt es ein gutes Framework mit Beakpoints?

OSMgo Greenwich

Was hat sich getan: Erst muss ich mal erwähnen, dass ich schon lange mit einem Freund zusammen 3D-Javascript bastle. Martin hat mir mal eben den Download mit AJAX und das Scannen des OSM-JSON gebastelt. Da konnte ich dann meine „new Node“ usw. eingehängt – schon wurde, statt ein paar Test-Daten, ein echter Ausschnitt aus OSM sichtbar, siehe Bild-Kommentar zum letzten Post. Es waren erst mal nur Highways und Buildings. Für die Tag-Auswertung war ein Konzept notwendig; jetzt gehen schon einige Tags mehr (leisure, waterway, landuse) aber immer noch rudimentär. Die „higway“s verschieden breit, Farben später. Bei „power“ war es erst mal Spaß, an jeder Node einen kleinen Mast auf zu stellen und diese dann mit Leitungen zu verbinden. Das auch „building“s zusätzlich „power“ haben können zeigt, dass die Main-Typen eine Priorität haben: Wenn das Tag „building“ da ist, ist „power“ ein Sub-Typ bzw. Detail-Info zum Gebäude. Gibt es eine Beschreibung der Logik des Renderns, als Text oder Pseudo-Code?

Lustig war auch, dass mein Code gleich den Fehler Tag-Array-Länge-Null geschmissen hat. Da ist tatsächlich ein recht lange Way ohne Tags in meiner Nachbarschaft. Darf ID das? Kein Felhler: die Tags sind an der Relation zu der der Way gehört: Ein Wasserschutzgebiet.

Meine 3D-Darstellung ist eher plakativ als realistisch, um die Flächen-Typen zu verdeutlichen. Es gibt Kartenstiele, die Farben etc. festlegen. Eine habe ich gefunden. Wäre es gut, wenn ich die einlese und alles „genauso“ darstelle? Gibt es fertigen Code, um diese Dateien ein zu lesen?

Demnächst will ich mir bei OSM2WORLD (und Cartagen) ansehen, wie die das machen, um so zwischendurch auch den Renderer zu verbessern. Von OSM2WORLD habe ich einen YouTube-Vortrag gesehen, sympathischer Knabe :-)

Auch GPS ist inzwischen angezapft; so wird schön die eigene Umgebung als dargestellter Abschnitt ausgewählt. Noch sind die Lauf- und Zykluszeiten harmlos. GPS und Overpass-Abfrage dauern da länger. Zum Testen ist es oft besser, GPS und AJAX durch Dummies zu ersetzen, läuft schneller und erzeugt keinen Stress für Overpass, das nicht immer schnell läuft. Es ist ja auch nicht als „Arbeits-Server“ gedacht. Für das Gaming/3D-Surfing wird irgendwann eine eigene Server-Instanz notwendig sein. Ob Overpass der richtige Vektor-Tile Server ist? Gibt es bessere? Von OSM selbst?

Wie bei 2D-Karten üblich kann man auch hier beim 3D-Rendern zusätzliche Infos als „Layer“ einbauen, als Erstes „Keep Right“. "“ macht das ja auch (in 2D). Bei kort kann ich das API und den ganzen Ablauf erkunden, sogar in Javascript! Welche Layer sind noch gut? Wikipedia, GeoCashing, OpenStreetView, welche Wünsche habt ihr?

Eine Gamification ist (fast) auch nur ein Layer. An einem Samstag habe ich ein simples Game eingebaut: Um die GPS-Position, an der der „Spielers“ OSM go startet, schwebt über jeder Node eine Kugel. Kommt man näher als 15m wechselt sie die Farbe, schwebt hoch und verschwindet. Und man bekommt 100 Punkte :-) Dazu reichen 65 Zeilen Code; natürlich alles roh und ohne Luxus. Ich habe aber mal zwei Level-Intros erdacht:

  • Du bist Packman! Schnapp dir all gelben Punkte um zum nächsten Level zu kommen.
  • Das Reich der Feen kannst du nicht sehen. Die Kamera deines Smartphones sieht mehr! Deine Fee hat goldene Kugeln für dich verteilt. Geh hinaus und suche sie alle, dann wird die Fee sich bei dir melden. Gehe nicht auf die Straße! Die Kugeln spüren dich und kommen zu dir.

OSM go Packman

Hier kann es jeder ausprobieren: (

Ich suche Pilot-Tester! Wer macht mit?

Ich habe nur mit iPhone Notebook getestet! Was geht bei Android? Es sind noch einige Render-Fehler enthalten, da geht’s hin wenn die Control geht.

  • Beim Smartphone sollte sich beim Drehen die Umgebung 1:1 grob wieder finden (plus Kugeln über den Nodes). Und beim Laufen sollten sich OSM-Darstellung und Realität synchron verschieben, soweit GPS genau ist. Auf zum Punkte sammeln!
  • Am Notebook kann man mit der 1. Maustaste drehen, mit der 2. Sliden und mit dem Rad zoomen.

Und wenn garnichts geht, neben den Bildern gibt es hier auch ein kleines live Video.

Mit GPS, JSON und "Packman" ist das „proof of concept“ eigentlich getan, jetzt müssen die vielen Feinheiten dazu, damit es sich ein Programm/Spiel nennen darf. Und die Grobheiten: Bedien-Funktionalität, Level usw. Zunächst bin ich dabei aus diversem Code einen eigenen Control basteln müssen. Bisher ist das Handling noch dürftig. Es soll ja mit Key, Maus und Touch genehm; am PC, Tablett und Smartphone; ohne und mit 3D-Brille; Bewegung frei oder per GPS; laufen, schweben, fliegen übergangslos hoch bis es in eine 2D-Ansicht über geht. Der Anwender soll selbst entscheiden, wie er Packman spielt oder Hausnummern sucht. Er soll auch einstellen können, bei welchem Zoom-Level was eingeblendet wird.

Eine 3rd-person ansieht wie bei Pokemon GO wird es natürlich auch geben. Aber keinen Körper-Editor sondern eine Symbol-Figur. OSM hat kein Plüsch-Maskottchen, oder? Eine Symbolfigur die jeder kennt, das für bewegen über die Erde steht. Ich denke da an einen lustigen Zugvogel. Andere Vorschläge?

OSMgo top

Google Earth ==> OSM Earth (EN)

Posted by -karlos- on 12 August 2016 in English (English)

No, I dod not cancel, “OSM go”, I extended the idea. But first, thank you for the suggestions. At first, the reactions was limited, after a week it got nice.

After I postet that PSM-go, I spend a day to take snippets of old code of mine. And at night, I had that first 3D-View. It enthused me so much, to have a sleepless night, my imagination running wild: Walk through OSM in 3D (not that discouraging Pokemon style, something tidy), overlay data, not only walk but “fly”; thats why I used the term OSM-Earth. Sure, more layers with external- / realtime data are possible. May be switching to 2D mode.

Actual I am fighting with JavaScript Orientation-Controllern (the compass is wrong using Android), someone may take over this. Contributors are welcome anyway, not only by writing code. Also advice, what frameworks exist. I.E: If I got JSON by AJAX, how to convert the OSM data to Javascript arrays and how to index the node ids?

Actual, everything exists already; renderer in 2D and 3D, gamification with OSM improvements. Demotivating? Well - it’ fine, if one has les to do himself. However, its quite difficult to dig into stacks of alien code. And often, only the solutions may be usable because it is not Javascript.

  • A running gamification (in 2D):
  • A Renderer in Javascript (2D): Cartagen
  • A 3D-Renderer (java,static):
  • Ingress, the “precursor von PG" OSM based:
  • Other tools to motivate editing: Mapillary, OSMand and Maps.ME.

With edits there are a lot of doubts because newbies shall do it. I like the idea, this edits to go into a pool, used by “real” OSMer, loaded in an editor and verified.

What next? Just things I will have fun with :-)

  • First get JSON data around the actual position by Overpass. So “real” things will be visible, not dummy nodes etc. That will motivate to show more and more details in 3D.
  • The handling of moves are improvable for sure. A Cardboard mode will come. Gi by keyboard&mouse, touch gestures or VR gadgets to any place and view angle on Earth.
  • And the first “gaming”; just real (GPS) walks will give first point. By personal experience, I think, gather house numbers will be a niche first useful action.

Below a view of my first rendering, an OSM-like style. At the German post, I will append an style, as close as possible to the Pokemon map style. And if you like to test it yourself (without guarantee): or as OSM-style: It works with keyboard, mouse, touch and device turning, but still petting.

(Do I really need to translate my German posts? Anyone interested? Is there a way to only offer automated translation, I would prefer to code)

OSM style rendering

Google Earth ==> OSM Earth (DE)

Posted by -karlos- on 12 August 2016 in German (Deutsch)

Nein, “OSM go” habe ich nicht gecancelt sondern die Idee erweitert. Aber erst mal Danke für die Anregungen. Die Reaktionen waren zunächst mäßig, nach einer Woche dann schon schön.

Nach meinem Go-Post habe ich einenTag lang einige Teile aus alten Code von mir zusammengeglaubt und hatte abends schon eine erste 3D-Ansicht. Was mich so begeistert hat, das mir einer schlaflosen Nacht die Phantasie durchgegangen ist: In 3D OSM durchwandern (nicht der abschreckende Pokemon-Style, was gescheites), Daten einblenden, nicht nur Laufen, auch “fliegen”; daher jetzt der Begriff “OSM Earth”. Klar sind dann weitere “Layer” auch mit Echtzeitdaten möglich. Vielleicht auch ein Wechseln zur 2D-Ansicht.

Derzeit kämpfe ich noch mit den JavaScript Orientation-Controllern (Der Kompass stimmt bei Android nicht) das kann gerne jemand Übernehmen. Mithelfende kann ich brauchen, nicht unbedingt nur zum Code schreiben. Aber auch Beratung, welche Frameworks es gibt. Zum Beispiel: Wenn ich mit AJAX JSON habe, wie konvertiere ich die OSM-Daten zu Javascript-Arrays und wie Indiziere ich die Node-IDs?

Eigentlich gibt es ja schon alles; Renderer in 2D und 3D, Gamification mit OSM-Verbessern. Demotivierend? Och - ist doch gut, wenn man weniger Arbeit hat. Allerdings ist es sau schwer, sich in einen Haufen fremden Codes einzuarbeiten. Und oft kann man nur die Lösungen nehmen, weil es kein Javascript ist.

  • Eine laufende Gamification (in 2D):
  • Ein Renderer in Javascript (2D): Cartagen
  • Ein 3D-Renderer (java,statisch):
  • Ingress, der “Vorgänger von PG" auf OSM Basis:
  • Andere Tools, die zum Editieren Motivieren: Mapillary, OSMand and Maps.ME.

Bei Edits gibt es viele Bedenken, da es ja Neulinge sein sollen. Mir gefällt die Idee, das diese Edits in einem Pool landen, die dann “echte” OSMler in ihren Editor laden und prüfen.

Wie geht es weiter? Immer das, was gerade Spaß macht :-)

  • Als nächstes gedenke ich von Overpass JSON-Daten der eigenen Position zu holen. Dann werden “echte” Sachen dargestellt, statt Test-Nodes Etc. Das wird motivieren, immer mehr Details auch in 3D darzustellen.
  • Die Bewegungsmöglichkeiten sind verbesserungswürdig. Ein Cardboard-Mode kommt dazu. Mit Tastatur&Maus, Touch-Gesten oder VR-Gadgets “Bewegen” zu jedem Blickpunkt der Erde.
  • Und erstes “Spielen”; schon echtes (GPS) ‘rumlaufen gibt erste Punkte. Aus persönlichem Erleben halte ich das Erfassen von Hausnummern für eine gute erste nützliche Aktion.

Hier ein Bild meines erstes Renderns, möglichst nahe am Pokemon-Kartenstiel. Einen OSM-Like-Stiel hänge ich an den englischen Post. Und wer es selbst ausprobieren möchte (ohne Gewähr): oder als OSM-Stiel: Die Bedinung geht mit Tasten, Maus, Touch und Drehen, ist aber noch recht fummelig.

OSM-go Pockemon-Style

Pokemon Go ==> OSM Go (EN)

Posted by -karlos- on 31 July 2016 in English (English)

Who did have the same association at once? One will get some ideas. Now eyes closed and then write down your ideas please. Gamification of OSM, als a helper to promote OSM as a useful every day tool. But not only this, the data base should also participate.

“If you have visions, see the doctor” Helmut Schmitt, German Chancellor. - A “OSM GO” is not a mini app, just plugged together in a minute. A server has to run, the handling should be DAU prove and appealing, the function understandable. That needs more than two enthusiastic coders until at last some basic level will run.

Wether the idea is nicked, anyone may note. Pokemon Go also is a mix of known elements: Collecting coins outdoor is done long way back. Augment reality too (I am irritated because Pokemon Go doesn’t use ist all the time)

The OSM-GO client may (at first) be a browser-app. 3D visualisation done with WebGL/Tree.js, Javascript On-Events to catch the moves and direction of the smartphone. As we don’t have an Javascript OSM render engine, this is, by the way, also a chalange.

There is still the question about the game play. Just do start, we also may do OSM-useless point collecting: Any healthy walked step counts, find and goto hydrants and water dispenser. If the player likes, he may set himself and its walks visible, virtual to all other players.

Really fun comes up with OSM-useful things: Check wether a shop, contained in OSM, still exists; the older the last verification the more points you get. Verify, update or insert tags of the shop. Note new house numbers. Is a way really a dead end or did the first mapper run out of time/enthusiasm? Enter new POI or even totally new ways.

At that moment OSM, data get changed, it gets critical and needs verifying. A lot helps a lot: If three player claim the same, it will be rather correct, and only now, it will be taken over to the OSM data. To collect more gameplay ideas and features there then may be a page in the OSM wiki.

Is all this a vision only or feasible? I don’t see any technically obstacles. If it runs fine, OSM will provide server capacity. The biggest OSM shortage is human contributors, organiser and coder. I would be part of it (references: )

And finally: Is there common interest to play this kind of “game”, anyway?

(This is my own limited translation of the German original text)