I agree with BushmanK and want to point out that there is still a map which automatically transcribes non-Latin characters into Latin (and abbreviates common suffixes like “street”, “Straße”, “улица”).

https://github.com/giggls/openstreetmap-carto-de

https://www.openstreetmap.de/karte.html?zoom=14&lat=54.10505&lon=54.1215&layers=B000TT

https://www.openstreetmap.de/karte.html?zoom=16&lat=43.75437&lon=142.39123&layers=B000TT

Please discuss your tool with the OpenStreetMap community on the Talk mailing list before your first upload of a changeset using this tool!

MiroJanosik wrote: > it is not good to do paper-walk mapping in cold weather, your fingers freeze off :)

You should buy a hybrid glove. I use them for mapping and professional surveying (as a surveyor).

U-Turns are forbidden at road crossing Borsigstraße/Heilbronner Str. in Stuttgart if you come from Friedrichswahl because there is a restricted area painted on the street. http://www.gettingaroundgermany.info/zeichen2.shtml#mark

That’s why u-turns are prohibited here but allowed here (coming from Plieningen doing a u-turn back to Plieningen). There is a no-passing line (road centre marking without gaps) painted after the traffic island at node 1.

Turn restrictions can be implicit in Germany.

Does/Will OSV offer a dump of all its photos available for download via HTTP or Torrent (like the OSM planet dump)? Or is it a data grave similar to Mapillary? (I have read at your blogpost that I can remove my data, but I want to get all photos of OSV) :-))

imagico schrieb: > Dass die Vorträge interessant und ein recht vielfältiger Mix waren dem kann ich zustimmen - wenngleich wie üblich recht wenig zu praktischen Mapping-Themen dabei war.

Aus dem Themenbereich war auch kaum etwas eingereicht worden. Vielleicht einfach das Konferenz-unter-der-Woche-Problem?

imagico schrieb: > Ich denke aber, dass von OSM-Seite das Format durchaus eine Menge Verbesserungspotential hat. Sowohl was dem OSM-Sonntag betrifft (der sowohl von den Räumlichkeiten als auch von der Programmgestaltung meiner Meinung nach nicht ganz ideal war - gab zu wenig Raum für vertiefende Gespräche und Diskussionen) […]

Möchtest du das ein wenig genauer erläutern? Hättest du dir andere Programmpunkte und mehr Raum für Diskussionen gewünscht?

Hallo R0bst3r,

hast du meinen freundlichen Kommentar in den falschen Hals gekriegt? changeset/40358864

Viele Grüße

Michael

The JOSM interface is extremely user-friendly and easy-to-use.

Usually people claim the opposite. Are you used to use GIS or CAD software or other drawing tools?

JOSM is a fast editor if you have your left hand at the keyboard (mainly A and S key but also X, Q, W and B) and the right hand at your mouse. JOSM is a veryyyyy slow editor if you always use the mouse to switch between drawing and selection mode instead of typing S/A.

Du bist gerne eingeladen, eine Wochenaufgabe dazu zu organisieren. Schreib einfach eine Mail an das Wochennotizteam. Den Rest klären wir dann per E-Mail.

Ich selbst zeichne nur noch selten von Luftbildern Gebäude ab, weil mir das Rausgehen mehr Spaß bereitet. Deshalb bin ich dazu übergegangen, Hausnummern nur als lose Nodes zu mappen, wenn es noch keine Gebäude gibt (zum Abmalen braucht man keine Ortskunde). Die setze ich dann mit Vespucci draußen. Dieser schlägt einem sogar oft passende Hausnummern vor (der Button mit dem Hausnummern-Icon).

Unter einer gewissen Temperatur braucht man dazu Handschuhe wie diese: http://www.hutx.de/handschuhe/handstulpen-fingerlose/p8924_halbfingerhandschuhe-handschuhe-ohne-finger-anthrazit.html Ich kaufe sie aber meist auf dem Weihnachtsmarkt. Als ich noch als Vermesser gearbeitet habe, hielt ein Paar meist einen Winter, danach war es verschlissen/kaputt. Klettverschlüsse sind hier Knöpfen zur Befestigung der Fingerkuppenkappe vorzuziehen.

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.

Ich sage nur eins: Mentz DV.

Hallo zarl,

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

[out:json][timeout:25];
(
  node["shop"]({{bbox}});
  way["shop"]({{bbox}});
  relation["shop"]({{bbox}});
  node[amenity~"^(restaurant|pub|bar|fast_food|food_court|ice_cream|cafe)$"]({{bbox}});
  way[amenity~"^(restaurant|pub|bar|fast_food|food_court|ice_cream|cafe)$"]({{bbox}});
  relation[amenity~"^(restaurant|pub|bar|fast_food|food_court|ice_cream|cafe)$"]({{bbox}});
);
out body;
>;
out skel qt;
{{style:
    https://wiki.openstreetmap.org/wiki/Tag:node[opening_hours!=.],way[opening_hours!=.]
        { color:red; fill-color:red }

    node[opening_hours],way[opening_hours]
        { color:blue; fill-color:blue; }
}}

http://overpass-turbo.eu/s/d5J

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.

Don’t forget to answer the questions at the wiki. osm.wiki/Talk:Foundation/AGM15/Election_to_Board

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? osm.org/#map=15/48.9155/8.5108

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.

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

malenki, your first link at your last comment does not work. The correct one is: http://resultmaps.neis-one.org/newestosm.php

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 https://wiki.openstreetmap.org/wiki/Key:maxspeed values. Does Graphhopper support https://wiki.openstreetmap.org/wiki/Tag:maxspeed=RO:urban? My tool does.

@MKnight: https://wiki.openstreetmap.org/wiki/Key:level fehlt nicht. https://wiki.openstreetmap.org/wiki/Tag: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.

@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 [email protected] 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) [email protected], talk-(your country)@openstreetmap.org, 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.