Nakaner has commented on the following diary entries

Post When Comment
Idea of issue tracker for tagging scheme over 1 year ago

I mostly agree with @Sanderd17's posting.

I think we do not need such a platform. It will just spread discussion and data users which are not familiar with OSM will think that their posting will make all mappers to change their tagging behaviour. But OSM is different. YOU CAN TAG WHAT YOU WANT.

BushmanK worte:

I am aware of difference between software development and OSM tags you've mentioned. However, there are certain mechanisms in OSM, which depend on "community approval" (even if it's not about formal proposal procedure). To get into editor presets, translations, Wiki, converters and so on, tag should be supported by developers of editors and converters, by translators, by Wiki editors.

If you want to deprecate a tag, you have to make all relevant data users (mainly renderers and routing engines) to drop support of that tag (i.e. if you want to weaken a specific waterway tag, you have to make OpenSeaMap drop its support).

Proposals and all that discussion stuff may express that some people think that a tag is good/bad/should be called "deprecated".

I hope, you already know this OSM wiki template and its users.

Fahrstühle... over 1 year ago

Ich sage nur eins: Mentz DV.

Wie gut sind die Öffnungszeiten in meinem "Revier" erfasst? over 1 year ago

Hallo zarl,

mittlerweile verwende ich Overpass QL statt Overpass XML für meine Abfragen. Hier mal die obige Abfrage in Overpass QL:

out body;
out skel qt;
        { color:red; fill-color:red }

        { color:blue; fill-color:blue; }

Wenn du noch das Datum der letzten Änderung abfragen willst, musst du vor dem ({{bbox}}) noch ein (changed:"2012-09-14T07:00:00Z") einfügen. Siehe dazu auch die Doku im Wiki.

Manifesto for the OSMF Board, 2015 almost 2 years ago

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

Analyse des Open-Data-Angebots der DB almost 2 years 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 almost 2 years 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 almost 2 years ago

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

Units in OpenStreetMap almost 2 years 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 almost 2 years 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 almost 2 years 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 almost 2 years 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 almost 2 years 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 almost 2 years ago

Hallo martinum4,

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

Wieder Garmin almost 2 years 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 about 2 years ago

Hi Mateusz,

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

Best regards


Stammtische und Berlin im Detail about 2 years 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 about 2 years 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 about 2 years 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 about 2 years 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 about 2 years 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)