[Talk-de] Konzept für Daten, Karte und Renderer

[Markus]

Ich möchte gern mal über "quo vadis" sprechen...

Einerseits lässt unsere Datenbank beliebige Detailliertheit zu
(Mikromapping, Einzelgeleise, Vorhausgärten, Parkplätze, Bäume, etc)

Andererseits brauchen wir kartografisch sinnvolle Generalisierung,
und routentechnische Berechnungseffizienz.

Einerseits gibt es das Credo: "wir arbeiten nicht für den Renderer",
andererseits geschieht genau dies permanent, denn der Benutzer beurteilt 
Qualität anhand dessen was er sieht.


Zunehmend werden komplexe (und auch nicht so komplexe) Zusammenhänge in 
Relationen abgebildet, die sowohl vom Benutzer als auch vom Renderer nur 
schwer zu handhaben sind. Fehler werden dadurch drastisch zunehmen.


Zunehmend geht die Nutzung von Punkten und Flächen und Namen wirr 
durcheinander.


Vor allem für neue Benutzer (es werden immer mehr :-) ) scheint es m.E 
dringend erforderlich, ihnen für sie nachvollziehbare Empfehlungen incl. 
erklärender Begründung an die Hand zu geben.


Dabei müssen wir darauf achten, dass wir die Freiheit (die Intelligenz 
der Masse) bewahren - denn sie ist eine unserer grössten Ressourcen und 
Qualitäten.


Ich könnte mir gut vorstellen, dass wir uns dazu mal treffen und 
gemeinsam Lösungen suchen:

Daten-Spezialisten, Kartografen, Routing-Spezialisten, Generalisten...

Wäre das nicht ein Thema für ein nächstes Treffen im Linux-Haus?

Gruss, Markus

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

Hallo Markus.

Inwieweit das ein Thema für ein Treffen von ein paar Stunden oder Tagen 
sein kann, weiß ich nicht, denn das ist 'ne ganz schön große Kiste, die 
du da als Thema hinstellst.

Nichtsdestotrotz sind die Fragen aber, denke ich, ziemlich richtig.

Auf der einen Seite sollten die Daten sauber sein, auf der anderen Seite 
fordert das für Renderer immer komplexere Gebilde.
Auf der einen Seite sollen die Daten handhabbar bleiben, auf der anderen 
Seite ist es schön, genau das Detail zu finden, das ich wirklich grade 
brauche.


Ich denke, eigentlich fehlt trotz vieler Bemühungen immer noch ein 
Zwischenschritt in der Pipeline, die das OSM-Universum bildet:

(a) Wir haben Mapper,
(b) wir haben Daten, die wir Anwendern geben können,
(d) es existieren Anwendungen wie Renderer/Karten, Router, 
Kunstanwendungen, Suchmaschinen und so weiter.


c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu 
verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die 
Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen.
Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem 
nützliches Tool.
Es gibt allerdings auch für osmosis diverse Anwendungen, die immer 
wieder vorkommen und nützlich wären:
- Wie generiere ich aus einem planet oder Gebietsextrakt einen 
Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und 
vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen 
einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte 
Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine 
ich hier nicht.
- Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau 
das collapsing von parallelen Strecken - aber genau darum geht es mir 
ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?)
- Analog zur Generalisierung von Flächen (Häuser zu landuse=residential 
zusammenfassen und so weiter)


Im Grunde gibt es zwei Ansätze, die man da fahren kann:
Man kann weiter so taggen, dass die Renderer, die bereits existieren, 
damit ohne Änderungen umgehen können - und damit die Datenbank 
entsprechend begrenzen, oder man setzt eben bei den Renderern selbst 
oder zwischen Renderern und Datenbank an.


Ich würde letzteres bevorzugen.

Gruß
Peter

Am 27.05.2011 09:19, schrieb Markus:

Ich möchte gern mal über "quo vadis" sprechen...

Einerseits lässt unsere Datenbank beliebige Detailliertheit zu
(Mikromapping, Einzelgeleise, Vorhausgärten, Parkplätze, Bäume, etc)

Andererseits brauchen wir kartografisch sinnvolle Generalisierung,
und routentechnische Berechnungseffizienz.

Einerseits gibt es das Credo: "wir arbeiten nicht für den Renderer",
andererseits geschieht genau dies permanent, denn der Benutzer 
beurteilt Qualität anhand dessen was er sieht.


Zunehmend werden komplexe (und auch nicht so komplexe) Zusammenhänge 
in Relationen abgebildet, die sowohl vom Benutzer als auch vom 
Renderer nur schwer zu handhaben sind. Fehler werden dadurch drastisch 
zunehmen.


Zunehmend geht die Nutzung von Punkten und Flächen und Namen wirr 
durcheinander.


Vor allem für neue Benutzer (es werden immer mehr :-) ) scheint es m.E 
dringend erforderlich, ihnen für sie nachvollziehbare Empfehlungen 
incl. erklärender Begründung an die Hand zu geben.


Dabei müssen wir darauf achten, dass wir die Freiheit (die Intelligenz 
der Masse) bewahren - denn sie ist eine unserer grössten Ressourcen 
und Qualitäten.


Ich könnte mir gut vorstellen, dass wir uns dazu mal treffen und 
gemeinsam Lösungen suchen:

Daten-Spezialisten, Kartografen, Routing-Spezialisten, Generalisten...

Wäre das nicht ein Thema für ein nächstes Treffen im Linux-Haus?

Gruss, Markus

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




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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Wolfgang]

Hallo,
Am Freitag 27 Mai 2011 10:52:51 schrieb Peter Wendorff:
> Hallo Markus.
> 
> Inwieweit das ein Thema für ein Treffen von ein paar Stunden oder Tagen
> sein kann, weiß ich nicht, denn das ist 'ne ganz schön große Kiste, die
> du da als Thema hinstellst.
> Nichtsdestotrotz sind die Fragen aber, denke ich, ziemlich richtig.
> 
> Auf der einen Seite sollten die Daten sauber sein, auf der anderen Seite
> fordert das für Renderer immer komplexere Gebilde.
> Auf der einen Seite sollen die Daten handhabbar bleiben, auf der anderen
> Seite ist es schön, genau das Detail zu finden, das ich wirklich grade
> brauche.
> 
> Ich denke, eigentlich fehlt trotz vieler Bemühungen immer noch ein
> Zwischenschritt in der Pipeline, die das OSM-Universum bildet:
> (a) Wir haben Mapper,
> (b) wir haben Daten, die wir Anwendern geben können,
> (d) es existieren Anwendungen wie Renderer/Karten, Router,
> Kunstanwendungen, Suchmaschinen und so weiter.
> 
> c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu
> verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die
> Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen.
> Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem
> nützliches Tool.
> Es gibt allerdings auch für osmosis diverse Anwendungen, die immer
> wieder vorkommen und nützlich wären:
> - Wie generiere ich aus einem planet oder Gebietsextrakt einen
> Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und
> vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen
> einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte
> Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine
> ich hier nicht.
> - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau
> das collapsing von parallelen Strecken - aber genau darum geht es mir
> ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?)
> - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential
> zusammenfassen und so weiter)
> 
> Im Grunde gibt es zwei Ansätze, die man da fahren kann:
> Man kann weiter so taggen, dass die Renderer, die bereits existieren,
> damit ohne Änderungen umgehen können - und damit die Datenbank
> entsprechend begrenzen, oder man setzt eben bei den Renderern selbst
> oder zwischen Renderern und Datenbank an.
> 
> Ich würde letzteres bevorzugen.

ich glaube nicht, dass es möglich ist, ein Tool zu schreiben, dass den ständig 
in Bewegung befindlichen "OSM-Way-of-tagging" bändigen, verwalten oder aktuell 
auswerten kann. Dafür sind wir zu dynamisch, und das ist letzen Endes auch gut 
so, auch wenn einem die eine oder andere Tendenz gegen den Strich geht. Ein 
solches Tool würde zwangsläufig immer hinterher hinken und niemanden so 
richtig glücklich machen. 

Auch die heutigen Tools wie osmosis, osm2postgresql etc. haben (subjektive) 
Schwachstellen, die dem einen oder anderen Wünche übrig lassen. Für den 
Standardfall ("mal eben") sind sie Klasse, und manche Funktionen geradezu 
unverzichtbar, aber manchmal muss man eben selbst zur 132-Tasten-Maus greifen.

Was wir aus meiner Sicht brauchen, ist endlich eine benutzbare X-Api, mit der 
es möglich ist, im Vorfeld zu filtern, was man aus der DB braucht. Für eine 
weltweite Karte aller Eisenbahnverbindungen muss man zur Zeit das Planetfile 
laden, obwohl man nicht mal 1% davon braucht.

Mehrgleisige Strecken mit einer Relation zusammen zu fassen sollte nicht das 
Problem darstellen.

Wer eine Anwendung auf freie Inhalte aufsetzen will, muss neben vielen 
Vorteilen wie Aktualität und Kostenlosigkeit eben auch ein paar Nachteile wie 
Nachverarbeitung in Kauf nehmen. Wenn er das nicht will, soll er seine Daten 
kaufen - bei anderen Anbietern oder bei jemandem, der ihm unsere Daten 
aufbereitet.

Hier ständig ein Protestgeheul für die eigene Anwendung zu starten, nervt auf 
Dauer etwas (womit ich nicht meinen Vorposter meine).

Gruß, Wolfgang


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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Markus]

Hallo Peter,


'ne ganz schön große Kiste


Ich denke, vielleicht ist die Zeit reif für ein paar Gedanken wie wir da 
"etwas mehr Ordnung reinkriegen". Klar geht das nicht in ein paar Tagen 
- aber ein Anfang wäre damit gemacht.



Zwischenschritt in der Pipeline, die das OSM-Universum bildet:


Ja, das klingt nach einem seehr guten Plan!

Eine noch zu lösende Aufgabe wird es sein, den Prozess so offen zu 
gestalten, dass es jederzeit möglich bleibt, die Core-DB (bzw. deren 
Spiegel) auch "am Standard-Prozess vorbei" beliebig zu nutzen.

Ein Standard-Prozess kann aber gefühlt 80..98% aller Aufgaben abdecken.


Ich könnte mir das so vorstellen:

Mapper > E-Verarbeitungsschicht > DB > A-Verarbeitungsschicht > Anwendung

Die Daten des Mappers (1)

werden von einem intelligenten Editor entgegengenommen und 
vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2).


In der Eingangsverarbeitung werden die Daten der verschiedenen Editoren 
standardisiert aufbereitet und in die Core-DB geschrieben (3).


Aus der DB werden in der Ausgangsverarbeitung verschiedene Schichten 
(standardisierte Views) generiert(4),


auf die die Anwendungen zugreifen (5).

Eine dieser Views ist ein Spiegel der Daten von 3. Auch die anderen 
Views kann man beliebig spiegeln, um schnellen Zugriff zu gewährleisten.


In der Ein- und Ausgangsvearbeitung gibt es dann:


Ansätze:
- weiter so taggen, dass die Renderer, die bereits existieren,
damit ohne Änderungen umgehen können
und damit die Datenbank entsprechend begrenzen,
- oder man setzt eben bei den Renderern selbst
- oder zwischen Renderern und Datenbank an.

Ich würde letzteres bevorzugen.


Ich auch.

Gruss, Markus

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 27.05.2011 10:52, schrieb Peter Wendorff:


c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut 
zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an 
die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit 
brauchen.
Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem 
nützliches Tool.
Es gibt allerdings auch für osmosis diverse Anwendungen, die immer 
wieder vorkommen und nützlich wären:
- Wie generiere ich aus einem planet oder Gebietsextrakt einen 
Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline 
und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen 
einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte 
Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas 
meine ich hier nicht.
- Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre 
genau das collapsing von parallelen Strecken - aber genau darum geht 
es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?)
- Analog zur Generalisierung von Flächen (Häuser zu 
landuse=residential zusammenfassen und so weiter)


Im Grunde gibt es zwei Ansätze, die man da fahren kann:
Man kann weiter so taggen, dass die Renderer, die bereits existieren, 
damit ohne Änderungen umgehen können - und damit die Datenbank 
entsprechend begrenzen, oder man setzt eben bei den Renderern selbst 
oder zwischen Renderern und Datenbank an.

Eine Lösung könnte auch eine layerorientierte Ausrichtung sein:
landuse-Layer (entspricht Flächennutzungsplan)
Cover-Layer(beschreibt die vorgefundene Bodenbedeckung)
Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne auf 
verkehrsrechtliche Details einzugehen)

Routing-Layer  (beschreibt fahrspurdetailiert die Verkehrswege)
Building-Layer
usw..
Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in den 
Editoren durch entsprechende Filter erzeugt werden.

Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden.

Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

Am 27.05.2011 11:47, schrieb Wolfgang:

Hallo,
[...]
ich glaube nicht, dass es möglich ist, ein Tool zu schreiben, dass den ständig
in Bewegung befindlichen "OSM-Way-of-tagging" bändigen, verwalten oder aktuell
auswerten kann. Dafür sind wir zu dynamisch, und das ist letzen Endes auch gut
so, auch wenn einem die eine oder andere Tendenz gegen den Strich geht. Ein
solches Tool würde zwangsläufig immer hinterher hinken und niemanden so
richtig glücklich machen.
Dass das Tool eher zurückhinken würde, ist erstmal klar - aber das 
Problem haben wir momentan auch, verstärkt und verteilt über 
verschiedene Renderer.
Wenn die Entwickler der Render-Engines nicht noch diesen Zwischenschritt 
aufwändig immer wieder anpassen müssten, könnten Kapazitäten für ein 
Gemeinsames Tool, das eben diese Aufbereitung vornehmen kann, frei werden.


Klar - wenn dann doch jeder sein eigenes Süppchen kocht und Updates 
lieber lokal in Mapnik oder sonstwo einpflegt, ist nichts gewonnen.

Auch die heutigen Tools wie osmosis, osm2postgresql etc. haben (subjektive)
Schwachstellen, die dem einen oder anderen Wünche übrig lassen. Für den
Standardfall ("mal eben") sind sie Klasse, und manche Funktionen geradezu
unverzichtbar, aber manchmal muss man eben selbst zur 132-Tasten-Maus greifen.
Das ist richtig - aber gerade bei osmosis gibt es doch mittlerweile 
einige (wenige) Beispiele für Module, die angepasst auf bestimmte 
Vorgänge sind: Datenbank-schreiben in verschiedenen Formaten z.B.

Was wir aus meiner Sicht brauchen, ist endlich eine benutzbare X-Api, mit der
es möglich ist, im Vorfeld zu filtern, was man aus der DB braucht. Für eine
weltweite Karte aller Eisenbahnverbindungen muss man zur Zeit das Planetfile
laden, obwohl man nicht mal 1% davon braucht.
Da stimm ich dir voll zu - und sicherlich ist auch (J)XAPI ein 
Puzzleteil auf dem Vorverarbeitungs-Layer.

Mehrgleisige Strecken mit einer Relation zusammen zu fassen sollte nicht das
Problem darstellen.
Also wenn ich sehe, wie oft Buslinien zerreißen - ich befürchte, das 
wird bei Bahnstrecken auch nicht viel besser sein (abgesehen davon, dass 
sie bisher möglicherweise seltener angefasst werden).
Das aber führt dazu, dass auch hier wieder Fehlertoleranz verlangt ist - 
wieder ein schwieriges Thema.


Gruß
Peter

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

Am 27.05.2011 12:20, schrieb Markus:

Hallo Peter,


'ne ganz schön große Kiste


Ich denke, vielleicht ist die Zeit reif für ein paar Gedanken wie wir 
da "etwas mehr Ordnung reinkriegen". Klar geht das nicht in ein paar 
Tagen - aber ein Anfang wäre damit gemacht.



Zwischenschritt in der Pipeline, die das OSM-Universum bildet:


Ja, das klingt nach einem seehr guten Plan!

Eine noch zu lösende Aufgabe wird es sein, den Prozess so offen zu 
gestalten, dass es jederzeit möglich bleibt, die Core-DB (bzw. deren 
Spiegel) auch "am Standard-Prozess vorbei" beliebig zu nutzen.

Ein Standard-Prozess kann aber gefühlt 80..98% aller Aufgaben abdecken.

Ich könnte mir das so vorstellen:

Mapper > E-Verarbeitungsschicht > DB > A-Verarbeitungsschicht > Anwendung

Da hast du mich falsch verstanden!
Ich bin für Mapper > DB > Verarbeitungsschicht > Anwendung
Je nach Kapazität auf den Servern kann man zusätzlich noch
Mapper > DB > Verarbeitungsschicht > aufbereiteteDB > Anwendung
einführen, um die Verwendbarkeit noch einfacher zu machen.
Ich halte allerdings die Verwendung von Osmosis nicht für zu viel 
verlangt; nur reinkommen ist erstmal relativ schwierig.

Die Daten des Mappers (1)

werden von einem intelligenten Editor entgegengenommen und 
vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2).
so intelligent kann die Schicht nicht sein, dass dadurch keine 
Informationen verloren gehen.
Außerdem ist einiges in dem Bereich nicht sinnvollerweise bei jedem 
Upload durchzuführen.
In der Eingangsverarbeitung werden die Daten der verschiedenen 
Editoren standardisiert aufbereitet und in die Core-DB geschrieben (3).

Insofern würde ich diesen Schritt weglassen


Aus der DB werden in der Ausgangsverarbeitung verschiedene Schichten 
(standardisierte Views) generiert(4),
...diesen allerdings hereinnehmen; wobei der eben auch auf Seite der 
Anwendung oder Anwendungsprogrammierung laufen kann - als Bibliothek 
oder Hilfsprogramm, das einfach nur aufgerufen werden muss.



Gruß
Peter

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

Am 27.05.2011 13:47, schrieb Garry:

Am 27.05.2011 10:52, schrieb Peter Wendorff:


c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut 
zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an 
die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit 
brauchen.
Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem 
nützliches Tool.
Es gibt allerdings auch für osmosis diverse Anwendungen, die immer 
wieder vorkommen und nützlich wären:
- Wie generiere ich aus einem planet oder Gebietsextrakt einen 
Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline 
und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen 
einfachen Graphen zu erzeugen - das Speziellere Erzeugen für 
bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder 
sonstwas meine ich hier nicht.
- Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre 
genau das collapsing von parallelen Strecken - aber genau darum geht 
es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt 
werden?)
- Analog zur Generalisierung von Flächen (Häuser zu 
landuse=residential zusammenfassen und so weiter)


Im Grunde gibt es zwei Ansätze, die man da fahren kann:
Man kann weiter so taggen, dass die Renderer, die bereits existieren, 
damit ohne Änderungen umgehen können - und damit die Datenbank 
entsprechend begrenzen, oder man setzt eben bei den Renderern selbst 
oder zwischen Renderern und Datenbank an.

Eine Lösung könnte auch eine layerorientierte Ausrichtung sein:
landuse-Layer (entspricht Flächennutzungsplan)
Cover-Layer(beschreibt die vorgefundene Bodenbedeckung)
Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne auf 
verkehrsrechtliche Details einzugehen)

Routing-Layer  (beschreibt fahrspurdetailiert die Verkehrswege)
Building-Layer
usw..
Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in 
den Editoren durch entsprechende Filter erzeugt werden.

Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden.

Die Idee gabs schon mehrfach.
Probleme dabei:
1) Wer definiert die Layer? Einerseits müssen die wegen der Evolution 
des Taggingschemas irgendwann geändert werden, andererseits müssen sie 
konstant bleiben, damit die Anwendungen nicht in die Falle tappen
2) Welche layer bietet man an? Routing-Layer: Mit oder ohne Fußwegen? 
was ist mit Rollstuhl-Routing-Eigenschaften? Adressgenau, oder nur die 
Fahrwege?


Nodes nicht layerübergreifend verwendbar?
Bei welchen Layern und warum? Ich befürchte, Gegenbeispiele gibt's da 
immer - es sei denn, man trennte die layer komplett voneinander, was 
dann aber schnell zu inkonsistenzen führt.


Gruß
Peter

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 27.05.2011 14:16, schrieb Peter Wendorff:

Am 27.05.2011 13:47, schrieb Garry:

Am 27.05.2011 10:52, schrieb Peter Wendorff:


c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine 
gut zu verwendende Verarbeitungsschicht, die man 
Anwendungsentwicklern an die Hand geben kann, ohne dass die erst 
monatelange Einarbeitungszeit brauchen.
Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem 
nützliches Tool.
Es gibt allerdings auch für osmosis diverse Anwendungen, die immer 
wieder vorkommen und nützlich wären:
- Wie generiere ich aus einem planet oder Gebietsextrakt einen 
Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline 
und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um 
einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für 
bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder 
sonstwas meine ich hier nicht.
- Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre 
genau das collapsing von parallelen Strecken - aber genau darum geht 
es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt 
werden?)
- Analog zur Generalisierung von Flächen (Häuser zu 
landuse=residential zusammenfassen und so weiter)


Im Grunde gibt es zwei Ansätze, die man da fahren kann:
Man kann weiter so taggen, dass die Renderer, die bereits 
existieren, damit ohne Änderungen umgehen können - und damit die 
Datenbank entsprechend begrenzen, oder man setzt eben bei den 
Renderern selbst oder zwischen Renderern und Datenbank an.

Eine Lösung könnte auch eine layerorientierte Ausrichtung sein:
landuse-Layer (entspricht Flächennutzungsplan)
Cover-Layer(beschreibt die vorgefundene Bodenbedeckung)
Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne 
auf verkehrsrechtliche Details einzugehen)

Routing-Layer  (beschreibt fahrspurdetailiert die Verkehrswege)
Building-Layer
usw..
Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in 
den Editoren durch entsprechende Filter erzeugt werden.

Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden.

Die Idee gabs schon mehrfach.

Ich weiss..

Probleme dabei:
1) Wer definiert die Layer? Einerseits müssen die wegen der Evolution 
des Taggingschemas irgendwann geändert werden, andererseits müssen sie 
konstant bleiben, damit die Anwendungen nicht in die Falle tappen
Eine Layerdarstellung in den Editoren ändert zunächst einmal nichts am 
Tagging-Schema.
Mittelfristig soll aber bewirkt werden dass eine saubere Trennung 
zwischen Bodenbedeckung, "landuse"(Flächennutzungsplan?), Verkehrswege etc.

einzug hält.
2) Welche layer bietet man an? Routing-Layer: Mit oder ohne Fußwegen? 
was ist mit Rollstuhl-Routing-Eigenschaften? Adressgenau, oder nur die 
Fahrwege?
Im Routing-Layer sollte alles angezeigt werden was routing-relevant ist, 
gegebenfalls vom user einzelne Elemente ausblendbar die er gerade nicht 
benötigt,
in dem Fall aber mit einer Verriegelung/Warnung wenn sich eine Änderung 
auf die ausgeblendeten Elemtente auswirken würde(So wie jetzt schon in 
Josm wenn man etwas ändern möchte was nicht vollständig geladen ist).


Nodes nicht layerübergreifend verwendbar?
Bei welchen Layern und warum? Ich befürchte, Gegenbeispiele gibt's da 
immer - es sei denn, man trennte die layer komplett voneinander, was 
dann aber schnell zu inkonsistenzen führt.
Z.B. sollten Verkehrswege keine gemeinsamen nodes mit landuse / 
Bodenbedeckung haben. Meist stammen die Daten aus unterschiedlichen
Quellen mit unterschiedlicher Genauigkeit. Bei gemeinsamen nodes würden 
eine Positionsänderungen im einen Layer (aus welchen Gründen auch immer)
die Daten im anderen Layer beeinflussen und unter Umständen hochgenaue 
Daten verschlechtern.


Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Heiko Jacobs]

Am 27.05.2011 09:19, schrieb Markus:

Ich möchte gern mal über "quo vadis" sprechen...


Ei, dann hätte das eben bei den Gleisen getippte besser hierher gepasst:

Ctrl-C, Ctrl-V:

Am 27.05.2011 17:13, schrieb Torsten Leistikow:
> Frederik Ramm schrieb am 26.05.2011 22:35:
>> man muss das halt beim Rendern in den Griff kriegen.
>
> Solche Aussagen ohne konkrete Vorschlaege (oder auch
> nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich.

Such mal im Wiki nach dem Stichwort "Linienbündel"

Am 26.05.2011 22:35, schrieb Frederik Ramm:
>  und es wirkte etwas seltsam, dass ein einzelner Way,
> der eine Trasse symbolisierte, sich an einem Bahnhof
> ploetzlich auffaecherte zu lauter Gleisen und dann hinter
> dem Bahnhof wieder zu einer Trasse zusammenlief -
> ziemlich unlogisch, aber ich habe immer angenommen,
> dass das halt ein voruebergehenden Zustand ist, bis
> irgendwann mal alle Gleise vollstaendig erfasst sind.

Nicht unlogisch, sondenr normal. Das wird auch so gemacht auf
Karten, auf denen die Zweigleisigkeit ggü. Eingleisigkeit
durch 'nen Querstrich mehr dargestellt wird (bspw. TK50)
oder auch nicht (Stadtplan KA 1:20.000).
Auch da fächert sich ein Bahnhof durchaus auf in passenden Maßstäben.
Aber nicht unbedingt zu voller Gleiszahl, sondern ca. der Hälfte.
So war der K'her Hbf auch vorm gleistreuen Mapping. Im Gegensatz
zu TK50 und K'her Stadtplan aber mit nach Osten korrekt raus geführten
DREI Strecken. Die bei den amtlichen gezeigten Fusionen lassen
Eisenbahnfans die Nackenhaare aufstellen ... ;-)

> Damals schon konnte man beobachten, dass das Auffaechern
> der Gleise auf den hohen Zoomstufen zwar gut war,
> auf mittleren Zoomstufen aber haessliche schwarze Flecken im
> Bahnhofsareal erzeugte.

Bei Osmarender habe ich immerhin das Symbol ab einem bestimmten
Maßstab gewechselt (wie auch bei Radwegen etc.)
Aber vom Optimum ist das natürlich noch weit entfernt...

> Das ist eine Herausforderung, der man beim Rendern Herr
> werden kann und muss. Eventuell *kann* man dem Renderer
> irgendwie helfen, indem man eine Gruppe von Gleisen zu einer
> "Bahntrassen"-Relation zusammenfasst und dann neue Funktionalitaeten
> im Renderer einbaut, die in der Lage sind, solche gruppierten
> linienfoermigen Objekte geeignet zu vereinfachen.
> Man muss aber dabei auch den Fall abfangen, dass eine
> solche Relation fehlen koennte.

Deswegen vielleicht eher ein Prozess, der versucht, automagisch
das passende zusammenzuwürfeln und nur dort, wo was unpassendes
rauskommt, Hinweise geben, was zusammengehört und was nicht ...

Das Problem stellt sich ja auch beim Thema separat gemappte
Rad- und Gehwege, Straße neben Fluss, aber auch bei Haus neben
(mit dem Zoom wachsender) Straße, Sackgasse, die knapp vor
Straße endet, ...

> Da wird man fuer das Standard-Rendering mindestens  am osm2pgsql,
> wenn nicht sogar auch am Mapnik herumdrehen muessen.
> Das wird nicht leicht, aber danach haben wir eine Karte, die
> auf allen Zoomleveln besser aussieht als vorher.

Ich fürchte, wir müssen langfristig Mapnik, Osmarender & Co.
ganz wegschmeißen, dann das sind alles keinerlei kartographische
Programme, sondern einfachste "Umetikettierer", die Null Möglichkeit
zur Koordinatenveränderung haben (außer dass sie gelegentlich Kurven
durch die Stützpunkte legen statt Geraden, auch nicht immer so doll...
aber auch da bleiben die Stützpunktkoordinaten unverändert).
Am deutlichsten wird es bei Osmarender, den's auch in einer (lahmen)
XSLT-Variante gibt ...
Problem ist auch das Ausgabeformat SVG, das in seinen
Darstellungsmöglichkeiten limitiert ist, daran scheitert in
Osmarender das Rendern einseitiger Radwege.

Für alle genannten Probleme müssen aber Koordinaten gerechnet
werden für
- die Mittellinie (ob nun mit real existentem Objekt wie Tram, ähm,
  vorm gleistreuen Mapping, oder nur virtuell als Mitte zwischen
  zwei Fahrbahnen)
- alle parallelen maßstabsabhängig (!) auf die Mitte abgestimmten
  Wege wie Gleise, Fahrbahnen, Radwege
- alle Objekte wie Häuser, Bäume, POIs, Sackgassenenden, ...
  die ggfs. zur Seite geschoben werden müssen
- ...
Das ist vermutlich zu komplex, um es jedesmal zu machen, sprich:
solche Geometrien muss man wohl zwischenspeichern und eine
automatische Aktualisierung bei Veränderung der Basisgeometrien
organisieren. Etc.

Und man muss verstärkt gewisse Sachen wegwerfen und vereinfachen müssenin
passenden Zooms wie jetzt schon einige Wegklassen peu a peu in Mapnik

> In der Zwischenzeit - solang eben die Renderer nicht gut
> genug sind - muessen wir Rueckschritte hinnehmen. Das ist an vielen
> anderen Fronten auch so (z.B. einzelne Haeuser, die man auf
> kleineren Zoomleveln eigentlich lieber als grosse bebaute
> Flaeche anzeigen will). Aber jetzt das Mapping-Rad
> zurueckdrehen, beim Mapping zu stagnieren, bloss weil
> der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv.

Erst wenn genug Leidensdruck durch massenhaft Details aufgebaut ist,
wird sich jemand dran setzen, obige Liste ab

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Heiko Jacobs]

Am 27.05.2011 14:07, schrieb Peter Wendorff:

Am 27.05.2011 12:20, schrieb Markus:

Ich könnte mir das so vorstellen:

Mapper > E-Verarbeitungsschicht > DB > ...

Da hast du mich falsch verstanden!
Ich bin für Mapper > DB > ...



Die Daten des Mappers (1)

werden von einem intelligenten Editor entgegengenommen

>> und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2).

so intelligent kann die Schicht nicht sein, dass dadurch keine
Informationen verloren gehen.
Außerdem ist einiges in dem Bereich nicht sinnvollerweise
bei jedem Upload durchzuführen.


Ich wäre auch vorsichtig, allzu viel in die E-Schicht zu packen.
Eins jedoch sollten Editoren -- oder wenn die es nicht machen --
die Eingangschicht der DB machen:
Splits und Vereinigungen erkennen und eine saubere Historie
auch für diese erzeugen. Das ist nicht nur DER Knackpunkt
der Relizenzierung (ohne saubere Historie auch bei Splits
und Vereinigungen ist die rechtlich angreifbar), sondern
auch ganz generell lästig, wenn man die Entstehungsgeschichte
eines Objekts verfolgen möchte, wann und von wem und warum bspw.
Tag X drangehängt wurde an die Y-Straße ...

Gruß Mueck


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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Heiko Jacobs]

Am 27.05.2011 09:19, schrieb Markus:

Andererseits brauchen wir kartografisch sinnvolle Generalisierung,
und routentechnische Berechnungseffizienz.


Beides fängt m.E. mit einem gemeinsamen Schritt an:
Zusammenfassen, was zusammen gehört, s.a. Ctrl-C+Ctrl-V-Mail ;-)

Linienbündel etc.:
Sowohl beim Rendern ( Radweg/Fahrbahn sollen sich nicht überdecken),
als auch beim Generalisieren (Straße mit/ohne Radweg) als auch
beim Routen (Rafahrer über Fahrbahn oder Radweg) braucht man die
Zusammenhänge paralleler Strukturen.
Einige Teilaufgaben brauchen paar mehr (Verdrängung Straße contra Fluss),
die andere nicht brauchen (oder? Hmmm... "nicht zu weit rechts fahren,
sonst *platsch* ;-) ), aber der geometrische Ansatz ist derselbe.

Das geht alles in Richtung GIS als Zwischenschicht.
Oder sowas in der Art.
Jedenfalls etwas, das Koordinaten nicht nur umbildet von
geographisch/WGS84 in Karten-x/y, sondern richtig analysiert
und verändert:
Was ist parallel zueinander?
Was stößt in einem Winkel darauf?
Was endet kurz davor?
Und all das darf sich nicht von unsauberem Mapping beeinflussen
lassen wie unterschiedlich dichte und verteilte Stützpunkte
bei parallelen Fahrbahnen, Unterbrechungen durch Brücken
(die tw. versetzt zueinander sind, wenn was in spitzem Winkel
gekreuzt wird etc. Oder beim parallelen Radweg fehlt die Brücke ...), ...
Und muss dennoch erkennen, ob ein eine Weile paralleler Radweg
doch irgendwo abschwenkt ...

Und dann:
Was gehört davon zusammen, was nicht?
Was für Aufgabe A (Verdrängung), B (Rendern), C (Routen), D (...), ...?

Und wie speichert man diese Zusammengehörigkeiten ab?
Wie hält man die aktuell, wenn jemand die Basisgeonetrie ändert?
Und wie steuert man die, wenn die Automagik falsch zusammenstöpselt?
Oder nur manuell, aber was, wenn die fehlt?

Gruß Mueck


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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Torsten Leistikow]

Heiko Jacobs schrieb am 27.05.2011 19:32:
>>> man muss das halt beim Rendern in den Griff kriegen.
> Such mal im Wiki nach dem Stichwort "Linienbündel"

Auch das erfordert weitere Information, das kann ein Renderer einfach nicht von
sich aus leisten.

Die schlechten Erfahrungen mit den Multipolygonen lassen mich ausserdem daran
zweifeln, dass solche Konstrukte das Richtige fuer die Masse der
Gelegenheitsmapper ist.

Was haltet ihr von folgendem Schema fuer Hilfstags aehnlich den Tags speziell
fuer Osmarender, d.h. sie sollen nicht das Objekt selber beschreiben sondern
eine Hilfestuetze zur Auswertung/Darstellung bieten.

- detail_level=minor

Ein Objekt, dass nur auf den groessten Zoomstufen angezeigt werden sollte. Auf
groeberen Karten kann es bei Bedarf weggelassen werden, da es durch andere
Objekte (mit detail_level=main oder detail_level=abstract) ausreichend
repraesentiert wird.

- detail_level=main

Ein Objekt, dass auf allen Zoomstufen angezeigt werden sollte.

- detail_level=abstract

Ein Objekt, dass nur auf den kleinsten Zoomstufen angezeigt werden sollte. Auf
genaueren Karten kann es bei Bedarf weggelassen werden, da es durch andere
Objekte (mit detail_level=minor) ersetzt wird.

Mit diesem Schema koennte man z.B. eine Strasse als main definieren und die
separat erfassten Rad- und Fusswege als minor.
Jeder Renderer koennte mit diesen Informationen dann ohne grossen Aufwand selbst
entscheiden, ab welcher Zommstufe der Begleitweg dargestellt wird, und ab
welchen Zoomstufen es sinnvoller ist, nur die eigentliche Strasse darzustellen.

Ein Mapper haette mit diesem Schema die Moeglichkeit, Elemente, die ihm
persoenlich unnoetig detailliert erscheinen, als untergeordnet zu markieren oder
sogar durch abstraktere Elemente zu ersetzen, ohne dass er dafuer die
eigentlichen Tags der Elemente in der Datenbank veraendern muesste. Es geht also
keine Information verloren, und ein Mapper, der meint in seinem Revier etwas
aufraeumen zu muessen, kollidiert nicht mit einem Detail-Mapper.

Gruss
Torsten

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Heiko Jacobs]

Am 27.05.2011 20:02, schrieb Heiko Jacobs:

Und dann:
Was gehört davon zusammen, was nicht?
Was für Aufgabe A (Verdrängung), B (Rendern),


... wobei da ja noch stark der Maßstab reinspielt und
die Zeichenregeln des Renderers. In z18 kann man noch fast alles
unverändert zeichnen. Wann die Objekte zusammenstoßen und
Variationen an den Koordinaten benötigen, ist beim renderer
mit dicken Linien früher der Fall als bei dem mit den dünnen ...
Das macht das mit dem zwischenspeichern von Hilfsgeometrien
nicht einfacher ...

Gruß Mueck



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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Henning Scholland]

Von einer solchen Abstufung halte ich nichts. Schließlich soll der 
Renderer (und der Programmierer dahinter) entschieden wann er was 
darstellt. Von daher ist es sinnvoller das Objekt besser zu beschreiben 
Im Falle vom Fußweg/Radweg/Straße bspw. könnte man kennzeichnen, dass 
der Radweg und der Fußweg zur Straße gehören und nicht einen 
eigenständigen Weg bilden. Dann kann der Renderer bspw. alle nicht 
eigenständigen Wege ausblenden.


Henning


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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Torsten Leistikow]

Henning Scholland schrieb am 27.05.2011 20:28:
> Von einer solchen Abstufung halte ich nichts. Schließlich soll der
> Renderer (und der Programmierer dahinter) entschieden wann er was
> darstellt.

Die Entscheidung liegt ja auch weiterhin bei dem Renderer. Er ist ja nicht
gezwungen die Hilfstags auszuwerten, und wenn er es tut, dann kann er das ja
auch fuer verschiedene Elemente unterschiedlich handhaben. Eine Karte fuer
Radfahrer koennte so z.B. Radwege immer darstellen wollen, eine Karte fuer
Autofahrer wuerde sich in diesem Falle anders entscheiden, und bei Gleisen
wuerde es beiden reichen, nur eins von mehreren parallel darzustellen.

Das Tag ist ja keine verbindliche Vorgabe fuer die Renderer, sondern es ist nur
ein Hilfmittel, um den Auswerteprogrammen das Weglassen von Objekten zu 
erleichtern.

Gruss
Torsten

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

Am 27.05.2011 19:46, schrieb Heiko Jacobs:

Am 27.05.2011 14:07, schrieb Peter Wendorff:

Am 27.05.2011 12:20, schrieb Markus:

Ich könnte mir das so vorstellen:

Mapper > E-Verarbeitungsschicht > DB > ...

Da hast du mich falsch verstanden!
Ich bin für Mapper > DB > ...



Die Daten des Mappers (1)

werden von einem intelligenten Editor entgegengenommen
>> und vorverarbeitet und in die Eingangs-Verarbeitungsschicht 
gespeichert (2).

so intelligent kann die Schicht nicht sein, dass dadurch keine
Informationen verloren gehen.
Außerdem ist einiges in dem Bereich nicht sinnvollerweise
bei jedem Upload durchzuführen.


Ich wäre auch vorsichtig, allzu viel in die E-Schicht zu packen.
Eins jedoch sollten Editoren -- oder wenn die es nicht machen --
die Eingangschicht der DB machen:
Splits und Vereinigungen erkennen und eine saubere Historie
auch für diese erzeugen. Das ist nicht nur DER Knackpunkt
der Relizenzierung (ohne saubere Historie auch bei Splits
und Vereinigungen ist die rechtlich angreifbar), sondern
auch ganz generell lästig, wenn man die Entstehungsgeschichte
eines Objekts verfolgen möchte, wann und von wem und warum bspw.
Tag X drangehängt wurde an die Y-Straße ...

+10!
Ja, ganz klar - das fehlt bisher in API und Editoren völlig.

Allerdings hilft das auch nur zum Teil: Bei der Beobachtung mancher 
Mapper (und etlicher Changesets) ist mir aufgefallen, dass oft eben 
nicht gelöscht + neu angelegt wird, sondern mal eben wiederverwendet, 
verschoben und "umgewidmet" wird.
Da soll eine Wiese gelöscht und ein Gebäude hinzugefügt werden - dann 
nimmt man den way der Wiese, arrangiert die Nodes des way neu und 
vergibt neue Tags - das kann beim besten Willen kein Editor als neues 
Objekt erkennen.


Gruß
Peter

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

Wir haben keinen Plasberg hier (oder? :D), aber ein Antrag an den 
erweiterten Faktencheck:
Man untersuche mal die OSM-Datenbank auf Überschneidungen von Tags und 
Tag-Gruppen. Also:
- Überschneiden sich landuses tatsächlich weitgehend NICHT mit highways? 
wenn doch, ist das ein Fehler oder eigentlich korrekt? Wenn es korrekt 
ist, ist hier der Layer eigentlich nicht machbar.

- Analog zu Routing-relevanten Tags (also im weitesten Sinne highway=*)

Wenn noch mehr Kapazität da wäre, würde ich weiter fragen - obwohl ich 
mir spätestens hier eigentlich auch selbst eine Antwort geben kann:
- Sind gleichzeitige (im Sinne von in-einem-changeset-getätigte) 
Änderungen an nur geometrisch naheliegenden Objekten (z.b. landuse und 
highway) voneinander unabhängig? Ich behaupte, das sind sie häufig 
nicht: Ich verschiebe den Weg und korrigiere die angrenzenden Flächen 
entsprechend (denn das Feld geht bis zum Straßenrand und auf der anderen 
Seite beginnt direkt neben der Straße das Fabrikgelände).
Trennt man jetzt aber die Layer, dann erschwert man dieses simultane 
Bearbeiten - und versteckt die dadurch provozierten Fehler eher vor dem 
Nutzer.


Gruß
Peter

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

Am 27.05.2011 21:59, schrieb Torsten Leistikow:

Henning Scholland schrieb am 27.05.2011 20:28:

Von einer solchen Abstufung halte ich nichts. Schließlich soll der
Renderer (und der Programmierer dahinter) entschieden wann er was
darstellt.

+1

Die Entscheidung liegt ja auch weiterhin bei dem Renderer. Er ist ja nicht
gezwungen die Hilfstags auszuwerten, und wenn er es tut, dann kann er das ja
auch fuer verschiedene Elemente unterschiedlich handhaben. Eine Karte fuer
Radfahrer koennte so z.B. Radwege immer darstellen wollen, eine Karte fuer
Autofahrer wuerde sich in diesem Falle anders entscheiden, und bei Gleisen
wuerde es beiden reichen, nur eins von mehreren parallel darzustellen.

Das Tag ist ja keine verbindliche Vorgabe fuer die Renderer, sondern es ist nur
ein Hilfmittel, um den Auswerteprogrammen das Weglassen von Objekten zu 
erleichtern.
Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf 
strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma 
auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine 
Straße auf dem Weg als besonders wichtig einstufen.
Klar - man kann die Regeln des Renderers anpassen und das da eben nicht 
mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher 
oder später jemanden geben, der sie ausnutzt, um die Standardkarte den 
eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu 
rendern.


Hier zeigt sich eben auch (mal wieder), dass das Konzept von der 
OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe 
nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration 
zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für 
Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre 
aber ein Glanzpunkt, was die Konzept-Implementierung angeht.


Gruß
Peter

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Heiko Jacobs]

Am 27.05.2011 20:28, schrieb Henning Scholland:

Im Falle vom Fußweg/Radweg/Straße bspw. könnte man kennzeichnen,
dass der Radweg und der Fußweg zur Straße gehören und nicht
einen eigenständigen Weg bilden.


Das ist eine Info, die auch zum (Rad-)Routen nützlich ist.

Gruß Mueck




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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Torsten Leistikow]

Peter Wendorff schrieb am 28.05.2011 09:50:
> Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf
> strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma
> auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine
> Straße auf dem Weg als besonders wichtig einstufen.

So ganz hast du die Idee des Vorschlags noch nicht verstanden. Mit den
vorgeschlagenen Hilfstags kann man keine Anzeige beim Renderer erzwingen, ein
Element kann dadurch nicht wichtiger werden, als es jetzt schon ist. In der
umgekehrten Richtung gibt es dem Mapper allerdings die Moeglichkeit, Elemente
fuer hohe oder niedrige Detail-Auswertungen als nachrangig zu kennzeichnen, da
sie auf diesem Detaillevel durch ein anderes Element hinreichend repraesentiert
werden.

> Klar - man kann die Regeln des Renderers anpassen und das da eben nicht
> mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher
> oder später jemanden geben, der sie ausnutzt, um die Standardkarte den
> eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu
> rendern.

Die Missbrauchsmoeglichkeiten sind da sehr beschraenkt:
1. Ein Mapper kennzeichnet etwas als main, was von anderen eher als minor
gekennzeichnet werden wuerde -> Das Element wird bei niedrigen Zoom-Stufen nicht
ausgeblendet -> Die Karte sieht genauso aus wie heute ohne solche Zusatztags.
Die Lage hat sich also durch den Missbrauch nicht verschlechtert.
2. Ein Mapper kennzeichnet was als minor, was von anderen eher als main
gekennzeichnet werden wuerde -> Das Element wird bei niedrigen Zoom-Stufen
eventuell von einigen Renderen nicht mehr angezeigt (bei vielen Typen wuerde ein
minor heute keinen Sinn machen und von einem Renderer deshalb auch nicht
beruecksichtigt werden.) -> Ein andere Mapper wird das Element auf der Karte
vermissen und das Tagging entsprechen korregieren. Das ist genauso, wie Mapper
auch heute bei den Strassenkategorien unterschiedlicher Meinung sein koennen,
davon geht die OSM-Karte nicht unter.
Auf die Kennzeichnung abstract gehe ich hier nicht weiter ein, da es bislang
keine derartigen Elemente gibt, das waere also eher was fuer die Zukunft, wenn
sich entsprechender Bedarf ergibt.

> Hier zeigt sich eben auch (mal wieder), dass das Konzept von der
> OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe
> nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration
> zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für
> Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre
> aber ein Glanzpunkt, was die Konzept-Implementierung angeht.

Dem will ich nicht widersprechen, vorallem deshalb, weil ich nicht verstanden
habe, was du damit sagen willst ;-)

Gruss
Torsten

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter Wendorff]

Am 28.05.2011 16:38, schrieb Torsten Leistikow:

Peter Wendorff schrieb am 28.05.2011 09:50:

Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf
strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma
auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine
Straße auf dem Weg als besonders wichtig einstufen.

So ganz hast du die Idee des Vorschlags noch nicht verstanden. Mit den
vorgeschlagenen Hilfstags kann man keine Anzeige beim Renderer erzwingen, ein
Element kann dadurch nicht wichtiger werden, als es jetzt schon ist. In der
umgekehrten Richtung gibt es dem Mapper allerdings die Moeglichkeit, Elemente
fuer hohe oder niedrige Detail-Auswertungen als nachrangig zu kennzeichnen, da
sie auf diesem Detaillevel durch ein anderes Element hinreichend repraesentiert
werden.

Ich hab den Vorschlag sehr wohl verstanden.
Aber wenn ich nicht wichtiger taggen kann, dann tagge ich eben alle 
konkurrierenden Objekte als minder wichtig, um mein Ziel zu erreichen.


Wo Leute die Sandgrube auf dem Golfplatz als Strand taggen, weil das 
Rendering die schönere Farbe zeigt, wird auch das früher oder später 
passieren.
Wie? Mapnik zeigt die Nachbarstraße an und nicht die Straße, in der ich 
wohne? dann tagge ich die Nachbarstraße eben als weniger wichtig.

Klar - man kann die Regeln des Renderers anpassen und das da eben nicht
mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher
oder später jemanden geben, der sie ausnutzt, um die Standardkarte den
eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu
rendern.

Die Missbrauchsmoeglichkeiten sind da sehr beschraenkt:
1. Ein Mapper kennzeichnet etwas als main, was von anderen eher als minor
gekennzeichnet werden wuerde ->  Das Element wird bei niedrigen Zoom-Stufen 
nicht
ausgeblendet ->  Die Karte sieht genauso aus wie heute ohne solche Zusatztags.
Die Lage hat sich also durch den Missbrauch nicht verschlechtert.
Falsch: Heute wird irgendwas ausgeblendet, dann wird bevorzugt etwas 
anderes ausgeblendet.

Klar: man kann dadurch nicht MEHR anzeigen, aber ANDERES.
Richtig ist zwar, dass sich die Lage nicht verschlechtert hat, 
verbessern wird sich dadurch aber auch nichts.

2. Ein Mapper kennzeichnet was als minor, was von anderen eher als main
gekennzeichnet werden wuerde ->  Das Element wird bei niedrigen Zoom-Stufen
eventuell von einigen Renderen nicht mehr angezeigt (bei vielen Typen wuerde ein
minor heute keinen Sinn machen und von einem Renderer deshalb auch nicht
beruecksichtigt werden.) ->  Ein andere Mapper wird das Element auf der Karte
vermissen und das Tagging entsprechen korregieren. Das ist genauso, wie Mapper
auch heute bei den Strassenkategorien unterschiedlicher Meinung sein koennen,
davon geht die OSM-Karte nicht unter.
Aber warum gibst du hier dem Mapper die Möglichkeit, bewusst zu 
entscheiden, dass etwas nicht gerendert werden soll?
Wenn jemand ein solches Element heute löscht, ist das Vandalismus und 
als solcher in OSM geächtet.
Wenn jemand nur dranpappt, dass das irrelevant ist, dann ist die Wirkung 
für einige, potenziell die wegweisenden Renderings die gleiche, aber du 
kannst es kaum noch als Vandalismus darstellen.

Gewonnen ist damit aber nichts.

Hier zeigt sich eben auch (mal wieder), dass das Konzept von der
OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe
nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration
zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für
Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre
aber ein Glanzpunkt, was die Konzept-Implementierung angeht.

Dem will ich nicht widersprechen, vorallem deshalb, weil ich nicht verstanden
habe, was du damit sagen willst ;-)
Die Mapnik-Karte wird von einigen OSM-Aktivisten (mich eingeschlossen) 
nicht in erster Linie als gute Karte angesehen.
Es geht nicht darum, dass die Standard-Stile auf osm.org die 
best-aussehenden Karten darstellen; es geht vielmehr darum, sichtbar zu 
machen, was mit OSM alles möglich ist.


Ein neuer Nutzer kommt auf die Webseite und sieht: "boah, da ist sogar 
der Fußgängerweg nebenan eingezeichnet - den hab ich sonst noch auf 
keiner Karte gesehen!".
Spannend in dem Zusammenhang gerade auch die Radfahrer- und ÖPNV-Karten 
- obwohl die nicht auf der Startseite zu sehen sind.


Auch die sind aus kartographischen Gesichtspunkten beurteilt keine 
herausragenden Werke; aber sie zeigen, was möglich ist.


Andererseits nutzen Mapper wie wir die Karten, um festzustellen, wo noch 
POIs fehlen oder wo Fehler zu beheben sind.
Wenn aber die technischen Möglichkeiten von Mapnik dahingehend genutzt 
(und insofern demonstriert) würden, dass Linienbündel zusammengefasst 
werden, dann gehen möglicherweise da wieder visuelle Informationen 
verloren, und ich kann die Frage, ob es sich jetzt um ein Eisenbahngleis 
oder eine mehrspurige Strecke handelt, möglicherweise nur noch schlecht 
beantworten.


Gruß
Peter

_

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Torsten Leistikow]

Peter Wendorff schrieb am 28.05.2011 19:17:
> Aber wenn ich nicht wichtiger taggen kann, dann tagge ich eben alle
> konkurrierenden Objekte als minder wichtig, um mein Ziel zu erreichen.

Das klappt deshalb nicht, weil ein Renderer ja gar nicht pauschal alles mit
minor markiertes unterdruecken wuerde, es kommt dabei ja immer noch zusaetzlich
auf den Typ des Objektes an.
Ausserdem wuerde damit ein Objekt ja auch nicht komplett aus der gerenderten
Karte verschwinden, sondern nur auf Zoom-Stufen, wo es in der Anzeige sowieso
mit einem anderen Objekt konkurrieren wuerde, d.h. mit guter Wahrscheinlichkeit
sowieso verdeckt waere.

Auch jetzt ist es so, dass ein Renderer ab einer bestimmten Zoom-Stufe
entscheidet, dass ein Objekt zu Gunsten der Uebersicht nicht mehr angezeigt
wird. Durch das Detail-Mapping haben wir nun aber immer haeufiger den Fall, dass
der Renderer allein aufgrund des Typs der Objekte nicht ausreichend auswaehlen
kann, was er weg lassen sollte (es gibt einfach zu viele gleichrangige Objekte).
Ist es da nicht sinnvoller, wem man als Mapper dem Renderer einen Tipp geben
kann, was er bei der Anzeige im Zweifelsfall unterdruecken koennte, als dass das
zufaellig passiert?

> Wie? Mapnik zeigt die Nachbarstraße an und nicht die Straße, in der ich
> wohne? dann tagge ich die Nachbarstraße eben als weniger wichtig.

Wenn man ein Objekt (eine Strasse) in der Anzeige bevorzugen moechte, dann hat
man auch heute schon die Moeglichkeit, an der Klassifizierung rumzuspielen.

> Die Mapnik-Karte wird von einigen OSM-Aktivisten (mich eingeschlossen)
> nicht in erster Linie als gute Karte angesehen.
> Es geht nicht darum, dass die Standard-Stile auf osm.org die
> best-aussehenden Karten darstellen; es geht vielmehr darum, sichtbar zu
> machen, was mit OSM alles möglich ist.

Mir geht es ja auch nicht darum, dass unbedingt die Mapnik-Karten besser
aussehen soll, das Problem betrifft naemlich auch alle anderen automatisch
erzeugten Karten. Wenn jemand also das Ziel hat, eine optisch moeglichst schoene
Karte zu erzeugen (im Gegensatz zu deinem Anspruch an die Standardkarte), dann
verbauen wir ihm dafuer jegliche Moeglichkeit.

Wenn wir den Mappern keine Moeglichkeit geben, in gewissen Grenzen die
Kartenansicht mit zu beeinflussen, dann neigen die Mapper dazu, zu diesem Zweck
die Daten zu verfaelschen (Mappen fuer den Renderer, haeufigster Fall ist da
sicherlich das Layer-Tag bei Flaechen). Das Problem ist bei einem Hilfstag
ausgeschlossen, wenn es per Definition fuer die Bedeutung des Elementes
irrelevant ist.

Gruss
Torsten

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 28.05.2011 09:41, schrieb Peter Wendorff:
Wir haben keinen Plasberg hier (oder? :D), aber ein Antrag an den 
erweiterten Faktencheck:
Man untersuche mal die OSM-Datenbank auf Überschneidungen von Tags und 
Tag-Gruppen. Also:
- Überschneiden sich landuses tatsächlich weitgehend NICHT mit 
highways? wenn doch, ist das ein Fehler oder eigentlich korrekt? Wenn 
es korrekt ist, ist hier der Layer eigentlich nicht machbar.

- Analog zu Routing-relevanten Tags (also im weitesten Sinne highway=*)

Wenn noch mehr Kapazität da wäre, würde ich weiter fragen - obwohl ich 
mir spätestens hier eigentlich auch selbst eine Antwort geben kann:
- Sind gleichzeitige (im Sinne von in-einem-changeset-getätigte) 
Änderungen an nur geometrisch naheliegenden Objekten (z.b. landuse und 
highway) voneinander unabhängig? Ich behaupte, das sind sie häufig 
nicht: Ich verschiebe den Weg und korrigiere die angrenzenden Flächen 
entsprechend (denn das Feld geht bis zum Straßenrand und auf der 
anderen Seite beginnt direkt neben der Straße das Fabrikgelände).
Vielleicht (!) bis zum Strassenrand, aber einen Randstreifen gibt es 
praktisch immer und ein highway = xx bezeichnet (als Linie) niemals 
einen Strassenrand sondern näherungsweise die Fahrbahn/Fahrstreifenmitte.
Trennt man jetzt aber die Layer, dann erschwert man dieses simultane 
Bearbeiten - und versteckt die dadurch provozierten Fehler eher vor 
dem Nutzer.
Nein, man verhindert somit dass sich ein Fehler auf den anderen Layer 
automatisch überträgt. Wenn ich z.b. eine Waldfläche bearbeite um die 
Konturen detaillierter zu erfassen ist es äusserst lästig wenn eine 
Strasse daran "klebt".


Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 29. Mai 2011 14:23 schrieb Garry :
> Am 28.05.2011 09:41, schrieb Peter Wendorff:
>> Trennt man jetzt aber die Layer, dann erschwert man dieses simultane
>> Bearbeiten - und versteckt die dadurch provozierten Fehler eher vor dem
>> Nutzer.
>
> Nein, man verhindert somit dass sich ein Fehler auf den anderen Layer
> automatisch überträgt. Wenn ich z.b. eine Waldfläche bearbeite um die
> Konturen detaillierter zu erfassen ist es äusserst lästig wenn eine Strasse
> daran "klebt".


eine Straßenmitte ist nie gleichzeitig ein Waldrand, von daher ist da
schon vorher irgendwo ein Fehler. Wenn man die Sachen auf
verschiedenen, getrennten Layern hat, dann kann man allerdings
topologische Zusammenhänge gar nicht mehr herstellen, von daher geht
das m.E. mit unserem Datenmodell sowieso nicht.

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Frederik Ramm]

Hallo,

On 05/31/11 12:45, M∡rtin Koppenhoefer wrote:

eine Straßenmitte ist nie gleichzeitig ein Waldrand, von daher ist da
schon vorher irgendwo ein Fehler.


Ich wehre mich gegen die Implikation, dass eine Generalisierung beim 
Mappen immer gleich ein "Fehler" sein muss.


Viele Mapper verwenden tatsaechlich eine Strassengeometrie als 
Flaechenbegrenzung. Das ist voellig in Ordnung, genauso wie es voellig 
in Ordnung ist, eine zweigleisige Bahntrasse als einzigen 
"railway=rail"-Way zu zeichnen. Es ist eine Ungenauigkeit, die den 
aktuell zur Verfuegung stehenden Mitteln oder der Erfassungsgenauigkeit 
oder der Arbeitsbereitschaft des Mappers geschuldet ist. Es ist kein 
"Fehler".


Bye
Frederik

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 31. Mai 2011 14:36 schrieb Frederik Ramm :
> Hallo,
>
> On 05/31/11 12:45, M∡rtin Koppenhoefer wrote:
>>
>> eine Straßenmitte ist nie gleichzeitig ein Waldrand, von daher ist da
>> schon vorher irgendwo ein Fehler.
>
> Ich wehre mich gegen die Implikation, dass eine Generalisierung beim Mappen
> immer gleich ein "Fehler" sein muss.
>
> Viele Mapper verwenden tatsaechlich eine Strassengeometrie als
> Flaechenbegrenzung. Das ist voellig in Ordnung, genauso wie es voellig in
> Ordnung ist, eine zweigleisige Bahntrasse als einzigen "railway=rail"-Way zu
> zeichnen. Es ist eine Ungenauigkeit, die den aktuell zur Verfuegung
> stehenden Mitteln oder der Erfassungsgenauigkeit oder der
> Arbeitsbereitschaft des Mappers geschuldet ist. Es ist kein "Fehler".


OK, es ist eine Ungenauigkeit, die man je nach Bezugsmaßstab als
topologischen Fehler werten kann, oder auch einfach nur als "vorläufig
grob" gemappt, einverstanden.

Prinzipiell bin ich bereit, Ungenauigkeiten, die z.B. aus der von Dir
genannten geringen "Arbeitsbereitschaft des Mappers" bzw. der
Erfassungsgenauigkeit resultieren, durchaus auch als Fehler zu werten
--- natürlich ohne dass daraus gleich eine Anklage wird.

Eine Straße ohne Namen, die eigentlich einen Namen hat, ist nicht
falsch, während ein falsch geschriebener Name klar falsch ist. Mit der
Topologie ist es ähnlich: nicht vorhandene Details (z.B. schludrig
gezeichneter Waldrand) sind erstmal nur unvollständig, während falsch
verbundene Dinge eben falsch sind. Weg-mitten können nie
Flächenbegrenzungen sein, dass sollte eigentlich klar sein. Ob man es
als Näherung akzeptieren will muss die Community abwägen.

Auf der einen Seite steht das einfachere und schnellere Mappen, auf
der anderen Seite führt diese Schludrigkeit zu falschen Flächengrößen
und oft auch zu weiteren Topologiefehlern (z.B. wenn der Waldrand
jetzt eingezäunt ist, machen manche einfach einen barrier=fence-tag an
den Waldrand, der in diesem Fall dann mitten auf der Straße läuft,
oder wenn weitere Objekte, die nicht zusammengehören, verbunden
werden, z.B. eine Querstraße mit dem Landuse anstatt mit der Straße).
Auch behindert es beim Ergänzen weiterer Details (wenn man aufnehmen
will, was zwischen Straße und Wald liegt).

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Frederik Ramm]

Hallo,

On 05/31/11 15:14, M∡rtin Koppenhoefer wrote:

Weg-mitten können nie
Flächenbegrenzungen sein, dass sollte eigentlich klar sein.


So, wie Du es geschrieben hast, mag das "klar" sein. Aber ein OSM-Way 
ist nicht "die Wegmitte", sondern eine Naeherungsdarstellung fuer die 
gesamte Strasse.


Frag jemanden, bis wohin der Wald geht, und derjenige sagt "bis zur 
Landstrasse". Dann *ist* die Landstrasse die Flaechenbegrenzung, und es 
ist voellig in Ordnung, die Landstrasse zur Flaechenbegrenzung zu nehmen.


Dass daraus dann etwas "Falsches" wird, wenn jemand den Way, der die 
Landstrasse repraesentiert, als "die Mitte der Landstrasse" 
interpretiert, das ist dessen Problem.


Bye
Frederik

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 31. Mai 2011 15:53 schrieb Frederik Ramm :
> Hallo,
>
> On 05/31/11 15:14, M∡rtin Koppenhoefer wrote:
>>
>> Weg-mitten können nie
>> Flächenbegrenzungen sein, dass sollte eigentlich klar sein.
>
> So, wie Du es geschrieben hast, mag das "klar" sein. Aber ein OSM-Way ist
> nicht "die Wegmitte", sondern eine Naeherungsdarstellung fuer die gesamte
> Strasse.


jedenfalls bis jemand kommt, und die Straßenflächen auch noch explizit
mappt (da gibt es ja einige, die das gerne wünschen bzw. wird es z.T.
auch schon gemacht).


> Frag jemanden, bis wohin der Wald geht, und derjenige sagt "bis zur
> Landstrasse". Dann *ist* die Landstrasse die Flaechenbegrenzung, und es ist
> voellig in Ordnung, die Landstrasse zur Flaechenbegrenzung zu nehmen.


naja, sprachlich ist derjenige halt auf etwas angewiesen, was der
andere wiedererkennen kann. Wenn ich jemanden frage: "wo ist der
Reichstag in Berlin?", und der sagt mir "neben dem Brandenburger Tor",
dann stimmt das ja auch ungefähr, aber trotzdem würde der
Durchschnittsmapper es gerne genauer eintragen.


> Dass daraus dann etwas "Falsches" wird, wenn jemand den Way, der die
> Landstrasse repraesentiert, als "die Mitte der Landstrasse" interpretiert,
> das ist dessen Problem.


Das "Problem" ist die Mischung von Graphen mit Flächen. Zwar ist das
unter anderem Blickwinkel auch eine Stärke, aber inwiefern so ein
Vorgehen in OSM gewünscht ist sollte man m.E. unter Abwägung der Vor-
und Nachteile in der Community abstimmen, so dass man wenigstens eine
klare Empfehlung abgeben kann - zu einer bestimmten Mappingweise kann
man ja sowieso niemanden zwingen.

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Torsten Leistikow]

Frederik Ramm schrieb am 31.05.2011 15:53:
> Aber ein OSM-Way
> ist nicht "die Wegmitte", sondern eine Naeherungsdarstellung fuer die
> gesamte Strasse.
> 
> Frag jemanden, bis wohin der Wald geht, und derjenige sagt "bis zur
> Landstrasse". Dann *ist* die Landstrasse die Flaechenbegrenzung, und es
> ist voellig in Ordnung, die Landstrasse zur Flaechenbegrenzung zu nehmen.
> 
> Dass daraus dann etwas "Falsches" wird, wenn jemand den Way, der die
> Landstrasse repraesentiert, als "die Mitte der Landstrasse"
> interpretiert, das ist dessen Problem.

Sehe ich genauso. Nach meiner Meinung gehoert also nur ein Abstand zwischen die
(als Linie erfasste) Strasse und eine Flaeche, wenn zwischen der Strasse und
dieser Flaeche noch ein anderes Objekt liegt, dass man spaeter zu erfassen 
gedenkt.

Bei einem Wald den Rand mit einer Genauigkeit < einer Fahrbahnbreite den Rand
festlegen zu wollen, ist sowieso muessig. Verlaeuft entlang der aeussersten
Borke eines Stammes der Waldrand? Ober ist der am weitesten hinausragende Zweig
der Rand des Waldes? Oder eine offizielle Flurstueckgrenze? Oder...

Gruss
Torsten

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 31. Mai 2011 16:26 schrieb Torsten Leistikow :

> Sehe ich genauso. Nach meiner Meinung gehoert also nur ein Abstand zwischen 
> die
> (als Linie erfasste) Strasse und eine Flaeche, wenn zwischen der Strasse und
> dieser Flaeche noch ein anderes Objekt liegt, dass man spaeter zu erfassen 
> gedenkt.


wer ist "man"? Praktisch jede Straße hat einen Graben, vor allem, wenn
durch einen Wald führt.


> Bei einem Wald den Rand mit einer Genauigkeit < einer Fahrbahnbreite den Rand
> festlegen zu wollen, ist sowieso muessig. Verlaeuft entlang der aeussersten
> Borke eines Stammes der Waldrand? Ober ist der am weitesten hinausragende 
> Zweig
> der Rand des Waldes? Oder eine offizielle Flurstueckgrenze?


m.E. ein Missverständnis, es ging um topologische Präzision nicht
darum, auf den cm genau den Waldrand angeben zu wollen. Dass wir z.T.
Probleme damit haben, die Ränder von Flächen genau zu bestimmen, hat
nichts damit zu tun, wie man Objekte untereinander miteinander
verknüpft. Wenn man schon keine Lust hat, den Waldrand zu bestimmen,
kann man genausogut (oder besser m.E.) einfach die Straße _durch_ den
Wald führen, also den Wald dort überhaupt nicht teilen und dadurch den
Generalisierungsgrad bereits angeben.

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Torsten Leistikow]

M∡rtin Koppenhoefer schrieb am 31.05.2011 16:36:
> Praktisch jede Straße hat einen Graben, vor allem, wenn
> durch einen Wald führt.

Dir ist schon klar, dass deine Formulierung impliziert, dass der Graben Teil der
Strasse ist?

> Wenn man schon keine Lust hat, den Waldrand zu bestimmen,
> kann man genausogut (oder besser m.E.) einfach die Straße _durch_ den
> Wald führen, also den Wald dort überhaupt nicht teilen und dadurch den
> Generalisierungsgrad bereits angeben.

Kann man auch. Haeufig bietet sich die Teilung des Waldes entlang von Strassen
nur aus rein pragmatsichen Gruenden an.

Interessanter sind sicherlich Faelle, wo nur auf beiden Seiten der Strasse
unterschiedliche Objekte angrenzen.

Gruss
Torsten

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 31. Mai 2011 16:53 schrieb Torsten Leistikow :

> Interessanter sind sicherlich Faelle, wo nur auf beiden Seiten der Strasse
> unterschiedliche Objekte angrenzen.


ja, und wenn da nun auf der einen Seite ein Wald und auf der anderen
ein Feld angeschlossen wird, dann grenzen die beiden in OSM direkt
aneinander (gemeinsame Nodes), während Du in der Realität eine Straße
_dazwischen_ hast. Klar, solche "Fehler" kann man auch durch Analyse
beseitigen.

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Frederik Ramm]

Hallo,

On 05/31/11 18:20, M∡rtin Koppenhoefer wrote:

ja, und wenn da nun auf der einen Seite ein Wald und auf der anderen
ein Feld angeschlossen wird, dann grenzen die beiden in OSM direkt
aneinander (gemeinsame Nodes)


Da sehe ich nun auch wieder gar kein Problem. Von mir aus soll sich 
jeder das Leben so schwer machen, wie er will, solang er es nicht 
*anderen* schwer macht.


Bye
Frederik

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 31. Mai 2011 18:26 schrieb Frederik Ramm :
> Von mir aus soll sich jeder
> das Leben so schwer machen, wie er will, solang er es nicht *anderen* schwer
> macht.


das war ja der Ansatzpunkt: m.E. macht man den anderen das Leben
schwer, wenn man Dinge verbindet, die gar nicht verbunden sind, und
man für kleine Verfeinerungen erstmal die nicht zusammengehörigen
Objekte mühsam auftrennen muss. Oder wenn man Multipolygonmonster für
landuse=residential (etc.) anlegt, wo klare Flächen ausreichend wären.

Auf dem Land mag das noch eher angehen, da man sowieso erstmal nicht
flächendeckend von einer hohen Detaillierung ausgehen kann, aber in
der Stadt führt das oft dazu, dass sich Folgefehler einschleichen.
M.E. ist das Mappen von Flächen in ihren wahren Grenzen die Methode,
die am besten skaliert und sich am einfachsten "weitermappen" lässt.
Multipolygone, wie oft gesehen z.B. für landuses, entwickeln sich im
Laufe des Mappens immer mehr zu unübersichtlichen Monstern (die kaum
von einem neuen Mapper durchdrungen werden können), während meistens
klare schlichte Flächen ausreichend und aussagekräftiger wären.

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Torsten Leistikow]

M∡rtin Koppenhoefer schrieb am 31.05.2011 18:20:
> ja, und wenn da nun auf der einen Seite ein Wald und auf der anderen
> ein Feld angeschlossen wird, dann grenzen die beiden in OSM direkt
> aneinander (gemeinsame Nodes), während Du in der Realität eine Straße
> _dazwischen_ hast. Klar, solche "Fehler" kann man auch durch Analyse
> beseitigen.

Guter Punkt.

Wenn man die Flaechen bis zur (linienfoermigen) Strasse eintraegt, dann kann man
in der Auswertung erkennen, dass Strasse und Flaeche gemeinsame Knotenpunkte
haben und daraus kann man die Topologie konstruieren.

Wenn man dagegen die Flaeche in einem Abstand von der Strassenlinie enden
laesst, ist man in der Auswertung ziemlich aufgeschmissen.

Nachteil von diesem Argument ist leider, dass die logische Schlussfolgerung
daraus ist, Flaechen grundsaetzlich als Multipolygon einzutragen, damit man die
einzelnen Grenzlinien gleich fertig geliefert bekommt.
Das kann man allerdings dadurch entkraeften, dass man so eine
Wer-grenzt-an-wen-Analyse normalerweise nicht braucht, die reinen
Flaechenauswertungen mit diesem
Ansatz aber erheblich aufwendiger macht.

Gruss
Torsten

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 31.05.2011 12:45, schrieb M∡rtin Koppenhoefer:


eine Straßenmitte ist nie gleichzeitig ein Waldrand, von daher ist da
schon vorher irgendwo ein Fehler. Wenn man die Sachen auf
verschiedenen, getrennten Layern hat, dann kann man allerdings
topologische Zusammenhänge gar nicht mehr herstellen, von daher geht
das m.E. mit unserem Datenmodell sowieso nicht.
Es spricht ja nichts dagegen dass man die verschiedene Layer 
gleichzeitig darstellt.
Es würde aber Sinn machen dass man Layer die nichts miteinander zu tun 
haben nicht gleichzeitig bearbeiten kann
um nicht genaue Daten (z.B. genauer Strassenmittenverlauf) wieder mit 
ungenauen Daten (grob abgezeichnerter Waldgrenzenverlauf)

zu "verschlimmbessern"...

Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Sebastian Hohmann]

Am 31.05.2011 18:41, schrieb M∡rtin Koppenhoefer:

Am 31. Mai 2011 18:26 schrieb Frederik Ramm:

Von mir aus soll sich jeder
das Leben so schwer machen, wie er will, solang er es nicht *anderen* schwer
macht.



das war ja der Ansatzpunkt: m.E. macht man den anderen das Leben
schwer, wenn man Dinge verbindet, die gar nicht verbunden sind, und
man für kleine Verfeinerungen erstmal die nicht zusammengehörigen
Objekte mühsam auftrennen muss.


Das kann aber auch andersrum passieren. Wenn man weiß die Straße bildet 
die Grenze zwischen z.B. Wald und Wohngebiet und man die Lage der Straße 
verfeinern will, ist es eventuell sogar erwünscht, dass sich die Flächen 
mitbewegen. Bei nicht verbundenen Dingen kann es dann aufwändiger sein, 
da man mehr einzelne Nodes korrigieren muss. Oder es ergeben sich sogar 
Fehler, wenn man die Flächen eben nicht auch korrigiert (dass z.B. eine 
Fläche über die Straße ragt, obwohl das in der Realität nicht der Fall ist).


Gruß

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Carsten Schönert]

Tachen

Am 02.06.2011 15:50, schrieb Sebastian Hohmann:

Das kann aber auch andersrum passieren. Wenn man weiß die Straße bildet
die Grenze zwischen z.B. Wald und Wohngebiet und man die Lage der Straße
verfeinern will, ist es eventuell sogar erwünscht, dass sich die Flächen
mitbewegen.


Wenn Du einmal in einem Stadteil oder Dorf das alles auseinander tröseln 
durftest weil da was zusammen gepappt war was nicht zusammen gehört und 
Du dann Dich auch gleich noch um zwei Radwegrelationen, vier 
Busrelationen und sonstige Flächenbezogene Relationen mit kümmern darfst 
wirst Du darüber möglicher Weise anders denken. Dann macht eine Kreuzung 
mal richtig Arbeit. Und auf der Karte siehst Du dann nicht mal das da 
was geändert werden (musste).


Ich sehe das so wie meine Vorschreiber, ein Fläche gehört nicht an einen 
Weg. Mir vergeht bei solchen Konstrukten recht schnell die Lust 
inzwischen da überhaupt Hand anzulegen.


--
Mit freundlichen Grüßen
Carsten Schönert

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter]

Hi

Am 02.06.2011 17:41, schrieb Carsten Schönert:

Am 02.06.2011 15:50, schrieb Sebastian Hohmann:



Das kann aber auch andersrum passieren. Wenn man weiß die Straße bildet
die Grenze zwischen z.B. Wald und Wohngebiet und man die Lage der Straße
verfeinern will, ist es eventuell sogar erwünscht, dass sich die Flächen
mitbewegen.


Wenn Du einmal in einem Stadteil oder Dorf das alles auseinander tröseln
durftest weil da was zusammen gepappt war was nicht zusammen gehört und
Du dann Dich auch gleich noch um zwei Radwegrelationen, vier
Busrelationen und sonstige Flächenbezogene Relationen mit kümmern darfst
wirst Du darüber möglicher Weise anders denken. Dann macht eine Kreuzung
mal richtig Arbeit. Und auf der Karte siehst Du dann nicht mal das da
was geändert werden (musste).

Ich sehe das so wie meine Vorschreiber, ein Fläche gehört nicht an einen
Weg. Mir vergeht bei solchen Konstrukten recht schnell die Lust
inzwischen da überhaupt Hand anzulegen.


Ja wird eklig.

Man kommt auf die Idee das Josm da einem viel Arbeit abnehmen könnte.

z.B. 2 Objekte markieren und 'Alle gemeinsamen Punkte trennen'
Oder auch mehrere Objekte als nur 2.
So als Featurerequest.

Müsste man noch bischen rumdenken und probieren ob es noch eine
allgemeinere Möglichkeit gibt.
z.B. 'Alle gemeinsamen Punkte markieren'. Danach dann 'trennen'
aufrufen. Das hätte den Vorteil das man dann auch die gemeinsamen
Punkte gemeinsam bewegen könnte. So hat man beide Fälle erledigt:
Getrennte Punkte haben wollend oder halt gemeinsame Punkte.


Vielleicht geht ja auch schon alles. Z.B. mit Filtern nur die
beteiligten Objekte anzeigen lassen, dann alle Punkte markieren,
dann trennen. Aber da kommt leicht zu viel dabei und es werden
dann die falschen Dinge getrennt.

Die erste Idee oben scheint da ganz ok.


Und vielleicht mal irgendwo aufschreiben wie das gemappt werden
sollte und: Warum! Nur mit Verständnis kann man sich das merken
und es wird eher befolgt.

Peter


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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[fly]

Am 02.06.2011 18:54, schrieb Peter:
> Ja wird eklig.

+1

> Man kommt auf die Idee das Josm da einem viel Arbeit abnehmen könnte.
> 
> z.B. 2 Objekte markieren und 'Alle gemeinsamen Punkte trennen'
> Oder auch mehrere Objekte als nur 2.
> So als Featurerequest.
> 
> Müsste man noch bischen rumdenken und probieren ob es noch eine
> allgemeinere Möglichkeit gibt.
> z.B. 'Alle gemeinsamen Punkte markieren'. Danach dann 'trennen'
> aufrufen. Das hätte den Vorteil das man dann auch die gemeinsamen
> Punkte gemeinsam bewegen könnte. So hat man beide Fälle erledigt:
> Getrennte Punkte haben wollend oder halt gemeinsame Punkte.
> 
> 
> Vielleicht geht ja auch schon alles. Z.B. mit Filtern nur die
> beteiligten Objekte anzeigen lassen, dann alle Punkte markieren,
> dann trennen. Aber da kommt leicht zu viel dabei und es werden
> dann die falschen Dinge getrennt.

Das Auftrennen ist bereits implementiert. Auf jeden Fall lohnt sich ein
Blick auf den utils2-Plugin.
Falls man nicht fündig wird, ist wohl ein Enhancement-Ticket angebracht,
wobei ein patch auch gerne gesehen wird.

Gruß
fly

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 3. Juni 2011 14:36 schrieb fly :
> Das Auftrennen ist bereits implementiert. Auf jeden Fall lohnt sich ein
> Blick auf den utils2-Plugin.


ja, das ist eine große Hilfe (davor war das Trennen mit komplexeren
Operationen aus Löschen, Kopieren, Teilen und Einfügen ja eine rechte
Qual), teilweise wird man aber Probleme mit Relationen bekommen (die
nach dem Auftrennen beide Teile als Member haben). Es ist einfach
keine gute Idee, landuses an Straßen zu hängen ;-)

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 02.06.2011 15:50, schrieb Sebastian Hohmann:

Am 31.05.2011 18:41, schrieb M∡rtin Koppenhoefer:

Am 31. Mai 2011 18:26 schrieb Frederik Ramm:

Von mir aus soll sich jeder
das Leben so schwer machen, wie er will, solang er es nicht 
*anderen* schwer

macht.



das war ja der Ansatzpunkt: m.E. macht man den anderen das Leben
schwer, wenn man Dinge verbindet, die gar nicht verbunden sind, und
man für kleine Verfeinerungen erstmal die nicht zusammengehörigen
Objekte mühsam auftrennen muss.


Das kann aber auch andersrum passieren. Wenn man weiß die Straße 
bildet die Grenze zwischen z.B. Wald und Wohngebiet und man die Lage 
der Straße verfeinern will, ist es eventuell sogar erwünscht, dass 
sich die Flächen mitbewegen. Bei nicht verbundenen Dingen kann es dann 
aufwändiger sein, da man 
Das ist nur dann der Fall wenn der Wald schon voehrher falsch erfasst 
wurde und vorher am Verlauf der Strasse "festgenagelt"wurde..
mehr einzelne Nodes korrigieren muss. Oder es ergeben sich sogar 
Fehler, wenn man die Flächen eben nicht auch korrigiert (dass z.B. 
eine Fläche über die Straße ragt, obwohl das in der Realität nicht der 
Fall ist).
Man kann nur die Aussagetreffen dass die Strasse fälschlicherweise die 
Strasse überdeckt, mehr auch nicht, Es kann genausogut die Strasse als 
auch der Wald falsch erfasst sein. Das eine dem anderen anzupassen ist 
also eine Mappen für den Renderer...


Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 03.06.2011 15:06, schrieb M∡rtin Koppenhoefer:

Am 3. Juni 2011 14:36 schrieb fly:

Das Auftrennen ist bereits implementiert. Auf jeden Fall lohnt sich ein
Blick auf den utils2-Plugin.


ja, das ist eine große Hilfe (davor war das Trennen mit komplexeren
Operationen aus Löschen, Kopieren, Teilen und Einfügen ja eine rechte
Qual), teilweise wird man aber Probleme mit Relationen bekommen (die
nach dem Auftrennen beide Teile als Member haben). Es ist einfach
keine gute Idee, landuses an Straßen zu hängen ;-)

+1
Eine Fehlermeldung in josm & Co währe sinnvoll wenn es trotzdem jemand 
versucht...


Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Frederik Ramm]

Hallo,

M?rtin Koppenhoefer wrote:

Es ist einfach
keine gute Idee, landuses an Straßen zu hängen ;-)


Kommt drauf an, beide Methoden haben ihre Vor- und Nachteile und ihre 
Berechtigung.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 5. Juni 2011 02:12 schrieb Frederik Ramm :
> M?rtin Koppenhoefer wrote:
>> Es ist einfach
>> keine gute Idee, landuses an Straßen zu hängen ;-)
>
> Kommt drauf an, beide Methoden haben ihre Vor- und Nachteile und ihre
> Berechtigung.


Im Prinzip stimme ich dem auf kurze Zeit gesehen zu. Sicherlich hat
(vor allem kurzfristig) auch das Wiederverwenden von Geometrie in der
Nähe bestimmte Vorteile, trotzdem würden mich die Implikationen
interessieren, die sich für den Mapper daraus ergeben:
Meinst Du damit, dass sie gleichwertig sind, und dass es demzufolge in
Ordnung ist, wenn man Stellen, wo jemand den Wald an der tatsächlichen
Wald-Grenze enden lässt, vereinfacht / generalisiert (z.B. mit dem
Hinweis, dass das die Verarbeitung beschleunigt bzw. den
Speicherbedarf reduziert), indem man die Waldgrenze löscht und den
Wald per Multipolygon über eine in der Nähe verlaufende Straße
umdefiniert?

Langfristig (und so habe ich die Aussage gemeint) ist es dennoch keine
gute Idee m.E., weil wie erwähnt weiteres Verfeinern unnötig
kompliziert wird (und je nach Größe der entstehenden Multipolygone
neben der Ungenauigkeit auch erheblicher Verarbeitungsmehraufwand
entsteht, da selbst kleine Kacheln ggf. riesige Multipolygone
enthalten, die weit über den eigentlichen Kachelbereich hinaus gehen).
M.E. bremst uns diese Mappingtechnik mittel- und langfristig eher, als
dass es das Mapping vereinfacht und beschleunigt.

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Sebastian Hohmann]

Am 05.06.2011 00:28, schrieb Garry:

Es kann genausogut die Strasse als
auch der Wald falsch erfasst sein. Das eine dem anderen anzupassen ist
also eine Mappen für den Renderer...



Was hat das mit Mappen für den Renderer zu tun, Objekte im Verhältnis 
zueinander korrekt zu positionieren? Erfassungsungenauigkeiten gibt es 
immer, aber wenigstens die relative Lage kann man durch Beobachtung in 
der Realität korrekt eintragen. Genauso wie man auch vermeintliche 
Kurven im GPS-Track zu Geraden macht, wenn da eben keine Kurve ist.


Und wenn die Straße genau die Grenze zwischen Wald und Wohngebiet 
darstellt, erfasst man eben die Straße. Wenn die Straße vom Verlauf her 
nicht korrekt aufgezeichnet ist, ist dann eben auch der Wald falsch. Es 
geht nicht um einen Waldrand, der 20 Meter von der Straße entfernt liegt 
und sinnvoll seperat erfasst werden kann.





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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Frederik Ramm]

Hi,

On 06/06/11 12:12, M?rtin Koppenhoefer wrote:

Meinst Du damit, dass sie gleichwertig sind, und dass es demzufolge in
Ordnung ist, wenn man Stellen, wo jemand den Wald an der tatsächlichen
Wald-Grenze enden lässt, vereinfacht / generalisiert (z.B. mit dem
Hinweis, dass das die Verarbeitung beschleunigt bzw. den
Speicherbedarf reduziert), indem man die Waldgrenze löscht und den
Wald per Multipolygon über eine in der Nähe verlaufende Straße
umdefiniert?


Ja, aber nicht als Selbstzweck. Wenn jemand in einer Gegend etwas mappen 
will und in seiner Arbeit davon behindert wird, dass jemand anders jedes 
Polygon an seiner vermeintlich tatsaechlichen Grenzen enden liess, dann 
hat derjenige durchaus das Recht, das an den Stellen zu aendern, die er 
aus anderen Gruenden anfassen muss - eben weil es keine Frage von 
richtig oder falsch, sondern eine des persoenlichen Stils ist.



Langfristig (und so habe ich die Aussage gemeint) ist es dennoch keine
gute Idee m.E., weil wie erwähnt weiteres Verfeinern unnötig
kompliziert wird


Ja, das wird oft behauptet, aber je nach Art des weiteren Verfeinerns, 
dass man im Sinn hat, kann es eben auch genau andersrum sein. Wenn ich 
die Strassengeometrie verfeinere, bin ich vielleicht ganz froh, wenn die 
Waldgeometrie dabei automatisch mitverfeinert wird, statt dass ich jeden 
Zusatznode, den ich platziere, dreimal setzen muss.



M.E. bremst uns diese Mappingtechnik mittel- und langfristig eher, als
dass es das Mapping vereinfacht und beschleunigt.


Ja, das behauptest Du immer wieder, aber das ist halt eine Beurteilung, 
die Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die 
werden eventuell davon eben nicht gebremst, sondern denen geht die 
Arbeit schneller von der Hand.


Ich will in dieser Sache niemandem etwas vorschreiben, aber ich wehre 
mich auch dagegen, wenn *andere* hier Vorschriften aufstellen (a la "na 
gut, voruebergehend darfst Du das so machen, aber Du musst Dir schon 
bewusst sein, dass das schlechter ist...").


Deswegen widerspreche ich Dir auch dauernd, weil Du genau das so 
zwischen den Zeilen tust.


Und die diversen Argumente dafuer, dass das eine richtiger sein sollte 
als das andere ("... oder wachsen die Baeume bis zum Mittelstreifen?"), 
halte ich fuer rhetorische Spitzfindigkeiten und nicht fuer echte 
Argumente. Das ist auf der gleichen Ebene wie "... oder willst Du etwa 
behaupten, diese Kurve hier bestehe aus genau 20 kleinen geraden 
Stuecken?" - natuerlich tut sie das nicht, aber das hat ja auch keiner 
behauptet.


Bye
Frederik

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

> On 06/06/11 12:12, M?rtin Koppenhoefer wrote:
>> Meinst Du damit, dass sie gleichwertig sind, und dass es demzufolge in
>> Ordnung ist, wenn man Stellen, wo jemand den Wald an der tatsächlichen
>> Wald-Grenze enden lässt, vereinfacht / generalisiert (z.B. mit dem
>> Hinweis, dass das die Verarbeitung beschleunigt bzw. den
>> Speicherbedarf reduziert), indem man die Waldgrenze löscht und den
>> Wald per Multipolygon über eine in der Nähe verlaufende Straße
>> umdefiniert?
>
> Ja, aber nicht als Selbstzweck. Wenn jemand in einer Gegend etwas mappen
> will und in seiner Arbeit davon behindert wird, dass jemand anders jedes
> Polygon an seiner vermeintlich tatsaechlichen Grenzen enden liess, dann hat
> derjenige durchaus das Recht, das an den Stellen zu aendern, die er aus
> anderen Gruenden anfassen muss - eben weil es keine Frage von richtig oder
> falsch, sondern eine des persoenlichen Stils ist.


das verstehe ich jetzt nicht, inwiefern man durch genauere Grenzen
behindert werden kann, wo Flächen nicht mit Straßengraphen verbunden
sind. Hättest Du da mal ein Beispiel?

Den "persönlichen Stil" (gut dass Du es ansprichst) gibt es durchaus.
Es ist unumgänglich gewisse Abstraktionen einzuführen. Wo man aber mit
wenige Clicks stundenlange Arbeit von anderen kaputtmachen kann in
einem Punkt, der wie Du sagst sowohl als auch "richtig" ist (sein
kann), da erfordert es der Respekt vor der Arbeit der anderen, dass
man den persönlichen Stil etwas an das anpasst, was man schon
vorfindet (solange es nur um Stil und nicht um Verbesserungen geht).
Dieses Thema ist da ganz gut vergleichbar mit der Frage, wie sog.
straßenbegleitende Radwege gemappt werden sollen. Da ärgert es mich
z.B. auch ziemlich, wenn (wie vor einiger Zeit geschehen) ein Mapper
einen explizit gemappten Radweg (einschl. weiterer Details wie
Fahrbahnoberfläche, kreuzende Einfahrten, leicht abweichende
Verkehrsführung, etc., --- der Weg war da über Jahre und von zig
Mappern weiterverfeinert) löscht und durch ein schnödes cycleway=track
ersetzt. Auf die 2. Anfrage per PM antwortet der dann: da war kein
Platz. Wie? Wo war da kein Platz? Dass die Topologie fürs Routing
dadurch teilweise zerschossen wurde sei nur am Rande erwähnt (Zugang
zu einem Fußgängerplatz der als Durchgang durch den Block auch von
Fahrrädern genutzt wird).

Es ist sicher eine Frage des Maßstabs (und der damit einhergehenden
Generalisierung), wie man mappt. Der Maßstab wird in OSM durch die
Genauigkeit dessen vorgegeben, was die Koordinaten hergeben, und evlt.
von den bestehenden Renderings (Mapnik derzeit bis z.18 ca. 1:2000,
andere Karten nutzen OSM probeweise sogar bis Z.21) , sehe ich nicht,
inwiefern man einer Reduktion der Detaillierung und stärkeren
Generalisierung im Bereich der Daten der Datenbank Positives
abgewinnen könnte. Eine derart grobe Generalisierung wie man sie
gelegentlich antrifft ist m.E. sinnvoll für z14 und weniger.


>> Langfristig (und so habe ich die Aussage gemeint) ist es dennoch keine
>> gute Idee m.E., weil wie erwähnt weiteres Verfeinern unnötig
>> kompliziert wird
> Ja, das wird oft behauptet, aber je nach Art des weiteren Verfeinerns, dass
> man im Sinn hat, kann es eben auch genau andersrum sein.


wenn man die Straßen zusätzlich als Flächen eintragen will, ist die
Lage sicher eindeutig. Aus meiner Sicht wird das in Städten auf jeden
Fall kommen, weil man anders ein sauberes Rendering, das auch
Informationen zur realen Form transportiert, nicht erhalten kann.


> Wenn ich die
> Strassengeometrie verfeinere, bin ich vielleicht ganz froh, wenn die
> Waldgeometrie dabei automatisch mitverfeinert wird, statt dass ich jeden
> Zusatznode, den ich platziere, dreimal setzen muss.


da der Wald nichts mit der Straße zu tun hat, muss ich den auch nicht
verfeinern, wenn ich an der Straße schraube. Straßenkurven haben daher
z.B. bei mir oft auch mehr Punkte als ein Waldrand. Klar, ein Zaun der
an der Straße langläuft müsste evtl. verfeinert werden, aber diesen
Zaun könnte ich nicht mal einzeichnen ohne dass ich einen
Topologie-Fehler einbaue, solange die Nachbar-Fläche an der Straße
hängt.


>> M.E. bremst uns diese Mappingtechnik mittel- und langfristig eher, als
>> dass es das Mapping vereinfacht und beschleunigt.
> Ja, das behauptest Du immer wieder, aber das ist halt eine Beurteilung, die
> Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die werden
> eventuell davon eben nicht gebremst, sondern denen geht die Arbeit schneller
> von der Hand.


sicher gehen einem manche Bearbeitungen schneller von der Hand, wenn
man sie ungenau macht.


> Ich will in dieser Sache niemandem etwas vorschreiben, aber ich wehre mich
> auch dagegen, wenn *andere* hier Vorschriften aufstellen (a la "na gut,
> voruebergehend darfst Du das so machen, aber Du musst Dir schon bewusst
> sein, dass das schlechter ist...").


ist meine ehrliche Meinung. (Habe ich durch das "m.E." ja kenntlich
gemacht). Ich schreibe nur deshalb auch immer wieder zu diesem Thema,
weil ich zutiefs

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Frederik Ramm]

Hallo,

M?rtin Koppenhoefer wrote:

das verstehe ich jetzt nicht, inwiefern man durch genauere Grenzen


Dass eine als einzelne Linie gezeichnete Grenze "genauer" ist als die 
Verwendung der Strassengeometrie, ist mitnichten erwiesen.



behindert werden kann, wo Flächen nicht mit Straßengraphen verbunden
sind. Hättest Du da mal ein Beispiel?


Nein, aber ich habe Leute sagen hoeren, was ich in meinem vorigen 
Posting schrieb: Dass jemand keine Lust hat, eine Strassengeometrie zu 
verfeinern, wenn sich dadurch tonnenweise Ueberschneidungen mit dem 
angrenzenden Wald ergeben und er die von Hand zusaetzlich korrigieren muss.


Entweder es gibt solche Mapper, die sich behindert fuehlen. Dann sollen 
die von mir aus gern die Gegend so (um)mappen, dass sie gut damit 
arbeiten koennen.


Oder es gibt sie nicht. Dann ist es auch recht.


kann), da erfordert es der Respekt vor der Arbeit der anderen, dass
man den persönlichen Stil etwas an das anpasst, was man schon
vorfindet (solange es nur um Stil und nicht um Verbesserungen geht).


Ja, das kommt sicher auf den Umfang der Aenderungen an. Einem Gebiet 
seinen persoenlichen Stil aufdruecken, weil man gerade mal im 
Vorbeifahren einen Briefkasten mappt, ist natuerlich nicht ok.



andere Karten nutzen OSM probeweise sogar bis Z.21) , sehe ich nicht,
inwiefern man einer Reduktion der Detaillierung 


Ich glaube, Du hast da eine etwas verkorkste Perspektive. Du scheinst 
anzunehmen, dass alles, was jemand vom Luftbild abmalt, automatisch 
hochgenau und detailliert ist. Ich wage mal die Behauptung: Der Fehler, 
in Metern, den ich einbaue, wenn ich den Strassen-Way als Begrenzung 
meines Waldes nehme, ist im Durchschnitt geringer als der Fehler, den 
ich einbaue, wenn ich das (Bing-)Luftbild nicht vorher ordentlich an 
GPS-Tracks justiere.



Ja, das wird oft behauptet, aber je nach Art des weiteren Verfeinerns, dass
man im Sinn hat, kann es eben auch genau andersrum sein.


wenn man die Straßen zusätzlich als Flächen eintragen will, ist die
Lage sicher eindeutig.


Das ist eine ganz andere Baustelle.


Aus meiner Sicht wird das in Städten auf jeden
Fall kommen, weil man anders ein sauberes Rendering, das auch
Informationen zur realen Form transportiert, nicht erhalten kann.


Informationen zur realen Form zu transportieren, ist unter Umstaenden 
aber etwas anderes als "sauberes Rendering". Und "sauberes Rendering" 
bekommt man ganz bestimmt auch ohne Strassen als Flaechen hin. Aber das 
ist, wie gesagt, wieder eine andere Geschichte.


Eine Karte ist kein Luftbild. Auch eine sehr gute Karte nicht.


da der Wald nichts mit der Straße zu tun hat, muss ich den auch nicht
verfeinern, wenn ich an der Straße schraube.


Andere muessen das vielleicht schon (wenn, wie oben geschildert, die 
verfeinerte Strasse sonst zuweilen den Wald ueberschneidet, was ja eher 
selten ist.)



Klar, ein Zaun der
an der Straße langläuft müsste evtl. verfeinert werden


Wenn wir es mit einem Zaun zu tun haben, dann hoert das natuerlich auf, 
dass man die Strasse als Waldrand benutzen kann. Aber dann haben wir das 
gleiche Ding mit dem Zaun; man koennte dann einfach den Zaun als 
Waldrand benutzen, oder man koennte argumentieren, dies sei ungenau und 
der Zaun stehe ja ausserhalb des Waldes..



Ja, das behauptest Du immer wieder, aber das ist halt eine Beurteilung, die
Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die werden
eventuell davon eben nicht gebremst, sondern denen geht die Arbeit schneller
von der Hand.


sicher gehen einem manche Bearbeitungen schneller von der Hand, wenn
man sie ungenau macht.


Du behauptest immer wieder, dass es ungenauer sei, den Strassen-Way als 
Waldrand zu verwenden, aber das ist eine unzulaessige Verallgemeinerung. 
Oder sagen wir: Es ist vielleicht genauer, aber nicht richtiger - 
genauso wie eine Loesung mit fuenf Nachkommastellen in der Matheklausur 
genauer ist, aber nicht richtiger.



Die Auswüchse, die sich aus den Relationen ergeben, wenn man erstmal
ein paar Landkreise als ein Farmland kennzeichnet, und danach alles
was nicht passt (und einem auffällt) wieder ausschließt (also landuse
Relationen, die schon ein Jahr oder so alt sind), behindern die
Entwicklung der Karte ungemein. 


Ja, da gibt es eine Menge Stilblueten, die ich auch nicht so prickelnd 
finde. Aber mit der Verwendung einer Strasse als Waldrand o.ae. hat das 
m.E. wieder nichts zu tun.



Es geht nicht um rhetorische Spitzfindigkeiten, das Argument war, dass
echte Flächengrößen mehr Informationen transportieren als durch
Generalisierung vergrößerte.


Der Unterschied duerfte im *Promillebereich* sein.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 6. Juni 2011 17:42 schrieb Frederik Ramm :
> Dass eine als einzelne Linie gezeichnete Grenze "genauer" ist als die
> Verwendung der Strassengeometrie, ist mitnichten erwiesen.


OK, verstanden. Gut, es gibt im OSM-Umfeld natürlich _alles_ ;-) Auf
dem Weg zu einer guten Annäherung ist man aber i.d.R. schon mit dem
gröbsten Wald näher als mit gar keiner "echten" Flächengrenze.


> Dass jemand keine Lust hat, eine Strassengeometrie zu verfeinern,
> wenn sich dadurch tonnenweise Ueberschneidungen mit dem angrenzenden Wald
> ergeben und er die von Hand zusaetzlich korrigieren muss.


Wieso sollte das jetzt ein Problem sein, wenn die Straße z.T. durch
das Waldpolygon führt (bis es jemand richtet), während bei der anderen
Methode die komplette Straße im Wald läuft? Man muss ja nicht alles
alleine machen, diese "tonnenweisen" Überschneidungen haben keine
negativen Auswirkungen, ausser, dass sie Ungenauigkeiten aufzeigen,
die man zukünftig noch durch Verfeinerung beheben kann.


> Ich glaube, Du hast da eine etwas verkorkste Perspektive. Du scheinst
> anzunehmen, dass alles, was jemand vom Luftbild abmalt, automatisch
> hochgenau und detailliert ist. Ich wage mal die Behauptung: Der Fehler, in
> Metern, den ich einbaue, wenn ich den Strassen-Way als Begrenzung meines
> Waldes nehme, ist im Durchschnitt geringer als der Fehler, den ich einbaue,
> wenn ich das (Bing-)Luftbild nicht vorher ordentlich an GPS-Tracks justiere.


Klar, die Lagegenauigkeit von Luftbildern ist nicht grundsätzlich gut,
und Fehler aus der Orthorektifizierung des Luftbilds kann man auch
durch nachträgliches Justieren (Verschieben) nicht mehr beheben. Da
haben wir in Italien einen gewissen Vorsprung, weil wir mit dem PCN
wirklich flächendeckend einheitliche Luftbilder haben (2006) und für
manche Gebiete auch von 2008, die sehr gut positioniert und
vorverarbeitet sind. Bing bietet einem im Vergleich in der Fläche
deutlich weniger und schlechter (Position/Alter) (in Rom aber z.B. z21
was für Details schon nicht zu verachten ist).

Viele Dinge kann man aber auch ohne Luftbilder genau zeichnen, oft
sogar aus dem Gedächtnis (bzw. anhand von Fotos und Aufzeichnungen,
die man vor Ort gemacht hat). Wie genau man mappt hat höchstens zu
einem Teil mit den Bildern zu tun, die man als Vorlage hat, eher mit
den Details, die einem bei der Begehung auffallen.


>> wenn man die Straßen zusätzlich als Flächen eintragen will, ist die
>> Lage sicher eindeutig.
> Das ist eine ganz andere Baustelle.


m.E. ist das genau dieselbe Baustelle: wenn man jetzt alle Flächen an
die Straßen hängt, wird man sie später alle wieder abhängen müssen.


> Informationen zur realen Form zu transportieren, ist unter Umstaenden aber
> etwas anderes als "sauberes Rendering". Und "sauberes Rendering" bekommt man
> ganz bestimmt auch ohne Strassen als Flaechen hin. Aber das ist, wie gesagt,
> wieder eine andere Geschichte.


jein, solange die Straßen regelmäßig sind, braucht man praktisch keine
Straßenflächen (selbst Spurerweiterungen -reduktionen folgen ja
Gesetzmäßigkeiten), wenn aber der Verkehrsraum seine Linearität
verliert und zu einer weitgehend ungerichteten Fläche wird, dann geht
es ohne natürlich nicht.


> Eine Karte ist kein Luftbild. Auch eine sehr gute Karte nicht.


+1.


>> Klar, ein Zaun der
>> an der Straße langläuft müsste evtl. verfeinert werden
>
> Wenn wir es mit einem Zaun zu tun haben, dann hoert das natuerlich auf, dass
> man die Strasse als Waldrand benutzen kann. Aber dann haben wir das gleiche
> Ding mit dem Zaun; man koennte dann einfach den Zaun als Waldrand benutzen,
> oder man koennte argumentieren, dies sei ungenau und der Zaun stehe ja
> ausserhalb des Waldes..


jetzt wirst Du allerdings ein bisschen rhetorisch ;-)
Ein Waldrand ist sicherlich nicht auf den cm oder einzelnen Meter
genau zu bestimmen. Sofern man aber zwischen Wald und xy noch etwas
anderes erkennen kann (dazu zähle ich auch z.B. Gestrüpp, einen
Straßengraben oder anderen Wasserlauf, eine Böschung, etc.), ist in
der "vorläufig endgültigen" Karte an dieser Stelle xy auch nicht mit
dem Wald verbunden.


> Du behauptest immer wieder, dass es ungenauer sei, den Strassen-Way als
> Waldrand zu verwenden, aber das ist eine unzulaessige Verallgemeinerung.
> Oder sagen wir: Es ist vielleicht genauer, aber nicht richtiger - genauso
> wie eine Loesung mit fuenf Nachkommastellen in der Matheklausur genauer ist,
> aber nicht richtiger.


Es freut mich schon, dass es wenigstens vielleicht (das bedeutet
vermutlich - s. Anfang D. Mail -, wenn es sorgfältig gemacht ist?)
genauer ist. Der Umkehrschluss ist dann, dass es (bei jeweils
sorgfältiger Herangehensweise) ungenauer ist, wenn man die Straße
verwendet. D.h. dass es zwar immer noch Gründe gibt, trotzdem die
Straße zu verwenden (Ersparnis von Aufwand), aber - solange man eine
genaue Karte anstrebt - dieser Zustand vermutlich eben doch nur ein
Übergangszustand sein wird.


>> Es geht nicht um rhetorische Spitzfindigkeiten, das Argument war, dass
>> e

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 06.06.2011 12:31, schrieb Sebastian Hohmann:

Am 05.06.2011 00:28, schrieb Garry:

Es kann genausogut die Strasse als
auch der Wald falsch erfasst sein. Das eine dem anderen anzupassen ist
also eine Mappen für den Renderer...



Was hat das mit Mappen für den Renderer zu tun, Objekte im Verhältnis 
zueinander korrekt zu positionieren? 
Weil dieses "korrekt" nur eine grobe Annäherung ist. Ich will keine 
"schöne" Karte im Sinne von jede Fläche wird durch meinen Renderer
lückenlos in schönen Farben eingefärbt sondern korrekte Daten in denen 
ich auch eine markante Waldrandkontur wiederfinde bzw. diese leicht 
eintragen kann.


Erfassungsungenauigkeiten gibt es immer, aber wenigstens die relative 
Lage kann man durch Beobachtung in der Realität korrekt eintragen. 
Genauso wie man auch vermeintliche Kurven im GPS-Track zu Geraden 
macht, wenn da eben keine Kurve ist.
Nun weiss Du aber nicht ob diese "vermeintliche" Kurve im Track real 
exisitiert oder tatsächlich ein Fehler Deines Receivers ist.
Kleines Beispiel: hier wurde im Wald vor 2-3 Jahren eine Kurve 
begradigt. In den üblichen Luftbildern ist diese Begradigung noch nicht 
zu finden.
Irgendjemand hat dann gemeint diese Kurve an ein hochauflösendes 
Luftbild anpassen zu müssen. Mit einem an der Strasse hängenden landuse 
wäre der Fehler
nicht so schnell aufgefallen... Verkehrstechnisch macht diese 
"Korrektur" den Unterschied ob man die Strasse nur mit 60km/h oder mit 
100km/h durchfahren kann.


Und wenn die Straße genau die Grenze zwischen Wald und Wohngebiet 
darstellt, erfasst man eben die Straße. Wenn die Straße vom Verlauf 
her nicht korrekt aufgezeichnet ist, ist dann eben auch der Wald falsch. 
Eben - wenn ich genaue Daten von der Strasse habe dann habe ich die 
Daten von der Strasse und nicht die vom Wald. Daher möchte ich dann auch
nur die Strasse anfassen und nicht den Wald. Genauso umgekehrt. Wenn ich 
Überschneidungen feststelle kann ich im Einzelfall immer noch

gegebenfalls prüfen wo der Fehler liegt.
Es geht nicht um einen Waldrand, der 20 Meter von der Straße entfernt 
liegt und sinnvoll seperat erfasst werden kann.


Eine anhaltende, gleichförmig dicht am Strassenrand entlanglaufende 
Waldgrenze ist ehr die Ausnahme als die Regel. Da kommen immer wieder
Parkbuchten, Einmündungen von Waldwegen, Bauwerke (dazu zähle ich auch 
Gräben, Dämme) etc. dazwischen die auch ein markantes Merkmal
in der Karte allein durch das "nichtvorhandensein von Bäumen" darstellen 
können.


Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Peter]

Am 03.06.2011 14:36, schrieb fly:

Am 02.06.2011 18:54, schrieb Peter:



Man kommt auf die Idee das Josm da einem viel Arbeit abnehmen könnte.

z.B. 2 Objekte markieren und 'Alle gemeinsamen Punkte trennen'
Oder auch mehrere Objekte als nur 2.
So als Featurerequest.

Müsste man noch bischen rumdenken und probieren ob es noch eine
allgemeinere Möglichkeit gibt.
z.B. 'Alle gemeinsamen Punkte markieren'. Danach dann 'trennen'
aufrufen. Das hätte den Vorteil das man dann auch die gemeinsamen
Punkte gemeinsam bewegen könnte. So hat man beide Fälle erledigt:
Getrennte Punkte haben wollend oder halt gemeinsame Punkte.



Vielleicht geht ja auch schon alles. Z.B. mit Filtern nur die
beteiligten Objekte anzeigen lassen, dann alle Punkte markieren,
dann trennen. Aber da kommt leicht zu viel dabei und es werden
dann die falschen Dinge getrennt.


Das Auftrennen ist bereits implementiert.


Ja, das meinte ich im Absatz davor, kam nicht so gut rüber.
Es funktioniert anders als ich dachte, tut aber besser als
meine Idee. Man muß Punkte markieren + die Linie die
jene Punkte als Kopien erhalten soll.

Das Auswählen fehlt noch.
Lieber modulare Funktionen die man kreativ zusammensetzt, bzw.
per script zusammenkleben könnte (s.u.).


Auf jeden Fall lohnt sich ein

Blick auf den utils2-Plugin.


Das tut es anscheinend in dem Fall nicht:
   
hab' es auch mal installiert und durchgeguckt.


Falls man nicht fündig wird, ist wohl ein Enhancement-Ticket angebracht,
wobei ein patch auch gerne gesehen wird.


Ich brauch das zu selten:-)
Wenn ich mal dazu komme mich in den josm code reinzugucken, java
ansich ist keinerlei problem. Zeit und Energie ist immer Mangelware.


Was ich mir leckerer vorstelle wäre sowas als javascript zu
basteln. So wie greasmonkey eine reihe userscripte zum sharen oder
im Wiki zu veröffentlichen. Beliebte kann man dann in den Kern
übernehmen, sowas wie plugin-lite.
Ob das gut wird weis ich nicht, bin mir aber recht sicher.

Nachteil ist halt der Aufwand aussenrum: Man bräuchte Kram
wie Fehlerconsole scriptdebugger etc. Rhino bringt das zwar
mit, naja ok, es könnte reichen.


Peter



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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 06.06.2011 17:42, schrieb Frederik Ramm:

Hallo,

M?rtin Koppenhoefer wrote:

das verstehe ich jetzt nicht, inwiefern man durch genauere Grenzen


Dass eine als einzelne Linie gezeichnete Grenze "genauer" ist als die 
Verwendung der Strassengeometrie, ist mitnichten erwiesen.



behindert werden kann, wo Flächen nicht mit Straßengraphen verbunden
sind. Hättest Du da mal ein Beispiel?


Nein, aber ich habe Leute sagen hoeren, was ich in meinem vorigen 
Posting schrieb: Dass jemand keine Lust hat, eine Strassengeometrie zu 
verfeinern, wenn sich dadurch tonnenweise Ueberschneidungen mit dem 
angrenzenden Wald ergeben und er die von Hand zusaetzlich korrigieren 
muss.


Entweder es gibt solche Mapper, die sich behindert fuehlen. Dann 
sollen die von mir aus gern die Gegend so (um)mappen, dass sie gut 
damit arbeiten koennen.


Oder es gibt sie nicht. Dann ist es auch recht.


kann), da erfordert es der Respekt vor der Arbeit der anderen, dass
man den persönlichen Stil etwas an das anpasst, was man schon
vorfindet (solange es nur um Stil und nicht um Verbesserungen geht).


Ja, das kommt sicher auf den Umfang der Aenderungen an. Einem Gebiet 
seinen persoenlichen Stil aufdruecken, weil man gerade mal im 
Vorbeifahren einen Briefkasten mappt, ist natuerlich nicht ok.



andere Karten nutzen OSM probeweise sogar bis Z.21) , sehe ich nicht,
inwiefern man einer Reduktion der Detaillierung 


Ich glaube, Du hast da eine etwas verkorkste Perspektive. Du scheinst 
anzunehmen, dass alles, was jemand vom Luftbild abmalt, automatisch 
hochgenau und detailliert ist. Ich wage mal die Behauptung: Der 
Fehler, in Metern, den ich einbaue, wenn ich den Strassen-Way als 
Begrenzung meines Waldes nehme, ist im Durchschnitt geringer als der 
Fehler, den ich einbaue, wenn ich das (Bing-)Luftbild nicht vorher 
ordentlich an GPS-Tracks justiere.


Ja, das wird oft behauptet, aber je nach Art des weiteren 
Verfeinerns, dass

man im Sinn hat, kann es eben auch genau andersrum sein.


wenn man die Straßen zusätzlich als Flächen eintragen will, ist die
Lage sicher eindeutig.


Das ist eine ganz andere Baustelle.


Aus meiner Sicht wird das in Städten auf jeden
Fall kommen, weil man anders ein sauberes Rendering, das auch
Informationen zur realen Form transportiert, nicht erhalten kann.


Informationen zur realen Form zu transportieren, ist unter Umstaenden 
aber etwas anderes als "sauberes Rendering". Und "sauberes Rendering" 
bekommt man ganz bestimmt auch ohne Strassen als Flaechen hin. Aber 
das ist, wie gesagt, wieder eine andere Geschichte.


Eine Karte ist kein Luftbild. Auch eine sehr gute Karte nicht.


da der Wald nichts mit der Straße zu tun hat, muss ich den auch nicht
verfeinern, wenn ich an der Straße schraube.


Andere muessen das vielleicht schon (wenn, wie oben geschildert, die 
verfeinerte Strasse sonst zuweilen den Wald ueberschneidet, was ja 
eher selten ist.)



Klar, ein Zaun der
an der Straße langläuft müsste evtl. verfeinert werden


Wenn wir es mit einem Zaun zu tun haben, dann hoert das natuerlich 
auf, dass man die Strasse als Waldrand benutzen kann. Aber dann haben 
wir das gleiche Ding mit dem Zaun; man koennte dann einfach den Zaun 
als Waldrand benutzen, oder man koennte argumentieren, dies sei 
ungenau und der Zaun stehe ja ausserhalb des Waldes..


Ja, das behauptest Du immer wieder, aber das ist halt eine 
Beurteilung, die

Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die werden
eventuell davon eben nicht gebremst, sondern denen geht die Arbeit 
schneller

von der Hand.


sicher gehen einem manche Bearbeitungen schneller von der Hand, wenn
man sie ungenau macht.


Du behauptest immer wieder, dass es ungenauer sei, den Strassen-Way 
als Waldrand zu verwenden, aber das ist eine unzulaessige 
Verallgemeinerung. Oder sagen wir: Es ist vielleicht genauer, aber 
nicht richtiger - genauso wie eine Loesung mit fuenf Nachkommastellen 
in der Matheklausur genauer ist, aber nicht richtiger.


Strassen werden potentiell genauer erfasst als Waldränder. Die Wälder 
haben in den Daten für die meisten einen ehr dekorativen Charakter während

die Strassen- und Wegedaten intensiv genutzt werden.
Wenn Du schon mit Deiner Matheklausur kommst  - die Grundlagen des 
technischen Zeichen dass man ein genaues Mass nicht mit einem ungenauen 
Mass verkettet wenn man ein genaues Ergebniss haben möchte sind Dir bekannt?
Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und 
wer die Waldgrenze bearbeiten möchte eben die Waldgrenze. Er sollte 
nicht genötigt werden beides anfassen zu müssen was er dann im 
Zweifelsfalls lassen wird -> keine Verbesserung der Daten.


Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Torsten Leistikow]

Garry schrieb am 07.06.2011 16:03:
> Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und
> wer die Waldgrenze bearbeiten möchte eben die Waldgrenze.

Noch mal zur Erinnerung: Wir reden hier von dem Fall, wo ein Wald bis an eine
Strasse heran reicht.

=> Waldgrenze = Strasse

Es macht also keinerlei Sinn, ein Objekt genauer und ein Objekt weniger genau in
der Datenbank haben zu wollen.

Gruss
Torsten

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Frederik Ramm]

Hallo,

On 06/07/11 16:03, Garry wrote:

Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und
wer die Waldgrenze bearbeiten möchte eben die Waldgrenze. Er sollte
nicht genötigt werden beides anfassen zu müssen was er dann im
Zweifelsfalls lassen wird -> keine Verbesserung der Daten.


Das ist jetzt mein allerletztes Statement zu diesem Thema, weil ich mich 
zu wiederholen beginne.


Bitte lies das folgende aufmerksam durch, ich habe es Martin schon 
geschrieben, aber Du hast das offenbar nicht gelesen.


Es ist eine Situation denkbar, in der die Strasse und der Waldrand als 
separate Linien nebeneinander gemappt sind, beide relativ grob, und in 
der eine Verfeinerung der Strasse dann dazu fuehrt, dass die Strasse den 
- immer noch grob gezeichneten - Wald stueckweise ueberlappt.


Der Mapper waere hier also genoetigt, um der Topologie Rechnung zu 
tragen, den Wald ebenfalls zu verfeinern; waere hingegen die Strasse 
zugleich der Waldrand, bliebe im diese Mehrarbeit erspart.


Das, was Du schreibst, kann also je nach Situation mal als Argument fuer 
die eine und mal als Argument fuer die andere Art zu mappen dienen.


Keine von beiden Arten ist besser; es kommt auf die Gesamtsituation und 
auf den Mapper und auf die Umstaende an. Alles andere ist eine 
unzulaessige Vereinfachung und der Versuch, anderen aufzudiktieren, wie 
sie ihre Arbeit machen sollen.


Bye
Frederik

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 07.06.2011 16:42, schrieb Frederik Ramm:

Hallo,

On 06/07/11 16:03, Garry wrote:

Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und
wer die Waldgrenze bearbeiten möchte eben die Waldgrenze. Er sollte
nicht genötigt werden beides anfassen zu müssen was er dann im
Zweifelsfalls lassen wird -> keine Verbesserung der Daten.


Das ist jetzt mein allerletztes Statement zu diesem Thema, weil ich 
mich zu wiederholen beginne.


Bitte lies das folgende aufmerksam durch, ich habe es Martin schon 
geschrieben, aber Du hast das offenbar nicht gelesen.


Es ist eine Situation denkbar, in der die Strasse und der Waldrand als 
separate Linien nebeneinander gemappt sind, beide relativ grob, und in 
der eine Verfeinerung der Strasse dann dazu fuehrt, dass die Strasse 
den - immer noch grob gezeichneten - Wald stueckweise ueberlappt.

Diese Information ist nicht vorhanden!
Wenn beides grob gemappt ist dann hat man nicht mehr als die Information 
dass der Wald ungefähr an der Strasse auf hört. Das kann 20 und mehr
Meter vor der Strasse sein, genauso aber erst einige Meter auf der 
anderen Strassenseite ("eigentlich Nicht-Wald-Seite") wenn dort auch 
noch ein

Baumstreifen steht.


Der Mapper waere hier also genoetigt, um der Topologie Rechnung zu 
tragen, den Wald ebenfalls zu verfeinern; waere hingegen die Strasse 
zugleich der Waldrand, bliebe im diese Mehrarbeit erspart.
Ist er nicht, er hat hier aus den OSM- Daten keine belastbare 
Information über die Topologie.
Abgesehen davon ist diese Mehrarbeit überschaubar, insbesondere im 
Verhältniss zur sonst später nötigen Nacharbeit.


Das, was Du schreibst, kann also je nach Situation mal als Argument 
fuer die eine und mal als Argument fuer die andere Art zu mappen dienen.
Ich argumentiere dass man die Daten verbessern kann/darf/soll die man 
hat, notfalls zu Lasten der (vermeintlichen)Topologie, insbesondere dann 
wenn es um etwas nur grob erfasstes geht.


Keine von beiden Arten ist besser; 
Dem widerspricht schon alleine die Mapper-Praxis dass doch einige nach 
anfänglicher Begeisterung für das zusammenlegen wieder davon abgekommen

weil man sich zuviele Folge-Probleme einhandelt.
es kommt auf die Gesamtsituation und auf den Mapper und auf die 
Umstaende an. Alles andere ist eine unzulaessige Vereinfachung und der 
Versuch, 
Eine unzulässige Vereinfachung ist  die Vermischung von Daten die nicht 
zusammengehören nur weil sie zufällig und sporadisch stückweise

ungefähr parallel laufen. Aber das hat ja Martin schon sehr schön erörtert..

anderen aufzudiktieren, wie sie ihre Arbeit machen sollen.

Das klingt aus Deinem Mund jetzt sehr paradox...

Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 8. Juni 2011 18:19 schrieb Garry :
> Am 07.06.2011 16:42, schrieb Frederik Ramm:
>> anderen aufzudiktieren, wie sie ihre Arbeit machen sollen.
> Das klingt aus Deinem Mund jetzt sehr paradox...


naja, wenn ich naturgemäß auch mit dem Rest Deiner Mail weitgehend
übereinstimme, hier widerspreche ich doch gern: Frederik ist
prinzipiell ziemlich liberal und laisser-faire-mäßig unterwegs, da ist
aus meiner Sicht nichts Paradoxes an seiner Aussage.

Gruß Martin

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[Garry]

Am 09.06.2011 12:59, schrieb M∡rtin Koppenhoefer:

Am 8. Juni 2011 18:19 schrieb Garry:

Am 07.06.2011 16:42, schrieb Frederik Ramm:

anderen aufzudiktieren, wie sie ihre Arbeit machen sollen.

Das klingt aus Deinem Mund jetzt sehr paradox...


naja, wenn ich naturgemäß auch mit dem Rest Deiner Mail weitgehend
übereinstimme, hier widerspreche ich doch gern: Frederik ist
prinzipiell ziemlich liberal und laisser-faire-mäßig unterwegs, da ist
aus meiner Sicht nichts Paradoxes an seiner Aussage.
Das Paradoxe ist dass er durch Androhung von Account-Sperren die 
Durchsetzung/Unterdrückung von Tags

unterstützt...

Garry

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

[M∡rtin Koppenhoefer]

Am 9. Juni 2011 17:23 schrieb Garry :
> Das Paradoxe ist dass er durch Androhung von Account-Sperren die
> Durchsetzung/Unterdrückung von Tags
> unterstützt...


jetzt bin ich doch neugierig geworden, um welche Tags gehts da?

Gruß Martin

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