We should map what is the reality. In some jurisdictions the numbers mark an entrance, in others they are assigned to an area (usually a parcel or a building). It is not always clear where the number applies to, if in doubt, use a node, but if you know the exact area a housenumber applies to it is better to put the number on this area. Using areas has the advantage that you can see the actual extension and you can infer the number for the included elements/occupants.

you have a good point when you mention that actually almost nobody can release his contributions into the PD, because it will most likely be tainted by the existing ODbL data around it (exceptions might be editing in an empty area or surrounded by other PD data)

Bitte nicht blind Verbindungen herstellen, wenn Ihr die Stellen nicht kennt. Es gibt auch viele Stellen, wo man im echten Leben nicht durchkommt, zumindest nicht mit dem Auto, oft aber auch nicht mal zu Fuß (unterschiedliche Höhenebenen). Klar, das ist dann nicht besonders detailliert gemappt, wenn da nur 2 nicht verbundene Straßen sind und nicht z.B. ein Fußweg, ein fence, eine retaining_wall, etc. aber ohne Ortskenntnis geht das halt nicht. Falsche Verbindungen sind genauso schlecht wie nicht verbundene Straßen, die eigentlich verbunden gehören.

how many points did you measure? I fear that the differences aren’t simple offsets but more complex, due to the way this imagery is produced.

Nice tutorial, but it’s not working only with flickr, basically you can use any image sharing platform, my favorite is 23hq.com which let’s you download the full versions of your images also after you stopped paying (it’s 20EUR a year for unlimited access or free for 30 uploads a month). You can also bulk download all images (or a subset), their API is the same as Flickr’s (or as Flickr’s was some time ago).

areas should not share nodes with highways, because the highway is representing the center of the road, and its borders are only implicit (add half the width to the center line), while areas are drawn at their real limits, so they shouldn’t have common nodes with the center of highways. If you unify them it reduces information and makes further editing more complicated.

Please don’t unify adjacent landuses, when there is a gap in between them i.e. the gap is there in reality because there is a way or path or scrub, a waterway, sand or something else that isn’t a field in the case of landuse=farmland). You are removing details that convey information. The landuses should share nodes if the have a common border (or better use multipolygons in case the shared way has more than very few nodes).

IMHO streets should not have a landuse (or should have an explicit street-landuse). This is also how reality deals with this: streets are not part of the parcel land, they are usually land that is not part of a parcel.

lass Dich nicht abschrecken, einfach mal abwarten und weitermachen (oder woanders wenn Dir das dort nicht mehr gefällt), eines Tages wird man den Wert noch erkennen, auch wenn man lokal Dein Engagement nicht schätzt, die Welt dankt Dir!

I agree with Pieren, and I extend the critics: it seems to be a license infringement not to quote the license of the data (this is a requirement of both, cc-by-sa and ODbL). Also the wording does not contain a “copyright” or © sign, so our data contribution to their maps is basically quoted as if it was PD.

If the current licensing terms are a problem for mashups then this could be addressed by the mechanisms that the CTs installed: a vote by 2/3 of the active contributors. Nobody, not even the board of the OSMF, has the right to change the license (or sublicense under different terms) by other means.

Es ist nicht ganz eindeutig sicher, was die beste Methode ist, um Hausnummern und POIs zu erfassen. Die POI-Tags ans Gebäude zu hängen hat mehrere Probleme. Zum einen ist oft nicht der komplette Gebäudeumriss POI (dann wäre es falsch, die tags dort unterzubringen). Zum anderen ist das Gebäude was anderes als ein darin enthaltener POI (Nutzung). Von daher finde ich es nicht schlecht, wenn man diese beiden Objekte logisch trennt. Sonst ist bei vielen tags überhaupt nicht klar, worauf sie sich beziehen, z.B. start_date, name, operator, etc.

Bei Hausnummern wäre das beste (m.E.), das komplette Gebiet damit zu taggen, wo die Nummer gilt, d.h. in Deutschland oft das Grundstück (ist allerdings nicht bundeseinheitlich geregelt). Innerhalb dessen müsste man eigentlich nicht nochmal die Adress-tags wiederholen, es erleichtert aber vielen einfacheren Tools die Auswertung, wenn man es trotzdem tut.

Solange die Information richtig ist wäre es unnötig und sogar ein bisschen schädlich (unnötige Server-/Datenbanklast), diese doppelten Informationen wieder zu löschen, wenn man sie zusätzlich auf dem POI (node) getaggt hat (und dieser Node innerhalb der Fläche ist, die dieselben Adressinfos enthält). Wenn der POI allerdings durch eine area beschrieben ist, sollte er eher keine zusätzlichen (doppelten) addr-tags haben (m.E.), vor allem wenn die beiden areas nicht deckungsgleich sind, weil sonst ggf. unklar ist, wo die Adresse gilt, oder ob ein Fehler vorliegt.

Soweit bin ich mir Dir einverstanden, dass man Objekte trennen sollte, die nicht zusammen gehören, z.B. ein Haus von einem Restaurant. Auch nutze ich selbst meist Punkte für POIs. Ich halte es aber nicht für falsch, im Gegenteil für besser, einen POI ebenfalls als Fläche zumappen, sobald er eine gewisse Ausdehnung erreicht (die Grenze sehe ich ungefähr bei 1 m², d.h. Briefkästen oder Bankautomaten sind Punkte, Telefonzellen sind an der Grenze und was größer ist wird mit einer Fläche besser repräsentiert als mit einem Punkt).

Man kann übrigens die Objekte schön trennen, indem man nicht alle tags an den gleichen Umriss setzt, sondern pro Objekt auch in OSM ein Objekt verwendet (es bietet sich hier multipolygon an, das geht auch mit einem outer way ohne inner ways).

I also agree with you Pieren. Dynamic visibility of buttons should be opt-in not opt-out. I guess it might also be quite confusing to new mappers if the UI presents itself "dynamic" for the key features.

Schade, dass Du zu diesem Schluss gekommen bist, vielleicht überlegst Du es Dir ja nochmal. Kontaktieren finde ich auf jeden Fall richtig, auch wenn es etwas Mühe macht. Löschen und wiederzeichnen ist keine Option sondern Vandalismus. Ggf. sollte man solche Leute auch der DWG melden, wenn dahinter System steckt. Ohne konkrete Links bzw. Objekte ist es natürlich schwer, hier was zum konkreten Fall zu sagen.

Besides the legal aspects it is OK if the local mapping community agrees to the import and finds the imported data useful, suitable, accurate and up to date. If there is no local community to maintain that data it might be better not to
import it.
To get a better general impression what many people think about
imports and their impact on the project and on the community, see the
panel discussion that took place some weeks ago at SOTM-EU in Vienna:
streaming:
http://matterhorn.zserv.tuwien.ac.at/engage/ui/watch.html?id=Unscheduled-lecturetube-ei7-1310828485866
download:
http://sotm-eu.org/videos/ImportsPanel.ogg

Please also see the Wiki what the community expects how automated edits should be performed:
osm.wiki/Import/Guidelines
osm.wiki/Automated_Edits/Code_of_Conduct

Fürs Aufzeichnen von Tracks für OSM sind dedizierte GPS-Geräte m.E. weitaus besser geeignet als Smartphones. Neben der deutlich längeren Akkulaufzeit ist auch die Lagegenauigkeit i.d.R. viel besser. Derzeit gibt es lediglich bei den dedizierten GPS-Geräten lediglich für GARMIN Geräte Karten, da deren Format reverse engineered wurde, und vermutlich ändert sich an dieser Situation auch so schnell nichts. Persönlich würde ich ein Gerät ohne Touch-Screen bevorzugen, da man mit dedizierten Tasten m.E. viel besser und schneller navigieren kann (z.B. auch ohne hinzusehen) als mit dem Touch-Screen, aber das sind evtl. persönliche Vorlieben.