Micromapping?

Hmm, interessant :wink:
Eigentlich sperre ich mich nicht gegen solche Informationsklassen. soweit ich weiß hat noch niemand über Autokennzeichen nachgedacht.

Viele Grüße,
Marek

sorry, hatte den Smilie vergessen - ich halte das für absoluten Blödsinn.

Zur Klarstellung:
Diese Informationen gehören nicht in OSM weil sie:

  • sich zu schnell ändern
  • Überladen die Karte mit unnötigem Balast
  • Zu detailliert für die Ziele der Community sind.

Richtig?

Ja, und weil es privat Infos sind.

Richtig: dazu kommt noch die Sache mit den Wunschkennzeichen - noch nicht einmal eine Geo-Information könnte man aus den Kennzeichen ableiten. Und dann gibt es auch noch Firmenwagen (*).

Gruss
walter

*) ach was war das herrlich, als ich mit Wiesbadener Firmenwagen-Kennzeichen in Essen die Sau rauslassen konnte - kannte mich da ja nicht aus :wink:

ich schmeiss die heute Abend wegen Datenschutz (*) raus (erst dann, damit man sich das noch ansehen kann).

Ok?

Gruss
walter

*) Osm muß unbedingt vor solchen Daten geschützt werden - oder hab ich da was falsch verstanden? :wink:

*) Jemand muß den edlen Ritter auf dem weißen Ross spielen.

Nun - denke ich mir jetzt - wäre es vielleicht sinnvoll aufzuschreiben, was und aus welchem Grund wir in OSM **NICHT ** haben wollen?
Es könnte vielleicht dem einen oder andern User behilflich sein. Ich denke nicht, dass es jemand in böser Absicht machte, aber solche Fälle wird es immwe wieder geben. Da wäre es gut auf eine solche Wiki Seite hinzuweisen…

Dabei ist mir etwas unwohl. Meine Befürchtung: Sobald so etwas niedergeschrieben ist, finden sich auch Leute, die die “Regeln” als in Stein gemeißelt betrachten und ihren Wortlaut ohne Sinn und Verstand durchsetzen. Siehe Wikipedia, wo aus einem simplen “was Wikipedia nicht ist” die vielfach kritisierten Löschhöllen und ausufernden Relevanzkriterien entstanden sind.

Es ist zwar anstrengend, so etwas immer wieder von neuem zu erklären und zu diskutieren. Aber dafür fällt beim erneuten Diskutieren leichter auf, wenn die ursprünglichen Begründungen für die Regel nicht mehr stimmen.

Also etwas für Blumenbeete wäre schon schön. Es gibt ja teilweise auch größere Flächen von Tulpen- oder Rosenbeeten.

So wie Chris66 schrieb:

man_made=bedding, bedding=flowers. Finde ich richtig gut.
Vielleicht könnte jemand das in einem Proposal vorschlagen?
Oder ist es zu klein dafür? :wink:

Viele Grüße,
Marek

Für größere Flächen ok.
Aber bitte nicht die einzelnen Blumen mappen :wink: (das wäre echtes micromapping).

Ich habe ein weiteres “Problemchen”.
Wie tagge ich eine Fläche in der Stadt, die ursprünglich mit Gras bewachsen, momentan aber völlig ausgetrocknet und eher ein trockener Lehmboden ist.
Solche Flächne sind kein landuse=brownfield weil es dort nie Etwas stand. 'Es ist auch kein landuse=greenfield, weil solche Flächen des ofteren zu klein sind, um dort Etwas zu bauen (oder es sind z.B. eben ausgetrocknete Flächen zwischen Plattenwohnhäuser) .
es ist auch kein natural=sand, denn es ist ein harter, ausgetrockneter Boden:
Etwa wie ein Unterschied zwischen einer Parkplatzfläche und umliegenden Felder.

Aus dem Bauch heraus würde ich es dem Sinn nach als landuse=dry soil beschreiben - vertrockneter Boden.
Siehe: http://static.ebobas.pl/img/articles/419/124818041261-w602.jpg

Was glaubt ihr?

Ich finde, nicht jedes Fleckchen muss ein eigener landuse sein. Da reicht doch surface=ground + area=yes.

Jetzt unter der Annahme, dass “momentan” ein etwas längerfristiger Zustand ist und nicht “weil es mal zwei Wochen nicht geregnet hat”. :wink:

Stimmt, es ist kein Landuse, es ist eher surface.
Und wir haben auch surface=dirt.
Problem gelöst.

edit:
da war ich zu spät

Siehe #34. Landuse ist eine Sache, die Beschaffenheit des Bodens eine andere.
Es ist also landuse=residential aber die Flächen dazwischen kann man zusätzlich beschreiben.
Viele Grüße,
Marek

Ich war am Grubeln bei einigen Wegen die innerhalb einer Stadt grenzwertig zwischen footway und pedestrian sind.
Die Definition in der Wiki ist momentan so:

.
Ich finde (insbesondere in großen Plattenbausiedlungen) Wege wo ich mir unsicher bin, ob sie schon pedestrian sind oder nicht.
Daher würde ich vorschlagen, dass man auf jeden Fall als Pedestrian Wege erfasst, die zwei PKW Parkplatzbreiten breit sind. Vorteil: Bei den meisten Luftbildaufnahmen in der Stadt sind Autos zu sehen und in sehr guten Luftbilder gut erkennbar. Wir können auch davon ausgehen, dass die Luftbildqualität steigt.

Ich denke man sollte das Wort Fußgängerzone nicht übersehen. Das hat in DE und anderen Ländern eine feste Bedeutung und wird mit einem Verkehrsschild (in DE #242) signalisiert. Das kann man aus einem Luftbild nur selten genau erkennen. Ohne örtliches Wissen geht da wenig.

Ich verwende pedestrian nur dort, wo es auch so ausgeschildert ist.
Wege zwischen Wohnblocks sind entweder Zufahrtswege (highway=service + service=driveway) oder Fußwege (highway=footway + ggfs. foot=designated, falls so beschildert). Oft sind Wege breit genug für PKW oder Kleintransport, dann würde ich das Tagging auf die hauptsächliche Verwendung abstellen. PKW regulär (für Anwohner) erlaubt dann highway=service oder nur als Ausnahme (z.B. schwere Gegenstände) geduldet dann highway=footway.

Es gibt oft Hinweise, die für Fußwege sprechen. Da wären Stufen oder scharfe Knicke im Verlauf. Ein kleiner Versatz ist bei den Planern oft beliebt. Der Fall Parkplatzwege (service=parking_aisle) ist ja im Luftbild in der Regel aufgrund der markierten Parkplätze / abgestellten Autos gut zu erkennen.

Mein Fazit:

  • pedestrian nur dort wo es ausgeschildert ist (oft frühere Straßen/Gassen).
  • footway wenn schmal oder regelmäßige Autonutzung nicht erkennbar ist.
  • service wenn eine regelmäßige Autonutzung erkennbar ist.
  • Unterschied nicht an der Breite festmachen.

PS:
Ausgeschilderte Fußgängerzonen sind innerhalb von Wohnbebauungen eher selten. In der Regel sind das eher breite Fußwege für z.B. vier Personen nebeneinander. Die Angabe von width=* mag in vielen Fällen nützlich sein. Ach ja, highway=pedestrian sollte in der Regel von einem Namen begleitet werden.

Edbert (EvanE)