Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 5. Apr 2018, at 16:38, Florian Lohoff  wrote:
> 
> Es gibt keine Notwendigkeit das jeder quadratcentimeter zu einem landuse
> gehören muss.


+1, es wurde das Konzept vorgestellt eine „allumfassende Initial-Fläche“ (kein 
Zitat) zu teilen[1] und weiterzuteilen usw., ich sehe OSM eher so, dass man im 
„Nichts“ kleine Dinge ablegt. Punkte oder kleine Gebiete, die man dann 
gemeinsam beschreibt und anpasst. Diese „Dinge“ können sich da durchaus 
überlappen. Aus dem Verhältnis der Dinge zueinander ergibt sich nach und nach 
die Karte.


Gruß,
Martin 


[1] https://lists.openstreetmap.org/pipermail/talk-de/2018-April/114803.html
„Es steht eine Gesamtfläche zum Mappen zur Verfügung und die Frage ist, wie 
genau und wo man sie unterteilt, um Teilflächen zu beschreiben.“
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Rainer]

So wie Volker ging's mir beim Mitlesen auch. Das Problem entsteht 
dadurch, daß highways und waterways linienförmig kartiert werden, 
landuses aber flächenförmig. Das resultiert letztlich aus der 
Zielsetzung, auf Straßen und Wegen routen zu können. Daher wurde die 
Breitenausdehnung von Wegen vernachlässigt. Außerdem werden Wege 
klassisch in Karten nicht entsprechend ihrer physischen Breite 
eingezeichnet, sondern die Breite entsprechend ihrer Verkehrsbedeutung 
variiert, letztlich aber immer breiter als in natura. In Stadtplänen 
will man ja auch noch einen Straßennamen hineinschreiben. D.h. die 
Straßenbreite in einer fertigen Karte wird immer von den Präferenzen und 
Einstellungen des Renderers abhängen, selbst wenn wir die Lücke zwischen 
z.B. dem landuse=forest links der Straße und dem landuse=meadow rechts 
der der Straße mit einem landuse=highway füllen. Etwas günstiger sieht's 
bei Bahnlinien aus, wo wir tatsächlich landuse=railway haben, der von 
flächendeckender Verwendung auch noch ein Stück entfernt ist, sich aber 
doch halbwegs rendern läßt.
Insofern bin ich dafür, gedanklich von einem landuse=highway auszugehen 
und die angrenzenden landuses an diesem enden zu lassen, also nicht mit 
linienförmigen Objekten (highway, waterway, aber natürlich auch railway) 
zu verkleben. Diese beiden Datenmodelle haben jeweils ihre Berechtigung.
Daher mein Vorschlag eines gedanklichen (ggf. später mal realen) 
landuse=highway, der ein Nichtverkleben der Objekte aus den 
unterschiedlichen Datenmodellen anschaulich plausibel macht.


Ich habe in ein paar Einzelfällen auch schon entklebt, wo ich sowieso 
landuse bearbeitet habe. Öfter begegne ich aber leicht überlappenden 
landuses, die zwischendurch auch mal mit einer Straße verklebt sind. 
Sowas versuche ich meist aufzulösen (Ziel: JOSM-Prüfung vor dem 
Hochladen wirft weniger Warnungen als nach dem Herunterladen).


Viele Grüße,
Rainer

Am 05.04.2018 09:28, schrieb Volker Schmidt:

Ich habe mit Interesse diese Diskussion mitgelesen.
Was ich vermisse in diesen Ausfuehrungen, ist ein Hinweis, dass der
Konflikt vorprogrammiert ist durch die Tatsache, das das Daten-Modell von
OSM ein Hybrid ist. Es koexistieren zwei Datenmodelle:
1) ways mit implizit oder explizit angehefteten Breiten
2) Flaechen (Polygone)
Mit ways mit angehefteten Breiten kann man keine komplizierten Flaechen
beschreiben, mit Flaechen (shapes) kann man alles beschreiben, aber der
Preis dafuer ist ein groeserer Aufwand, der fuer viele Anwendungsfaellee
nicht notwendig ist.

Wenn man akzeptiert, dass in OSM beide Modelle koexistieren sollen, dann
kann man sich den praktischen Aspekten widmen. Und das ist haeufig ein
Kompromiss oder besser ein Provisorium.

Ich bin auch ein - gelegentlicher - Entkleber, aber nicht aus Prinzip,
sondern einfach weil ich mit der Verbesserung der Daten, die ich verbessern
kann, vorankommen will. Genauer: ich moechte die Verwendbarkeit von OSM
fuer Radfahrer verbessern, weil ich sie selbst benutze. Ich kann nicht
ausserdem alle "Fehler" beseitigen, die links und rechts "meiner"
Radstrecke liegen. Normalerweise benutze ich meine eigenen GPX tracks und,
zumindest seit den letzten zwei Jahren, in der Regel auch Mapillary-Fotos.
Ein typischer Fall:
Ich treffe auf einen an die Strasse angeklebten, mehrere Hektar grossen
landuse=farmland, vor acht Jahren importiert, und wahrscheinlich vom Inhalt
her deutlich aelter, und beim Import nicht kontrolliert. Mittlerweile steht
dort ein Supermarkt und eine Neubausiedlung. Die Strasse ist von einem
freundlichen OSM-Kollegen recht grob eingetragen worden, mit erhebliche
Geometrie-Fehlern. Ausserdem sehe ich auf den Fotos, dass neben der Strasse
ein Drainage-Graben ist, der auf der Karte fehlt, und der jetzt teilweise
unterirdisch verlaeuft, und jenseits davon ein neuer Fuss-Rad-Weg.
Was mach ich da? Als erstes wird der landuse entklebt, da er offensichtlich
nicht den Tasachen entspricht und ein fixme draufgesetzt. Die
Strassen-Geometrie verbessere ich soweit moeglich, Den neuen Radweg, den
Graben, wo er sichtbar ist, und die neuen Strassen trage ich ein (falls sie
schon auf den Satellitenbildern drauf sind, sonst nur die Einmuendungen von
den Mapllary Fotos). Landuse und neue Gebauede lasse ich fuer andere.
Ausser dem Supermarkt, falls ich auf den Fotos den Namen sehe. Den setze
ich mit ungefaehrer Position ein. Aber der offensichtlich falsche landuse
bleibt - mit fixme - auf der Karte, mit seiner falschen Geometrie und tags,
aber er ist nicht mehr mit anderen Wegen verklebt.




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2018-04-04 18:38 GMT+02:00 "Christian Müller" :


Sent: Wed, 4 Apr 2018 17:38:23 +0200
From: "Florian Lohoff" 
To: "Christian Müller" 
Cc: 

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Wed, Apr 04, 2018 at 06:23:57PM +0200, "Christian Müller" wrote:
> Vielleicht läuft auf der Waldgrenze ein Weg, der hat, bei genauer
> Betrachtung eine Fläche, also grenzt dann nicht Wald an Wiese,
> sondern Wald an Weg und Weg an Wiese, nicht?

Sobald du eine Fläche mit dem Weg verbindest behauptest du das diese
Seite Geometrisch zu dem landuse daneben gehörst. Das sagst du dadurch
das die neue Grenze des landuses die Knoten in der Straßenmitte sind.

Das sehe ich als Fehler. Der Weg an der "Waldgrenze" gehört ja nicht zum
Wald und auch nicht zum Acker daneben. Er ist eigenständig.

Wir zeichnen eine Linie in der Mitte um einen routingfähigen Graphen zu
bekommen. Wenn du das geometrisch richtig machen willst musst du den Weg
auch zusätzlich als Fläche erfassen. Da gibt es ja reichlich versuche
zu.

> Nochmal, das Problem ist eines der Abwägung:  Wieviel Detail soll
> erfasst werden und wieviel Detail darf durch Abstraktion verloren
> gehen!?

Verkleben bedeutet Abstraktion und Informationsverlust - Genauer
eigentlich sogar nicht Verlust sondern Verfälschung. Die Begrenzung
der Fläche sind absichtlich falsch um eine Lücke zwischen Straße und
Fläche zu vermeiden. Ein anderes Argument kenne ich nicht.

> Wie bereits gesagt, entsteht dadurch ein Fehler (abstraktions-
> bedingt), der bei der Flächenberechnung aber z.B. dadurch min-
> imiert werden kann, dass (Länge*getaggte Breite)/2 von der Be-
> rechnung der Flächengröße der geklebten Fläche abgezogen werden
> kann.  /Wenn/ alle Flächen so gemappt würden, dann ist das auch
> programmatisch einfachst umzusetzen, dann programmiert man das
> einmal und gut ist.

"man" oder "Du" - Ich kenne derzeit keine Anwendung die das macht. Wir
haben seit 10 Jahren das Thema das Straßen und Flußbreiten nichtmal
gerendert werden. Wenn das alles so einfach ist warum hat es dann noch
keiner gemacht?

> Je nachdem wie genau man hinschaut, lassen sich also mehr und
> mehr Flächen (und damit auch Flächengrenzen) identifizieren,
> aber es ist Unsinn, eine Lücke herzustellen, ohne diese dann
> auch als getaggte Fläche auszuzeichnen.

Warum? Die Böschung des Grabens - Stand heute machen die leute das zum
farmland. Defakto gehört das zum Graben. Jetzt kann man da natürlich
eine Riverbank einzeichnen für einen 30cm breiten graben. Das wiederum
halte ich für Mumpitz. Defakto ist da aber was was nicht zum farmland
gehört.

Es gibt keine Notwendigkeit das jeder quadratcentimeter zu einem landuse
gehören muss. Das ist mapping für den Renderer.

> Und auch das Phänomen, dass eine Fläche an eine andere an-
> schließt, wird sich durch Lückenbildung (egal aus welcher

Wir sind aber nicht beim verkleben von Flächen untereinander
sondern von Flächen mit Wegen.

> Ich bin Vereinfachungen gegenüber grundsätzlich aufgeschlossen,
> wenn sie keine Verschlimmbesserungen darstellen.

Dann lassen wir das mit dem verkleben. Das ist eine Vereinfachung 
die die Geometrie falsch abbildet.

> Die Kompliziertheit in OSM besteht nicht darin, dass MPs schwierig
> zu verstehen wären, sondern darin, dass sie eines von drei Mitteln
> der Flächendarstellung sind, alle drei bunt durchwürfelt zu finden
> sind, sie aber modellhaft und asymbiotisch konkurrieren.
> 
> Anders gesagt:  Es ist weniger bedeutsam, welche Methode Flächen ab-
> zubilden, genutzt wird.  Es sind alle einfach, sofern sie alleinig
> /einheitlich genutzt würden.  Wie Frederik bereits betonte, macht
> es aber keinen Sinn, dass mit Gewalt durchdrücken zu wollen.  Das
> muss sich evolutionär lösen.

Es ist wichtig eine gewisse Disziplin anzuwenden. Nicht alles weil
es einfach ist mal eben übereinanderklatschen und auch nicht drauf
achten ob dinge verbunden sind oder nicht.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Wed, Apr 04, 2018 at 06:38:17PM +0200, "Christian Müller" wrote:
> Und wieder und wieder werden Leute bevormundet, die du überhaupt nicht
> kennst, nie in deinem Leben gesehen hast, mit Behauptungen, die einzig
> und allein einem Bauchgefühl (und vielleicht ein paar Beobachtungen in
> den Daten) entspringen zu scheinen.
> 
> Der "Gelegenheitsmapper", das ist so der "Ottonormalverbraucher" oder
> der "Kleine Mann", jeder will ihn kennen, nie hat ihn jemand gesehen
> oder verstanden.

> Wieviel Projekte wird das Internet noch sehen müssen, bevor sich der
> letzte von solchen Aussagen trennt?
> 
> Du unterschlägst sowohl Intelligenz, Wissbegier, Neugier, Lernfähigkeit
> der freiwilligen Mapper, imho.  Vielleicht liegt dein Fokus auch zu sehr
> auf den vermeintlichen Problemen, anstatt zu sehen, dass eine ganze
> Menge an Edits eben nicht fehlerbehaftet ist.

Das ist meine Erfahrung aus 10 Jahren. Ich kommentiere viel und
ausführlich in Changesets und meine Erfahrung ist das der neu und/oder
Gelegenheitsmapper schon mit viel einfacheren Dingen total überfordert
ist. Ich habe da keine "Top 10" aber so dinge wie "Es macht sinn die
Adresse auf dem Gebäudeoutline zu hinterlegen und nicht auf einem Node"
ist oft schon zu viel. Da bekomme ich dann zurück "Kannst du das nicht
reparieren - ich weiss nicht wie". Alternativ auch - "Wenn du ein
landuse in einem landuse machst du musst das mit einem Multipolygon
ausschneiden" - Die wissen oft nichtmal wovon ich rede und ich werde oft
gebeten das "mal eben" zu reparieren.

Und das ist für mich die Realität von OSM. Das Thema ist schon heute mit
den ganzen "Impliziten" Regeln und der dahinterstehenden Technik so
unglaublich kompliziert.

Und da geht es nicht darum das ICH anderen unterstelle nicht genug
Intelligenz mitzubrinen sondern das ist das was ich geschrieben bekomme
was sie nicht hinbekommen. Selbst wenn ich dann Doku mitschicke ist das
vielen zu kompliziert. Also repariere ich dann.

Relations sind schön - aber wenn massenhaft verwendet einfach nicht
handhabbar.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Neue Folge von Radio OSM erschienen: OSMDE049 – FOSSGIS 2018 Spezial

[Michael Kugelmann]

Gestern Abend wurde eine neue Folge von Radio OSM veröffentlicht.
  OSMDE049 – FOSSGIS 2018 Spezial
  https://podcast.openstreetmap.de/2018/04/04/osmde049/

Zitat:
<<
Wir melden uns mit einem Rückblick auf die FOSSGIS Konferenz 2018 in 
Bonn. Dabei werfen wir auch einen detaillierten Blick auf den 
OSM-Samstag. Weiteres Thema ist die jährliche Mitgliederversammlung des 
FOSSGIS e.V., welche am Rande der Konferenz stattgefunden hatte. Als 
Gäste haben wir uns dazu Hanna und Nakaner eingeladen.

>>

Wir freuen uns über Feedback sowie über Anregungen zu Themen.


Viel Spaß beim Hören,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hi Michael,

On Wed, Apr 04, 2018 at 07:54:30PM +0200, Michael Reichert wrote:
> Hallo Flo,

> An dem Quellcode wäre ich interessiert, um es mal bundesweit laufen zu
> lassen. Ich habe im Sommer 2015 eine Abstimmung auf Haralds
> Umfrageplattform gemacht, bei der die Nichtkleber in der Mehrheit waren.
> [1, 2, 3, 4]
> 
> Ich bin sehr daran interessiert, die Abstimmung mit den Füßen
> auszuwerten, und würde mich freuen, wenn du deinen Code entweder mir zur
> Verfügung stellen könntest oder gleich als freie Software
> veröffentlichen könntest. Die Auswertung ist nicht ganz einfach, weil
> man weder einfach die Objekte noch die Länge noch den Flächeninhalt
> zählen muss, sondern auch beachten muss, wer was beigetragen hat.

Kein ding:

git clone git://pax.zz.de/wayareaconflicts2

Braucht libosmium - geht davon aus das das im selben Verzeichniss liegt,
cmake und so ein bischen boost zeugs. Wobei ich glaube das gar nicht
mehr wirklich gebraucht wird.

Der möchte gerne ein pbf auf der command line und schreibt
dann im aktuellen Verzeichniss eine sqlite und den stdout
kannst du mit dem output-to-html in eine html Seite verwandeln.

Für NRW brauchst du ~12GByte Ram - Das dingen ist null optimiert und
eher so zusammengepfriemelt. Ich mache im moment Ostwestfalen-Lippe.

Was ich mache ist das ich mir für jeden node merke welche Wege attached
sind. Dann gehe ich alle Wege durch (Nur die lines - also high und
waterway) und gucke ob an 2 aufeinanderfolgenden nodes jeweils eine
area mit derselben ID attached ist.

Also ein Geometrischer match sondern ein logischer über die nodeIDs 

Es gibt ein paar cornercases die ich nicht abgeklopft habe.
Multipolygone sind das eine. Das andere sind wenn der erste und letzte
node verklebt sind (Des Weges oder der area) - Es könnte sein
das das dann unter Umständen nicht matched. War mir aber erstmal
nicht so wichtig. Erstmal die 80% Lösung und damit anfangen.

In der sqlite stehen für jeden weg/area jeweils die id, der letzte
bearbeiter, das letzte changeset und die letzte uhrzeit und eben
die geometrie einer linie zwischen den beiden nodes die überlappen.

Am ende hab ich mir überlegt noch alle nodes rauszuschreiben die 
jeweils an linien und Flächen sind. So das du auch einzelne
nodes findest. Ist so ein Sekundärproblem aber wenn man es eh
auswertet - Und falsch ist das in 90% der Fälle auch.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Erinnerung Berliner OSM-Hack Weekend 14. + 15.4.2018 und Stammtisch

[lars lingner]

Hallo,

zur Erinnerung möchte ich auf das Berliner OSM-Hack-Weekend
am 14./15.4.2018 aufmerksam machen. Alle Infos dazu gibt es
entweder auf der Wiki-/Meetup-Seite [1][1a] oder direkt bei mir.

Wer von außerhalb kommt, bringt bitte gutes Wetter mit
Davon hängt es ab ob evtl. der Grill am Samstag genutzt werden kann.

Das Wichtigste:

Wann:  14./15.04.2018 jeweils ab 10:00 Uhr
Wo: mindbox Berlin, Holzmarktstraße 6-9, 10179 Berlin
ÖPNV: S+U-Jannowitzbrücke
Karte:
https://www.openstreetmap.org/node/1244345598#map=19/52.51439/13.41968

Wer am Freitag 13.04. sich bereits in Berlin aufhält, findet vielleicht
auch die PostgreSQL-Konferenz [2] interessant.

Freitagabend trifft sich die Berliner und Brandenburger Community zum
Stammtisch ab 19:00 Uhr im Resonanz [3]

Samstag ab 10:00 startet das Hack Weekend in der mindbox. Snacks und
Getränke sowie Pizza werden zur Verfügung gestellt.

Am Samstag ist ab 19:00 Uhr ein Tisch für uns im Brauhaus Lemke am
Alexanderplatz [4] reserviert.

Ein großer Dank geht an das Team der mindbox, deren Räumlichkeiten wir
nutzen dürfen. Die Verpflegung wird finanziert durch Mapbox und meine
Firma mapwebbing.



Viele Grüße

Lars


[1] https://wiki.openstreetmap.org/wiki/Berlin_Hack_Weekend_April_2018
[1a] https://www.meetup.com/de-DE/OSM-Berlin-Brandenburg/events/247048865/
[2] http://2018.pgconf.de/de/location.html
[3] https://wiki.openstreetmap.org/wiki/Berlin/Stammtisch
[4] http://www.lemke.berlin/am_alex/device.desktop/lang.de/

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Volker Schmidt]

Ich habe mit Interesse diese Diskussion mitgelesen.
Was ich vermisse in diesen Ausfuehrungen, ist ein Hinweis, dass der
Konflikt vorprogrammiert ist durch die Tatsache, das das Daten-Modell von
OSM ein Hybrid ist. Es koexistieren zwei Datenmodelle:
1) ways mit implizit oder explizit angehefteten Breiten
2) Flaechen (Polygone)
Mit ways mit angehefteten Breiten kann man keine komplizierten Flaechen
beschreiben, mit Flaechen (shapes) kann man alles beschreiben, aber der
Preis dafuer ist ein groeserer Aufwand, der fuer viele Anwendungsfaellee
nicht notwendig ist.

Wenn man akzeptiert, dass in OSM beide Modelle koexistieren sollen, dann
kann man sich den praktischen Aspekten widmen. Und das ist haeufig ein
Kompromiss oder besser ein Provisorium.

Ich bin auch ein - gelegentlicher - Entkleber, aber nicht aus Prinzip,
sondern einfach weil ich mit der Verbesserung der Daten, die ich verbessern
kann, vorankommen will. Genauer: ich moechte die Verwendbarkeit von OSM
fuer Radfahrer verbessern, weil ich sie selbst benutze. Ich kann nicht
ausserdem alle "Fehler" beseitigen, die links und rechts "meiner"
Radstrecke liegen. Normalerweise benutze ich meine eigenen GPX tracks und,
zumindest seit den letzten zwei Jahren, in der Regel auch Mapillary-Fotos.
Ein typischer Fall:
Ich treffe auf einen an die Strasse angeklebten, mehrere Hektar grossen
landuse=farmland, vor acht Jahren importiert, und wahrscheinlich vom Inhalt
her deutlich aelter, und beim Import nicht kontrolliert. Mittlerweile steht
dort ein Supermarkt und eine Neubausiedlung. Die Strasse ist von einem
freundlichen OSM-Kollegen recht grob eingetragen worden, mit erhebliche
Geometrie-Fehlern. Ausserdem sehe ich auf den Fotos, dass neben der Strasse
ein Drainage-Graben ist, der auf der Karte fehlt, und der jetzt teilweise
unterirdisch verlaeuft, und jenseits davon ein neuer Fuss-Rad-Weg.
Was mach ich da? Als erstes wird der landuse entklebt, da er offensichtlich
nicht den Tasachen entspricht und ein fixme draufgesetzt. Die
Strassen-Geometrie verbessere ich soweit moeglich, Den neuen Radweg, den
Graben, wo er sichtbar ist, und die neuen Strassen trage ich ein (falls sie
schon auf den Satellitenbildern drauf sind, sonst nur die Einmuendungen von
den Mapllary Fotos). Landuse und neue Gebauede lasse ich fuer andere.
Ausser dem Supermarkt, falls ich auf den Fotos den Namen sehe. Den setze
ich mit ungefaehrer Position ein. Aber der offensichtlich falsche landuse
bleibt - mit fixme - auf der Karte, mit seiner falschen Geometrie und tags,
aber er ist nicht mehr mit anderen Wegen verklebt.




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2018-04-04 18:38 GMT+02:00 "Christian Müller" :

> > Sent: Wed, 4 Apr 2018 17:38:23 +0200
> > From: "Florian Lohoff" 
> > To: "Christian Müller" 
> > Cc: talk-de@openstreetmap.org
> > Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
> >
> > Ich hatte ja in dem Thread auch ausgeführt das es ein Problem gibt mit
> > neumappern. Das Thema MP Relation und die Wege alle einzeln hinzufügen
> > ist noch eine viel größeres Pflegedesaster. Ich gebe dir Recht das das
> > eine total saubere Sache ist (Syntaktisch) - Aber leider ist das eben
> > für "gelegenheitsmapper" völlig ungeeignet.
>
> Und wieder und wieder werden Leute bevormundet, die du überhaupt nicht
> kennst, nie in deinem Leben gesehen hast, mit Behauptungen, die einzig
> und allein einem Bauchgefühl (und vielleicht ein paar Beobachtungen in
> den Daten) entspringen zu scheinen.
>
> Der "Gelegenheitsmapper", das ist so der "Ottonormalverbraucher" oder
> der "Kleine Mann", jeder will ihn kennen, nie hat ihn jemand gesehen
> oder verstanden.
>
> Wieviel Projekte wird das Internet noch sehen müssen, bevor sich der
> letzte von solchen Aussagen trennt?
>
> Du unterschlägst sowohl Intelligenz, Wissbegier, Neugier, Lernfähigkeit
> der freiwilligen Mapper, imho.  Vielleicht liegt dein Fokus auch zu sehr
> auf den vermeintlichen Problemen, anstatt zu sehen, dass eine ganze
> Menge an Edits eben nicht fehlerbehaftet ist.
>
>
> Gruß
> cmuelle8
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de