Nakaner has commented on the following diary entries

Post When Comment
Manifesto for the OSMF Board, 2015 6 days ago

Don't forget to answer the questions at the wiki.

Analyse des Open-Data-Angebots der DB 11 days ago

Im NE-Bereich scheinen noch ein paar Probleme zu schlummern. Zwar ist die Liste bei der Albtal-Verkehrs-Gesellschaft (Stadtbahn Karlsruhe/Heilbronn) schon deutlich aktueller – Stationen, die in den 90er-Jahren bei den Umbauten auf Stadtbahnbetrieb neu eingerichtet wurden, sind enthalten, aber an einer Stelle fällt mir die Zuordnung schwer:

RLSS Langensteinb.Er.
RLBB Langensteinbach
RLSB Langensteinbach

Was davon ist jetzt ist jetzt Langensteinbach Schießhüttenäcker, Langensteinbach Bahnhof und Langensteinbach St. Barbara?

Aber die Umbenennung von Ettlingen Freibad in Ettlingen Albgaubad fehlt. Die DB kennt diesen Bahnhofsteil/Haltepunkt noch als "Ettlingen Freibad". Die Umbennung scheint mindestens fast zwanzig Jahre her zu sein.

Auch bei den Haltestellen der Verkehrsbetriebe Karlsruhe (Straßenbahn Karlsruhe) scheint die Zeit stehen geblieben zu sein. Seit dem 18. November 2013 ist der "Südabzweig" Marktplatz–Poststraße gesperrt, mittlerweile sind Teile davon restlos entfernt. Dennoch kennt die Liste noch die Haltestelle "Marktplatz (Pyramide)", welche heute mitten in der Baustelle liegt.

Überlappende Gebäude in Osmose bzw. in .de bzw. in OSM 15 days ago

Frankreich dürfte deshalb sauber sein, weil es sich dort um "professionelle Geodaten" :-) handelt. Die haben ja fast alles importiert, was sich importieren lies.

bot user accounts 16 days ago

malenki, your first link at your last comment does not work. The correct one is:

Units in OpenStreetMap 23 days ago

As long as the OSM data contains a unit if it is not an SI unit, it is no problem. You just have to look if there a non-digit characters at the end of the value string. If yes, you check which unit the mapper used and use the correct conversation factor. If no, you can just treat the number as a metric (default) unit and convert it into a float or integer.

There could only be one huge problem: If the default unit (the unit without a unit at the end of the value) varies from region to region. If width=6 were feet in UK and metres in France, it would be a problem. But luckily, UK mappers are good mappers and add mph if the use miles per hour.

If am writing a data conversation tool from OSM data into another very common data format at work. I just had a look how those non-SI countries tag maxspeed and width and choose which units I will support.

You will also get this problem if you have a look at the common maxspeed=* values. Does Graphhopper support maxspeed=RO:urban? My tool does.

Reverse Engineering von Fahrscheinentwerter-Nummern about 2 months ago

@MKnight: level=* fehlt nicht. indoor=yes ist jedoch nicht getaggt, weil ich es dort falsch fände. Sie werden erst auf Zoomstufe 20 gerendert. Das ist auch gut so, weil sonst wären manche Stationen vor lauter Entwertern nicht mehr sichtbar.

Data issues in Japan about 2 months ago

@PlaneMad: your descriptions about the state of Japanese road data at OSM really sound like a second TIGER import – misalignements, wrong topology, wrong tagging and no active community.

I have looked through the archives of Imports mailing list in 2011 and I have NOT FOUND any discussion about this import. The Import Guideline said following about the pre-import discussions in 2011 (note that the guideline has been reformated in April 2012):

Discuss your import on the mailing list and/or with appropriate local communities. Many local communities have their own wiki pages and/or a Mailing lists.

It does not clearly say that you must contact imports mailing list. Nowadays (since April 2012) it looks like this:

Discuss your plan. Email the OSM community to notify them of your plans, including a link to your wiki page. You can do this with an email to (at a minimum), talk-(your country), and the OSM group specific to the the area directly impacted by the import.

The import also has some other issues:

  1. There is no English documentation. The whole documentation is in Japanese. The English wiki page just contains four sentences. This has to be fixed.
  2. According to the imports catalogue, Yahoo Japan offered "ex-used map data", i.e. old data they could not use commercially any more. I think that this the reason why this import should not have taken place. OSM is not a dumping ground for outdated and bad commercial geospatial data! Companies should use /dev/null if they do not need their data anymore.

From my point of view, the quickest and most sustainable solution would be a deletion all the roads which have not been modified after the import (i.e. partial revert of the import). If the import discussion had been taken place at Imports list and its data had been reviewed, this import might have taken place in a different way and might have been much slower. The history tells us that countries with large and quick imports do not have the powerful community to maintain their data. Just have a look who much edits take place in urban US areas and urban areas in UK or German speaking countries.

It looks as the Japanese community imported the data because they the Great Earthquake took place on March 11, 2011. Nowadays, humanitarian needs (HOT) can not be used as a single argument to import bad data into OSM. You cannot get an approval at Imports mailing list for a bad import even if a humanitarian crisis took place at the area of the import and HOT became active there.

Data users like Mapbox can still use the deleted data in their maps and products because it is free (ODbL-licensed) but the community should not suffer under the bad data as the U.S. community does/did.

Reverse Engineering von Fahrscheinentwerter-Nummern about 2 months ago

In Karlsruhe Hbf rendert OpenLevelUp! als einzige mir bisher bekannte Anwendung Entwerter. Warum in Berlin-Hermsdorf die Entwerter nicht gerendert werden, ist mir noch nicht klar. Da müsste ich in den Quellcode von OpenLevelUp! schauen.

Average highway node distance between 2 points in OpenStreetMap - September 2015 2 months ago

I think that a line plot as you used is not the best way to visualize your data. Such diagrams are good for plotting a variable y which is a function of a variable x. A set of bar diagrams (one per road class with one bar per continent) would be better.

You have the data. Could you just plot it again?

Mappen mit dem Deutschlandpass – Schlafplätze bei Mappern gesucht 3 months ago

Hallo martinum4,

danke für dein Angebot. Aber unsere Tour ist schon seit dem 24. August vorbei.

Wieder Garmin 3 months ago

Hallo zut,

verrätst du uns noch, ob es sich um einen Vista HCx oder Legend HCx handelt? Seit wann war er in Betrieb?

Viele Grüße vom Wochennotizteam


New road style for the Default map style - the full version 4 months ago

Hi Mateusz,

I really like your improvements, especially your huge use of service=* on railway tracks.

Best regards


Stammtische und Berlin im Detail 4 months ago

Wenn ihr derzeit (d.h. seit ihr im Resonanz seid) durchschnittlich nur auf gut 6 Besucher pro Stammtisch kommt, ist das für die Größe Berlins eigentlich erschreckend wenig. Karlsruhe, das nicht mal ein Zehntel eurer Einwohner hat, hat gefühlt im Schnitt genauso viele Teilnehmer. Liegt das vielleicht daran, dass der Karlsruher Stammtisch eine Abspaltung der örtlichen LUG war? Oder liegt das daran, dass in Berlin die Wege aufgrund der Größe Berlins so weit sind, dass manchen der Weg zum Stammtisch zu weit ist?

Vielleicht schaue ich ja bei eurem nächsten Treffen vorbei.

Mapping turn lanes in OpensStreetMap 4 months ago

It is no good idea to use relations for turn lane mapping. Roads are very often touched by newbies. Newbies use iD and/or have no knowledge (iD does not help them to get it) about relations.

I hereby strongly suggest neither to use the plugin you promote nor to use relations for turn lane mapping!

Starting up again 4 months ago
  • Get offset on Bing maps sorted out.
  • Get plug in to handle .gml files available from land registry (INSPIRE index polygon data.)

Data imports must be discussed! See Import Guidelines.

  • Work out how to get more layers such as electoral boundaries , district council boundaries etc.

OSM may not be the right location for electoral boundaries.

  • Find out about adding photos to the map

New road style for the Default map style - the first version 5 months ago

I would prefer red junction names.

pnorman wrote:

Is switching from blue motorways necessary? I realize that blue doesn't cleanly fit into a yellow orange red scheme, but it's unfortunate to lose a color which currently doesn't conflict.

There is already a conflict! Motorway blue looks similar to water blue.

I had a client who got rendered OSM maps (the Carto-like style of Maperitive) for printing. He asked me first to change the motorway blue to orange because it looked better.

From car driver point of view, there is less difference between a trunk and a motorway. By default, trunk have no speed limit in Germany (like motorways). The only differences are shorter curve radius and smaller lanes. That's why rendering of motorways and trunks should be similar.

New road style for the Default map style - the first version 5 months ago

I agree with your decision on rendering trams only at zoom 12+ as a railway fan (and co-developer of OpenRailwayMap). I have had a look on tram lines which go kilometres out of their city, e.g. Gotha–Tabarz.

If you go to change rendering of trams, you should also have a look at rendering of light rails (railway=light_rail). Light rails often run near roads (or between the two carriageways). Especially in Germany, we have multiple cities where light rails serve the job of trams, e.g. Stuttgart or Frankfurt (Frankfurt has two separate systems a partially over- partially underground light rail and a tram network). (trams are pink, light rails green, undergrounds blue, orange/black/brown/yellow/red are heavy railway tracks, tunnels are brighter)

Natural Atlas + OpenStreetMap 5 months ago

Your Terms of Service state:

Geographic location data (latitude, logitude coordinates) from Natural Atlas cannot be used commercially without explicit written concent from an employee of Natural Atlas. If you're interested in this data, please email *****

From my point of view "cannot be used commercially without explicit written concent" is not compatible to OpenStreetMap data license.

  1. You cannot forbid me to vectorize map data from your map.
  2. If your users place the markers based on an OpenStreetMap-based map, these positions are covered by the share-alike of Open Database License.
Häuser zerschneiden… 6 months ago

zarl schrieb:

Lustiger finde ich diesen Kreisel ein paar Meter weiter in der Krummen Strasse auf einem Parkhaus, der anscheinend von einem Bot erstellt wurde. Wie kontaktiert man den denn?

Der User ist kein Bot, der heißt bloß so. :-) Außerdem sollte jeder Bot auf PNs und Changeset-Kommentare reagieren oder wenigstens auf seiner Profilseite den Account seines "Kommandanten" angeben, den man dann anschreien kann.

Stirbt Talk-de? 7 months ago

@derFred: Ja, da hast du Recht. Ich überlege gerade bloß, ob ich das tun soll und mal wieder "in ein Wespennest stechen" [1] soll.

[1] ein altgedienter OSM-Aktiver hat das kürzlich zu mir in einem anderen Zusammenhang gesagt. :-)