Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sun, 21 Nov 2010 21:36:04 +0100
> Von: Johannes Huesing 
> An: qbert biker 
> CC: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] OSM Alpin?

> qbert biker  [Sun, Nov 21, 2010 at 07:19:41PM CET]:
> > 
> [...]
> > 
> > Der Schwierigkeitsgrad eines Weges ansich ist ja weitgehend
> > unabhängig davon, wie gut er im Gelände sichtbar ist.
> 
> Sag das dem Schweizer Alpenverein. Nach dieser Skala 
> ist ein Weg, der selten begangen über eine flache Alm
> führt (und somit keine Wegspur hat oder sie nicht von
> den quer verlaufenden Spuren der Rinder zu unterscheiden 
> ist), nicht zu klassifizieren. 

Um das gehts ja - die Alpenvereine können zwar mit ihren
Skalen einen Anhaltspunkt für die Klassifizierung geben,
aber sie können sie aus guten Gründen nicht bestimmen.

Alpenvereine, auch die hiesigen, haben klare Vorstellungen
von der touristischen Nutzung der Pfade, die aber von dem
Konzept einer allgemeinen Karte abweichen. Sie wollen ja
nicht jeden Pfad in ihren Gebiet beschreiben, sondern 
die Wanderer kanalisieren. 

Und deshalb legen die Alpenvereine wenig wert auf eine
unabhängige Beschreibung von Sichtbarkeit und 
Schwierigkeitsgrad. Und dass der schweizer Alpenverein
besonderen Wert auf die gute Beschreibung von möglichst
extremen Wegen legt, hat ja nun sicher auch etwas mit
dem dahinterliegenden Geschäftsmodell zu tun. 

Wenn sich jetzt aber die OSM-Karte immer mehr von den
Alpenvereinen weg emanzipiert und viele Wege eingezeichnet
werden, die von diesen ignoriert werden, dann muss man
die Oberhoheit der sec skala in Frage stellen, zumindest
auuserhalb der Extremregionen bzw. in der Fläche.

Gruesse Hubert
-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

> Was ist jetzt bei Dir das Haupt- und was das Zusatzattribut?

Nachdem 'sec_scale' direkt als Klassifizierung verwendet 
wird und auch viualisiert wird, ist es das Hauptattribut.

Über 'trail_visibility' wird geschrieben, dass es ausgelagert
wurde und es hat eigentlich nur ergänzende Bedeutung.

Oder andersrum - ohne 'sec_scale' kann man mit 'trail_visibility'
relativ wenig anfangen. 

Beide haben aber bestimmte Beschreibungen gemeinsam, also
z.B. 'Wegspur kaum vorhanden.' bei 'sec_scale' und 
'trail_visibility'.

Eine starke Beschreibungssprache verzichtet auf solche
Überschneidungen und dann sind die Attribute gleichwertig
und unabhängig voneinander anwendbar. 

Der Schwierigkeitsgrad eines Weges ansich ist ja weitgehend
unabhängig davon, wie gut er im Gelände sichtbar ist.
Einen kaum zu findenden Waldpfad kann ich u.U. mit 
Pantoffeln begehen, bei einem ausgezeichnet sichtbaren
Hochgebirgssteig ist das weniger zu empfeheln. Auf einer
Ferrata haben sich auch noch wenige verlaufen, auch wenn
die durch die Felsen führt.

 
-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sun, 21 Nov 2010 11:42:50 +0100
> Von: Johannes Huesing 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] OSM Alpin?


> Meine ich nicht. Ich interpretiere es so, dass eine
> Farbmarkierung an jedem siebten Stein eine gute Sichtbarkeit
> bedingt.

Wieder mal klassisch OSM - das Zusatzattribut vermischt sich
in Inhalt und Funktion mit dem Hauptattribut, denn auch da ist
die Sichtbarkeit ein Thema. 
 
> Ich glaube, dass die Hochgebirgswanderwegtags im JOSM *zu* 
> präsent sind. 

Wobei das weniger an JOSM liegt, sondern daran, dass man
ein Schema auf alle Wanderpfade umlegt, das nur fürs
Hochgebirge wirklich gut passt. sec_scale ist zwar gut 
gemeint, aber die meisten Pfade sind nun mal in leichten
oder mittelschweren Gelände und da kann ich wieder nur
einen schwammigen Mischmasch eintragen. 

Im genannten Beispiel bestimmt nicht das Gelände oder
die Höhe über Null (kein Schotterabhang) die Sichtbarkeit,
sondern schlicht, dass sich für diesen Weg kein
Touribüro oder sonstwer interessiert. Er ist einfach da,
zwar schlecht zu erkennen aber trotzdem begehbar und 
wurde eingetragen.

Und welcher OSMler nimmt nicht gerne die gelegenheit war,
etwas neues einzutragen das nicht ganz so leicht zu finden
ist. Ich könnte mir also gut vorstellen, dass genau
diese Wege in OSM stark zunehmen werden und dass man sich
nicht ganz so stark vom Hochgebirge und dem was die
Touriverbände unter Wegen verstehen, leiten lassen sollte.

Wenn es eine Regel gibt, die auch in mittelschweren
Gelände abseits des Hochgebirges zwischen leicht 
erkennbaren und fast unsichtbaren Pfaden unterscheidet, 
trage ich diese Unterscheidung ein. Wenn nicht gibts eben
auch von mir Einheitstagging und wer sich verläuft, hat
eben den Fehler gemacht, sich auf OSM zu verlassen ;)

Grüsse Hubert

-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 20 Nov 2010 15:30:05 -0800 (PST)
> Von: NopMap 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] OSM Alpin?


> Wanderwege werden in der Tat als Relationen eingetragen und dann sind auf
> den einschlägigen Karten auch entsprechend hervorgehoben. Dabei ist es
> egal,
> ob es sich um einen offiziellen internationalen
> Premium-Millenium-Fernwanderweg handelt, ein Trampelpfad mit ein paar
> Farbtupfen auf den Felsen oder ein Netzwerk von Wegen wie in der Schweiz -
> das läßt sich alles sinnvoll abbilden. Wenn es ein vor Ort erkennbar
> markierter Weg ist, dann ist es auch eine Relation wert.
> 
> Infos dazu finden sich im Wiki unter "Wanderweg". [1]

Das ist wohl auch der Grund fuer die Stifmütterliche 
Behandlung abseits der Hauptrouten. Viele haben noch nie
eine Relation gesetzt und werden es auch nie tun, weil 
eine Relation ansich zu abstrakt erscheint und auch
nicht leicht zu handhaben ist, zumindest mit den 
gängigen Relation-Editoren, die ich so kenne. Man muss
das Modell hinter den Relations erst verstanden haben, um
sie als solche zu verstehen.

Ist das nicht vom einfachen Mapper etwas zuviel erwartet? 
 
> Auf der Hauptseite wirst Du nichts geeignetes finden. Die Anforderungen
> für
> die Hauptseite sind wohl auch ziemlich heftig. 

Ein Layer für Fussgänger/Radfahrer und ein anderer optimiert
fürs KFZ statt drei sehr ähnlichen Styles wäre machbar.
Hier wird viel Potential verschwendet, denn langsam wird 
OSM für den Wanderer zu einer recht bemerkenswerten Quelle -
wenn er sich nicht im Informations- und realem Dickicht
verläuft ;)

> Die Presets in der Richtung sind mit Vorsicht zu genießen. 

Sie sind aber derzeit das beste Mittel, mal schnell etwas 
einzutragen. Dass sehr viele Mapper das ähnlich sehen, lässt
sich retour über die Fehler der Eintragung erkennen. Ich
führe den aktuellen Stand bei den Wanderwegen direkt
auf auf diese Handlungsweise zurück. Man hat einen Weg
gezeichnet und will ihn attributieren - schnell und effektiv
und sich nicht parallel im Wiki verfransen.

> Ich arbeite
> daran, parallel zu meiner Wanderkarte auch einen dedizierten Editor
> speziell
> für Wanderwege bereitzustellen, mit entsprechenden Presets. Man kann das
> Ganze schon ausprobieren, auch wenn es noch nicht fertig und der Editor
> Potlatch2 auch noch experimentell ist, tue ich mir beim Mappen abseits der
> Straßen damit schon jetzt deutlich leichter als mit JOSM.

Klingt spannend - Ein Tipp vor mir, was Relations angeht:
Es sollte eine Funktion geben, die die komplexität der 
Relations vor dem Nutzer versteckt. Cloudmade hat das
mal mit Abbiegebeziehungen versucht, wenn ich mich recht 
erinnere. Umso direkter eine Eintragung möglich ist, desto
mehr spricht sie den Nutzer an. Also optimalerweise als
Kontextstruktur, die im Hintergrund dann die Relation anlegt.

Gruesse Hubert
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 20 Nov 2010 15:56:48 -0800 (PST)
> Von: NopMap 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] OSM Alpin?

> 
> 
> qbert biker wrote:
> > 
> > Und es gibt das Konzept der Sichtbarkeit
> > 
> > http://wiki.openstreetmap.org/wiki/Key:trail_visibility
> > 
> > das wenigstens einen Teilaspekt abdeckt, allerdings nicht 
> > vergeben war und wie man in einer anderen Diskussion 
> > nachlesen kann, oft falsch vergeben wird. Das Attribut habe
> > ich mittlerweile ergänzt - ob und wie es ins Rendering 
> > einfliesst, weiss ich derzeit nicht.
> > 
> 
> Nach meinem Wissen wird dieses Tag von allen Renderern ignoriert. Meines
> Erachtens spielt es bei einem markierten Weg auch keine Rolle - wozu ist
> er
> markiert? :-)

Das ist auch im anderen thread angesprochen - das ist ein
Missverständnis, denn es geht um die Sichtbarkeit des Weges 
ansich, was allerdings von vielen mit der Existenz von
Markierungen verwechselt wird. 

Im konkreten Fall ist es einfach so, dass es ein Pfad mit
stark wechselnder Sichtbarkeit ist, der sich teilweise im
Gelände verliert. Dass es keinerlei Markierungen und Schilder
gibt, ist davon unabhängig, bzw. ein weiteres Merkmal. Wer experimentierfreudig 
ist und solche Pfade mag (z.B. ich),
der ist durchaus interessiert an so einer Eintragung. Ich
habe deshalb hier das mit der Sichtbarkeit ergänzt, egal
obs nun gerendert wird oder nicht.
 
> Das ist halt eines der Probleme mit OSM: Es gibt keinen Mindeststandard.

Es gab eigentlich immer Bestrebungen, einen Mideststandard
zu halten, aber leider arbeiten einige Fundis aktiv dagegen
an, da sie darin eine Bevormundung sehen. Schade eigentlich...

Gruesse Hubert
-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 20 Nov 2010 21:01:13 +0100
> Von: "Ulf Möller" 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] OSM Alpin?

> Am 20.11.2010 18:51, schrieb qbert biker:
> 
> > Und hier setze ich den Anspruch etwas anders an. Ich sehe
> > das problem nicht darin, dass so etwas in OSM nicht lösbar
> > wäre, sondern eher darin, dass man auf uralte Ansätze
> > setzt, die mal richtiger Strukturierung bedürften.
> 
> Das hilft bei diesem Problem wenig. Bei einem Crowdsourcing-Projekt 

Crowdsourcing oder nicht spielt hier keine Rolle. 

> kann 
> es prinzipbedingt immer Lücken und Fehler geben. 

Es gibt immer Fehler, auch in der DAV-Karte. Es stellt sich
einfach nur die Frage, wie man mit ihnen umgeht. 

Im Prinzip ist jeder nicht offizielle Weg ein Mehrwert für
OSM, solange es ein Minimum an Unterscheidbarkeit gibt.
Das Problem, das sich hier aufzeigt ist doch, dass

1. Viele Mapper die Informationen nicht finden, die sie
bräuchten, um alles so einzutragen wie sei es vorfinden

und 

2. Sich manche Klassifizierungen als zu komplex erweisen,
dass sie sich in der praktischen Anwendung bewähren.

Am Beispiel sac_scale kann man gut sehen, dass man hier 
zwar feine Unterscheidungsgrade fürs Hochgebirge hat, aber
die Masse der Wege landet in nur 2 Kategorien: 'hiking'
und 'mauntain hiking'. Die restlichen Abstufungen beziehen
sich auf Gelände, das die Masse der Mapper wohl selten
zu sehen bekommt.

> Wenn Kartenfehler dich 
> in eine gefährliche Situation bringen können, darfst du dich nicht 
> allein auf OSM verlassen. Dann gehört halt eine DAV-Karte in den
> Rucksack...

Ich habe kein ernstes problem damit - mach deine Aussage
einfach nochmal, wenn OSM eine schlechte Presse bekommt,
weil sich irgend ein Sandalentourist wegen OSM verlaufen 
hat, weil er daran geglaubt hat, dass es nichts besseres
als OSM als Karte geben kann ;)

Gruesse Hubert

-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 20 Nov 2010 18:11:10 +0100
> Von: Johannes Huesing 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] OSM Alpin?

> Soll der Gelegenheitsmapper die alpinen Wege pflegen?

Er soll die gesammelten Informationen möglichst effizient
und sicher eintragen können. Wenn massenhaft Fehler passieren
(siehe path_visibility thread) könnte das auf ein 
konzeptionelles problem hindeuten. 

Ich habe den Weg im Wiki verfolgt und man kommt schon an
die Information ran, wie man besser einträgt - ob viele
Mapper diese Geduld aufbringen, kann bezweifelt werden,
wenn man die Ergebnisse anschaut.

Nur als beispiel meine Wenigkeit. Wenn ich kaputt von 
der Tour zurückkomme und noch schell josm anwerfe, dann
klappe ich kurz die Vorschläge auf und werde bei
demanding_alpine fündig. War ja anstrengend, auch 
technisch anspruchsvoll und in den Alpen wars auch.

Dann klick ich ein paar Wege rundrum an - die anderen
machens auch so - und schon habe ich Murks eingetragen. 
Ich werde das demnächst anpassen, so wie meine alten
footway-Frühsünden, aber die Masse wirds nicht machen.

> Expertise für OSM ist alles andere als deckungsgleich mit der
> Expertise für das Bergwandern. Ein Gelegenheitsmapper kann 
> ein Bergfex sein, ein OSMonaut mit schwarzem Gürtel kann 
> bergunerfahren sein. 

Und hier setze ich den Anspruch etwas anders an. Ich sehe
das problem nicht darin, dass so etwas in OSM nicht lösbar
wäre, sondern eher darin, dass man auf uralte Ansätze
setzt, die mal richtiger Strukturierung bedürften.

Wenn ich eine halbe Stunde im Wiki rumklicken muss, um
mit viel Glück die Beschreibungen zu finden, werde ich es
irgendwann einfach unterlassen und blind dem Editor 
vertrauen - was der vorschlägt und irgendwie passt,
wird schon richtig sein...

Grüsse Hubert

-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 20 Nov 2010 18:03:27 +0100
> Von: Falk Zscheile 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] OSM Alpin?


> Ich sehe in dem von Dir geschilderten Fall kein Problem in den
> OSM-Daten. Das von Dir geschilderte Problem resultiert aus einer für
> Deine Zwecke unpassend gerenderten Karte 

Leider nein, ich habe mir sowohl die Daten als auch die 
Beschreibung nochmal angeschaut. Dafür, dass es keine 
Beschilderung gibt, ist offensichtlich kein Konzept 
vorgesehen. Es gibt das Konzept der Routen, das mittels
Relations umgesetzt ist. Hier interessieren aber keine
Routen, sondern schlicht ob es einen Hinweis gibt, wohin
der Weg geht.

Und es gibt das Konzept der Sichtbarkeit

http://wiki.openstreetmap.org/wiki/Key:trail_visibility

das wenigstens einen Teilaspekt abdeckt, allerdings nicht 
vergeben war und wie man in einer anderen Diskussion 
nachlesen kann, oft falsch vergeben wird. Das Attribut habe
ich mittlerweile ergänzt - ob und wie es ins Rendering 
einfliesst, weiss ich derzeit nicht.

> und einer falschen
> Vorstellung vom Karteninhalt.

Na ja, was hier falsch oder richtig ist - in diesem Fall 
war es die Art der Eintragung.
 
> Man kann also von einem eingezeichneten Weg in der
> Karte auf dessen Vorhandensein in der Realität schließen, aber nicht
> darauf, dass dieser Weg auch markiert ist. 

Nimm dir eine Wanderkarte des bayrischen Vermessungsamts 
zur Hand und du kannst eben genau das sehen. Was darin rot
markiert ist, erfüllt einen Mindeststandard an Existenz,
Markierung und Bschilderung.

> auch nur heißen"da ist schon einmal jemand entlang
> gelaufen". 

Dessen bin ich mir sehr wohl bewusst und ich bin auch
mit einer Abenteuerlust da reingestolpert. Ich habe genug
Bergerfahrung, um damit umzugehen, mich auch mal zu
verlaufen und hätte umkehren können, als kein Schild 
vorhanden war. 

Problematisch wird es bei der Planung des Ausflugs und 
besonders dann, wenn ich nicht alleine bin. Dann heisst
es dann, dass alles was nicht näher beschrieben ist,
erst mal als 'da ist mal wer durchmarschiert' eingestuft
werden muss. Und spätestens hier muss ich dann wieder
zum Alternativmaterial von Vermessungamt und Alpenverein
zurückgreifen.  
 
> Man muss also bei der Verwendung von auf OSM basierendem
> Kartenmaterial auch wissen, was der Renderer bei der Datenauswertung
> berücksichtigt (das sollte sich mittelbar über die Legende der Karte
> erschließen).

Was dann ziemlich traurig für OSM aussehen würde, wenn
der Renderer wirklich konservativ vorgeht und nur Wege
als begehbar anzeigt, die das auch belegbar sind.

Gruesse Hubert


-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 20 Nov 2010 16:36:15 +0100
> Von: Fichtennadel 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] OSM Alpin?


> Wenn Du Dir Nop's Reit- und Wanderkarte z.B. für
> http://www.wanderreitkarte.de/index.php?lon=15.7306&lat=47.6933&zoom=14ansiehst
> und die Legende einblendest, wird sehr schön zwischen den einzelnen
> Wegarten unterschieden.
> Ob der Weg markiert ist oder nicht, ist leider nicht zu erkennen, stimmt.

Ahhh, ich wusste ja, dass es da noch was gibt, es gibt sicher
auch noch ein paar mehr verborgene Perlen, schade dass man
sie auf dem direkten Weg nicht findet.

Leider komme ich im Moment nicht drauf, aber ich setze dann
noch einen Link.
 
> Der Mapnik Stil auf der OSM "Hauptseite" ist als Wanderkarte total
> untauglich.

Gilt eigentlich fuer alle Stile dort. Irgendwie habe ich den
Eindruck, dass die auch schon mal besser rübergekommen sind.
Warum tracks, die breite gut ausgebaute Forststrassen sind,
die man auch mit einem Porsche befahren könnte, eine ähnliche
Optik haben wie ein kleiner Pfad, erschliest sich nicht
unbedingt. Platz genug für Doppellinien wäre in den hohen
Zoomstufen schon da.

Alles in allem gibt die OSM-Hauptseite wenig für den 
Wanderer her.
 
> Das Problem gibt's bei OSM immer. Ich denke im Wiki sind die Sachen schon
> recht gut beschrieben, sie müssten nur gelesen und auch befolgt werden.

Das Wiki ist eine riesige Informationswüste, die wohl nur von 
wenigen wirklich durchquert wird ;)

Mich stört hier, dass das einfach als gegeben dargestellt
wird. Ist das Wiki wirklich eine sinnvolle Informationsquelle
für den Gelegenheitsmapper, der mal schnell etwas eintragen 
will, oder bräuchte es kürzere Informationswege, damit 
auch weniger eingeweihte schnell mal eine Information
dazufügen können?

Gruesse Hubert
-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

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

Re: [Talk-de] OSM Alpin?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 20 Nov 2010 16:07:50 +0100
> Von: Torsten Leistikow 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] OSM Alpin?

> qbert biker schrieb am 20.11.2010 14:55:
> > In diesem Fall war die Lehre aus der Sache, dass OSM
> > derzeit keine Wanderkarte ersetzt, die markierte und
> > beschilderte Wege sauber in der Darstellung von wilden
> > Trampelpfaden trennt, wobei man letzere nur mit viel
> > Selbstvertauen und Geländegefühl begehen sollte. 
> 
> Nach meinem Verstaendnis sollten ausgeschilderte Wege als Relationen
> eingetragen
> werden, 

Mein Verständnis ist ja eher, dass Relations eine Eigenschaft
mehreren Elementen zuweisen sollen, also z.B. dass der
Wanderweg xy über die ways A,B,C und D geht. Ich hätte z.B.
auch keine Ahnung, welche Relation ich anwenden sollte.

> die dann auf den ueblichen Wanderkarten auch entsprechend
> hervorgehoben

Und zu denen muss man erst mal finden. Ohne Intergrundinfo
lande ich auf der OSM-Hauptseite und habe die Auswahl zwischen
Osmarender, Mapnik und Radfahrer. Welche Karte müsste ich
nutzen, damit ich mehr Infos zu Wanderwegen bekomme?

> werden. Etablierte Mittel und Wege gibt es also.

Man kann in der Liste Hunderte von Beiträgen lesen, die alle
beinhalten, dass alles irgendwie geht. Nur was man unter
etabliert verstehen soll, ist etwas anderes. 

> Offensichtlich warst du in einer Gegend unterwegs, wo die OSM-Karte noch
> nicht
> so ausgereift ist wie anderswo. 

Ein paar Meter weiter ist die Zugspitze und da toben sich 
natuerlich etwas mehr Leute aus ;)

Aber im Ernst - es ist schon eine gut versorgte Ecke, leicht
von München aus zu erreichen und auch entsprechend begangen,
insofern nichts exotisches. 

> Aber das wir mehr oder minder weisse
> Flecken
> haben ist ja nichts neues.

Nein, das hat nichts mit weissen Flecken zu tun. Es ist 
eher die Standardversorgung in der Fläche, abseits der
total überlaufenen Wege. 

Und hier stellt sich die Frage, ob das Zusammenspiel von
Wiki und Presets wirklich funktioniert. Ein massenhaft
begangener Weg hat auch viele Eintrager, die auch mal
etwas korrigieren, aber in der Fläche muss auch der Mapper
angesprochen werden, der eben gerade da ist und keine
Lust hat, im Wiki zu wühlen, ob es für das was er sieht
irgendwo schon eine Lösung, womöglich auch noch mittels
Relation, gibt.

Die meisten machens wohl so wie ich auch meistens. Wenn
ein Preset zu passen scheint, erstmal rein damit.

Gruesse Hubert
-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

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

[Talk-de] OSM Alpin?

[qbert biker]

Ich habe gerade ein wenig in den Diskurs um sac_scale und
visibility reingeschaut und erst mal heftig geschluckt. 
In diesm Fall bin ich ein konkret Betroffener, denn ich bin
kuezlich mit ausgedruckten OSM Screenshot munter im
Gebirge rum und dabei genau über dieses Thema gestolpert -
wobei das ziemlich woertlich zu nehmen ist.

Es geht um das Gebiet um den Heimgarten herum. Zwar am
Alpenrand gelegen, aber trotzdem gefährlich genug, dass
man beim Verlaufen ernsthaft in Gefahr kommen kann. 

Ich hatte mir also eine nette Rundtour zusammengesucht, die
so nach der OSM-Karte haette eigentlich funktionieren 
hätte sollen, aber übersehen, dass einige Wege darin nicht
ausgeschildert und auch sonst eher kaum vorhanden sind.
Da steht man dann schnell im offenen Gelände und versucht
den Weg wiederzufinden.

Gut, es gäbe da Tags dafür und es wurde ja oben munter
diskutiert, wie man die am besten anwendet. Allerdings löst 
das nicht das Problem, dass die Information die Beteiligten
nicht erreicht hat. Wo liegt nun das Problem? Hatte der
Eintragende schlicht keine Lust, die Sichtbarkeit 
einzutragen oder wusste er nichts von der Option?

In diesem Fall war die Lehre aus der Sache, dass OSM
derzeit keine Wanderkarte ersetzt, die markierte und
beschilderte Wege sauber in der Darstellung von wilden
Trampelpfaden trennt, wobei man letzere nur mit viel
Selbstvertauen und Geländegefühl begehen sollte. 

Ich vermisse hier die klare eindeutige Darstellung z.B.
in den klassischen Wanderkarten wie rot (durchgaengig,
gestrichelt, gepunktet) für ausgeschilderte markierte
Wege nach Schwierigkeit sortiert und schwarz (durchgezogen,
gestrichelt) für Wege bei denen man auf Ueberraschungen
gefasst sein sollte.

Dann muesste nur noch die Informationskette funktionieren
damit die Information des Eintragenden auch beim Nutzer
ankommt. Diskussionen wie oben sind zwar fuer Kenner sehr
aufschlussreich, der normale Mapper ist aber offensichtlich
deutlich überfordert und und verlässte sich daher einfach
auf das Werkzeug und interpretiert die Optionen wie es
ihm gefällt. 

Gruesse Hubert
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

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

Re: [Talk-de] AIO Europe nun zu groß für 4GB SD

[qbert biker]

 Original-Nachricht 
> Datum: Mon, 08 Nov 2010 08:15:50 +0100
> Von: "André Joost" 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de]AIO Europe nun zu groß für 4GB SD

 
> Nun, dann sollen die Editoren (ob mobil oder nicht) die OSM-IDs eben 
> auch als Text behandeln, und -wenn nötig- intern eine eigene numerische 
> Indizierung verwenden. Den gesamten planet.osm bekommt ja sowieso keiner 
> in den Speicher.

Das mit dem IDs als Text ist für den Export praktisch, aber 
ansonsten ist der 64Bit Namensraum (1.8*10^19) schon ganz 
ansehnlich. Deshalb auch die Unterscheidung von Editoren, die 
auf Mobilgeräten arbeiten und welchen, die man auf dem heimischen 
PC einsetzt. Der 0815-PC ist von Haus aus 64-Bittig und hat 
soviel Speicher, dass die Verdopplung kaum etwas ausmacht.

Im Mobilbereich hat man es aber mit vorwiegend mit 32-Bittern
zu tun (z.B. ARM) und dann sind 64 Bit ungünstig was Rechnezeit
und den nicht so üppig vorhandenen Speicher angeht.

Bleibt das Mapping, also die Abbildung auf einen eigenen
Namesraum. Es ist zwar kein grösseres Problem, sich für den
mobilen Router die Daten einzudampfen und mit gemappten lokalen
IDs ohne Lücken zu arbeiten, aber fürs Zurückschreiben sind 
dann Klimmzüge notwendig, weil man dafür die original-IDs
zwingend braucht. Und die brauchen als Text dann noch mehr
Speicher als der normale 64Bitter, also 10 Byte statt 8 und
das auch nur bis 33Bit.

Und Rechnen mit Strings macht nur begrenzt Spass, auch wenn
man Strings schon zum indizieren verwenden kann...


-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

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

Re: [Talk-de] AIO Europe nun zu groß für 4GB SD

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 06 Nov 2010 08:54:16 +0100
> Von: Carsten Moeller 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] AIO Europe nun zu groß für 4GB SD


> > ich hab keine Ahnung (das ist ja eine tolle Einleitung ...;), was da
> > alles in die Karte aufgenommen wird. Anscheinend ja fast alles! Ich sehe
> > mich mit ähnlichen Dingen konfrontiert und will nur ein paar Zahlen
> für
> > Deutschland liefern. Als ich mich vor einem Jahr mit dem OSM-Routing
> > (hardcore) begann zu beschäftigen, da lieferte mir OSM in etwa 40Mio
> > Knoten. Heute sind's bereits annähernd 60Mio. Und dies eigentlich nur,
> > weil OSM ja nicht zwischen z.B. Gebäuden und Wegen und so trennt. Da
> ist
> > ein Knoten erstmal ein Knoten. Wenn also der Speicher zu gering ist,
> > egal ob Kiste oder Navi, dann kann man eigentlich nur noch Dinge
> > weglassen, um die Mengen zu reduzieren. Ein weiteres Problem wird es
> > gefühlt in ca. 3 Jahren geben. Dann nämlich wird OSM mit seinen IDs an
> > die 32-Bit-Grenze stoßen - schöpfen heute bereits 31 Bits aus - und
> > sämtliche IDs auf 64-Bit umstellen. Wenn da vorher seitens der Garmins,
> > Router, usw. keine Umschlüsselung stattfindet, dann wird der
> > Speicherbedarf sogar ohne Mehrinformation von heut auf morgen
> aufgepumpt.
> >
> > Gruß,
> >
> > Carsten
> Korrektur: Meinte natürlich 30 / 31 Bits (32 wären ja negativ;-)

Nö, das mit den 32 Bit passt schon, denn ein Knoten hat in
der Anwendung keine negativen Werte. Die Beschneidung auf 31 Bit, 
bzw. negative Werte ist nur ein Trick, um noch ein Flag zu
übrig zu haben. Das kann bei Editoren sein, ob jetzt ein Datum
schon übertragen wurde oder auch nicht.

Das OSM-XML-Format ist komplett aussen vor, da die Zahlen in
Textform gespeichert werden, die keine Begrenzung kennen. 

Bei der praktischen Anwendung in mobilen Geräten muss man 
nur unterscheiden, ob man die Fähigkeit behalten will, Daten
zurückzuschreiben. Bei rein darstellendem Zugriff kann man mit
32 Bit noch lange leben, da man bei der Wandlung den
Knotennamensraum komprimieren kann. Auch kann man Flächen
in effiziente Strukturen wandeln und kann sie getrennt 
speichern.

Wer allerdings mobil Daten eintragen will, braucht das original
OSM-Datenmodell mit seinen Unzulänglichkeiten und da wird
man wohl in den sauren 64-Bit Apfel beissen müssen.
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

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

Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 5 Nov 2010 10:08:48 +0100
> Von: "M∡rtin Koppenhoefer" 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?


> ja, man sollte einfach mal ins Wiki schreiben, dass width die
> Fahrbahnbreite ohne Gehsteige enthalten sollte.

Im Wiki dämmert viel Information vor sich hin, ohne von der
Mehrheit beachtet zu werden. Tags ohne Sichtbarkeit auf der 
Karte haben wenig Chancen überhaupt wahrgenommen zu werden.
Ausserdem wurde ja das Wiki von höherer Stelle als reines
Vorschlagswesen eingestuft ;)


> ja, oder auch schmaler. In Z18 ist die OSM-Straße meist schmaler als
> die Realität.

Stimmt, Fällt z.B. hier unangenehm auf:

> http://www.openstreetmap.org/?lat=52.08868&lon=8.69753&zoom=17&layers=B000FTF

In dieser Zoomstufe wird die vorhandene Fläche nicht effektiv
zur Darstellung der Fahrbahneinzelheiten genutzt. Möglich ist
z.B. diese Darstellung (noch ausbaufähig):

> http://img214.imageshack.us/img214/2618/bosmcrossing2.png

Dass es Google&Co (noch) nicht hinbekommen, so aufgelöst
darzustellen, da auch z.B. GDF hier alles andere als optimal
ist, ist eine andere Sache. Aber OSM will doch in jeder 
Beziehung anders und vor allem besser sein als das ewige
Vorbild. 

Gruesse Hubert
-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

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

Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 04 Nov 2010 03:16:06 +0100
> Von: Stephan Wolff 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?

> Sobald die Bedeutung von width klar ist, könnte man enge Straßen in
> der Karte schmaler zeichnen. Osmarender wertet width für Flüsse aus.
> Solange nicht klar ist, ob eine Straße im Gewerbegebiet mit 20m
> Gesamtbreite und 7m Fahrbahnbreite oder eine enge Altstadtstraße mit
> 7m Gesamtbreite und 4m Fahrbahnbreite das Tag width=7 erhält, kann
> man es nicht nutzen.

Ist ein Klassiker, der zeigt, dass diese Form der Basisdeokratie,
also abwarten bis es sich von selber löst, Schwächen hat. 
Niemand hat Vorteile von zwei konkurierenden Definitionen, die
sich gegenseitig ausschliessen und die Auswertung erschweren.

Dabei gäbe es durchaus interessante Definitionen und Vorgaben,
an denen man sich orientieren könnte: 

http://de.wikipedia.org/wiki/Stra%C3%9Fenquerschnitt
http://de.wikipedia.org/wiki/Richtlinie_f%C3%BCr_die_Anlage_von_Stra%C3%9Fen_%E2%80%93_Querschnitt
(Analog auch für andere Länder)

Ähnlich sieht es mit den Spuren aus. Ich habe mal ausprobiert
wie man mittels Spurbeschreibungen auf eine gute Annäherung an
die Realität kommen kann:

http://lists.openstreetmap.org/pipermail/talk-de/2010-January/060852.html

Zusammen mit den Informationen zur Spurbreite, die man auch aus
den Standards ableiten kann (falls als Bezug angegeben) ergibt
das in den unteren Zoomstufen eine Alternative zu der heute
gebäuchlichen Überhöhung der Breite. Gemeint ist die übliche
nicht massstabsgerechte Darstellung der Breite, die je nach
Zoomstufe deutlich breiter ist als in der Realität. 
 
Dabei ist in den hohen Zoomstufen durchaus eine realistische
Darstellung des Flächenverbrauchs möglich und dann wird auch 
die Breite real nutzbar. 

Gruesse Hubert
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

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

Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 30 Oct 2010 09:45:42 +0200
> Von: Jochen Topf 
> An: Jonas Stein 
> CC: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
 
> Das ist keine Anarchie. 

Nein, das ist keine Anarchie, das ist die natürliche Entwicklung
eines Systems, das weitgehend sich selbst überlassen ist. Es
verliert Struktur und verfettet. Kennt jeder irgenwie vom 
deutschen Steuerrecht oder manche von uns von endlosen
Projektsitzungen bei denen immer nur ein schaler Kompromiss
herauskommt. OSM ist hier nicht herrausragend, weder in die
eine, noch in die andere Richtung.

Ein Konzept wie das OSM-Taggingschema kann an seinen
Selbstreinigungskräften gemessen werden. Wie gross sind die
Chancen, dass Altlasten, die sich nicht bewährt haben,
abgeworfen werden oder wird alles zusammenaggregiert und
verwurschtelt? 

> Aber es funktioniert.

Es kommt darauf an, was man unter 'funktionieren' versteht. Ja,
es stimmt, das OSM Datenmodell schleppt sich gemächlich über
die Jahre ohne eine echte Entwicklunsperspektive zu haben.

> Langfristig setzt sich so nämlich die Mehrheit der an einem Thema
> interessierten durch. 

Na ja, meistens setzt sich das durch, was der Editor als
Mehrheitsbeschaffer vorgibt ;)

Aber auch wenn nicht, Mehrheiten erzeugen keine Tiefe und
vermitteln auch keine Selbstreinigungskräfte. Das wird besonders
deutlich, wenn sich zwei Lager bilden, von denen jede Seite
genug Einfluss hat, um ihre Wahrheit in Teilbereichen 
durchzusetzen.

> dann muss man das nicht in einem speziellen (selbsternannten) Gremium
> durchsetzen. 

Der gute alte Buhmann - das Gremium, das über die Köpfe der
Anwender hinweg bestimmt. Was ist, wenn dieses Gremium nur
Vorschläge macht und die Anwenderschaft darüber abstimmt,
ob sie diesen Vorschlag für Vrteilhaft hält? Aber im 
heutigen OSM ist das undenkbar - es gibt nur die primitive
Abstimmung mit der Macht der Einträge über tagwatch oder
einsame diktatorische Entscheidungen hinter verschlossnen
Türen, die man als Mapper gefälligst zu akzeptieren hat.

> Oder es hat diese Macht, dann werden sich alle Mapper, die der Meinung des
> Gremiums nicht zustimmen, von OSM abwenden.

Huhuuu, noch so ein Horrorszenario. Ein pöses machtgeiles
Gremium vertreibt die Mapper. Warum immer diese dummen
Polarisierungen, die jeden Mittelweg als ungangbar 
brandmarken? In den ganzen Jahren gab es so gut wie niemanden.
der ein so machtvolles Gremium gefordert hat, aber jeder gut
gemeinte Ansatz wurde mit Pauschalargumenten wie diesem
hier in Grund und Boden geschrieben. 

Was hingegen immer wieder viele Mapper gefordert haben, war
eine Richtschnur, die ihnen das Mappingleben erleichtert.
 
> OSM verwendet schon das richtige Verfahren. Sonst wäre das Projekt nicht
> so
> weit gekommen. 

Es ist wie es ist und weil es so ist, ist es gut? Diese Aussage
ist in dieser Pauschalität einfach nur Unsinn. Keiner von uns
hat eine Glaskugel, die das 'was wäre wenn' beantworten kann, aber
einige von uns kennen noch die alten Zeiten (vor Mitte 2007), 
in denen durchaus kreativ an den Tags gearbeitet wurde und 
zusammen das Schema verbessert wurde - ganz ohne Tagwatch & Co.

> die
> Welt, die nunmal sehr komplex ist, in ein simples Schema zu pressen. 

Und deshalb versucht man bei OSM diese Komplexität noch zu
übertreffen, indem man über ein primitives Basisschema eine
quasi unendliche Vielfalt an Taggingvariationen stülpt die
alles oder nichts aussagen?

> es geht
> darum,
> etwas praktisch nutzbares zu entwickeln. 

Und genau hier hätte ich weniger fromme Sprüche erwartet, sondern
eine ernsthafte Abhandlung darüber, ob OSM in der praktischen
Nutzbarkeit wirklich so überlegen ist. Also etwas Modelltheorie,
die sich mit Redundanzen und der maximal erreichbaren Komplexität
(nicht nur schreibend, auch lesend) befasst. 

Schon eine so simple Sache wie Abbiegeverbote hat OSM schon oft
an seine Grenzen gebracht oder bringt es sie noch?

-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

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

Re: [Talk-de] Schlechtest Wertung für OSM im Kartenv ergleich

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 26 Oct 2010 06:59:57 +0200
> Von: Bernd Wurst 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Schlechtest Wertung für OSM im Kartenvergleich

 
> Ich denke nicht, dass dieser Test mich irgendwie vom Hocker reißt...

Muss er auch nicht, er hat nur einen Teilaspekt verglichen,
also was man in einer bestimmten Zoomstufe in verschiedenen
Onlinekarten sehen kann. Und dabei ist er auf bekannte 
Schwächen der OSM-Renderer gestossen, die ja auch hier
schon ausgiebig diskutiert wurden.
 
> Meiner Meinung nach hat da jemand zwar schon Ahnung von Kartographie, aber
> dennoch das Internet nicht verstanden. Die Möglichkeit in verschiedenen
> Zoom-
> Leveln eben nicht das selbe Bild anzuzeigen sondern Details ein- oder 
> auszublenden ist doch grade das was das Internet von gedruckten Karten 
> unterscheidet.

Es ist auch ein Kriterium, wieviel ich zoomen muss, um an
die gewünschte Information zu kommen. Man kann es dem
Anwender nicht vorwerfen, wenn er ein wenig 'zoomfaul' ist.
 
> Dennoch hat der Autor einen sehr merkwürdigen Anspruch, denn er will
> Details 
> sehen ohne dafür zu zoomen. Er fidnet es offenbar eine gute Idee bzgl.
> der 
> Übersichtlichkeit, die Karte flächendeckend mit Symbolen und Texten voll
> zu 
> stopfen. 

Überladen ist die eine Sache, eine andere ist es, ob in der 
jeweiligen Zoomstufe die wichtigsten Inforrmationen angezeigt
werden, die in exakt dieser Zoomstufe interessieren. Ich kenne
das Problem in der Art, dass ich oft dauernd rein- und
rauszoome weil eine Infoemation anders nicht zu finden ist,
ganz typisch dabei sind eben Ortsnamen.

An anderer Stelle kommt OSM aber noch gut weg. Bei anderen
Ausschnitten sind nach wie vor die wichtigen trunks fast
unsichtbar, weil sie von stark grün eingefärbten Flächen
fast verdeckt werden. Hier sollte man doch wirklich mal ernsthaft
überlegen, ob es nicht möglich ist, Hauptverkehrsstrassen vom
Hintergrund besser abzuheben, entweder indem man die 
Flächen weniger intensiv einfärbt oder indem man eine 
andere Farbe für trunk wählt. 

Dann zoomt man sich vielleicht nicht mehr die Mausfinger wund,
wenn man einen Streckenverlauf verfolgen will ;)

Gruesse Hubert


-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

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

Re: [Talk-de] Qualitätsvergleich, war schlechteste Wertung

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 26 Oct 2010 11:43:07 +0200
> Von: "M∡rtin Koppenhoefer" 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de]Qualitätsvergleich, war schlechteste Wertung

> Am 25. Oktober 2010 20:56 schrieb qbert biker :
> 
> > - Schwammige Beschreibungen, die man sich in einem
> > unübersichtlichen Wiki selber zusammensuchen muss und die
> > auch nicht durchgängig angewendet werden.
> 
> 
> das wird sich bei einem crowdgesourceten Anarchoprojekt wie OSM
> systembedingt nicht vermeiden lassen und hat auf der anderen Seite ja
> auch positive Effekte.

Geht nicht, gibts nicht ;)

Was sich systembedingt vermeiden lässt, ist eine weitgehend 
eine Frage der Spekulation, auch ob die positiven Effekte
mehr Realität als Wunschtraum sind, kann weder bewiesen, noch
widerlegt werden.

Ich halte mich hier lieber an das konkrete und das bedeutet in
diesem Fall, dass Fred immer sehr aggressiv gegen jede 
Form von Datenmodell angewettert hat unds jetzt genau er sich
beschwert, dass man draussen mehr die Karte sieht und weniger
die Daten. 

 
> > - Eine Ebene, also ein Graph für alles und damit eine
> > sehr unübersichtliche und ineffiziente Struktur zum Routen
> 
> 
> Wer routen will, muss sich natürlich die Daten entsprechend
> vorbereiten, das ist klar. Wir sind ja keine reine Routingdatenbank.

'Wir mappen ja nicht für...' ich weiss noch gut, wie dieser
Spruch damals aufgekommen ist. Das war eine Reaktion darauf, 
dass immer mehr Leute sich die Attribute so zurechtgebogen 
haben, dass es auf der Karte gut aussieht. Hier wurde dann
mit Recht darauf hingewiesen, dass nicht die Optik der 
Kachel im Mittelpunkt steht, sondern die Integrität der 
Daten. 

Hier geht es aber um etwas anderes. Es gibt verschiedene 
Ansätze, wie man Daten so strukturiert, dass sie von 
verschiedenen Anwendungstypen gut verarbeitet werden können.
Die Datenstruktur von OSM erschwert derzeit einseitig das
Routen, da es sehr schwierig ist, den Graphen von Ballast
zu befreien und zu straffen. Das ist aber dann wieder die
Voraussetzung für effizientes schnelles Routen und gute
Optimierung. 

> > - Flache Struktur bei der Abbildung der Strassenattribute,
> > also keine getrennte Erfassung verschiedener Typenklassen
> 
> 
> kannst Du das nochmal weiter ausführen? Wir haben ja sowohl
> administrative (ref) als auch "intelligent gewichtete" (highway) als
> auch physikalische (surface, width, lanes, smoothness, trackgrade) als
> auch legale (access, maxspeed, z.T. highway) "Klassen" bzw. Typen. Wo
> fehlt Dir da noch was?

Was fehlt sind weniger 'intelligent gewichtete' sondern
nach konkreten Angaben gewichtete Parameter und das 
flächendeckend. Es stimmt, dass es eine fast unüberschaubare
Anzahl von additiven Parametern gibt, die aber sehr selten
angewendet werden. Ein negativer Effenkt der intelligenten
Gewichtung ist auch, dass viele konkrete Angaben nicht eintragen 
weil sie annehmen, dass die Angabe schon irgendwo in der
intelligenten Entwicklung steckt.

 
> > Draussen kommt OSM vor allem als grosser Malkasten an und
> > deshalb auch der ständige Vergleich mit Google Maps und seinen
> > auf Fremddaten aufgebauten Kacheln. Wenn man OSM vor allem
> > als Datensammlung anbieten will, sollte man dann doch ein
> > wenig daran arbeiten, die Daten als abstraktes Datenwerk
> > etwas verdaulicher anzubieten.
> 
> 
> ich sehe das eher so: wir bieten die Daten kostenlos an z.T. in einer
> besseren Qualität als kommerzielle Anbieter. Der Preis dafür ist, dass
> man sich ein bisschen anstrengen muss bei der Interpretation /
> Auswertung. Diese Hürde werden immer mehr auf sich nehmen, je besser
> und vollständiger unsere Daten werden, sieht man ja schon jetzt
> unübersehbar (z.B. Skobbler, AOL).

Auch hier wieder wie oben: Ursache und Wirkung. Warum Skobbler 
ausweichen musste ist bekannt und auch ansonsten geht es eher
zäh als flott voran mit der Anerkennung der OSM-Formate und
der blanken Daten. In der derzeitigen Form verteuert OSM die
Entwicklung von Anwendungen statt die potentiellen Entwickler
zu umschmeicheln. 

Ich schreibe das als Entwickler, der OSM Daten seit Ende 2006
interpretieren kann und seit Anfang 2007 darauf routet. So hart
wie es klingt, das einzige was die Arbeit wirklich derzeit 
erleichtert ist, dass an den Strassen und Wegen kaum mehr 
gefummelt wird und die Stagnation das erreichte erhält. 

Gruesse Hubert
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

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

[Talk-de] Qualitätsvergleich, war schlechteste Wertung

[qbert biker]

Frederik Ramm wrote

> Genau, das ist aergerlich. Wenn wir es besser schaffen wuerden, darauf 
> hinzuweisen, dass es bei uns nicht primaer darum geht, gegen Google etc. 
>  anzustinken, dann wuerde "OpenStreetMap" in so einem Test gar nicht 
> aufgenommen 

Diese Haltung von dir hatte ich noch nie verstanden. Statt sich
zu freuen, dass OSM als Alternative wahrgenommen wird, soll sich
OSM verstecken und nicht verglichen werden? 

> (genauso wie auch "Navteq" und "Teleatlas" nicht mit eigenen 
> Produkten antreten) - und darauf sollten wir hinarbeiten. 

Das wird ohne Datenmodell nicht gehen, und gegen ein
ausgearbeitetes Datenmodell hast du dich ja persönlich ja 
mit aller Macht gestemmt. 

> Ich will, das 
> in so einem Test dann MapQuest oder sonst wer steht und dass am Rand 
> angemerkt wird, dass fuer dieses oder jenes Angebot die Quelle 
> OpenStreetMap ist.

Deshalb hatte ich vor längerer Zeit angemerkt, dass man auch
ein Auge auf externe Anwendungsentwickler haben sollte und 
denen werden OSM-Daten nach wie vor nicht schmackhaft gemacht.

Die Steine, die OSM den Anwendungsentwicklern in den Weg legt
haben sich seit langer Zeit nicht geändert:

- Schwammige Beschreibungen, die man sich in einem 
unübersichtlichen Wiki selber zusammensuchen muss und die
auch nicht durchgängig angewendet werden.

- Eine Ebene, also ein Graph für alles und damit eine
sehr unübersichtliche und ineffiziente Struktur zum Routen

- Flache Struktur bei der Abbildung der Strassenattribute,
also keine getrennte Erfassung verschiedener Typenklassen

Draussen kommt OSM vor allem als grosser Malkasten an und
deshalb auch der ständige Vergleich mit Google Maps und seinen
auf Fremddaten aufgebauten Kacheln. Wenn man OSM vor allem 
als Datensammlung anbieten will, sollte man dann doch ein 
wenig daran arbeiten, die Daten als abstraktes Datenwerk 
etwas verdaulicher anzubieten. 

Drueber zu jammern, dass die Daten als solche nur als 
Nebensache gesehen werden und man die Renderkacheln doch
bitte nicht vergleichen sollte, bringt eher wenig.

Grüsse aus der (beruflich bedingten) Versenkung

Hubert
-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

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

Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs. Nutzung

[qbert biker]

 Original-Nachricht 
> Datum: Sun, 11 Apr 2010 16:37:00 +0200
> Von: "Johann H. Addicks" 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs.
> Nutzung

> Am 11.04.2010 15:54, schrieb qbert biker:
> 
> > Solange Ausbauzustand und Nutzungsbeschränkung nicht unabhängig
> > voneinander erfasst werden, kann ich mir weder beim Ausbau, noch
> > bei den Beschränkungen wirlich sicher sein, was ich vorfinde.
> 
> Du ignorierst trotzdem "die dritte Dimension": Die Tatsächliche Nutzung.

Nicht wirklich, denn es gibt noch einige 'Dimensionen' mehr.
Es gab ja auch mal den Vorschlag mit der Smoothness, die z.B.
für die Skater interesant ist. Die Anzahl der potentiellen
Dimensionen und der möglichen Kriterien ist nach oben offen.
 
> Ich erinnere nochmal an die betonierten Feldwege "zwischen den Äckern" 
> in der Gegend hier.
> Überall 250er davor mit "Land- und Forstwirtschaft frei". Reale Nutzung 
> (nach Nutzerzahlen) jedoch nicht durch Traktoren oder Förster, sondern 
>  >99% Jogger, Gassigänger und Freizeitradler (ebenfalls mit Hund...).
> 
> Gebaut ist das als etwas was anderswo schon ein unclassified wäre. 
> Breite 250 bis 350, stabilisierte Bankette, guter smoothness-Wert.
> Designiert ist es ein Track mit jede menge "no" für den Access 
> (vermutlich sogar Radfahrer).
> Von der Nutzung ist's zu 100% ein kombinierter Rad- und Fußweg wo 1-2 
> mal die Woche auch ein Traktor langfährt, wenn nicht gerade 
> Zuckerrübenkampagne oder Weinlese ist.

Ich sehe das ja immer aus der Entwicklersicht, also demjenigen, 
der die Daten liest und interpretiert und dann dem Nutzer 
Vorschläge machen kann, welcher Weg für ihn geeignet ist. 
Zuerst interessiert da, ob überhaupt ein Weg vorhanden ist, 
was der Eintragung des Ways abgehakt ist.

Die zweite Ebene beschreibt dann, ob man den Weg nutzen kann
oder darf und zwar unabhängig voneinander. Man kann das als 
Matrix sehen und ich versuche das mal zu verdeutlichen, indem
ich jeweils 5 Stufen für die Beschaffenheit und 5 Stufen für
die Beschränkungen annehme. Das gibt dann eine Matrix von 
5x5 mit Beton- oder Teerstrasse bis fast verwildert in der
einen Dimension und komplett frei bis komplett verboten in der
anderen Dimension.

Die meisten Verbindungen sammeln sich in der Diagonale, die
von 'guter Ausbau/freie Benutzung' nach 'miserabler Ausbau/
Verboten' geht. 

Je weiter weg man sich von der Diagonale weg bewegt,
desto seltener sollte die Kombination werden. Das gipfelt
dann in den Ecken senkrecht zur Diagonale mit den Kombinationen
'guter Ausbau/Totalverbot' und 'freie Fahrt/unbefahrbar'.

Insgesamt erhalte ich mit nur zwei Attributen 25 Möglichkeiten
der Basisbeschreibung eines Weges, die alle gültig sind. Der
Beschreibungaufwand steigt linear, die Beschreibungsqualität
quadratisch. Bei dem oben beschriebenen Fall driftet das in
die Ecke 'guter Ausbau/Totalverbot'

Quetscht man Ausbau und Restriktion in eine Skala, bewegt
man sich entlang der wahrscheinlichsten Kombination, also
entlang der beschriebenen Diagonalen und spannende Details
bleiben auf der Strecke. Das von dir beschriebene Beispiel
ist hier sehr typisch. Egal für was sich der Mapper 
entscheidet, ob unclassified, track oder was auch immer,
ohne Zusatzinformation bleibt der Weg suboptimal beschrieben.

Bestimmte Nutzer wie z.B. Fahrradfahrer oder Rollstuhlfahrer
fühlen sich in der Ecke mit dem guten Ausbau und der 
starken Restriktion am wohlsten und auf der anderen 
Seite sucht der Motocrossfahrer ganz gezielt nach unbefestigten
Strassen in möglichst miserablen Zustand, die er befahren 
darf und die ihm erst Spass machen, wenn man kaum noch 
durch kommt.

Ich denke also durchaus an die Dimension der tatsächlichen
Nutzung, wenn ich eine möglichst differenzierte und neutrale
Beschreibung für die beste halte.

Grüsse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs. Nutzung

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 9 Apr 2010 16:03:09 +0200
> Von: Thomas Ineichen 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs.
> Nutzung

> Hallo Mrtin,
> 
> >> Für   mich   ist   wichtig:  "da  muss  ich  normalerweise
>  nicht  mit
> >> zweispurigen Fahrzeugen rechnen, also setze ich ein highway=path. Eine
> >> genauere Angabe, wie breit der Weg ist, setze ich im width-Key."
> 
> > Wenn Du den Weg nur vom Satellitenfoto kennst, wie willst Du dann
> > beurteilen, ob Du da mit zweispurigen Fahrzeugen rechnen musst oder
> > nicht?
> 
> Mein  obiger  Absatz  war  allgemein  formuliert  und  nicht  auf  den
> konkreten Weg bezogen.
> 
> 
> Dass  zwei Personen den selben Weg unterschiedlich bewerten können, es
> daher  kein  "richtig  oder  falsch"  gibt und ich meine unvollkommene
> Beurteilung  nicht  als  den  "einzig  wahren Weg" durchsetzen möchte,
> sollte eigentlich aus meiner Mail bereits hervorgegangen sein..


Das eigentliche Problem ist, dass man zwei Abhängigkeiten in eine
Skala presst und das wird immer zu den genannten Problemen führen.
Solange Ausbauzustand und Nutzungsbeschränkung nicht unabhängig
voneinander erfasst werden, kann ich mir weder beim Ausbau, noch
bei den Beschränkungen wirlich sicher sein, was ich vorfinde.

Wenn man so eintragen möchte, dass die Daten später richtig
interpretiert werden, sollte man sich nicht auf die Einordnung
als track oder nicht verlassen, sondern mit getrennten Attributen
beschreiben, was man vorfindet.

In diesem Bereich ist ein explizites access und ein explizites
surface Gold wert, denn niemand weiss, wie sich die Sichtweise
auf implizit vermutete Eigenschaften von track morgen wieder 
ändert.

Grüsse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

[Talk-de] eZ430-Chronos Development Tool

[qbert biker]

Hallo,

es gibt jetzt ein Entwicklungstool für MSP430 Microcontroller
in Form einer Armbanduhr von Texas Instruments. Was das 
Gerät für die Bastler unter den OSMlern interessant machen 
könnte sind die eingebauten Sensoren. Ein barometrischer 
Höhenmesser ist dabei, ein Temperatursensor wie auch
Beschleunigungssensoren für x,y, und z. Dazu gibts noch ein 
Funkmodul, um die Daten aus dem Gerät herauszubekommen.

Das ganze gibts incl. Dokumentation, Entwicklungsumgebung,
USB-Verbinder für Funk und Entwicklung für 50$. In der 
aktuellen c't (9/2010, ab Montag, ausser bei Abo) gibts 
einen Kurzartikel zum Gerät und hier

http://focus.ti.com/docs/toolsw/folders/print/ez430-chronos.html

gibts auch noch etwas Information dazu. Barometrische
Höhenmessung war ja schon des öfteren ein Thema hier auf der
Liste und deshalb dachte ich, das Ding könnte den einen oder
anderen interessieren.

Grüsse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 01 Apr 2010 22:16:31 +0200
> Von: "Nils Heuermann" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

Hi, 

da muss ich mich kurz entschuldigen, denn ich hatte Quatsch 
geschrieben, weil ich was verwechselt hatte. Ich halte die 
wayparts hier für einen sehr eleganten Lösungsansatz. 

Grüsse Hubert

> Hi!
> 
> Am Wed, 31 Mar 2010 17:01:37 +0200 hat qbert biker   
> geschrieben:
> 
> >> > Dazu nochmal das klassische Gegenbeispiel, bei dem die
> >> > Linienbuendel nicht wirklich gut funktionieren: Die Doppellinie,
> >> > die nur von einer Spur zur anderen gequert werden kann. Das
> >> > laesst sich auf den Graphen nicht abbilden.
> >>
> >> Mit dem Modell der Wayparts
> >> <http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts> ginge es,
> >> wenn man
> >> ein Tag festlegt, dass den Divider nicht nur crossable, sondern z.B.
> >> outside-
> >> crossable (von der beschreibenden Spur weg) bezeichnet.
> 
> da das ganze Modell bisher ohnehin nur ein Ansatz ist, kann man gerne  
> weitere Dinge dort definieren.
> Wobei ich mir das für die "einseitig gestrichelte Linie" so gedacht
> hatte:
> 
>|
> part1 || part2
>|   |^
>|   ||   |
>v   ||
>||
> 
> part1:divider=line
> part2:divider=dash
> 
> oder:
> 
>|   ||
> part1 | part2 |  part3
>|   |   ^   ||   ^
>|   |   |   ||
>v   |   |   ||   |
>|   |
> 
> part1:divider = line
> part2:divider = line
> part2:outer_divider = line
> part3:divider = dash
 ...
-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Spurzahl-Tagging statt Linienbündel (was: Details mappen in Dortmund)

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 02 Apr 2010 17:52:20 +0200
> Von: "Johann H. Addicks" 
> An: talk-de@openstreetmap.org
> Betreff: [Talk-de] Spurzahl-Tagging statt Linienbündel (was: Details mappen 
> in Dortmund)

> qbert biker schrieb:
> > Und nochmal der Gegenbeweis:
> > http://img214.imageshack.us/img214/2618/bosmcrossing2.png
> > 
> > Jede Koordinate in diesem Bild wurde aus den Basislinien 
> > erstellt. Man muss dazu nichts per Hand parallel zeichnen,
> > das kann der Rechenknecht viel besser. 
> 
> 
> Das ist doch wunderbar!
> Auch wenn sich's blöd anhört, aber ließe sich das irgendwie in Mapnick
> einbringen?

Ich weiss nicht, warum sich das blöd anhören sollte ;)

> Dann könnte die die Darstellung von einigen Autobahn- und
> Motorway-Kreuzen deutlich vereinfachen. Und sicher wird dann irgendwann
> auch mkgmap nachziehen und sinnvolle Garmin-Routinganweisungen daraus
> erstellen (statt wie derzeit Abbiegehinweise zum Befahren von
> Abbiegespuren zu geben)

Ich habe leider sehr wenig Ahnung von Mapnick und SVG und kann
deshalb nur ein wenig spekulieren. 

Ich gehe davon aus, dass Mapnik mit Vektoren und Flächen, die
über Geokoordinaten definiert sind, etwas anfangen kann. Diese
Daten fallen in dem gezeigten Programm als Zwischenergebnis
an. Was ich mir vorstellen könnte ist eine art Proxy, der
das Teilnetz auswertet, die benötigten Koordinaten erstellt
und dann an Mapnik übergibt. 

In meinem Beispiel ist die Darstellung ueber Qt mit normalen
Grafikprimitiven realisiert. Zuerst wird die graue Fläche als 
Basis gezeichnet und dann an den Begrenzungen die weissen Linien.
Zuletzt kommen die gestrichelten Linien dran, die über die 
graue Fläche gezeichnet werden.

Zur Realisierung: Die gegebenen Netzdaten werden in eine
Abbildung projeziert, die die Rechtwinkligkeit herstellt. Auch
wird auf Meter normiert so dass ich Befehle anwenden kann
wie: Erstelle eine Parallele zum Polygon in 3m Abstand zur
Basislinie. Diese Funktionen bauen ihrerseits auf einer
selbstgebastelten Geometrielib auf, die Geradengleichungen
nutzt, um an die benötigten Schnittpunkte zu kommen.
Die erstellten neuen Punkte können dann wieder zu 
Geokoordinaten zurückgewandelt werden.

Im Grenzbereich zu den anderen Elementen werden dann noch
gemeinsame Punkte berechnet, um Darstellungsfehler zu 
vermeiden. Deshalb braucht das Verfahren auch einen Netzbezug,
die auf einen Knoten grenzenden Links muessen also bekannt
sein. 


Wie kann ich also helfen. Wenn Interesse besteht, kann ich 
die Verfahren dokumentieren, so dass sie direkt in einem
Renderer umgesetzt werden können. Und/oder ich kann die 
C/C++ Routinen zur Verfügung stellen, damit jemand den Proxy
bauen kann. Ich selber habe leider nur sehr begrenzte 
(Zeit-)Ressourcen.

Gruesse Hubert
-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 3 Apr 2010 03:21:58 +0200
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund

> Am 2. April 2010 12:15 schrieb qbert biker :
> > Um mit den obigen Worten zu sprechen: Man kann den Eindruck
> > bekommen, dass einige so berauscht von den Luftbildern sind,
> > dass sie am liebsten OSM auf ein simples Vektorabbild dieser
> > Bilder reduzieren möchten.
> 
> 
> ein "simples Vektorabbild", mit einer Handvoll simplen Tags. Das
> willst Du ernsthaft mit einem Bitmap auf eine Stufe stellen? Was soll
> das Wort "simpel" in diesem Kontext bedeuten?

Simpel bezieht sich auf das Modell, bzw. den
Abstraktionsgrad.

Gruesse Hubert 
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 2 Apr 2010 13:51:42 +0200
> Von: Bernd Wurst 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Details mappen in Dortmund

> Am Freitag 02 April 2010 12:49:31 schrieb qbert biker:
> > Und nochmal der Gegenbeweis:
> > http://img214.imageshack.us/img214/2618/bosmcrossing2.png
> 
> Mache einen Renderer, der solche Bilder macht, 

OK, abgehakt, siehe screenshot

> irgendwo öffentlich
> zugänglich 

Naja, das letzte Vierteljahr ist keiner auch nur auf die
Idee gekommen, danach zu fragen. Also OK, wenn sich 
jemand fuer den Quellcode interessiert, dem kann geholfen 
werden, sobald die aktuellen bugs raus sind. 

> (das stets aktualisierte Ergebnis, nicht nur den Sourcecode),

Kacheln? Da muesste jemand anderes ran. Das ist (eher wird)
ein Editor mit WYSISYG-Darstellung. Ich interessiere mich
mehr für Echtzeit-Vektorvisualisierungen (z.B. Spurassistent 
fürs Handy). Bitmaps sind nicht so mein Ding.

> dokumentiere
> die 
> Tags die es dazu braucht 

In der Mail vom 1.1.2010 ist das Netzbeispiel mit drin.
Eigentlich muss nur 'lanes' richtig gesetzt sein.

> und ich garantiere dir, in kürzester Zeit wird
> es 
> einige Autobahnen geben, die derartig gemapped sind.

Kann sein, kann auch nicht. Ich habe jetzt erstmal einiges
an Arbeit reingesteckt, um diese Methode überhaupt 
demonstrieren zu können. Weiterentwicklung findet statt,
aber berufsbedingt relativ langsam.

Grüsse Hubert
-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 02 Apr 2010 03:08:44 +0200
> Von: "André Reichelt" 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund

> Nehmen wir als Beispiel die Einfädelspur einer beliebigen
> Autobahnauffahrt. Um diese zu beschreiben müsste ich unter Verwendung
> von *Vektoren* zunächst zwei Spuren parallel zeichnen: Die Autobahnspur
> sowie die Beschleunigungsspur. 

Und nochmal der Gegenbeweis:

http://img214.imageshack.us/img214/2618/bosmcrossing2.png

Jede Koordinate in diesem Bild wurde aus den Basislinien 
erstellt. Man muss dazu nichts per Hand parallel zeichnen,
das kann der Rechenknecht viel besser. Und ja, der Übergang
am Ende der Einfädelspur fehlt noch, aber die lässt sich 
ebenso einfach aus den Basislinien errechnen wie der Rest.

Ich hatte das ohne Luftbild gemacht aber mit Luftbild 
kann man dann die Geometrie nochmal gegen dieses prüfen
und die Daten interaktiv berbessern.

> Dann muss ich über abstrakte Elemente
> (Relation) beschreiben, in welchem Stück eine Überfahrt möglich ist.

Auch das ist kein Zwang. Für den Router sind parallele
Spuren ein Weg und eine Spurassistenz hat bei dieser 
Darstellung die Daten, die sie braucht. Nur Ausnahmeregeln
(z.B. Doppellinie, einseitiges Wechseln) müssen noch
explizit hinterlegt werden.

> Sofern die Übergangsflächen rechteckig sind, geht das einfach.
> Spätestens wenn ich allerdings wie auf der Autobahn S-Kurven habe, muss
> ich über zusätzliche Vektoren beschreiben, wie die Ränder der
> Auffahrspur genau verlaufen. 

Nein, man muss es nicht, man kann. Ausserdem sind diese
S-Übergänge kein Hexenwerk (siehe anderer Beitrag)

> Des weiteren muss ich über ein Regelwerk
> festlegen, ob denn nun der Startpunkt des Auffahrspurenvektors die
> Straßenmitte widerspiegelt oder ob wir uns auf der Linie befinden. 

Stimmt, aber festzulegen, auf was sich ein Punkt oder eine
Linie eigentlich bezieht, könnte direkt Sinn machen ;)

> Wenn
> wir in der Mitte sind muss außerdem der Abstand zum Rand bekannt sein,
> den man über die abstrakte Angabe der Breite nur schwer abstrahieren
> kann.

Also, man gehe davon aus, dass die Breite bekannt ist, bzw. 
sich ausmessen lässt. Dann ist bei einer Linienführung in der
Mitte der Abstand vom Rand Breite/2. Ohne Breite macht eine
Flächeneintragung wenig Sinn.
 
Dass die Mitte als Referenzlinie nicht immer die beste
Lösung ist, ist ein anderes Thema.

> Bei einer *Fläche* hingegen habe ich ein sichtbares, für den Menschen
> intuitives Abbild der Wirklichkeit. Eine Festlegung von Regeln ist nicht
> notwendig, da sich alle Regeln aus der Abbildung ergeben, und auch ohne
> Fachwissen über das Datenformat kann Jedermann sofort erkennen, was
> gemeint ist.

Hint: Das geht noch besser, wenn man sich das Bild, also die
Vorlage von der man abmalt, direkt anschaut und man spart sich 
viel Arbeit ;)

Sorry für den kleinen Scherz, aber das OSM-Format ist in seiner
Rohform ziemlich unverdaulich. Erst die Interpretation über
josm, die Renderer oder auch die Router bereitet das 
menschenlesbar auf. Und so aufbereitet erkennt Otto-Normaluser
seine Strasse, egal ob die als Fläche oder als Vektor kodiert
ist. 

Gruesse Hubert
-- 
GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern
E-Mail, SMS & mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 02 Apr 2010 03:15:02 +0200
> Von: "André Reichelt" 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund


> Wenn es immer so einfach wäre. 

Nein, es muss nicht IMMER so einfach sein, es reicht, wenn
es FAST IMMER so einfach ist. Nicht die Ausnahme sollte das
Design bestimmen, sondern die Regel, aber die Regel sollte
Ausnahmen zulassen koennen.

> Jedoch geschieht der Übergang zwische
> verschiebenden Straßenbreiten nicht schlagartig. 

Ich hatte bei den Parametern eine Uebergangslänge
angegeben, die das ausdrückt. 

> Dementsprechend müsste
> ich die Breitenzunahme komplex als Funktion beschreiben, um exakt zu
> sein. 

Um was zu beschreiben? 

> Um dies zu tun muss ich nicht nur Mathematik studieren sondern
> auch noch diverse Regeln festlegen, um aus der abstrakten Beschreibung
> ein genaues Bild zu rekonstruieren.

Die Erweiterung beginnt an Punkt A mit x Meter und endet an 
Punkt B mit y Meter Breite. Dazu ist weder ein koplexes 
Regelwerk, noch ein Mathematikstudium nötig. Wem das nicht 
genug ist, der kann noch einen Abrundungsradius dazufügen.

> Und kommt mir jetzt nicht mit dem Argument, diese Genauigkeit sei gar
> nicht erforderlich. Ich weiss, dass ich den genauen Verlauf der weißen
> Linien an einer Autobahnauffahrt für die Navigation nicht brauche. Das
> ist aber nicht der einzige Anwendungsfall, auch wenn sich das einige
> hier anscheinend wünschen.

Findest du das nicht ein wenig zu polemisch?  Ja, Routing ist 
wichtig bei einer digitalen Karte, aber weder das wichtigste, 
noch die einzige Anwendung. 

Aber hier gehts nicht darum. Hier gehts darum, ob es mehr als
eine Methode der genauen Darstellung gibt und dass hier der
Eindruck erweckt wird, dass allein das haendische Reinmalen von
Nodes den Anspruch hoechster Genauigkeit erfuellen kann. Und 
ich vertrete eben die Meinung, dass da ein geometriegestützter
Ansatz gut mithalten kann oder vielleicht sogar überlegen ist.

Um mit den obigen Worten zu sprechen: Man kann den Eindruck 
bekommen, dass einige so berauscht von den Luftbildern sind, 
dass sie am liebsten OSM auf ein simples Vektorabbild dieser
Bilder reduzieren möchten. 

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Strassen als Flaechen

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 01 Apr 2010 15:38:46 +0200
> Von: Frederik Ramm 
> An: Openstreetmap allgemeines in Deutsch 
> CC: m...@koppenhoefer.com
> Betreff: Re: [Talk-de] Strassen als Flaechen

> Hallo,
> 
> qbert biker wrote:
> > Weil die Werkzeuge das bisher nicht unterstuetzen. Wenn
> > ich eine Basislinie zeichne und die in die Breite ziehe, ist
> > das auch intuitiv und einfach und ich vermesse in einem
> > Arbeitsgang auch gleich die Breite mit. 
> 
> Vorausgesetzt, Du hast die Basislinie intuitiv in die Mitte gezeichnet ;-)

Vielleicht intuitiv, besser ueberlegt, bzw. konfigurierbar. 

Bei Luftbildern ist es intuitiv einfacher mit einer der
Kanten anzufangen und das dann ueber die Mitte zur anderen 
Kante rueberzuziehen. Dann stimmt auch die geometrische 
Mitte ;)

Bei rechteckigen Haeusern mache ich das schon ein Weilchen
und da klappts das super. Bei Strassen klappt das 
massstabsgetreue Darstellen schon ganz gut (siehe Link 
vom 1.1.), aber das Werkzeug zur dynamischen Manipulation 
fehlt noch. Mal schaun, wenn das Wetter zu Ostern so mies 
wird wie angesagt...

Gruesse Hubert
-- 
NEU: GMX DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit!
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 1 Apr 2010 14:55:42 +0200
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund

Hallo,
 
> das ist nicht falsch, und sicher wird das auch im überwiegenden Fall
> so gemacht werden (vor allem ausserhalb der Städte, da gibt es weder
> Luftbilder, noch Leute oder Bedarf, die Flächen genau zu erfassen,

Auf die Gafahr hin, dass ich mich wiederhole. Es geht hier um 
die Flaechen, die man mittels geometrischer Beschreibung und
etwas Rechnerhilfe auch sehr gut und vielleicht sogar besser
erfassen kann als mit einem Knotenmeer. Und gerade wenn man
Luftbilder hat, kann man die Geometrie nutzen, mehr Information
mit weniger Overhead unterzubringen. Die Annahme, dass eine
Flaecheneintragung pauschal genauer ist als eine geometrische
Beschreibung, ist irrefuehrend. Es kommt auf den Einzelfall an.

> auch sind die Straßen da fast immer regelmäßig), aber es gibt auch
> andere Fälle, wo die Leute gerne Flächen hätten, und wo diese auch
> viele Vorteile bieten. 

Was hier immer in Raum schwebt ist, dass es hier um zwei
Dinge geht, die sich ausschliessen. Die Masse der Strassen ist
eben regelmaessig und kann vereinfacht abgebildet werden und
fuer den keinen Rest gibts wie auch heute schon (-> Plaetze),
die Alternativmethode. 

> Im Übrigen ist Flächen zeichnen intuitiver und
> damit deutlich weniger komplex (und fehleranfällig z.B. auch bei Edits
> von weniger Erfahrenen) als die Parametrisierung.

Weil die Werkzeuge das bisher nicht unterstuetzen. Wenn
ich eine Basislinie zeichne und die in die Breite ziehe, ist
das auch intuitiv und einfach und ich vermesse in einem
Arbeitsgang auch gleich die Breite mit. Das fehleranfaellige
haendische Eintragen der Breite entfaellt.

Gruesse
-- 
NEU: GMX DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit!
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 1 Apr 2010 13:32:37 +0200 (CEST)
> Von: Fabian Schmidt 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund

> 
> Am 01.04.10 schrieb Robert S.:
> 
> > 2010/4/1 qbert biker 
> >   Warum? Rinksbuendige Referenz + Spurbreite + Spuranzahl +
> > Uebergangsbeschreibung (z.B. Aufweitung auf 100m Laenge)
> > und das Ding ist sauber beschrieben.
> > 
> > Ach, und das soll dann ernsthaft EINFACHER zu erfassen sein als das
> einfache
> > Nachzeichnen einer Fläche anhand von hochauflösenden Luftbildern?

Ja, denn dabei kann man sich von der SW sehr gut unterstuetzen
lassen. Man zeichnet die Basislinie ein, zieht sie in die Breite,
bis das mit dem Luftbild uebereinstimmt und traegt die 
Spuranzahl ein. GGf. zieht man das noch ein wenig zurecht.
Jetzt Klickt man die Spuren an und parametrisiert sie. 

Geht ganz sicher schneller und einfacher als jede einzelne Spur 
und die die Flaeche einzeln Punkt fuer Punkt reinzufummeln. 
 
> Ja, denn spätestens für turn_restrictions muss ich die Spuren sowieso 
> erfassen, egal ob als eine Linie + Tags oder als mehrere Linien. Also 
> warum soll ich die Fläche zusätzlich erfassen?

Turn restrictions funktionieren auch ohne einzeln eingetragene
Spuren. Rein technisch ist es moeglich, die Information an eine
einzige Basislinie zu haengen und ich halte das auch fuer
sinnvoll. Ein Vorteil ist z.B. dass die Breite der Fahrbahn
auch wieder direkt ausgelesen werden kann. 

OSM soll doch eine freie Datensammlung sein - warum kommt jetzt
ploetzlich diese Fixierung auf Umrisse? Wenn eine Datenbank 
abgeleitete Groessen wie eben die Fahrbahnbreite direkt zur
Verfuegung stellt, was soll daran falsch sein? 

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 01 Apr 2010 02:52:25 +0200
> Von: "André Reichelt" 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund

> Das mag auf Autobahnen fast immer und außerorts gelegentlich gelten,

Ich glaube wir leben auf unterschiedlichen Planeten ;)

Bitte zeige mir mal die Ausserortsstrassen, deren Breite 
gar so fuerchterlich staendig schwankt, dass sie nur 
'gelegentlich' den Anschein erwecken, parallel zu sein.

> innerstädtisch wirst Du damit aber in der Regel massiv auf die Schnauze
> fallen. Abbiegespuren kannst Du mit deiner Methode im Übrigen auch nicht
> sauber darstellen.

Warum? Rinksbuendige Referenz + Spurbreite + Spuranzahl +
Uebergangsbeschreibung (z.B. Aufweitung auf 100m Laenge)
und das Ding ist sauber beschrieben.

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Open Kataster Map, war Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 01 Apr 2010 02:59:54 +0200
> Von: "André Reichelt" 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund

Hallo,
 
> Das einfache Modell funktioniert bei der Navigation und bei groben
> Stadtplänen wunderbar, das habe ich schon gesagt. Spätestens wenn ich
> aber in die Straßenperspektive wechsle wird dir das Ding um die Ohren
> fliegen -- und zwar ganz massiv. 

Das ist mir jetzt zu pauschal und entspricht auch nicht
meinen Erfahrungen. 

Mit ein paar zusaetzlichen Vereinbarungen kann man
eine Darstellung bauen, der die Masse der staedtischen
Strassen gut abbildet. 

> Es gibt Anwendungen, da interessiert
> mich, wo genau in der Kreuzung eine Insel liegt und wie groß die ist. Du
> kannst Dir das vielleicht nicht vorstellen, da Du selbst keine
> Anwendungen in diese Richtung entwickelst, aber grundsätzlich müssen wir
> so detailiert wir möglich mappen. Wir dürfen uns nicht auf die Falle
> einlassen, etwas wegzulassen nur weil wir glauben, dass es gegenwärtig
> nicht sinnvoll nutzbar ist.

Du verwechselst den Detaillierungsgrad mit der Abbildung.
Nur weil man derzeit fast nichts aus dem aktuellen Modell
rauskitzelt, bedeutet das nicht, dass das nicht geht. Da
ist noch sehr viel drin, ohne dass man den ganzen aktuellen
Datenbestand auf den Kopf stellt. Leider ist die 
Ueberhoehung der Breiten bei den OSM-Renderern der Stand
der Technik und sie uebernehmen diese Darstellung damit
(leider) vom grossen Vorbild Google Maps.
 
Ich spreche mich nicht dagegen aus, dass man moeglichst
jedes Detail mappt, aber ich spreche mich dafuer aus, dass
man nicht alles mit der Brachialmethode 'dann setze ich
eben eine Node mehr rein' loest.  

> Das war auch genau der Grund, weswegen man das bis heute nicht macht.
> Jetzt stehen allerdings die Luftbilder zur Verfügung, die uns auf ein
> paar Zentimeter genau erlauben, genau diese Daten zu erfassen. 

Ist doch OK, dann werden eben endlich mal Breiten und 
Abrundungsradien konkret erfassbar und koennen interaktiv
ermittelt werden. 
 
> Wir mappen nicht für heute sondern für morgen. 

Und morgen haben wir dann die OpenKatasterMap :)

Gruesse Hubert
-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 31 Mar 2010 17:01:37 +0200
> Von: "qbert biker" 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

Kleine Korrektur:

> 
> |
> --->x  <- Turn restriction
> |
> ---|   |--->x
>|---||
> \/
> 

OK, leasst man sie getrennt, kann man eine 
turn-restriction einbauen, fuer Rechtsabbieger

Das laesst sich aber auch mit einem Datensatz 
loesen, der die Daten eines Links aufnimmt. Ist
ja ein haeufiger Fall: Z.B. Spur 1 ist Rechtsabbieger
2 Gradeaus und 3 Linksabbieger.

Gruesse Hubert
-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 31 Mar 2010 15:45:32 +0200
> Von: Wolfgang 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

> Hallo,
> 
> hier nochmal das Beispiel (vielleicht war es schon zu spät am Abend...
> :-) )
> 
> xx  k
>r\   bb  k
>  \  -r  k 
>   \/
>\  ppp /
>  /
> 
> x = normale Fahrbahn
> r = Rechtsabbiegespur
> b = Busspur, überqueren nicht erlaubt
> p = Parkplätze
> k = Kreuzung
> 
> Der Bereich direkt vor der Kreuzung ist eine zusammenhängende
> Verkehrsfläche, 
> aber aufgrund der Busspur darf man nur vor den Parkplätzen auf die Spur
> "r" 
> wechseln. An der Kreuzung darf von "x" aus nicht und von "r" aus nur
> rechts 
> abgebogen werden. Im Bereich der Parkplätze sind "x" und "r" baulich
> getrennt.

OK, dann hatte ich das schon richtig verstanden.
 
> Klar, das kann man. Aber, vielleicht fehlt mir hier eine Info, woher weiß
> die 
> Routing-Routine, dass zum Rechtsabbiegen über den Parkplatz, für die
> übrigen 
> Richtungen aber am Parkplatz vorbei geroutet werden muss? Der Klartext
> reicht 
> dazu wohl kaum aus, und das Zusammenführen der Fahrbahn vor der Kreuzung
> lässt 
> der Routing-Routine wieder die (falsche) freie Auswahl.

Auch wenn die nicht wieder zusammengefuehrt sind, kann die
Kuerzestwegsuche nichts damit anfangen, ausser man trickst
sie aus und macht den Weg fuer Rechtsabbieger kuerzer, indem
man die Node ein wenig verschiebt. Eine einfache Routingengine
weiss ja nichts vom Rechtsabbiegen. Wenn die Rechtsabbiegerspur
einen Bogen macht und dadurch laenger wird, wird sie 
unattraktiver und Normal- und Rechtsabbiegerspur sind 
ja wieder mit der Querstrasse verknuepft und somit beide
eine Option.

|
--->x
|
---|   |--->x
   |---||
\/

Eine Wertung fuer Abbiegevorgaenge ist prinzipiell moeglich,
allerdings weiss ich nicht, ob eine der hiesigen Engines
sowas eingebaut hat.

> > Dazu nochmal das klassische Gegenbeispiel, bei dem die
> > Linienbuendel nicht wirklich gut funktionieren: Die Doppellinie,
> > die nur von einer Spur zur anderen gequert werden kann. Das
> > laesst sich auf den Graphen nicht abbilden.
> 
> Mit dem Modell der Wayparts 
>  ginge es,
> wenn man 
> ein Tag festlegt, dass den Divider nicht nur crossable, sondern z.B.
> outside-
> crossable (von der beschreibenden Spur weg) bezeichnet.

Das ist dann auf die Wayparts abgebildet, aber der Graph ist
gnadenlos und interessiert sich nur wenig dafuer. Die
Kuerzestwegsuche ueber den Graphen kennt keine Links, ueber
deren Laenge ein Austausch, egal ob in eine oder in beide
Richtungen, passieren kann.

Man kann natuerlich nach belieben Knoten einfuegen und die
Lanes mit Einbahnen verbinden, aber das ist auesserst unschoen.

In etwa fuer zwei ways einer Fahrbahn mit einseitiger
Wechselmoeglichkeit:

x---x--x>
^   ^  ^ 
|   |  |
x---x--x>
 
Das alles, nur um das einseitige Wechseln der Spur im
Graphen annaeherungsweise abzubilden. Ein Netzoptimierer, der
erkennt, dass das Spuren sind wird das aber wohl wieder 
rausschmeissen, denn jeder Knoten erhoeht den Rechen- und
Zeitaufwand der Suche (linear).

> aber welche? Ich kann die Busspur, die baulich nicht getrennt ist, nicht 
> weiter beschreiben, ohne dabei auf Relationen auszuweichen, die nicht 
> allgemein unterstützt werden. Damit fehlt mir für das Straßenstück von
> der 
> Wiedervereinigung der baulich getrennten Fahrspuren bis zur Kreuzung der
> nicht 
> überquerbare Trenner, eben die Busspur.

Meine ganz persoenliche meinung dazu: Lieber Elemente verwenden,
die noch nicht allgemein ueblich sind, als zu versuchen, den
Router auszutricksen, was nur funktioniert, wenn man den
Funktionsmechanismus des Routers wirklich gut versteht.
 
> Genau das würde ich ja gerne machen, aber wie? Dafür muss es ein Muster
> geben, 
> wie diese Zusatzinformation automatisch bei den Informationssystemen
> ankommen 
> soll.

Die klassische OSM-Antwort darauf ist: Einfach loslegen und 
machen, wenn sich auf der Liste keiner findet, der da naeheres
dazu weiss. 

Gruesse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 31 Mar 2010 13:23:02 +0200
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund
 
> wobei ein Autobahnkreuz auch nicht der Anwendungsfall ist, der mir vor
> Augen schwebt. Da kommt es prinzipiell auf 10 m mehr oder weniger
> überhaupt nicht an (wahrscheinlich nicht mal auf 30 m oder 50 m). 

Wie locker flockig da mal 50m hin oder her egal sind ;)

Eigentlich waers schoen, wenn es eine groessere Entkopplung
von Detailschaerfe und persoenlichen Praeferenzen gaebe.
Bei 50m daneben ortet einen das GPS gerne mal auf den
Feldweg daneben, nur so nebenbei.

Aber schon bei 10 oder 20m daneben sieht einiges ziemich
eigenartig aus, z.B. wenn sich die Fahrbahnen bei 
massstabsgerechter (Breiten-)Darstellung wie wild ueberlappen 
oder Waypoints von Zufahrten mitten auf der Hauptfahrbahn
liegen. 

> Interessant sind die Flächen doch in
> Gegenden wie hier:

So spannend finde ich diese Ecken jetzt auch wieder nicht.
Die grossen Abweichungen arbeitet man dann mittels expliziter
Flaeche ein und bindet die an die Breite der Normalfahrbahn
an. Eigentlich kein Hexenwerk. 

Mal konkret: An welche Anwendung denkst du, wenn du 
diese Flaechen besser abgebildet haben willst?

Gruesse Hubert

-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 31 Mar 2010 00:07:16 +0200
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund

 
> nö, das eine hat mit dem anderen nichts zu tun. Wem an einer
> ansehnlichen Darstellung gelegen ist, der sollte wohl versuchen, die
> Nodes jeweils auf gleicher Höhe zu setzen, solange es wirklich um
> parallele Verläufe geht.

Also die vielen 'krummen Dinger', die ich bei OSM finde,
finde ich in der Realitaet nicht ;). Ansonsten ist das natuerlich
auch etwas, was der Fehlerfortpflanzung unterworfen ist, ausser
man hat so perfeke Ausgangsdaten, dass man beide Linien an
Messdaten oder Bildern ausrichten kann, die eine entsprechende
Aufloesung (Hausnummer: unter einem Meter) erlauben.
 
> Änderungen in der Bauausführung im Vergleich zur Planung sind nicht in
> erster Linie "Fehler des Bauarbeiters" sondern Reaktionen auf
> Unvorhergesehenes, Änderungen aufgrund zwischenzeitlich geänderter
> Anforderungen, sonstiger (z.B. gesetzlicher) Grundlagen und
> Einschätzungen, Reaktionen auf Widerstände (z.B. von Anwohnern), etc.

Oder eben Pixelfehler, die zu angenommenen Abweichungen fuehren
oder, eher der Normalfall, kleine Aussetzer im Auge des Mappers.
Ich habe lange genug die Richtungsfahrbahnen der Autobahnen
als Doppellinie gesetzt, um Erfahrungen darin zu haben...
 
> Interessant sind ja gerade die Stellen, wo es zu Reibungen kam, oder
> z.B. auf unterirdisch verlaufende Leitungen reagiert wurde, etc.,
> nicht die, die glatt durchgezogen werden konnten. Diese Vorgänge sind
> so komplex dass wir mit unserem Ansatz, iterativ diese Details
> aufzunehmen, besser fahren als mit der Idee, von der Planung über die
> Realisierung die Wirklichkeit parametrisch nachbauen zu wollen.

Aus eigener Erfahrung kann ich sagen, dass von dieser gefuehlten
Genauigkeit wenig uebrig bleibt, wenn man da mal richtig
nachmisst. So ein Klassiker ist z.B. die Zeitmessung im Skisport.
Da haben mal teusendstel Sekunden ueber Sieg und Niederlage
entschieden, bis sich jemand mal den Ausloeser am Start
vorgenommen- und rausgefunden hat, dass der technisch nur
Hunderstel aufloest ;)

Derzeit wird bei Strassen eh nur eine gefuehle Mittellinie
eingetragen, schon das ist eine Fehlerquelle. Ich kenne jetzt
auch keine Moeglichkeit, eingetragene Spuranzahlen und Breiten
ueberhaupt zu verifizieren. Wie schon geschrieben, hatte ich
mich mal an dem besagten Kreuz ausgetobt und Breitendaten
aktiv zur besseren Anpassung an die Realitaet genutzt und ich
finde das Ergebnis bildet die Flaechen schon ganz gut ab.

Gruesse Hubert
-- 
GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 25 Mar 2010 00:03:16 +0100
> Von: olvagor 
> An: Frank , Openstreetmap allgemeines in Deutsch 
> 
> Betreff: Re: [Talk-de] Details mappen in Dortmund


Hallo,
 
> Man kann ganz andere Auswertungen fahren. Z.B. gibt es immer mal wieder
> Zeitungsberichte, dass die Umwelt darunter leidet, dass zuviel
> städtische Fläche versiegelt ist. Saubere Daten dazu bekommst du aber
> nur, wenn die Flächen auch wirklich erfasst sind. Linien mit "width=x"
> sind eine Annäherung aber bilden nicht die Realität in dem Maße ab, den
> ich mir vielleicht wünsche.

Die Frage ist, ob es wirklich eine Verbesserung der Darstellung
ist. Ich frage mich z.B. bei diesen Diskussionen immer, warum
keiner Kreissegmente fordert, denn einen Bogen in einzelne 
Segmente aufzuloesen, ist auch ungenau. Diese Ungenauigkeit
wird jetzt noch verstaerkt, wenn man versucht, per Hand eine
parallele Linie zu setzen.

Strassen sind ja menschengemacht und die wurden mal konstruiert.
Natuerlich kann man das ignorieren und Fehler der Bauarbeiters
und Pixelfehler vermessen, aber ist die Flaeche dann wirklich
genauer wiedergegeben? 

> Das Routing funktioniert meines Erachtens eben noch nicht zuverlässig.
> Auf aktuellen OSM-Daten ist es meines Wissens momentan nicht möglich,
> Abbiegeinformatinonen zu bieten, wie sie mein Garmin-Navi seit Jahren
> möglich macht:
> 
> "Halten Sie sich rechts Richtung Karlsruhe und dann links". Das bedingt
> allein schon das Erfassen mehrerer Fahrspuren und ihrer Beziehung
> untereinander. Um mehrere Spuren zusammenzufassen böten sich Flächen
> einfach an.

Dazu ein Experiment, das ich Anfang des Jahres mal gemacht
habe. Hier ist ein Grossteil der Geometrie eines Kreuzes bis
hinunter zu den Fahrspuren (aber noch keine Spurverengungen)
abgebildet.

http://lists.openstreetmap.org/pipermail/talk-de/2010-January/060852.html

Jeder Punkt der hier dargestellt ist, ist eine reelle
Geokoordinate, auch die Strichellinien als Spurentrenner.
Die Parallelverschiebung passiert also direkt mit den
Geokoordinaten und erst dann wird das fuer den Bildschirm
skaliert. 

Trotzdem unterlasse ich es, diese Koordianten der 
parallel verschobenen Linien in den Datenbank zu schreiben,
denn sie sind redundant, da aus den Daten jederzeit zu
ermitteln.

Das was ich hier gemacht habe, hat allerdings einen Haken,
muss ich zugeben. Bei Autobahnen/Schnellstrassen gehe ich
von der Linksbuedigkeit aus, also dass sich der Way auf
den linken Rand bezieht und nicht auf die Mitte. Nur so 
kann man den schmalen Streifen, der die Richtungen trennt
genau genug abbilden, so meine Erfahrungen.
 
> Hat niemand verlangt. Das Routing soll ruhig weiterhin auf Linien laufen.

Mal andersrum: Wenn ich mit etwas Parallelverschiebung eine
so gute Annaeherung erreiche, warum nehme ich dann nicht
Linien als Basis fuer Flaechen? Ich habe den Eindruck, dass
wir derzeit einen Deadlock haben, der verhindert, dass 
Spuren und Breiten effizient genutzt werden.
  
> Nicht zwangsläufig. Wie ich oben geschrieben habe, würde ich nicht alle
> Informationen als Linie _und_ als Fläche erfassen. Ich würde
> routingrelevante Infos (Spuren) als Linie taggen und andere Dinge (Name
> der Straße) als Fläche.

Gegenvorschlag: Man nutze mal Spuranzahl und Breite nach 
allen Regeln der Kunst und schaut dann mal, wie nah man an
das Original rankommt, ohne gleich doppelt einzutragen. 
Bei grossen Abweichungen vom Normal (Parallelitaet) ist die
konkrete Flaeche eine gute Ergaenzung, aber macht es 
wirklich Sinn, jetzt auf Tausenden von km Autobahn jede
Spur nochmal haendisch zu ergaenzen?
 
> Das bedeutet aber immer, dass da ein Mensch (oder eine KI) hocken muss,
> die die Daten interpretiert. Wenn ich als Mapper die Bilder bereits
> abstrahiert und mit maschinenlesbaren Daten versehen habe, habe ich
> einen Mehrwert. Natürlich kann ich aus den tatsächlichen Fotos oft noch
> zusätzliche Informationen gewinnen. Wo willst du die Grenze setzen, ob
> Daten sinnvoll sind oder nicht.

Anhand einer Fehlerbetrachtung. Nur wenn die handgemalte
Flaeche die Situation genauer darstellt als ihre geometrische
Beschreibung, macht der Zusatzaufwand Sinn.
 
Gruesse Hubert

-- 
GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern
E-Mail, SMS & mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail

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

Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Mon, 29 Mar 2010 22:56:52 +0200
> Von: Wolfgang 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

Hallo,

> Nach örtlicher Beschilderung und Verkehrsregeln muss der Fahrer über die
> extra-Fahrbahn fahren, wenn er rechts abbiegen will. Um richtig geroutet
> zu 
> werden, darf die Fahrbahn also wirklichkeitswidrig nicht wieder vereint 
> werden.

Das habe ich damit gemeint, dass viele Konflikte gar keine sind.
Natuerlich darf die Fahrbahn wieder vereint werden und das 
sollte man auch tun, wenn es in der Realitaet so aussieht. 
Was du ansprichst, ist Fahrerinformation, und das ist eine
Zusatzinfo. Wenn vor dem Komplex ein Schild steht, dass man
sich als Rechtsabbieger auf der Sonderspur einordnen soll,
kann man das auch im Klartext, z.B. an einer Node 
hinterlegen.

Warum soll man die Realtiaet verzerren, Informationen verlieren 
(dass es sich um eine durchgehende Fahrbahn handelt), nur 
damit der Router versuchen darf, aus indirekt gegebener Info
eine Nachricht zum Einordnen zu generieren?

Dazu nochmal das klassische Gegenbeispiel, bei dem die 
Linienbuendel nicht wirklich gut funktionieren: Die Doppellinie,
die nur von einer Spur zur anderen gequert werden kann. Das
laesst sich auf den Graphen nicht abbilden.

In deinem Fall wird man die baulich getrennte Spur als 
eigenen Way eintragen und bei der Busspur wuerden Attribute
helfen, die die Beziehung der Spuren untereinander klaeren,
bzw., dass es fuer eine der Spuren eine Nutzungsbeschraenkung
gibt.

> Es ist mit den bisherigen Werkzeugen nicht möglich, diese Ecke richtig
> für 
> Router und Karten zu mappen. 

Das sehe ich wie oben schon geschrieben nicht so. Fuer die
Kuerzestwegsuche genuegt ein Link bis zur Kreuzung. 
Zusatzinformationen hinterlegt man am besten explizit und
direkt fuer das Informationssystem (das die Route auswertet)
lesbar.
 
> Vielen scheint das Routing im Moment der wichtigste Aspekt für OSM zu
> sein.

Wirklich? Ich sehe da die Renderer mit ihren Rasterkarten
noch weit vorne. Das Problem ist, dass man Fehler in den
Rasterkarten sofort sieht, aber die Routingqualitaet ein
sehr abstrakter Wert ist. Es ist eher eine sehr aktive
Minderheit, die sich das Routing zu Herzen nimmt und der es
wichtig ist, dass es bei den wichtigeren Entscheidungen mit
eine Rolle spielt.

Gruesse Hubert

-- 
GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern
E-Mail, SMS & mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail

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

[Talk-de] Attraktivitaetsbezogenes Routen, war Re: Routen ueber Flaechen

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 30 Mar 2010 02:04:46 +0200
> Von: Martin Simon 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Routen ueber Flaechen

> Ich dachte auch daran, nur einzelne Objekte, die Verkehrsflächen sind,
> einer solchen Behandlung zu unterziehen und die Ergebnisse dann in den
> Graphen einfließen zu lassen - der dadurch ja nicht komplizierer wird,
> wenn auch etwas größer. ;-)
> 
> Wenn ich also 1000x highway=* area=yes habe, mache ich diese kompakte
> Betrachtung nur 1000x, ohne Kenntnis vom gesamten Verkehrsnetz zu
> haben und baue dann mit den gewonnenen Erkenntnissen den Graphen.

OK, ich denke, jetzt hab ichs auch.

Aber ich sehe da durchaus eine Option, das ein wenig groesser
anzugehen. Manche verkehrsberuhigte Innenstadt ist fuer einen
Fussgaenger eher eine Flaeche mit Hausinseln als ein
restriktives Wegenetz.

Ich kann mir vorstellen, den Rasteransatz fuer so einen Bereich
als ganzes anzuwenden. Die Vorschlaege kommen also nicht mehr
von einem streng begrenzten Vektor, sondern ich schaue mir
die Attraktivitaet der Kacheln um mich herum an und lasse mich
in der Flaeche routen. Muss sagen, die Idee hat was :)

Ich nenn das mal 'attraktivitaetsgesteuertes Routen' so als
Kontrast zum restriktionsgesteuerten Routen. Ich kann mir 
vorstellen, dass das bei Aufgaben wie einen Innenstadtbummel 
zu unterstuetzen, deutlich flexibler zu handhaben ist. Oder
wenn sich eine Gruppe mittels Smartphone organisiert.

Danke fuer die interessante Idee und

Gruesse Hubert 


-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Routen ueber Flaechen

[qbert biker]

 Original-Nachricht 
> Datum: Mon, 29 Mar 2010 21:35:25 +0200
> Von: Martin Simon 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Routen ueber Flaechen

 
> Ah ok, also benutzt man nicht wirkliche zusätzliche Wege, sondern
> bewertet nur die Kosten individuell.

Aus Sicht des Graphen sind es schon echte Wege. Allerdings
ist der Routensuche die physische Gestalt des Weges egal.
Bewertet wird nur eine Zahl, die im einfachsten Fall die
Länge ist.
  
> Ja, aber routing will ja auch nur den "optimalen Weg" finden - was man
> draus macht, bleibt ja jedem selbst überlassen...

Bei der Form von Routing, über die hier immer geschrieben
wird, ist die Umgebung sehr restriktiv. Ich darf mit dem 
Fz. die Strasse nicht einfach verlassen, auch wenn ich
es könnte. Diese Regeln bildet der Algorithmus mit Hilfe
der Graphentheorie ab. 

Auf den Fussgänger, der sich relativ frei bewegen kann,
lässt sich das schwer übertragen. Das beste Kriterium ist 
noch der kürzeste Weg, aber der weicht auch nicht dramatisch
ab, wenn ich um einen Platz rumgehe, statt mittendurch. 
Im Stadtszenario gehts ja eher darum, Durchgänge zu finden,
die nicht direkt ersichtlich sind. Oder eben andersrum - 
Durchgänge zu identifizieren, due ich nicht benutzen kann,
z.B. als Rollstuhlfahrer. 
 
> Ja, aber das wäre ja eine Krücke, die sich eines Objektes bedient, das
> es nicht gibt.

Der entsteht doch schnell von selber, wenn eine Abkürzung
attraktiv ist, z.B. in Form von Trampelpfaden. 
 
> Na ja, man müsste die Plätze ja nur einzeln analysieren, um sie durch
> "Geisterwege" für den Graphen zu ersetzen... also "einfach" die
> Geometrie betrachten und prüfen, ob eine Verbindung als gerade Linie
> zulässig ist - wenn nicht, diese durch einfügen zusätzlicher Punkte so
> lange modifizieren, bis sie an keiner Stelle mehr außerhalb der Fläche
> läuft oder innerhalb eines Hindernisses.

Siehe oben, die Frage ist, mit was man auf das Fussgängerrouting
raus will. Die Randmethode ist ja nicht so schlecht und die
betrifft ja nur die Kürzestwegsuche. Beim Auswerten, also dem
Abgehen der gefundenen Route kann man immer noch Informationen 
geben wie 'Überqueren sie den Platz xy'.
 
> Wie das mit der Wegfindung in Computerspielen genau funktioniert, weiß
> ich nicht, ich kann auch keine 5 Zeilen Code schreiben, ohne daß
> jemand die Hände überm Kopf zusammenschlägt ;-) - das sind also nur
> die Gedanken eines absoluten Laien...

Die klassische Methode ist die Definition eines Spielfelds 
wie ein Schachbrett und man definiert die Übergänge von jedem
Feld zum anderen. Ausgehend von der eigenen Position sind
dann für jede Figur die Bewegungsmöglichkeiten definiert.
Das Geschehen in einem Spiel ist ja ziemlich kompakt. In einem
realen Verkehrsnetz ist das anders.

Grüsse Hubert
-- 
GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] Routen ueber Flaechen

[qbert biker]

 Original-Nachricht 
> Datum: Mon, 29 Mar 2010 18:13:12 +0200
> Von: Martin Simon 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Routen ueber Flaechen

> Am 29. März 2010 16:41 schrieb qbert biker :
> 
> > Was natuerlich eine Kruecke ist, so wie jede Behandlung von
> > Flaechen in einem graphenbasierten Router eine Kruecke ist.
> 
> Kann man nicht einfach beim bauen des Graphen die kleinstmögliche
> Länge[1] der Verbindungen zwischen jeweils 2 einmündenden Wegen
> berechnen und diese dann als Grundlage der Berechnung der Kosten für
> einen "Geisterweg" benutzen?

Kann man, kenne ich z.B. auch von Kreuzungen, wenn man die 
Kosten der Abbiegemöglichkeiten bewerten will. Das gibt dann
eine Matrix von virtuellen Verbindungen. Bei einem Platz
kann man die Matrix typischerweise stark vereinfachen, denn
die Wege zu den benachbarten Einfahrten liegen näherungsweise
auf dem Umfang. Bei einem rechteckigen Platz mit Zufahrten 
an den Ecken bleiben dann noch die Diagonalen übrig.

Trotzdem würde ich es bei einem eigenen Programm nicht so
machen (und laut der Aussage oben machen das die anderen 
auch nicht), denn die Verarbeitung wird eines marginalen
Vorteils willen deutlich komplexer. Ausserdem ist der Weg 
quer drüber nicht immer der, den man nimmt. Der Fussgänger 
hat ja die absolute Freiheit, ob er lieber am Rand entlang
läuft, um z.B. in die Schaufenster zu sehen. 

Bei exotischen Formen gibts immer noch die Möglichkeit, bei 
günstigen Verbindungen einen expliziten Fussweg zu ergänzen
und grössere Plätze sind meistens sowieso strukturiert.
 
> [1] Das kann doch kein so großes Problem sein, auch bei komplexen
> Flächen, wenn in Egoshootern schon seit ~15 Jahren Bots zuverlässig
> ihren Weg durch komplexe Labyrinthe finden, oder?
> hmm, Quake(gpl) als Teil eines Routers für OSM... ;-)

Wie komplex sind die Labyrinthe der Spiele im Vergleich 
zu OSM? Und wenn ich das richtig in Erinnerung haben, sind
diese Labyrinthe primär nicht graphenbasiert, sondern 
matrixbasiert.

Gruesse Hubert
-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 26 Mar 2010 15:16:35 +0100
> Von: Chris-Hein Lunkhusen 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Details mappen in Dortmund


> Für mich persönlich sind routingfähige Karten das wichtigste
> Produkt für OSM, deshalb bekomme ich immer Bauchschmerzen
> wenn ich diese Vermischung von Fläche und Vektor sehe.

Besonders, weil es meiner Ansicht nach auch keinen echten
Konflikt gibt. Die Masse aller Strassen hat eine ueber
lange Strecken unveraenderliche Breite. Diese vielleicht 99%
aller Strassen sind mit einer definierten Linie und der
Breite doch exakter beschrieben als man das je mittels der
Editoren reinmalen koennte. 

Bevor man sich jede Menge Redundanz und potentielle 
Fehlerquellen in die Datenbank holt, sollte man vielleicht 
doch ueberdenken, ob mehr Punkte wirklich immer mehr 
oder bessere Information bedeuten. Ein paar eindeutige 
Definitionen koennten viele Konflikte loesen, so wie der
Wiese, die an die Strasse heranreicht. 

Wenn definiert ist, wie sich die Wiese zu der Mittellinie 
der Strasse verhaelt, kann man diese Mittellinie auch
mehrfach nutzen, also z.B.: Wenn eine Flaeche eine 
Strasse als Abgrenzung nutzt, ist die Breite der Strasse
zu beachten und die Flaechengrenze der Wiese entsprechend 
parallel zu verschieben. Programme (z.B. Renderer) koennen 
das dann in ihre Abbildung einbauen. 

Es gibt eigentlich wenige wirkliche Konflikte zwischen
genauer Darstellung und Graphenabstraktion. Die meisten 
sind hausgemacht.

Gruesse Hubert

-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Routen ueber Flaechen

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 26 Mar 2010 19:46:21 +0100
> Von: Bernd Wurst 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Details mappen in Dortmund

> Am Freitag 26 März 2010 14:14:31 schrieb Michael Buege:
> > Geht eigentlich Fussgaengerrouting ueber Fussgaengerzonen als Flaeche,
> wenn
> > die entsprechenden Wege nicht mit eingezeichnet sind?
> 
> Flächen im Sinne von highway=pedestrian / area=yes werden von den mir 
> bekannten Routern in der Regel als Weg an der Außenkante behandelt und
> das 
> Routing leitet einen dann an der Außenkante entlang.

Was natuerlich eine Kruecke ist, so wie jede Behandlung von
Flaechen in einem graphenbasierten Router eine Kruecke ist.

Das Problem geht ja schon damit an, dass das Ziel des Routens
nur in einer restriktiven Umgebung Sinn macht. Also umso
zugeregelter eine Einbahnwueste ist, desto mehr Hilfestellung
brauche ich. Auch der gruenen Wiese gehe ich einfach direkt
von Punkt A nach Punkt B.

Wie man nun mit einem Platz umgeht, ist mehr oder weniger 
Geschmackssache, denn es muss ja nicht immer der kuerzeste
Weg ueber den Platz der sein, den der Nutzer haben will.
Die Umrandung des Platzes als Verbindung in den Graphen
aufzunehmen, bietet sich als Kompromiss an. 

Gruesse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Viele Fehler in Haiti

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 26 Jan 2010 19:46:32 +0100
> Von: Stefan Schwan 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Viele Fehler in Haiti

 
> Der Grundgedanke ist, dass OSM Geodaten sammeln und frei zur Verfügung
> stellen möchte. 

Ja, soweit OK.

> Ein anderer Grundgedanke ist, dass sich die Sache von
> alleine steuern muss.

Das wird von der endlosen Wiederholung auch nicht richtiger.
Das ist kein Grundgedanke, sondern eine Entwicklung, die
vor ein paar Jahren andere Positionen verdraengt hat.

> Du tust so, als könnte man Mapper (in Haiti, oder sonstwo) irgendwie
> in eine bestimmte Richtung, sei es hin zu bestimmten
> Qualitätsstandards oder Schwerpunkten beim Mappen, steuern.Es gibt
> keine Steuerung, keine Mindeststandards.

Natuerlich gibts eine Steuerung, auch wenn die unterschwellig
passiert. Diese Steuerung hat vor ein paar Jahren die Parole
ausgegeben, dass man vorerst alles einfach halten muss, 
weil Entwickler fehlen und solange es weisse Flaechen gibt
Masse wichtiger ist als Klasse. Und spaeter hat diese
Steuerung eben die Parole ausgegeben, dass es jetzt so viele
Daten und Mapper gibt, dass man nichts mehr aendern kann
und hat die Entscheidung von vorgestern zum Grundprinzip 
erklaert.
 
> Die Diskussion "Warum malen wir nicht die freien Flächen zu?" 

Werden unter anderem deswegen gefuehrt, weil man nie ein
Layerkonzept eingefuehrt hat. Jetzt versucht man verzweifelt,
mit Daten auszukommen, die historisches und aktuelles, 
Wege und Flaechen, temporeaeres und statisches, usw. zu einem
gigantischen Knotensalat verwurschteln. Selbst etwas so
einfaches wie 'zeige mir alle Wege an und blende Wiesen
und Waelder aus', ist bei OSM alles andere als trivial. Aber 
Minimalstandards waeren ja der Untergang von OSM...

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Wie sicher ist Openstreetmap vor Ausbeutung?

[qbert biker]

 Original-Nachricht 
> Datum: Mon, 25 Jan 2010 13:53:18 +0100
> Von: Jonas Stein 
> An: talk-de@openstreetmap.org
> Betreff: [Talk-de] Wie sicher ist Openstreetmap vor Ausbeutung?


> Welche Abhaengigkeiten bestehen? Falls Stadtplandienst die OSM Server
> kauft,
> koennte eine neue Gruppe den letzten Datenstand auf eigene Server
> hochladen
> und weiter machen?

Soweit es das Worldfile betrifft, ist die Sache einfach zu 
beantworten. Alle Daten, die da drin sind, koennen fuer
einen Neustart auf einem beliebigen Server an beliebigen Ort
verwendet werden.

Spannender wirds bei den ganzen Changeset-Sachen, die immer
wichtiger werden. Das wuerde mich auch interessieren, 
inwieweit da Daten verlorengehen, wenn alle DB-Server mit
allen Backups verloren gehen wuerden. 
 
> Welches Interesse haben die Betreiber und Sponsoren an dem Projekt?
> Ich fand dazu bislang noch keine Antwort, auch bei der letzten 
> Mapping-Party war das den Teilnehmern nicht ganz klar.

Bei Geofabrik und Cloudmade sollte das Interesse klar sein.
Wenn die ein Geschaeftsmodell haben, muesste die Antwort
da drin stehen. Denke mal, die ziehen Projekte rund um 
OSM-Daten an Land mit denen sie die Loehne der Mitarbeiter 
bezahlen.

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Gratisnavi von Nokia

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 21 Jan 2010 16:10:04 +0100
> Von: DarkAngel 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: [Talk-de] Gratisnavi von Nokia

> Nokia bietet seine Navilösung Ovi-Karten ab sofort (für ausgewählte
> Handys) kostenlos an. In Kürze soll der Dienst dann für alle Symbian60
> Handys verfügbar sein. Im Gegensatz zu früher ist damit auch die
> Navigation kostenlos und die Karten lassen sich im Gegensatz zu Google
> bereits vorher am PC herunterladen und auf dem Handy speichern. Somit
> ist unterwegs keine Datenverbindung erforderlich.
> 
> http://www.focus.de/digital/handy/gratis-navigation-nokia-eroeffnet-den-kartenkrieg_aid_472846.html
> http://www.nokia.de/ovi-dienste-und-apps/ovi-karten/home
> 
> Möglicherweise ist dies aber nicht nur als Schritt gegen Google gedacht,
> sondern auch eine Reaktion auf OSM.

Gibts denn ein Massenprodukt, das auf OSM aufsetzt? Wenn nicht,
waere es ziemlich dumm von Nokia, auf die Einnahmen gerade jetzt
wegen OSM zu verzichten. Im Gegenzug muss sich NOKIA gegen 
Google positionieren, das mit Android und dessen Online-Navi
maechtig aufgetrumpft hat.

NOKIA ist ein weltweit agierendes Unternehmen und da stellt
sich die Frage, wie gut die OSM Abdeckung in Europa und ganz 
besonders in Asien ist, denn da verkauft NOKIA nicht schlecht.
Gibts dazu eine Statistik?

Gruesse Hubert


-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Gartenzwerge im OSM-Land, war Aufruf

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 16 Jan 2010 13:00:54 +0100
> Von: Sven Sommerkamp 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Gartenzwerge im OSM-Land, war Aufruf


> Aber damit das anders laufen könnte bräuchte es andere Strukturen bei
> OSM..

Das waere wieder mal ein Thema zum totdiskutieren.
Es ist wie es ist und Gartenzwerge sind den meisten
eben wichtiger als Autobahnen ;)

> Oder vielleicht ein zweites in dem man einen Gegenvorschlag für
> allgemeine 
> Verfahrensweisen macht.

Noe, kein zweites OSM, aber es gibt freilich schon 
Moeglichkeiten. Ich habe schon angefangen, andere 
Verfahrensweisen und Werkzeuge zu entwicklen, die OSM
nutzen, ohne dessen Begrenzungen abzubekommen. Ein 
Zwischenergebnis davon habe ich am 1. Januar, siehe
'spurgenaue Abbildung' veroeffentlicht. 

Das ist allerdings nur ein Zwischenschritt. Das 
mittelfristige Ziel ist Konstruktionen als solche 
abzubilden mit ihren Parallelen, Symmetrien und 
anderen Eigenschaften. Dieses (Arbeits-)format kann
dann auch nach OSM exportiert werden, wobei 
die internen Konstruktionsdaten natuerlich verloren
gehen.

Die neuen Werkzeuge sind also keine Konkurrenz zur
OSM-Welt, sondern eine Parallelwelt mit Verbindungen
zu OSM. Wenn ich z.B. einen Router mit Spurassistenz
will, man sich aber bei OSM nicht auf entsprechend
genaue Abbildungen eingen kann, erstelle ich die
Autobahnen teilweise neu und binde ansonsten das 
bestehende OSM-Datenmaterial ein. 

Ein weiteres Problem, das ich mit dieser Vorgehensweise
erschlage ist das leidige Lizenzproblem. Alle von
mir mit den neuen Tools erstellten Daten sind 
lizenztechnisch von OSM unabhaengig. Erst mit dem
Einbinden der OSM Daten zu einem Gesamtdatensatz
greift die jeweilige OSM-Lizenz. Die Ursprungsdaten
kann ich auch unter einer BSD-Lizenz vertreiben.

Gruesse Hubert

Ach ja, wenn es bei den Werkzeugen entsprechende
Fortschritte gibt, werde ich die hier melden. Derzeit
sind die noch nicht so weit, dass eine Veroeffentlichung
viel Sinn macht.
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

[Talk-de] Gartenzwerge im OSM-Land, war Aufruf

[qbert biker]

Hallo zusammen,

letztens hat mal jemand die OSM-Gemeinde mit einem
Kleingartenverein verglichen, in dem jeder die schoenste
Parzelle haben will. 

Kleiner Nebeneffekt dieses Parzellendenkens ist dann
auch oft, dass sich der Blick aufs Ganze eintruebt und 
der Gartenzwerg auf der eigenen Parzelle zum Zentrum des
Universums wird.

Gruesse Hubert


-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Reisezeitmodelle, war: maxspeed=DE:Urban

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 8 Jan 2010 16:04:23 +0100
> Von: Martin Koppenhoefer 
> An: qbert biker 
> CC: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] maxspeed=DE:Urban

> Am 8. Januar 2010 15:13 schrieb qbert biker :
> 
> >  Ein Limit kann ja auch die maximale moegliche Geschwindigkeit
> > erhoehen,
 
> nein, ein Fahrzeug kann nicht schneller fahren, nur weil man schneller
> fahren darf. Dieser Zusammenhang ist so nicht gegeben.

Denke mal, jetzt hab ich begriffen, auf was du raus willst:
Du beziehst dich auf dynamische, also verkehrsabhängige
Modellierung und das ist eine ganz andere Baustelle.

> in gewissem Rahmen bekommst Du halt trotzdem funktionierende Ergebnisse...

Ich halte es für eine korrekte, aber eben statische Modellierung.
Es wird modelliert, was Strasse und Fahrzeug hergeben.

> Ob das Limit "stimmt" und welche Geschwindigkeit im Schnitt erzielbar ist,
> sind 2 Paar Schuhe, Deine Auswertelogik (maxspeed-20%) ist ein Hack, der
> mit
> "vernünftigen" und "üblichen" Werten funktioniert (wenn alle Autos
> ungefähr
> ähnlich schnell fahren können), aber eben einen Zusammenhang herstellt,
> wo
> nur bedingt einer ist.

Ich machs so wie ichs gelernt habe: Die typische Geschwindigkeit
ergibt sich aus der Zielgeschwindigkeit (das was der Fahrer
fahren will, also meistens maxspeed) abzueglich der gemittelten
Verluste beim Anfahren, Wartezeiten, etc. Bei einer Vorfahrtsstrasse
sind diese Verluste geringer also zieht man anteilig weniger ab.
Bei einer kurvigen Nebenstrasse zieht man mehr ab, aber immer 
steht das im Verhältnis zur Zielgeschwindigkeit.

Erst jetzt kommt der Verkehr, also der dynamische Part, ins Spiel 
und der kann die erreichbare Geschwindigkeit nochmal verringern,
muss aber nicht. Und hier sehe ich ein Problem in deinem Ansatz,
denn du mischt dynamische Aspekte in das statische Modell.

Es ist aber sinnvoll, dynamische und statische Modellierung zu
trennen, denn so kann man beliebige externe Quellen in die 
dynamische Modellierung einfliessen lassen. Ob man wegen LKW 
nicht über 80 drüberkommt, hängt vom Wochentag ab und der tägliche
Berufsverkehrsstau eine Rolle spielt kann man über 
Tageszeitprofile ermitteln. 

Gruesse Hubert

-- 
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] maxspeed=DE:Urban

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 8 Jan 2010 14:27:00 +0100
> Von: Martin Koppenhoefer 
> An: qbert biker 
> CC: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] maxspeed=DE:Urban

> Am 8. Januar 2010 14:15 schrieb qbert biker :

Hallo,

> eben. Deshalb sollte man als Router einen Default annehmen (z.B. 80 auf
> Landstraßen, 110 auf der Autobahn), bzw. den User eingeben lassen, und an
> den Stellen, wo kein Maxspeed angegeben ist, diesen verwenden, andernfalls
> diesen _begrenzen_ natürlich aber nicht nach oben ausdehnen. Von daher
> spielen Maxspeeds oberhalb meiner erreichbaren Geschwindigkeit keine
> Rolle.

Im Prinzip sind wir uns einig, ich gebe nur zu bedenken, dass
man keine Auswertelogik voraussetzen kann. Dein Vorschlag ist
sinnvoll aber nicht der einzig moegliche.

Ein Limit kann ja auch die maximale moegliche Geschwindigkeit
erhoehen, also z.B. von 100 auf 120kmh auf besser ausgebauten
Landstrassen oder von 50kmh auf 60 oder 70kmh in der Ortschaft.

Ist ein explizites Limit gegeben, setze ich normalerweise auch
voraus, dass es auch stimmt, verwende es direkt und errechne
die typische Geschwindigkeit mittels prozentualen Abzug vom
Limit anhand div. Parameter (Spuranzahl, Ampeln, etc.).

Den Job des Abschneidens nach Maximum uebernimmt eine
nachgeschaltete Plausibilitaetspruefung und die laesst bei
mir viel hoehere Werte zu als z.B. die 80kmh auf Landstrassen.

Na ja, jeder hat eben so seine eigene Methodik ;)

Gruesse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] maxspeed=DE:Urban

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 8 Jan 2010 13:28:07 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] maxspeed=DE:Urban


> Du solltest nicht die Höchstgeschwindigkeit als
> Durchschnittsgeschwindigkeit
> annehmen. Wenn ich jetzt maxspeed=12346743245 km/h tagge, bin ich dann mit
> Deinem Router in Sekundenbruchteilen diese Straße komplett abgefahren?
> ;-)

Erwischt :-)

So und jetzt die technische Antwort: Der Router machts genau
so, solange ich ihm den Wert einfach durchreiche. 

Dass man vorfiltern sollte und nicht blind den Werten 
vertrauen, darum gings ja. Wenn ich jetzt von 12346743245kmh
20% abziehe um von max auf real zu kommen, ists immer noch
viel.

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] maxspeed=DE:Urban

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 07 Jan 2010 23:13:59 +0100
> Von: Tobias Knerr 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] maxspeed=DE:Urban

> qbert biker schrieb:

> Ich glaube, du hast das Problem nicht ganz getroffen. Die *Realität* ist
> dreidimensional, und wenn in der Realität die Straße auf einer Brücke
> zu
> einer anderen "Zone" gehört als die Straße unten drunter, dann kann man
> das nur mit zweidimensionalen Polygonen nicht abbilden.

Das Modell ist ausschlaggebend, der Rest ist Definition, wie
man bei Polygonen drin und draussen definiert, z.B. waybasiert
oder knotenbasiert. Damit kann man entsprechende Schlaufen 
ziehen, was zwar nicht elegant ist, aber technisch realisierbar.

Etwas einfacher ists natuerlich, wenn man eine Relation baut,
die das Polygon mit dem Exotenelement verbindet. Wenn diese 
Exotenkonstruktion ueberhaupt mal vorkommt, die Masse der 
Polygone ist problemlos definierbar.
  
> Was voraussetzt, dass zumindest beim Vorverarbeitungsschritt eben doch
> alle Daten zur Verfügung standen. Lösbar, aber eine kleine zusätzliche
> Auflage.

Eben, ich wende mich an dieser Stelle nur gegen ein plumpes
geht nicht. Ob man es macht und obs Vorteile bringt, ist
etwas anderes, aber die genannten Punkte sind alle technisch
loesbar.

> Ok, wir messen anscheinend den Aufwand unterschiedlich. 

Anwendungsentwickler gegenueber Tagger?

> Meine
> Betrachtung bezog sich hier auf eine "Fehler in den Daten werden in den
> Daten gefixt, nicht von mir"-Software. Wenn du dich natürlich noch für
> das Erraten von Fehlern zuständig fühlst, werden Tags in der Tat
> aufwendiger. Das halte ich aber nicht für die Aufgabe der meisten
> Datennutzer.

Als Anwendungsentwickler gehe ich prinzipiell von 
fehlerhaften Daten aus und versuche stabile Verfahren zu
bauen, die den Fehlereffekt von sich aus begrenzen. 

Kleines Beispiel: Ein potentielles Polygon umfasst 100 
ways. Die wiederum sind auf 10 verschiedene Arten
Limit-getaggt und bei einem ist der Schreibfehler passiert
und es steht statt 30km/h 300km/h drin. 2km mit 300kmh
statt 30 koennen das Routingergebnis ganz schoen verziehen.
Oder mir gehen 10 Strassen mit 30 durch die Lappen, weil
wieder mal jemand eine neue Schreibweise eingefuehrt hat
und die gehen auf den Default 100kmh oder 50kmh zurueck.
Die 50kmh kommen schon aus der Fehlerbegrenzung, wenn man
den Default fuer residential so setzt. Wird innerorts
unclassified verwendet (nicht verboten) und ich habe kein
Polygon, wird 100kmh draus. Da werte ich lieber Ortsgrenzen
aus und begrenze den moeglichen Fehler.

Wenn ich also einen Router baue und den einem Nicht-OSMler
zumuten will (also einer, der das Ding einfach benutzen 
will ohne Fehler zu berichtigen) werde ich versuchen,
diese Dinge zu stabilisieren, weil ich OSM und die 
Taggingkreativitaet der OSMler kenne.

Ein Polygon ist sehr stabil, weil es algorithmisch 
ausgewertet werden kann und visuell sehr einfach zu testen
ist. Einen Algo zu bauen, der alle in OSM verwendeten
Schreibweisen, Trenner usw. zu 100% auseinanderdroeselt,
ist da schon ein anderes Kaliber.

Gruesse Hubert 
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] maxspeed=DE:Urban

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 06 Jan 2010 18:34:24 +0100
> Von: Tobias Knerr 
> An: Sascha Silbe , Openstreetmap 
> allgemeines in Deutsch 
> Betreff: Re: [Talk-de] maxspeed=DE:Urban

Hallo,

als ob die Arbeit mit Polygonen ein Hexenwerk waere...

> > Why don't you use polygons for this?
> > * Polygons are two-dimensional. There are situations where bridges
> >   or similar three-dimensional structures cause "zones" to vertically
> >   overlap, which cannot be represented by polygons.

Das Datenmodell von OSM ist zweidimensional, daran aendern 
auch die Ebenen nix. Die OSM-Datenverarbeitung kennt keine
echte Z-Ebene, sondern nur Kreuzungen, die keinen Knoten
bilden mit der Erklaerung dazu, dass sie sich eben in
einer anderen Ebene befaenden, hauptsaechlich als Hinweis 
an die Visualisierung.

Ein zweidimensionaler Algorithmus wird also alle Elemente
finden.

> > * Downloading only a part of the map (e.g. a part of a city) can
> >   result in polygons missing from the download, despite ways from
> >   inside the polygon being part of the downloaded data.

Ein einfacher Loesungsansatz dafuer:
Jedes Polygon bekommt ein umschreibendes Rechteck, das sich
leicht zuordnen laesst, auch wenn kein einziges Element
des Polygons heruntergeladen wird, z.b. weil das Polygon
viel groesser ist als der geladene Bereich. 

Der Rest ist, die Beziehung der Polygone und des 
geladenen Bereichs zu klaeren (alle drin, alle draussen,
Schnittmenge)

> > * A mapper will often know that a certain way is part of a zone
> >   without knowing where the zone boundaries are.

Da kann ja 'is_in' als Uebergangsloesung verwendet werden,
oder es wird eine Teilgrenze eingetragen und ein anderer
macht das polygon dann zu.

> > * Tags on ways are easier to evaluate for applications. Polygons
> >   require more advanced programming techniques to reduce performance
> >   problems from inclusion tests.

Da bin ich durchaus anderer Meinung. Was hier immer wieder
an Beschreibungsvarianten auftaucht ist durchaus vielfaeltig
und ein Algo muss die alle fehlerfrei erkennen koennen
und auch ob ein Geasschen vergessen wurde.
 
Ein Polygon hingegen ist geometrisch stabil und wenn die
Algorithmen dazu sauber durchgetestet ist, laeuft das
erstmal. Fehler in einem Polygon zuzuordnen (nicht geschlossen,
etc.) ist auch sicherer und stabiler als sicherzustellen,
dass alle Einzelelemente des Bereichs auch richtig
ausgewertet werden. 

Letzteres ginge uebrigends am einfachsten, indem man ein
Poygon erzeugt und alle Elemente innerhalb des Polygons
ueberprueft (Katze, Schwanz, beissen...).

> > * it's very incorrect, because only the roads themselves are part of
> >   any kind of traffic-zone and not the whole area; e.g. roads in parcs
> >   or on private property or even tracks.

Stimmt, wie will man sicherstellen, dass ein Baum in 
einem Park sich beim davonlaufen ans Tempolimit haelt :)
Etwas Logik in die Auswertung und das Thema ist
gegessen: private schlaegt public, explizites Schild
schlaegt Zone, usw. 

Es gibt auch noch die Moeglichkeit, eine Zone ueber den
Graphen selber zu beschreiben, indem man alle begrenzenden
Knoten markiert und mit den Mitteln des Graphen in das
Gebiet hineinscannt. Diese Methode erfasst nur Elemente 
des Graphen selber (also i.A. 'highway'), erfordert aber
ein gehoeriges Mass an Disziplin und ist etwas sensibel 
gegen das 'Auslaufen', z.B. wenn eine Node nicht erfasst
ist. Auch das kann man abfangen aber fuer die technisch
robusteste Loesung halte ich das echte Flaechenpolygon.

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Spurgenaue Abbildung, Update

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 02 Jan 2010 19:33:59 +0100
> Von: "Nils Heuermann" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Spurgenaue Abbildung, Update

> Hallo Hubert,
> 
> > hab heute noch ein wenig mit dem Programm rumgespielt
> 
> jetzt hab ichs mir auch angeguckt. Sieht hübsch aus :)
> 
> Vom Tagging her ist es sehr simpel und nutzt auch keinen neuen  
> "Zaubereien". Für tiefgehendere Informationen zu einzelnen Spuren
> bräuchte  
> man dann natürlich eine ganze Latte an Tags am Way...

Oder eben dann Relations. Grundsätzlich finde ich es sehr
praktisch, die ways an Verzweigungen zu unterbrechen. Das
hab ich gemacht und weils dann fast keinen Grund mehr gab,
innerhalb von ways Info einzufügen, hab ichs für den ersten
Schritt beim einfachen Tagging gelassen.

Das Programm ist als Versuch zu sehen, wie man aus sehr 
wenig Info einiges rausholt. Und mir ist klar, dass 
das z.B. bei Sonderlinien an die Grenzen stösst.

> Zu beachten wäre noch, dass wenn eine Spur im normalen Straßenverlauf  
> wegfällt, dies i. d. R. die linke ist. Im Beispiel z. B. die von Nordwest
>  
> kommenden 2 Spuren, die sich auf 1 verringern.

Das beschriebene Konzept klappt nur bei Autobahnen oder 
autobahnähnlich ausgebauten Strassen. Und da sind die Masse 
an Spuren die wegfallen, Einfädelspuren von Kreuzungen oder
Einfahrten. Die links wegfallenden Spuren sind die Ausnahme
wenn man Einfädelspuren wie alle andern Spuren betrachtet.
Aber du hast natürlich recht damit, dass das vorkommt und
man eine Ausnahmebehandlung vorsehen sollte.

> Auch dies ist nichts Neues für dich:
> Auf Straßen mit Gegenverkehr, also die nicht oneway sind, gibt es z. B.  
> die wechselnden 2+1-Straßen oder unterschiedlichste Abbiegespuren an  
> Kreuzungen. Da kanns schnell unübersichtlich werden und nur mit "lanes=x"
>  
> kommt man nicht weiter. Hast du dir dazu weitere Gedanken gemacht?

Wohl am besten mit einem speziellen Konstrukt, z.B. mit
passenden Relations. 

Ich wollte ja hauptsächlich demonstrieren, dass es sich 
lohnt, die Basisdaten wie lanes einzutragen, weil passende 
SW da einiges rauskitzeln kann. Wer mehr will, kann jederzeit
mehr eintragen, aber es wäre schade, wenn Leute Spuranzahl
und ähnliches gar nicht eintragen, weil sie meinen, dass 
keiner damit was anfangen kann.

Grüsse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Spurgenaue Abbildung, Update

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 2 Jan 2010 18:19:08 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Spurgenaue Abbildung, Update

Hallo,

> Sieht schon viel anschaulicher aus, fast perfekt. Richtig schön wäre es
> jetzt noch, wenn man auch den Beginn einer Spur drin hätte, also dort, wo
> sie noch nicht voll benutzbar ist, der Asphalt sich aber schon verbreitert
> (bisher fangen die Spuren sofort bei "voll" an, ist aber vielleicht auch
> nur
> ein Renderingthema?).

Ist es - ich habe schlicht noch keine Regel dafür implementiert.
Bisher habe ich mich nur mit der automatischen Anpassung von
Y-Verbindungen beschäftigt, also '2 auf 1' oder '1 auf 2'.

Es bräuchte also noch eine Regel für '1 auf 1' mit 
Spuranzahländerung. Mal schaun, wann ich dazu komme.

> Etwas merkwürdig der südliche Teil der durchgehenden horizontalen
> Autobahn:
> ist da gerade Baustelle, oder warum hat die z.T. nur eine Spur?

Das was von rechts unten nach links oben geht ist keine 
Autobahn, sondern eine autobahnähnlich ausgebaute Bundesstrasse,
also in diesem Bereich 'trunk'. Die Spuränderungen sind 
zumindest nach den Satellitenbildern so wie beschrieben, ohne
Baustelle. 

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Spurgenaue Abbildung, Update

[qbert biker]

Hallo,

hab heute noch ein wenig mit dem Programm rumgespielt und 
eine alternative Visualisierung gemacht:

http://img214.imageshack.us/img214/2618/bosmcrossing2.png

Die Ausgangsdaten sind gleich geblieben, also:

http://www.opencarbox.de/osm/test6.osm.bz2

Vielen Dank an Guenther Meyer fürs Bereitstellen.

Für die Änderungen der Spuranzahl auf der Strecke muss ich
mir noch was einfallen lassen, eine Abschrägung sollte
es fürs erste tun. 

Gruesse Hubert


 Original-Nachricht 
> Datum: Fri, 01 Jan 2010 11:05:17 +0100
> Von: "qbert biker" 
> An: talk-de@openstreetmap.org
> Betreff: [Talk-de] Spurgenaue Abbildung

> Erstmal ein gutes Neues zusammen!
> 
> Ich war letztes Jahr mal in ein paar Diskussionen dabei, in
> denen es um spurgenaue Abbildung von Autobahnkreuzen, etc.
> ging. Ueber die Feiertage hatte ich Zeit, ein wenig
> damit zu spielen und das ist dabei rausgekommen:
> 
> http://img191.imageshack.us/img191/7219/bosmcrossing1.png
> 
> Das Kreuz ist bei Herford (ca. 52°05'20'', 8°41'46'') und
> wurde mal im November als Beispiel angegeben:
> 
> http://www.openstreetmap.org/?lat=52.08868&lon=8.69753&zoom=17&layers=B000FTF
> 
> http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058720.html
> 
> Ich bin dabei komplett ohne Relations ausgekommen und habe
> als Eingangsdaten nur 'lanes', '*.link', 'oneway' und 
> 'highway' verwendet (ohne Gewähr auf Vollständigkeit). Bei
> einer angenommenen Spurbreite von 5m sieht das ganze
> relativ realistisch aus.
> 
> Allerdings habe ich das Kreuz lokal bei mir ziemlich umbauen
> muessen, damit das raus kommt, was zu sehen ist. Die 
> Änderungen habe ich sicherheitshalber nicht hochgeladen, denn 
> mit einem lokalen Datensatz kann man besser basteln ohne die
> anderen zu stören. 
> 
> Gruesse Hubert
> -- 
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Spurgenaue Abbildung

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 1 Jan 2010 13:53:06 +0100
> Von: Guenther Meyer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Spurgenaue Abbildung


> immer diese vorschnellen und unbewiesenen behauptungen...
> man sollte sich vielleicht erst mal die realisierung, also die daten
> selbst, 
> anschauen, bevor man darueber urteilt.

Höhere Komplexität verstärkt die Gefahr, dass sich Fehler
einschleichen. Wenn ich 3 Spuren als Einzelelemente des
Graphen einfüge und danach dem System über ein weiteres 
Konstrukt mitteilen muss, dass man beliebig zwischen 
ihnen wechseln kann, ist das fehleranfälliger als
'lanes=3'

Wenn ich Einzelspuren als ways tagge und die dem Router
direkt vorsetze, wird er erstmal langsamer, weil die
Geschwindigkeit direkt von der Anzahl der (Verbindungs-)
Knoten abhängig ist.

Grüsse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Spurgenaue Abbildung

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 01 Jan 2010 13:34:50 +0100
> Von: Chris-Hein Lunkhusen 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Spurgenaue Abbildung

> > Erstmal ein gutes Neues zusammen!
> 
> Dito!
> 
> > Ich bin dabei komplett ohne Relations ausgekommen 
> 
> Die Relationen sind dafür gedacht, dass ein Router die
> Spuren wieder zu einer Fahrbahn zusammenfassen kann.
> Auf Grund der GPS Genauigkeit wird ein Router durch
> zu eng zusammenliegende Spuren ja eher verwirrt.

Wenn man wirklich vor hat, einem Router so ein 
Linienbündel vorzusetzen. Ich hatte ja schon mal einen
Router für OSM geschrieben und schon damals habe ich 
die meiste Zeit in die Vorbehandlung investiert, also
der Vereinfachung des Graphen.

Auch hier wäre das erste was ich machen würde, einen
Algo zu bauen, der die Linienbündel wieder in einen
einfachen Graphen zurückbaut. Einzelspurabbildung ist
ineffizient beim Routing, weil es plötzlich pro Spur
einen eigenen Weg im Graphen gibt. 
 
> Des weiteren ist die Fehleranfälligkeit eines solchen
> Konstrukts natürlich auch größer, so dass das
> Spurenmapping für das Routing vermutlich eher eine
> Verschlechterung bringen wird.

Als Anwendungsentwickler wollte ich mit dem Bild zeigen,
welche Daten ich brauche, um die Geometrie abzubilden
und das mit einfach zu handhabenden Attributen. 
Und dazu sind fast alle Informationen drin, die
ich für Navigation und Spurwechselassistenz brauche.
Genaue geometrische Beschreibung und Navigation müssen
ja kein Gegensatz sein.

Was fehlt, aber relativ einfach nachzutragen ist, sind
Sonderlinien, wie die breiten Strichlinien, die die
Einfädelspuren abgrenzen. Das wäre noch ein Attribut 
dazu.

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Spurgenaue Abbildung

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 01 Jan 2010 12:07:15 +0100
> Von: Tobias Knerr 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Spurgenaue Abbildung

> qbert biker schrieb:
> > Ich bin dabei komplett ohne Relations ausgekommen und habe
> > als Eingangsdaten nur 'lanes', '*.link', 'oneway' und 
> > 'highway' verwendet (ohne Gewähr auf Vollständigkeit). Bei
> > einer angenommenen Spurbreite von 5m sieht das ganze
> > relativ realistisch aus.
> 
> So eine Minimallösung geht aber doch nur, wenn man zahlreiche
> Einschränkungen vornimmt, die mehr oder weniger nur für Autobahnkreuze
> zutreffen? Ich kann mir nicht vorstellen, dass sich damit eine
> innerstädtische Situation abbilden ließe - selbst dann, wenn man sich
> auf Autofahrbahnen beschränken würde.

Fuer jedes Gebiet die passende Abbildung. Das was ich da 
probiert habe, ist erstmal für Autobahnen/Schnellstrassen gedacht, 
weil die sehr genauen Regeln folgen. Andererseits sind für
Navis mit Spurwechselassistent die Autobahnen/Schnellstrassen 
von besonderer Bedeutung. 

Wenn ich dazukomme, werde ich noch etwas ähnliches für
Innenstadtbereiche probieren. Ich denke schon, dass da mit
der passenden Abstraktion einiges drin ist. 
 
> > Allerdings habe ich das Kreuz lokal bei mir ziemlich umbauen
> > muessen, damit das raus kommt, was zu sehen ist. Die 
> > Änderungen habe ich sicherheitshalber nicht hochgeladen, denn 
> > mit einem lokalen Datensatz kann man besser basteln ohne die
> > anderen zu stören. 
> 
> Kannst du das als .osm-Datei bereitstellen?

Gerne, aber eine kurze Frage vorab, wie ich das am besten
anstelle. Die bz2-komprimierte Datei kommt noch auf ca. 52kb
und das dürfte etwas zuviel für die Liste hier sein, oder?

Aber viel hab ich nicht gemacht. Erstmal habe ich Einfädelspuren
korrigiert, die als eigener Link drin waren. Dann habe ich
die ways anhand der tracks von der Mitte der Fahrbahn auf
den linken Rand verschoben, weil sonst die Geometrie kracht.
Und ich habe noch die ways neu gesplittet und wieder 
zusammengefügt, so dass sie an jeder Verzweigung enden und
beginnen.

Letzteres ist nicht unbedingt nötig, erleichtert aber die
Programmierung ungemein. Ich hätte sonst virtuell im
Programm splitten müssen und da habe ich über die 
Nachbearbeitung des Netzes ein wenig abgekürzt ;)

Ach ja, ein Hinweis noch. Für das Rauslesen der Spuranzahl
habe ich Google Earth benutzt, der Datensatz ist also nicht
mehr lizenztechnisch sauber. 

Grüsse Hubert

-- 
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

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

[Talk-de] Spurgenaue Abbildung

[qbert biker]

Erstmal ein gutes Neues zusammen!

Ich war letztes Jahr mal in ein paar Diskussionen dabei, in
denen es um spurgenaue Abbildung von Autobahnkreuzen, etc.
ging. Ueber die Feiertage hatte ich Zeit, ein wenig
damit zu spielen und das ist dabei rausgekommen:

http://img191.imageshack.us/img191/7219/bosmcrossing1.png

Das Kreuz ist bei Herford (ca. 52°05'20'', 8°41'46'') und
wurde mal im November als Beispiel angegeben:

http://www.openstreetmap.org/?lat=52.08868&lon=8.69753&zoom=17&layers=B000FTF

http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058720.html

Ich bin dabei komplett ohne Relations ausgekommen und habe
als Eingangsdaten nur 'lanes', '*.link', 'oneway' und 
'highway' verwendet (ohne Gewähr auf Vollständigkeit). Bei
einer angenommenen Spurbreite von 5m sieht das ganze
relativ realistisch aus.

Allerdings habe ich das Kreuz lokal bei mir ziemlich umbauen
muessen, damit das raus kommt, was zu sehen ist. Die 
Änderungen habe ich sicherheitshalber nicht hochgeladen, denn 
mit einem lokalen Datensatz kann man besser basteln ohne die
anderen zu stören. 

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] kleines Meinungsbild: Tagging des Nü rburgringes/Nordschleife

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 23 Dec 2009 15:41:48 +0100
> Von: "Mirko Küster" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de]kleines Meinungsbild: Tagging des 
> Nürburgringes/Nordschleife

Hallo,
 
> Dadurch wird aber noch immer keine Straße im Sinne des öffentlichen 
> Verkehrs. Es ist und bleibt eine Hobbyrennstrecke oder Touristenattraktion
> ohne Verbindungsfunktion, Bedeutung oder Aufgabe im Straßennetz.

Wie schon geschrieben, habe ich kein Problem mit racetrack,
aber ich habe ein Problem mit der Begründung. Warum ist es
absolut selbstverständlich, dass eine 'normale Strasse' ein
Teil des öffentlichen Strassennetzes mit Verbindungsfunktion
zu sein hat?

An anderer Stelle wird diese Voraussetzung schlicht ignoriert,
z.B. beim Flughafen. Das ist typischerweise Privatgelände,
das über Privatstrassen den Kunden (=Fluggäste) zugänglich
gemacht wird, die über die üblichen Klassen abgehandelt werden. 

Ich finde, dass so implizit definierte bombenfeste 'Tatsachen'
eine schlechte Voraussetzung für saubere Definitionen und
Beschreibungen sind. Wenn so eine Definition existiert, dann
sollte sie explizit ausgearbeitet sein, denn für einen anderen
ist ein Teerband, auf dem Autos fahren genauso felsenfest 
eine normale Strasse und es hagelt Missverständnisse.

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] kleines Meinungsbild: Tagging des Nü rburgringes/Nordschleife

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 23 Dec 2009 14:07:37 +0100
> Von: "Mirko Küster" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de]kleines Meinungsbild: Tagging des 
> Nürburgringes/Nordschleife

> > daraus leite ich ab, dass die nordschleife *keine normale* straße im
> > rahmen der stvo ist. die nürburgring-gmbh übernimmt nur freiwillig die
> > regeln der stvo, das ist aber alles.

Was ist dann eine 'normale Strasse'? 
 
> Eben nichts anderes wie jede andere exclusive Rennstrecke auch. Auch 
> anderswo kann man privat rauf. Der einzige Unterschied der zu stören
> scheint 
> ist wahrscheinlich folgender. 
> "Normale" Rennstrecken befinden sich auf in 
> sich geschlossenem Privatgelände, was hier aufgrund der Ausdehnung ja
> nicht 
> geht und das ganze wie eine normale Aussieht. 

Siehe Tourist Trophy, es gibt kein normales Aussehen einer
Rennstrecke. Die Nordschleife ist eigentlich einfach nur
eine weitgehend ausgemusterte Rennstrecke, da der moderne
F1-Rennbetrieb nach einem Neubau geschriehen hat. 

> Das die StVO gilt hat nichts
> zu bedeuten. Kann jeder freiwillig für sein Privatgelände festlegen.

Exakt, so wie jeder auf Privatgelaende das Tempolimit
festlegen oder aufheben kann wie bei der Nordschleife unter
Nutzung des KFZ-Strassenschildes geschehen. 
 
> Also Rennstrecke und nichts anderes. Diese Straße hat nichts mit den 
> öffentlichen Straßen zu tun und hat keine Funktion im Straßennetz. 

Ich habe ja nix gegen racetrack aber diese Definition
einer Strasse ist etwas aus der Luft gegriffen. Auch die
Nordschleife ist eine Strasse, auch wenn auf der nur zum
Vergnuegen gefahren wird und nicht um von A nach B zu
kommen. 

> Das
> ist 
> eine reine private Touristenrennstrecke. Das mit Mitteln zu beschreiben
> die 
> wir für das öffentliche Netz nutzen wäre hier total falsch. Außer ich
> will 
> die Router damit verarschen und nicht ortskundige Kartenutzer ein bissel 
> rollen.

Schiebt doch nicht immer alles auf die Router ab, denn die
koennen mit sowas recht gut umgehen. Die Schleife braucht 
viele km um zwei Punkte zu verbinden, die recht nah 
beieinander sind. Ein Router, der nicht rausfindet, dass das
keine optimale Loesung ist, gehoert weggeschmissen (mal ganz
abgesehen von der Auswertung von access-tags, usw.)

Auch wenn ich auch der Meinung bin, dass highway=racetrack
hier keine schlechte Loesung ist, waere ich mit dem 'total
falsch' schon vorsichtiger. Eigentlich ists eine 
Betriebsstrasse und auch wenns komisch klingt, service waere
wohl die Alternative zu racetrack.

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] KFZ-strasse und primary, war Nürburg ring

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 23 Dec 2009 14:11:13 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de]KFZ-strasse und primary, war Nürburgring

Hallo,

> habe ich was verpasst? Genau diese Abgrenzung hat man doch vor ein paar
> Monaten vorgenommen und bestätigt, dass der Verbindungstyp  in der
> Highway-Klasse steckt. 

Ich habe viel Diskussion mitbekommen und dass es nach wie vor
keine Entscheidung gibt oder etwas was einer nahe kommt. Aber
wenns weitgehenden Konsens gibt, dass highway den Verbindungstyp
beschreibt, umso besser :)

> (S. Wiki, rel. große Abstimmung, rel. eindeutiges
> Ergebnis). Im hier vorliegenden Fall ist aber highway=raceway auch eine
> Überlegung wert, meint Ihr nicht? Quasi alle sind sich doch mittlerweile
> einig (die PR-Abteilung des Betreibers eingeschlossen), dass es sich um
> eine
> Rennstrecke handelt, die ansonsten für Touristenfahrten geöffnet wird.

Ist sicher nicht verkehrt. Ich halte es zwar fuer grundsaetzlich
moeglich, jede Rennstrecke in das normale Klassenkonzept 
einzubinden (andere Datenanbieter machen das afaik auch), aber
raceway(racetrack?) macht nix kaputt und ist selbsterklaerend. 

Mir gings mit meinem Beitrag nur um die Verwirrung um trunk
und motorroad und da liegt im Gegensatz zur Nordschleife noch
einiges im argen.

Gruesse Hubert
-- 
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] KFZ-strasse und primary, war Nürburg ring

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 23 Dec 2009 06:34:46 +0100
> Von: Mathias Kemper 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] KFZ-strasse und primary, war Nürburgring

> Moin moin Hubert,
 
> Ok, also würdest du folgende Taggs für korrekt halten ?
> 
> highway = primary
> motorroad = yes
> name = Nürburgring Nordschleife
> oneway = yes
> sport = motor
> toll = yes

Die Darstellung halte ich was die KFZ-Strasse betrifft fuer
richtig und ansonsten hat das einen hohen Informationsgehalt.
Ich mag diese Form der aufgeschluesselten Darstellung, denn
jeder kann sich sie Info rausholen, die er braucht, und das
ohne viel Redundanz. 
 
> Könnte ich sehr gut mit leben. Durch "primary" bekommt die NS nicht den 
> so hohen Stellenwert wie durch "trunk" und auch die Renderer dürften die 
> Strecke nicht so fett zeichnen.

Schwierige Frage, denn es gibt ja nach wie vor keine 
Definition, was die Strassenklasse ('highway=') eigentlich
aussagen soll. Die Nordschleife hat so gut wie keine
Verbindungsfunktion, ist aber sehr gut ausgebaut. Dass es
eine KFZ-strasse ist, ist ja schon ueber motorroad ausgesagt
also kann man prinzipiell alles von trunk bis unclassified
vergeben, ohne die Regeln zu verletzen.

Ich denke, man sollte mal ueber Sondernutzungen nachdenken,
denn es gibt ja viele solcher Strassen, die hauptsaechlich
von Firmen betrieben werden. Ich denke da an abgeschlossnene
Teststrecken, Rennstrecken oder auch Flughaefen. Deshalb
auch das beispiel vorher mit dem Muenchner Flughafen, denn
da sind die KFZ-Strassenschilder auf dem Gelaende des
Flughafens ja auch aus rein organisatorischen Gruenden
aufgestellt (z.B. Fussgaenger aussperren) und nicht weil das
eine besonders wichtige Strasse ist.

> Allerdings sollte es den verkehrstechnischen Gegebenheiten entsprechen 
> und nicht einfach nur schön sein:-)

Wir mappen nicht fuer ... :)

Verkehrstechnisch ists eine unclassified, wenn man den
Verbindungstyp betrachtet aber nicht nach Breite und
Ausbau. Schade dass man sich nicht durchringen kann, Ausbau
und Verbindungstyp getrennt zu erfassen, denn dann waere
das Abbilden der Nordschleife und vielen anderen 
Problemfaellen deutlich einfacher und genauer. 

Gruesse Hubert

-- 
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] KFZ-strasse und primary, war Nürburg ring

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 22 Dec 2009 16:57:51 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de]KFZ-strasse und primary, war Nürburgring

> Am 22. Dezember 2009 16:50 schrieb qbert biker :
> 
> >
> > Bleibt die etwas gequaelte Konstruktion 'trunk'. Es scheint
> > sich leider durchgesetzt zu haben, dass immer 'trunk' gesetzt
> > wird, wenn das KFZ-Schild angebracht wird.
> 
> 
> kannst das ja ändern und am Besten einen Note setzen, damit es nicht
> übermorgen wieder zurück geändert wird.

Na eher morgen...

Mittlerweile finde ich bei diesen Dingen das Beobachten spannender
als das Ändern, besonders wenn ich das vor langer Zeit mal selber
eingetragen hatte.

Und diese trunk-Murks setz ich eh nimmer, denn einerseits finde ich
das grün hässlich und andererseits weiss ich selber nicht mehr,
was ich mir drunter vorstellen soll. OK, ok, die erste Begründung
ist ein Scherz :) 

Grüsse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] KFZ-strasse und primary, war Nürburg ring

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 22 Dec 2009 15:54:39 +0100
> Von: Mathias Kemper 
> An: m...@koppenhoefer.com, Openstreetmap allgemeines in Deutsch 
> 
> Betreff: Re: [Talk-de] Nürburgring Nordschleife (betrifft eventuell 
> Rennstrecken allgemein)

> unter highway=primary lese ich was von Bundesstraße, nicht 
> BundesKRAFTFAHRstraße.

Primary ist die Hauptverbindungsstrasse, die typischerweise,
aber nicht immer mit der Bundesstrasse zusammenfaellt. Eine
Bundesstrasse kann KFZ-Strasse sein aber auch eine Staats-
oder Kreisstrasse.

KFZ-Strasse bezieht sich darauf, wie eine Strasse von wem
benutzt werden darf (z.B. Radfahrer und Fussgaengerverbot)
und nicht darauf, welche Bedeutung sie hat oder wie sie 
ausgebaut ist. Und natuerlich ist eine KFZ-Strasse normalerweise
eine gut ausgebaute Strasse, aber es gibt auch Ausnahmen und
man kann das nicht zwingend voraussetzen.

> Auch finde ich dort keinen Hinweis auf motorroad=yes.

'motorroad' ist ein unabhaengiges Attribut das sich 
eindeutig auf Strassen(abschnitte) bezieht, die vom 
entsprechenden Schild begrenzt werden. 
 
> Der Unterschied Bundesstraße zu Bundeskraftfahrstraße fänd ich in so 
> fern schon wichtig als dass man auch auf der NS nicht (gundlos - für die 
> Koritenkacker) anhalten darf und Fahrzeuge auch bauartbedingt 60Km/h (?) 
> fahren können müssen, Mofas jedenfalls nicht.

Klappt aber so nicht, weil sich das eine auf die Bautreagerschaft
bezieht und das andere auf Verkehrsregeln. Wie schon geschrieben
gibts durchaus auch Kreisstrassen, die den Status KFZ-strasse
haben. 
 
Bleibt die etwas gequaelte Konstruktion 'trunk'. Es scheint
sich leider durchgesetzt zu haben, dass immer 'trunk' gesetzt
wird, wenn das KFZ-Schild angebracht wird. In Muenchen und
Umgebung schaut das jetzt so aus, dass der kreuzungsfrei
und autobahnaehnlich ausgebaute Mittlere Ring den trunk-Status
verloren hat, weil das Schild fehlt und gut ausgebaute gegen
schlechter ausgebaute Abschnitte (Ampeln, etc.) nicht mehr
unterscheidbar sind. 

Besser ausgebaute Nebenstrassen (die genannten Kreisstrassen)
erscheinen im fetten gruen, nur weil das Schid vorhanden ist.
Am Muenchner Flughafen ist die eine Strasse unclassified und
eine andere aehnliche Strasse trunk, nur in Abhaengigkeit
vom KFZ-Strassenschild. Besonders aussagekraeftig fuer die
Orientierung ist das alles leider nicht. 

Gruesse Hubert



-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Fahrtzeiten in Staus

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 18 Dec 2009 17:21:44 +0100
> Von: Florian Lohoff 
> An: Marcus Wolschon 
> CC: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Fahrtzeiten in Staus


> Aber steht nicht in den TMC meldungen genau die zu erwartende
> verzoegerung in Minuten?  Zumindest erinnere ich mich da an was.

Wohl eher eine sehr grobe Schaetzung. TMC stammt ja historisch
von den Radiomeldungen ab, bei denen die Meldung die Meldekette
oft erst dann durchlaufen hatte, wenn das Stau schon wieder weg 
war.

Heute geht das zwar schneller aber die Krux bleibt die
Schaetzung der zu erwartenden Verzoegerung. Die ist nicht 
direkt messbar, weil es ja eine Prognose eines Vorganges ist, 
der in der Zukunft stattfindet. In der Zukunft deshalb, weil 
ich den Stau idealerweise noch nicht erreicht habe, wenn die
Meldung frueh genug kommt, um ihn zu umfahren.

Jetzt ist ein Stau aber keine statische Angelegenheit, sondern
in vielen Faellen ein hochdynamischer Vorgang mit vielen
Unbekannten. Schon alleine deshalb kann so eine Prognose gar 
nicht genau sein, bzw. man muesste einen Soll- ist Vergleich 
machen um zu sehen, wie nahe die Prognose an die Realitaet
rangekommen ist. Der wird aber nur in den seltensten 
Faellen gemacht.

Was bleibt sind Daumen mal Pi Abschaetzungen aus allgemeinen
Erfahrungswerten. Man kennt meist die Verkehrsfluesse als 
Profil ueber den Tag hinweg und kann bei einer Spurverengung
Rueckschluesse ziehen. Dann dazu noch die berühmte Schätzung
der Staulänge und fertig ist der Prognosewert. Manchmal ists auch
pure Statistik, denn manche Staus treten ja zyklisch auf und
ein Blick eines Operators auf die Überwachungskamera genügt,
um die Standardmeldung auszulösen. Eine andere, leider sehr
fehlerbehaftete Quelle sind automatisch erzeugte Stauwarnungen
aus den Streckenbeeinflussungsanlagen heraus. Die haben nur
ein paar Querschnitte als Bezug und daraus eine Prognose der
Verzögerung abzuleiten, grenzt an Kaffeesatzleserei ;)

Gruesse Hubert

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Fahrtzeiten in Staus

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 17 Dec 2009 07:22:42 +0100
> Von: Marcus Wolschon 
> An: talk-de@openstreetmap.org
> Betreff: [Talk-de] Fahrtzeiten in Staus

> Mit der Weihnachtszeit stehen auch wieder sie Staus an.

Nachdem ich in der vergangenheit ein wenig mit dem Thema
Staus und Reisezeitschaetzung verbandelt war, ein wenig Senf
von mir dazu:

Bei der Reisezeitschaetzung hat man zwei unterschiedliche
Datenquellen. Zum einen die klassische Methode ueber
Querschnitte, also die Induktionsschleifen oder andere
Detektoren die die Bewegungen ueber einen Querschnitt 
zaehlen. Die zweite und modernere Methode ist das 
'floating car' also das Fz, das im Verkehr mitschwimmt
und dabei Statusmeldungen abgibt.

Bei der Querschnittserfassung gibts zwar massig staatlich
erhobener Daten, auch dank der Streckenbeeinflussungen
(Schilderbruecken mit variablem Tempolimit), die wie
Pilze aus dem Boden spriessen. Allerdings ist die 
Reiszeitschaetzung ueber diese Daten nicht besonders
genau, da man nur lokale Effekte messen kann, ein Stau
aber ein Effekt ist, der irgendwo dazwischen beginnen und
enden kann. Meine Erfahrungen mit den entsprechenden
Methoden waren jedenfalls nicht das gelbe vom Ei.

Frueher wurde die TMC-Daten fast ausschliesslich ueber
diese Daten erhoben oder noch schlimmer ueber die
beruehmte Schaetzung der Polizei vor Ort, die auch so
in den verkehrsmeldungen rueberkommt. Entsprechend duenn
ist (war?) die Aussagekraft. Die Navihersteller wollen 
verkaufen und wurschteln das rein, so gut wies eben geht.
Gemeinerweise kann man ja immer nur eine Route 
gleichzeitig fahren und erfaehrt so selten, ob die andere
schneller gewesen waere ;)

Nun zur zweiten Erfassungsmethode, die Floating cars. 
Leider bin ich nicht mehr in diesem Geschaeft und weiss
nicht wie sich das entwickelt hat. Grundsaetzlich gibts
aber ein ziemliches Problem, Floatingcar-Daten 
oeffentlich zu erheben und verfuegbar zu machen. Wir
haben damals schon einiges damit gemacht, z.B. mit
Taxiflotten, die die Daten online Kommunen zur Verfuegung
gestellt haben, aber da gibts natuerliche Grenzen.

Das geniale dran ist, dass man im Idealfall ein exaktes
Profil des Staus bekommt und auch exakt den Zeitverlust
(gemessene Fahrtdauer abzueglich Standardfahrzeit). Klar 
gibts da auch Fehlerquellen, aber die lassen sich 
eigentlich ganz gut filtern. 

Ich denke, wenn man schon Staus vergleicht, sollte man
versuchen, das auf eine moeglichst objektive Basis zu 
stellen. Da viele von uns ein GPS haben und auch so
manches mittracken, gibts auch immer mal einen Track, der
einen Stau beschreibt. Diese Tracks waeren eine tolle
Ergaenzung zu den einfachen Stauberichten, die hier
vorgeschlagen werden.

Gruesse Hubert


-- 
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] Straßenbegleitende Fußwege an Ampeln (was: Wie würdet Ihr das zeichnen ??)

[qbert biker]

 Original-Nachricht 
> Datum: Sun, 13 Dec 2009 03:24:36 +0100
> Von: "Mirko Küster" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de]Straßenbegleitende Fußwege an Ampeln (was: Wie 
> würdet Ihr das zeichnen ??)

Hallo,

> Und genau dafür lohnt es sich das auch genau zu erfassen. Wir haben die 
> Mittel und Wege, auch wenn das Straßenmodell noch einiges an Luft nach
> oben 
> hätte.

Es stellt sich eher die Frage, ob das Strassenmodell das
begrenzende Element ist, oder die OSM-Modellierung an sich.
Jedes noch so kleines Element in einen einzigen jetzt schon
gewaltigen Knoten-Namensraum zu packen ist kein besonders
elegantes Konzept. 

Eine Kreuzung ist erstmal eine einfaches Element fuer den
Treffpunkt zweier Elemente des Graphen, das anzeigt, wie
man weiterkommt. Man kann natuerlich diese Kreuzung bis
zur Pflastersteinebene ausschmuecken, aber muss das 
unbedingt im Namensraum des Graphen passieren? 

Mit ein wenig Objektorientierung waere das ganze besser
loesbar: 'Du naeherst dich jetzt der Kreuzung xy, wenn du
weitere Infos willst, lade die Detaildaten der Kreuzung
nach'. 
 
> Das Problem liegt schlicht an den Routern selbst. 

Router werden so oft missverstanden, dabei sind sie 
eigentlich nur Abbildungen von relativ einfachen 
Algorithmen. Je besser die Abstraktion des Wegenetzes
gestaltet ist, desto schneller ist die Berechnung und
desto brauchbarer sind die Anweisungen.

Ein OSM-Router muss sich an technischen Tatsachen 
orientieren, wie sein kommerzielles Gegenstueck auch.
Klar kann man aus komplexesten Abbildungen wieder auf
die wesentlichen Verbindungen zurueckrechnen, aber 
dafuer brauchts stabile Vereinbarungen. 

Und das ist eben das Problem mit 'dann mach eben eine
Relation drum, der OSM-Wunderrouter wird schon 
rausfinden, was damit gemeint ist'. Ein Router, bzw.
die davorgeschaltete Datenaufbereitung kann nur 
verarbeiten, was er kennt. 

Wenn man einigermassen konfliktfrei Autos, Radfahrer,
Rollstuhlfahrer und Blinde jeweils fuer sich optimal
routen will, sollte man sich mal Konzepte ausdenken,
wie man das besser organisiert. Einfach die Datenbank
ohne jede Ruecksicht auf irgendeine Anwendung zu
befuellen und auf den OSM-Wunderrouter zu warten, der
mittels HAL9000-KI die optimale Route fuer jeden
findet, ist die Alternative ;)

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Luftbilder aus Lauf

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 02 Dec 2009 23:28:59 +0100
> Von: "André Reichelt" 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Luftbilder aus Lauf

> qbert biker schrieb:
> > Aber die Rundungen, die ich meine, kann man abstrakt beschreiben
> > und direkt rendern: 'corner=round size=3m' oder ähnlich kann
> > beschreiben, dass die Ecken der Kreuzung mit einem Radius von
> > 3Meter abgebildet werden sollen / so gebaut sind.
> 
> Das klingt leider alles sehr abstrakt und extrem kompliziert zu
> bedienen. Außerdem brauchst du für jede Sonderform eine Extrawurst.

Welche Sonderformen sollten denn betrachtet werden? Eckig
ergibt sich automatisch, wenn nichts eingetragen ist 
(Kreuzungspunkt der Parallelen mit Radius = 0) und rund mit 
Radius ist immer eine sehr gute Naeherung. Den Rest kann man 
immer noch explizit reinmalen.

Abstraktion ist die Methode der Wahl, wenn man mit wenig Daten
viel Effekt haben will. Navis mit (Pseudo-)3D und 
Spurwechselassistent speichern ja auch nicht jeden Strich 
auf der Strasse einzeln, sondern rechnen das aus komprimierter
Information raus. 

> Ich habe ja bereits vor einigen Monaten angeregt, man könne neben
> geraden Ways ja auch echte Kurvenobjekte einsetzen. Das Ganze verlief
> sich aber im Sand, da damals noch keine Notwendigkeit bestand. Bei
> detaillierter Flächenbeschreibung sehe ich aber keinen Weg mehr daran
> vorbei.

Es bestand immer Notwendigkeit oder auch nie, je nachdem wie
man das Ziel von OSM definiert. Jede Kurve kann ueber 
Einzelpunkte angenaehert werden, was ja auch der Grund ist,
warum GDF und shape auf Kreise oder andere Kurvenbeschreibungen
verzichten. Bei OSM ist man frei, da darueber raus zu
gehen, man muss sich aber klar sein, dass es ohne Planung
und Regeln sehr, sehr schwierig wird, neue Geometrieobjekte
einzufuehren.

> Aber wie gesagt, ich bin gegen eine reine Taggingbeschreibung. Das wird
> so komplex, dass man Anfänger damit sofort vertreibt und keiner mehr aus
> den Tags herauslesen kann, was eigentlich gemeint ist.

Das gehoert in die Editoren rein und dann ist das relativ 
einfach. Kreuzungsnode anklicken, Radius ziehen und 
Ergebnis direkt am Editor betrachten - so solls sein. Die
anachronistische Knoten-Way-Fummelei mit haendischen 
Eintragen von Attributen ueberfordert die meisten Mapper
schon heute.

> Meiner Meinung nach sollten geometrische und physikalische Eigenschaften
> klar voneinander getrennt werden, sofern dies möglich ist. Die
> Oberflächenbeschaffenheit einer Straße kann man nur in Tags abbilden,
> jedoch sollte man diese nicht dazu missbrauchen, Dinge wie Fahrspuren,
> die Breite jeder einzelner Spur und ähnliches anzugeben. Dagegen bin ich.

Die Alternative ist eine endlose Fummelei an jedem Detail,
egal ob es einer Regel folgt oder nicht. Will ich die Abrundung
an einer normalen Kreuzung per Hand reinmalen, bedeutet das
4 Ecken mit ca. 90Grad also bei 10Grad Aufloesung das 
haendische setzen von ca. 36Nodes. Da finde ich eine 
abstrakte Beschreibung: 'Die Fahrbahn ist 5m breit und die 
Ecken im 3m Radius abgerundet' viel einfacher.

Gruesse Hubert
-- 
Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen   
Debütalbum "One Moment in Time". http://portal.gmx.net/de/go/musik

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

Re: [Talk-de] Luftbilder aus Lauf

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 2 Dec 2009 19:52:31 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Luftbilder aus Lauf


> In der Großstadt sind es hundert Faktoren, die eine Extrawurst brauchen,

Und so gut wie alle Extrawürste führen zu geometrisch gut
beschreibbaren Strukturen. Ich habe München angeführt, weil ich
die Stadt gut kenne und auch über OSM noch besser kennengelernt
habe. Dabei bin ich über viele km mit parallelen Verläufen
gefahren, geradelt und gelatscht. Eine Ausnahme ist der historische
Kern der aber flächenmässig fast untergeht. Schwabing, das zu
den ältesten Vierteln gehört hat mit die exaktesten Geometrien,
abschnittsweise perfekt rechtwinklig.

Gruesse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Luftbilder aus Lauf

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 2 Dec 2009 17:04:53 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Luftbilder aus Lauf

Hallo,

> Rundungen ist ein gutes Stichwort: Kurven wären auch mal nicht schlecht
> als
> Grundobjekt.

Sehe ich auch so und ist auch so eine Sache, an der ich dran
bin. Ist aber im Moment zurückgestellt, weil mich das wayparts
Konzept davon überzeugt hat, einen Zwischenschritt einzulegen
und zu sehen, was man aus ways und nodes rauskitzeln kann.

Aber die Rundungen, die ich meine, kann man abstrakt beschreiben
und direkt rendern: 'corner=round size=3m' oder ähnlich kann
beschreiben, dass die Ecken der Kreuzung mit einem Radius von
3Meter abgebildet werden sollen / so gebaut sind.

> als ob die Welt aus Neubaugebieten auf dem Land und in Suburbia bestehen
> würde ;-)

Man vergleiche bei einer Stadt wie München die Strassen-km die
älter als 100 Jahre sind und welche neuer. Dabei werden schon 
mendestens seit der Aufklärung Strassen geplant. Kompletten
Kickhack gibts vor allen auf wenigen 100m in kleinen Orten
und in mittelalterlich geprägten Orten.

Grüsse Hubert

-- 
Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen   
Debütalbum "One Moment in Time". http://portal.gmx.net/de/go/musik

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

Re: [Talk-de] Luftbilder aus Lauf

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 2 Dec 2009 17:06:48 +0100
> Von: "Mirko Küster" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Luftbilder aus Lauf

> > Der Bedarf an konkreten Flaechen wuerde sich dann auf krumme
> > Dinger beschraenken (alte Ortsdurchfahrten, exotische Wendehaemmer)
> > die dann ausserhalb des Graphen existieren.
> 
> Was in meinem Gebiet eher die absolute Regel darstellt. Exakte 
> Reißbrettstraßen gibts nur in absoluten Neubaugebieten oder eben
> größeren 
> Städten. Da könnte sowas automatisches helfen. Aber in der großen
> Fläche ist 
> die Straße nach Bebbaung geplant, nicht umgekehrt.
> 
> Normal ist sowas wie beispielsweise hier.
> http://osm.org/go/0MBdGAqKm
> http://osm.org/go/0MBW4x34r

Also der zweite Link mag grade nicht, aber beim ersten 
verstehe ich das Problem nicht. Und ich bin auch schon viele
km im Osten gefahren und die Strassen sind zwar nicht 
gerade (hier im Westen ja auch nicht), aber weitgehend parallel.
Strassen, die im Verlauf ihre Breite dauernd um mehr als 10%
ändern, sind überall in der Minderheit.

So, jetzt ist der zweite auch da und auch da erkenne ich 
nicht, wo das Problem sein soll. 
 
> Das kann kein System errechnen und die Maßangabe für die Breite über
> alles 
> wäre fließend. Bei der Fahrbahn selbst gehts noch einigermaßen, obwohl
> auch 
> die in vielen Fällen eher konisch als genau läuft.. 

Es geht ja in erster Linie um die Fahrbahn und konische Bereiche
sind möglich und auch das ist abbildbar. Node 1, Breite a, Node 2,
Breite b und fertig. 

> Das drumherum
> fließt 
> förmmlich. Da geht nur exakt nachzeichnen, alles andere geht in die Hose.

Was einen eigenen unabhängigen, Verlauf hat, wird auch als
solcher gezeichnet, wo liegt das Problem? Trotzdem folgen deutlich
mehr als 90% aller Strassen der technischen Vorgabe, den Verkehr
aufzunehmen und seit der Römerzeit oder schon vorher laufen die 
Räder parallel ;)

Gruesse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Luftbilder aus Lauf

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 2 Dec 2009 15:33:22 +0100
> Von: "Mirko Küster" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Luftbilder aus Lauf

 
> Problem ist das man mit Flächen allein nicht weit kommt. Lässt sich
> nicht 
> drüber Routen etc. Es läuft also erstmal auf einen Mix aus Fläche und 
> darunter liegenden Linien mit den eigentlichen Funktionen heraus. Diese
> Wege 
> kann man dann rein für die Funktion nutzen und die Darstellung bei der 
> Fläche belassen Dann würden ortsplazierte Dinge mit Straßenbezug wie 
> Bushaltestellen auch endlich mal einen Sinn ergeben, den es bisher nicht 
> hat. Ob Punkt auf der Linie oder daneben, an normalen Haltestellen in 
> kleinen Orten kein spürbarer Unterschied.

Da halte ich dagegen, dass man Flaechen auch abstrakt beschreiben
kann, ohne das Graphenprinzip zu verlassen. Man muss die Parallelen
dann eben fuer die Realumgebung (metrisch) rechnen und nicht in
der Ansichtsebene. Auch die Rundungen an den Kreuzungen lassen 
sich automatisiert berechnen.

Der Bedarf an konkreten Flaechen wuerde sich dann auf krumme 
Dinger beschraenken (alte Ortsdurchfahrten, exotische Wendehaemmer)
die dann ausserhalb des Graphen existieren.

Ich arbeite derzeit an sowas, ist aber in einem sehr fruehen Stadium
und braucht noch seine Zeit.

Was mir allerdings gar nicht gefaellt, ist die Verwendung von
highway fuer Flaechen, unabhaengig von Attributen. 'highway' konnte
bisher immer als Graphenelement aufgefasst werden, mit einer
Parallelbedeutung als Flaeche wird das aufgeweicht. Ein 
unabhaengiger Bezeichner ('highway_area'?) koennte helfen, dass
man nicht rund um die eigentliche Strasse herumroutet, wenn 
einer vergisst, das Flaechenattribut anzugeben.

Gruesse Hubert 

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Mapnik - living streets

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 1 Dec 2009 17:01:09 +0100
> Von: "Mirko Küster" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Mapnik - living streets

Hallo,
 
> Es gibt Dinge wo man sich wahrlich streiten kann. Und es gibt Dinge wo man
> sich sinnlos totquatschen kann. Breitenangaben beziehen sich in allen mir 
> bekannten Quellen immer auf die Fahrbahn. 

Kann ich nur zustimmen.

> Das alles über einen Kamm zu scheren mag für manchan schön einfach
> sein, ist 
> und bleibt aber eine Krücke.

Meiner Meinung nach fehlt vor allem ein Konzept um von einer
einfachen Darstellung stufenweise mehr Komplexität zu 
erreichen, ohne vorhandenes wieder zu zerstören. Auch deshalb
stimme ich dir bei der Fahrbahnbreite als Basis zu. Da kann
man gut anbauen, allerdings tendiere ich mehr und mehr zu
einem relationbasierten Konzept, das zusätzlich der 
Fragmentierung entgegenwirken kann.
 
> Die aktuellen Bauvorschriften nützen hier in der Regel ohnehin nichts.

Da bin ich grade dran. Ich denke schon, dass Standardquerschnitte
etwas Ordnung ins Chaos bringen können, weil man geeignete 
Strassen einrasten lasten kann, optimalerweise mit etwas
SW-Unterstützung. 

> Nur 
> weil irgendwo eine Vorschrift 6 m für Landstraßen vorsieht, wird es in
> der 
> Realität nicht breiter. 

*g* Andersrum funktionierts auch besser. Wenn ich weiss, dass 
eine Strasse etwa vor 10 Jahren erneuert wurde (wissen Ansässige
meist recht gut), brauch ich nur antesten, ob und welcher
Standard zur Anwendung gekommen ist und kann direkt die Daten
auslesen und vergleichen.

> Das kann man, ist aber immer auf die subjektive regionale Sichtweise 
> bezogen. 

Na ja, ich bin auch schon im Osten gefahren und ganz so konzeptlos
gehts da auch nicht zu ;)

Aus eigener Erfahrung sind bei normalen Strassen so ca. 3-4
Ausbaustufen relativ gut unterscheidbar. Die Breite vor allem
über die Restbreite, wenn man ein Bild mit PKW vor sich hat
aus dem hervor geht, wie das Verhältnis von Fz-Breite zu
Fahrbahnbreite ist.


> Maximal nur Gewichtsbeschränkungen an beispielsweies Brücken im
> Abschnitt 
> werden wit vorher angekündigt, alles andere nur direkt vor dem Hinderniss
> selbst. Der LKW erkennt das Problem erst wenn er davor steht. 

Das ist durchaus üblich, aber mehr brauchts ja auch nicht. Der
Mapper kann am Hindernis direkt ablesen, welche Breite (oder
auch Höhe) das Hindernis zulässt. Das ist aber eine Eigenschaft
des Hindernisses (z.B. Unterführung) und nicht der Strasse und
soll auch dem Hindernis zugeordnet werden. 
 

> Bröckelhafter Ausbau ist hier 
> Normalzustand. Müsste man gute und schlechte Abschnitte über den Highway
> tag 
> abbilden, es würde ein bunter Mix aus kurzen Schnipseln entstehen.

Das auf das highway-tag abzuladen ist auch keine gute Idee,
solange die Tendenz zur verbindungsorientierten Abbildung geht.
Wenn man will, dass die Info nicht vom nächsten highway-
Spezialisten überschrieben wird, benutzt besser ein geeignetes,
direkt und eindeutig auf den Ausbau bezogenes Attribut.

> Klar geht das so nicht auf den Millimeter, aber allemal um Lichtjahre 
> genauer wie Schätzen oder Fehlinterpretationen über Bauvorschriften, die
> im 
> Einzellfall garnicht auf die vorliegende Straße anwendbar sind.

Fotometrische Auswertung ist aber nicht jedermanns Sache. 
Bauvorschriften dürfen natürlich nicht blind vorausgesetzt werden,
so nach dem Motte, dass man allen Bundesstrassen einfach eine
Standardbreite zuweist. Aber man kann die Information geben,
dass im Bundesland xy folgende Standardbreiten angewendet werden
und dann muss man nur noch prüfen, ob man davon etwas anwenden
kann.

Gruesse Hubert
-- 
Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen   
Debütalbum "One Moment in Time". http://portal.gmx.net/de/go/musik

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

Re: [Talk-de] Mapnik - living streets

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 01 Dec 2009 16:25:26 +0100
> Von: Tobias Knerr 
> An: "Mirko Küster" , Openstreetmap allgemeines in 
> Deutsch 
> Betreff: Re: [Talk-de] Mapnik - living streets

> Mirko Küster schrieb:
> > Wer interpretiert da wo und wie? Ist mir noch nirgends untergekommen das
> da 
> > einer Breite über alles eingetragen hätte, schon garnicht
> absurderweise 
> > zwischen Grundstücksgrenzen. Straßenbreiten, Regelquerschnitte etc.
> beziehen 
> > sich immer auf die Fahrbahn und nicht auf straßenbegleitende
> Maßnahmen. 
> 
> In OSM repräsentiert ein Straßen-Way meist nicht nur eine Fahrbahn,
> sondern auch verschiedene begleitende Gehsteige, Radwege etc. - sonst
> hätten die ja eigene Ways und wären nicht nur Attribute
> (Tags/Relationen) am Straßen-Way.

Darueber gehen die Meinungen weit auseinander. Die Verfechter
des expliziten Eintragens von Einzelways fuer jedes Element
sehen das z.B. komplett anders. Ich selber sehe Parallelwege
auch lieber als Element eines Ways, die man z.B. im Einzelnen
so beschreiben kann:

http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058720.html
http://wiki.openstreetmap.org/wiki/DE:User:%C3%96mmes/Wayparts

> width=* ist die Breite des mit einem Way dargestellten Gebildes. Dieser
> Logik nach ist das alles beim width-Wert eines highway-Ways mit
> einzubeziehen.

Und wie beschreibt man dann die Fahrbahn selber? Die Breite
ueber alles hat sehr wenig Aussagekraft, z.B. wenn man die
Breite beim Rendern einbeziehen will oder pruefen, ob man mit
dem Fz. nun durchkommt oder nicht. 

Der worst case ist aber wenn die eine Haelfte in width die
Breite der Fahrbahn sieht und die andere die des ganzen
Gebildes. Eine Definition dazu waere hilfreich, egal wie sie
ausfaellt, sonst ist die Auswertung sehr schwierig.

Gruesse Hubert

-- 
Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen   
Debütalbum "One Moment in Time". http://portal.gmx.net/de/go/musik

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

Re: [Talk-de] Mapnik - living streets

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 1 Dec 2009 14:37:17 +0100
> Von: "Mirko Küster" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Mapnik - living streets

 
> Wenn nichtmal in den Mapfeatures für width eine eindeutige Angabe steht,
> in 
> deutsch gleich garnicht, muss man sich auch ehrlich gesagt nicht wundern. 
> Breiten zu Straßen beziehen sich i.d.R. immer nur auf die Fahrbahn, nicht
> über straßenbegleitende Bauten, zwischen Grundstücken ist komplett
> falsch.
> 
> So ins Wiki, als hint in JOSM und schon dürften sich die Ausreißer in 
> Grenzen halten.

Wuerde ich begruessen und zumindest ich finde es so logisch
und verstaendlich. Allerdings gabs schon einige Diskussionen 
darueber hier und die Meinungen waren vielfaeltig und der
Konsens fern. 
  
> Die Maße beziehen sich vielleicht auf aktuelle Bauvorschriften für 
> Neubauten. Sind aber in der Praxis für den überwältigenden größeren 
> Altbestand total unbrauchbar. 

Das mag regional stimmen, aber in anderen Ecken ist die
Mehrheit der Strassen schon mehrheitlich nach aktuellen 
Regeln ausgebaut. Also hier im Sueden muss man Altbestaende,
die massiv abweichen, eher suchen.
 
> >  => Breite bei 2 Spuren im Gegenverkehr: 5 - 9 m
> >  => Breite bei 4 Spuren: 10 - 11,20 m
> >  => Breite bei 6 Spuren: 15 - 16,80 m
> 
> Das sind Milchmädchenrechnungen die man sich auch komplett schenken kann.

Immerhin besser als nichts. Das hauptproblem ist, dass der
Mapper vor Ort die Bauvorschrift selten kennt und schon gar 
kein Messgeraet dabei hat um das genau festzustellen. Und
ein Massband quer ueber die Autobahn zu spannen ist ja 
auch nicht jedermans Sache ;)

Mal ein anderer Ansatz: Ich denke, dass ein Mapper vor Ort
schon gut einordnen kann, ob der Ausbau normal, ueberbreit
oder sehr schmal ist. Wenn man dann noch ein wenig 
Hilfestellung gibt (Querschnittszeichnung, Bilder?) bekommt
man vielleicht eine Genauigkeit hin, die zwar nicht perfekt
ist, aber schon mal die Richtung vorgibt.
 
> für eine zukünftige Routinganwendung für LKW Fahrer interesannt. 

Auch hier scheints regional Unterschiede zu geben. Ich kenne
das eigentlich nur so, dass relevante Engstellen explizit
beschildert sind, solange es auch nur einen Hauch von
Durchgangsverkehr gibt. Dann sind aber die Daten (Hoehe, Breite) 
direkt abzulesen.

> In der Theorie. In der Praxis wird das unterschritten, genau wie 
> Fahrstreifen bei breiten Straßen oft auch nur nach Kassenlage aufgebracht
> werden. Da steht dann an der Kreisgrenze das berühmte "Straßenschäden"
> und 
> die Markierung endet.

Dann wird eben die Strasse immerhalb und aussserhalb der 
Kreisgrenze anders beschrieben.
 
> Abweichungen von mehr als 0,5 m sind für unsere Möglichkeiten deutlich 
> zuviel.

Bleibt die Frage, wie mans besser hinbekommt. Leute mit
Lasermessgeraeten sind Mangelware.
 
> > im Schnit bei ca 5 m liegen dürfte.
> 
> Eine eingebildete Unsicherheit. 

Nach welcher Messmethode? Sowohl die Abbildung aus Bildern
als auch aus Tracks ist fehlerbehaftet. Es geht hier nicht
um wenige Spezialisten, die das Maximum aus der technik
rauskitzeln, sonndern um den Durchschnitt der Mapper mit
durchschnittlicher Technik und da ist man mit 5Meter gut
dabei, denk ich mal.

Gruesse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 25 Nov 2009 22:54:26 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Relationen besser als Tags?

Hallo

> ach so? Na meine Fähigkeiten erweitern habe ich auch nichts dagegen,
> mir
> kam das zunächst so vor, als würde es die Anforderungen an den Mapper
> und
> die Tools deutlich erhöhen.
 
Das 'und' drueckt hier wohl das Missverstaendnis aus. Hoehere
Anforderungen an die Tools senken die Anforderungen an die
Mapper, bzw. verbessern deren Moeglichkeiten, komplexe Dinge
einzutragen. Ein Editor fuer Querschnittsbeschreibungen, der
das Ergebnis gleich visualisiert, ermoeglicht den Mapper mit
wenig(er) Aufwand die Komplexitaet zu bewaeltigen.

> > Die klassische Abbiegespur ists jedenfalls und die
> > typischen Parallelwege in Wohngebieten auch.
 
> in typischen Wohngebieten, oder?

Ein gutes Modell bildet die Regel als Regel und die Ausnahme
als Ausnahme ab und nicht umgekehrt. Wenn ein Konzept fuer
90% der Parallelwege funktioniert und ich diese relativ
einfach abbilden kann, senkt das die Gesamtkomplexitaet.
Die Ausnahme, die dann ueber explizite ways abgebildet werden
kann, bleibt ja deshalb immer noch abbildbar.
 
> habe das schonmal etwas ausführlicher im Archiv nachlesbar beschrieben,
> konkret werde ich demnächst mal im Wiki einen Vorschlag machen. Ist ja
> schnell gemacht, da es wirklich einfach ist, und im Grunde dasselbe, was
> wir
> schon ewig machen, auf Spuren ausdehnt. Die barriers, die wir auch schon
> haben, integrieren sich da bestens.

Aber bitte so, dass die Spuren auch als Spuren erkennbar 
bleiben. Es waere schade, wenn man mit hochkomplexen 
Algorithmen das Netz wieder zurueckrechnen muesste, weil 
Spuren wie normale Strassen behandelt werden und das sind
sie nun mal nicht.

Die Einfaedelspurinformation auf den Autobahnen ist schon 
jetzt kaum mehr aus den Daten restaurierbar, weil es kein
Konzept fuer Bereiche mit Spurwechselmoeglichkeit gibt.

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 25 Nov 2009 13:05:17 +0100
> Von: Martin Koppenhoefer 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Relationen besser als Tags?


> ja, und aus den Luftbildern und vor allem auch aus der Kenntnis der
> Situation. Wenn ich weiss, dass der Schlenker an der Telefonzelle ist,
> dann
> mache ich ihn dort auch hin. Willst Du das nicht?

Was ich will, spielt mal die allerkleinste Rolle und 
Luftbilder in der noetigen Aufloesung sind nur selten
verfuegbar. Was jedenfalls nicht in die DB gehoert, 
sind nachgemalte Fehler der Trackaufzeichnung oder 
Fehlinterpretationen wegen mangelnder Aufloesung der 
Luftbilder.
 
> ja, da sind wir uns ja einig. Daher würde ich darauf ja auch nicht
> verzichten wollen. Genau darum geht es hier ja.

Niemand will auf das Element der Linie verzichten, die
einen Verlauf beschreibt. In der Diskussion steht ja
nur, ob eine Linie mehr als nur einen Verlauf beschreiben
kann. 
  
> wie gesagt, das wird jemand auch wieder richten. (crowd)

Die Crowd ist erstmal nur ein Synonym fuer 'viele werkeln
dran' mit allen Vor- und Nachteilen. Die Crowd ist kein
Wunderding.
 
> denke ich nicht. Es werden vor allem jede Sekunde mehr ;-).

Masse alleine machts nicht, besonders wenn die Masse ueber
Datenmodell und Werkzeugen in ihren Moeglichkeiten limitiert
ist. Deshalb finde ich auch den vorgestellten Ansatz mit
dem Plugin so gut, denn der erweitert nicht die Anzahl der
Mapper, sondern deren Faehigkeiten, komplexer einzutragen.

> Wenn es um einzelne Wege geht (gern als "straßenbegleitend" beschrieben,
> aber in der Realität eben einfach in der Nähe einer Straße gelegene
> unabhängige Wege mit eigenen Eigenschaften, Regeln, Verlauf im Detail,
> Lage,
> etc.), bin ich für eine Abbildung wie gehabt: zeichnen und taggen. Man
> kann
> so z.B. auch Kreuzungsmöglichkeiten genauer definieren, etc. (s.o.,
> eigentlich habe ich ja alles schon wiederholt geschrieben).

Wenn sie einen unabhaengigen Verlauf haben, gibts einen
eigenen way, da gabs ja nie Differenzen. Nur haben wir
offensichtlich unterschiedliche Vorstellungen, wann ein
Weg geometrisch fix mit einem anderen gekoppelt ist. 
Die klassische Abbiegespur ists jedenfalls und die 
typischen Parallelwege in Wohngebieten auch. Wenn ich
daheim aus dem Fenster schaue, gibts eindeutige parallele
Verlaeufe. 

Na ja, lassen wirs auf den Vergleich ankommen. Du zeigst
mir einen ausgearbeiteten Entwurf mit dem man die 
Einzelways mit all ihren Abhaengigkeiten in den Griff 
bekommt und wie komplex das ist und ich versuch mich weiter
an der querschnittsorientierten geometrischen Abbildung
nach dem hier vorgestellten Schema. Dann wird man ja 
sehen, was besser rueberkommt.

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 25 Nov 2009 00:50:05 +0100
> Von: Martin Koppenhoefer 
> An: qbert biker 
> CC: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Relationen besser als Tags?

> > Dazu brauchts aber Konzepte und Technik. 'Frei Auge' hat
> > natuerliche Limitierungen. Iterativ wird ab einem bestimmten
> > Niveau nur noch hin und her geschoben, aber wenig verbessert.
> > Sind jedenfalls meine Beobachtungen.
> >
> >
> soweit sind wir m.E. noch praktisch nirgends (von Mirkos Ecke mal
> abgesehen). Erst bei richtig vielen Details, die ja jeweils auch wieder
> Korrekturen des Bestehenden mit sich bringen, wird sich das einstellen.

Das sehe ich etwas anders. Sauber gerade eingetragene Strassen
die so der Realitaet entsprechen, werden z.B. beim nachbessern 
gerne mal in krumme Kurvenstrecken verwandelt. Man muss schon
sehr gut sein, um beim haendischen Reimmalen von Einzelspuren
die urspruengliche konstruktive Basislinie zu erhalten, die
dem ganzen das Gesicht gibt.

Wenn es mal flaechendeckend Bilder in 10cm-Aufloesung als Basis
gibt, laesst sich sowas sauber abzeichenen. Aber in der Stadt
sind die GPS-Fehler um Groessenordnungen groesser als die von
dir angedachte Aufloesung. Willst du tatsaechlich in den
Strassenschluchten der Stadt kleinste Schlenker im Fahrradweg 
aus den GPS-Daten herausfiltern?
 
> ja, aber noch unübersichtlicher geht es kaum. Man könnte auch auf die
> Ways
> komplett verzichten und alles beschreiben, nur: wollen wir das?

Sei doch nicht so sparsam mit Superlativen ;)

Der way ist und bleibt die unverzichtbare Basis, die der
Konstrukeur der Strasse mal angelegt hat. Und warum ein relativ
sparsames Bezugssystem unuebersichtlicher sein soll als ein 
Wald von nodes, ways und relations erschliesst sich mir jetzt 
nicht so ganz. 

> klar, das ist wie bei allen Straßen und Wegen: einen Way in der
> Mittellinie.
> Alles andere ist "falsch", das kein richtig und falsch bezieht sich aufs
> tagging, nicht darauf, wo man die nodes und ways einträgt.

Noe, dass es die Mittellinie ist, ist keine Frage von falsch
oder richtig bei OSM, sondern einfach nur Gewohnheit, denn
es gibt keine Definition dafuer. Ich bin da langgefahren und
habs getrackt, also wirds eben die Mitte sein. Entspechend 
krumm und schief siehts mancherorts aus. Um die Mitte einer
Strasse auch nur mittelmaessig genau aus tracks bestimmen
zu koennen, muss man sie mindestens in jede Richtung einmal
abgefahren haben und ueber beide tracks sauber mitteln. Das 
wird wohl nur auf einen kleinen Teil der gemappten Strassen
zutreffen. 

Die Einbeziehung von geometrischen Tatsachen kann das Mapping
verbessern und da gehoeren Bezugssysteme wie das vorgeschlagene
dazu. Davon bin ich wiederum so ueberzeugt wie du von deiner
Einzelspurabbildung.

Gruesse Hubert

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 24 Nov 2009 14:14:50 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Relationen besser als Tags?

> Am 23. November 2009 17:04 schrieb qbert biker :
> 
> > Und die Lagedetails, die man verliert, sind meist
> > pseudogenau.
> 
> 
> das lasse ich nicht gelten. 

*g*

> Auch wenn die Genauigkeit zunächst nur
> relativ
> ist (der Weg liegt rechts in diesem Abstand und der nächste ist doppelt
> so
> weit entfernt), wird sich im Laufe der Zeit und mit mehr Details immer
> mehr
> Genauigkeit iterativ einstellen. 

Dazu brauchts aber Konzepte und Technik. 'Frei Auge' hat 
natuerliche Limitierungen. Iterativ wird ab einem bestimmten
Niveau nur noch hin und her geschoben, aber wenig verbessert.
Sind jedenfalls meine Beobachtungen. 

> Auch Objekte, die sich zwischen diesen
> Ways
> befinden (z.B. auch Ampeln, Stromkästen, Bordsteine, Blitzgeräte,
> Straßenschilder, etc.), können sauber eingetragen werden: das ist bei
> reinen
> Tags komplett unmöglich.

Komplett unmöglich ist schon mal garnix. 'Auf dieser Hoehe
zwischen Element x und y' ist realisierbar und genau.
  
> gegen absichtlich falsches Mapping ist halt kein Kraut gewachsen.

Nachdem es bei OSM kein falsch und richtig geben darf, wie
soll es da falsches Mapping geben? ;) Nö, im Ernst, falsch 
und richtig bedarf einer Zielvorstellung, wie das Ergebnis
auszuschauen hat und bisher hat niemand definiert, wie
Radwege ortsgenau einzutragen sind. Ein Mapping, das die
Abfolge der Parallelen kennt, kann sich hingegen dynamisch 
anpassen.
 
> je nachdem, wie sehr man sich bemüht. (und wie sehr man ggf. durch die
> Editoren unterstützt wird). "Der Bereich ist 3m breit" gilt halt für
> einen
> definierten Punkt, 

Nein, für einen Abschnitt und das nicht zufällig, sondern
weil das mal einer so festgelegt hat und das so in den Plänen
steht. Wer genauer taggen will wie die Vermesser, braucht aber
mindestens deren Technik.

> meist verändern sich die Breiten ja dynamisch 

Nö, ausser der Knilch an der Maschine war besoffen ;)

> (vor
> allem,
> wenn Spuren beginnen und enden, dann gibt es noch die quergestreiften
> Flächen, etc.).

Das ist ein Thema, das bei mir noch auf der Liste steht.
Diese ganzen Zusammen- und Auseinanderführungen folgen ja
i.A. festen Regeln die sich gut abstrahieren lassen sollten.
 
> Die hier vorgeschlagenen Tagabstraktion sehe ich als deutlich
> routingorientiert an, das ist aber m.E. nicht das Hauptziel wenn es darum
> geht, die Welt in einer Geodatenbank zu beschreiben.

Nein, sie ist geometrieorientiert. Sie bildet ab, dass es
sich um Konstruktionen handelt und nicht um zufällig 
entstandene Linienführungen.

> wir sprechen hier ja nicht von einem Way sondern genau betrachtet von
> mehreren. Das Prinzip von OSM ist, reale Gegebenheiten auf Linien zu
> abstrahieren und diese zu beschreiben. Mehrere Spuren sind daher m.E. in
> einem fortgeschrittenen Stadium mehrere ways, (und ggf. auch zusätzliche
> Flächen). Abbiegespuren etc. sind so transparent abbildbar.

Wie das fortgeschrittene Stadium aussehen wird, ist ja noch
offen. Dass das zwangsläufig alles über die unterste Ebene
(Node-Verbindungen) abgebildet werden muss, ist kein Naturgesetz.
Ich habe mir jetzt sein Autobahnkreuz runtergezogen und werde
mich mal ein wenig damit spielen. Wenn das Ergebnis (erstmal mich)
überzeugt, kann das ja als weitere Diskussionsgrundlage dienen.
 
Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Sun, 22 Nov 2009 15:04:51 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Relationen besser als Tags?


> das halte ich  nach wie vor fuer einen umstaendlichen und vor allem
> unnoetig
> abstrakten Weg, die Realitaet abzubilden. Zudem verliert man Lagedetails.

Ein klein wenig abstrakt vielleicht, aber gleich unnoetig
abstrakt?

Und die Lagedetails, die man verliert, sind meist 
pseudogenau. Radwege werden z.b. gerne mal im Abstand 
der Visualisierung angepasst und auch wenn nicht ist die
Angabe 'dieser Bereich ist 3m breit' fast immer genauer
als der versuch, parallele Linien per Hand reinzumalen.

> Ich habe in der Vergangenheit hier schon Beispiele gepostet
> (zugegebenermassen extreme), wo man am Ende auf ueber 30 einzelne
> virtuelle
> "Spuren" kommt. 

Und warum nimmt man nicht die 95% der Wege zum vorbild,
die nicht extrem sind und macht fuer die eine passende
Abstraktion? Fuer die 5% Rest kann man dann immer noch
ueberlegen, ob man aufdroeselt.

> Da blickt man selbst mit Editorunterstuetzung kaum noch
> durch, vor allem, weil diese Spueren ja noìicht durchgaengig laufen,
> sondern
> irgendwo anfangen und aufhoeren (d.h. splitten waere auch da ziemlich oft
> noetig).

Kommt eben auf den Editor an, das im link gezeigte Plugin
macht das alles schon ganz handlich. Und zum splitten:
Auch beim Ansatz mit eigenen ways fuer jede Spur wird 
gesplittet und nicht zu knapp. Aber nicht nur eindimensional
wie beim Vorschlag hier, sondern das ganze Netz wird
gespreizt. 
 
> Ich plaediere fuer den Ansatz, die Spuren und divider separat zu mappen,
> und
> dann ueber Relationen die Verbindung bzw. den Bezug herzustellen (z.B.
> auch,
> wenn es eine trennende Mauer ist, aber auch, um bei parallelen Spuren eine
> unterbrochene oder durchgezogene Linie abzubilden).

Wenn es eine physische Trennung (Mauer, Gruenstreifen) gibt,
wird ja i.A. schon immer mit getrennten ways gearbeitet.  
 
> Neben der erhoehten Lagegenauigkeit sehe ich dabei auch einen Vorteil in
> der
> unmittelbaren Abbildung der Realitaet (einfacher fuer den Mapper), und
> auch
> ohne extreme Erweiterung der Tools ist das Resultat besser nachvollziehbar
> und optisch ueberpruefbar.

Ich bezweifle eben, dass ein ganzes Geflecht von ways 
besser handhabbar ist als ein way, dessen Gestalt ueber
Zusatzinfos ausgearbeitet ist. Besonders bei den 
Relationen, die die Beziehungen der Spuren untereinander
klaeren sollen, bin ich bei Einzelways skeptisch.

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 20 Nov 2009 21:20:52 +0100
> Von: "Nils Heuermann" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Relationen besser als Tags?

Hallo,

> thematisch sind es schon 2 verschiedene Dinge (die sich u. U. direkt  
> ergänzen können); ich hatte meine Aussage eher aufs Prinzip mit  
> Start-/Endnode bezogen, damit die Wege nicht zerstückelt werden.

Hatte ich auch so aufgefasst. Aber wenn man sich mit dem einen
Beschäftigt, stolpert man fast zwangsläufig über das andere.

> > Was vielleicht
> > ein wenig untergeht ist die Sache mit der Bezugslinie.
> > Soweit ich das sehe, gehts du ja davon aus, dass die
> > Basislinie als linke Seite der Richtungsfahrbahn angenommen wird,
> > richtig? Damit 'waechst' die Fahrbahn mit den unterschiedlichen
> > Spuren und Breiten in Fahrtrichtung rechts.
> 
> genau. Also Vorwärts-Spuren (mit partnum +) sind in der Regel rechts,  
> Rückwärts-Spuren (mit partnum -) links, von der Mitte (ergo dem OSM-Way)
>  
> aus gesehen. Wobei hier nicht die Richtung des Ways entscheidend ist,  
> sondern die der Relation (Start-/Endnode).
> 
> > Meiner Erfahrung
> > nach ist das auch die einzige Methode, das optisch richtig
> > hinzubekommen.
> 
> Abgesehen davon, dass die Darstellung vom Plugin noch lange nicht perfekt 
> ist, habe ich vor allem bei Einbahnstraßen überlegt: Wahrscheinlich
> müsste  
> man dort die Spur (wenn es nur 1 ist) auf die Mitte zeichnen bzw.  
> rechts/links immer gleich viele Spuren. Wird jedoch auch nicht immer  
> passen...

Ich bin das Thema mal vor ein paar Jahren angegangen:

http://lists.openstreetmap.org/pipermail/talk-de/2007-July/001651.html
(flickr link im Beitrag) 

Damals hatte ich mich dafuer entschieden, auch Einbahnstrassen
mit Linksorientierung darzustellen, denn so kann man die an
Kreuzungen gut erkennen. Zusaetzlich habe ich auf das Zeichnen
der linken Linie verzichtet, um mehr Details erkennen zu können.
Deshalb auch die etwas eigenartige Optik beim Autobahnkreuz.
Mit etwas Übung sieht man aber direkt, ob die Richtungen der
Einbahnverbinder stimmen. Die Visualisierung war mehr als 
Testsysem gedacht, denn als realistischer Renderer und verwendete
die wenigen Tags die damals üblich waren. 

> noch nicht getestet, aber im Moment wird es dort genauso aussehen wie  
> überall ;)

Bei mir hat er bei Linksverkehr die Darstellung ziemlich versaut,
weil die Spuren über die Mittellinie rübergewachsen sind, deshalb
der kleine Hinweis.
 
> Man hätte dafür ja 2 Möglichkeiten:
> 1) Zusätzlichen Tag, der Linksverkehr angibt, sodass man direkt Bescheid 
> weiß und die Teile getauscht werden: rechts <-> links (nicht die
> Richtung)  
> usw.

Hab das damals damit hinbekommen, dass man die Werte bei 
Linksfahrländern negativ angibt. Länderregeln sind bei OSM so
eine Sache - sie wären eigentlich für vieles die eleganteste
Lösung, aber es gibt keine vernünftige Infrastruktur dafür, 
so entnehme ich das jedenfalls den laufenden Diskussionen.

Ich bin grade wieder ein wenig am basteln und verwende ein
paar Komponenten des alten Ansatzes weiter. Wenn sich dabei die
Querverbindung zu deinem Ansatz nutzen lässt, umso besser :)

Gruesse Hubert

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Handy für OSM

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 20 Nov 2009 12:33:49 +0100
> Von: marcus.wolsc...@googlemail.com
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Handy für OSM

> On Fri, 20 Nov 2009 11:18:40 +0100, Peter Körner
> 
> wrote:
> > Dieter Jasper schrieb:
> >> Hallo Liste,
> >> da ich nun als bisher Handy-Vereigerer ein Handy brauche, hätte ich 
> >> gerne Info über Handys ,die auch gut für OSM geeignet sind:
> >> 
> > 
> > Wie wäre es mit einem iPhone? MotionX GPS als
> > Tracker, Fotos sind automatisch Georeferenziert und ein Voice Recorder 
> > liegt auch bei.
> 
> Beliebiges Windows-Mobile Handy mit GPS und/oder Bluetooth(für externes,
> genaueres GPS).
> Optional mit Kamera.

Als Windows- und iPhoneverweigerer bin ich am ueberlegen ob ich
mir ein Nokia N900 zulege. Kamera, GPS & Co ist alles an Bord und
getrieben wird das Ding offensichtlich von einem recht
originalem Linux. 

Gruesse Hubert 

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Thu, 19 Nov 2009 20:54:01 +0100
> Von: "Nils Heuermann" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Relationen besser als Tags?


> einen prinzipiell fast identischen Ansatz (auch zu segmanted_ways) habe  
> ich mir in letzter Zeit ebenfalls erdacht. Schon interessant, dass dazu  
> "auf einmal" mehrere unabhängige Ideen entstehen.

Wobei ich bei dem einen Ansatz den Fokus darin sehe, dass
man die Fragmentierung entlang des Weges in den Griff 
bekommt und bei deinem Ansatz mehr die Querschnittsbeschreibung.

Aber die beiden Dinge sind schon verwandt zueinander.
 
> Meinen Ansatz habe ich im Wiki zusammengefasst:
> http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts

Genial, besonders die Idee mit dem Plugin. Was vielleicht
ein wenig untergeht ist die Sache mit der Bezugslinie.
Soweit ich das sehe, gehts du ja davon aus, dass die 
Basislinie als linke Seite der Richtungsfahrbahn angenommen wird,
richtig? Damit 'waechst' die Fahrbahn mit den unterschiedlichen
Spuren und Breiten in Fahrtrichtung rechts. Meiner Erfahrung
nach ist das auch die einzige Methode, das optisch richtig
hinzubekommen. 

Der kleine Haken dran ist, dass dann beruecksichtigt 
werden muss, auf welcher Seite gefahren wird. Hast du dein
Plugin schon mal in England getestet? 

Ich werde mich auf alle Fealle noch genauer mit deinem
Ansatz auseinandersetzen, denn es ist bisher das beste,
das ich zum Thema der Beschreibung von Strassenquerschnitten
bei OSM gesehen habe, besonders weil es sich auf
innerorts (Gruenstreifen, begleitende Wege) und ausserorts
(Autobahn, Abbiegespuren) gut anwenden laesst.

Gruesse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Leerstehende Ladenlokale

[qbert biker]

 Original-Nachricht 
> Datum: Mon, 16 Nov 2009 00:34:15 +0100
> Von: Garry 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Leerstehende Ladenlokale


> Es gibt Leute, die gehen nicht ohne Not zum Makler um ihm das Geld in 
> den Rachen zu werfen.
> Und warum soll nicht jemand auch OM zu Hilfe nehmen können wenn er bei 
> Gelegenheit in einen
> seinen Bedürfnissen besser entprechenden Verkaufsraum wechseln möchte?
> OSM wäre dazu auch eine zentrale Anlaufstelle während  es 
> Immobilienportale und  Makler  "tausende "
> gibt.

Absolut richtig, solche Anwendungen sind es, die aus einer
simplen Datanbank den Mehrwert rausholen. 

Aber wie schon bei den Weihnachtsmaerkten entwickelt sich die
Diskussion in eine eigenartige Richtung. Loeschen oder nicht
loeschen ist doch nicht die Frage, sondern wie man das
alles so strukturiert, dass man an die Infos auch noch 
rankommt.

Ein potentieller Wohnungssuchender hat wenig von einer DB,
in der die Info die er sucht, in staendig wechselnden 
Tags versteckt ist und wer nicht gerade nach der Wohnung 
sucht, den interessiert die Info nicht. Das schreit doch
gerade nach Datenoverlays. Relativ statische Daten in die
Basis-DB und temporaere Sonderfaelle in einen Overlay, der
sich bei der Ortung auf OSM-Basisdaten bezieht.

Es ist jedenfalls von Vorteil, wenn man sich OSM-intern
mal drueber gedanken macht. Denn ein Externer, der OSM 
fuer ein Immoportal nutzen will, braucht die Community nicht
und es ist dann fraglich, ob in dem Fall etwas zurueckfliesst.
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] OpenSeaMap auf der "boot" in Düsse ldorf

[qbert biker]

 Original-Nachricht 
> Datum: Wed, 11 Nov 2009 11:26:27 +0100
> Von: Frederik Ramm 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] OpenSeaMap auf der "boot" in Düsseldorf

Hallo,

> Eigentlich will OpenSeaMap am liebsten 
> eien Reihe internationaler Standards auf OSM abbilden - so etwas haben 
> wir noch nie gemacht und es ist total OSM-untypisch; 

Bzw. eine kleine Minderheit wettert sehr lautstark gegen 
jede Standardisierung und Konsensbildung und legt fest, 
was die OSM-Prinzipien zu sein haben.

> bei OSM wird 
> normalerweise immer das Rad neu erfunden. 

Das stimmt, immer wieder neu und parallel und keiner kommt
auf die Idee, an den vier Ecken aehnliche Raeder 
anzuschrauben. Man hat ja mittlerweile das Rad viermal
neu erfunden also soll auch bitte von jeder Sorte eines
ran ;)

Gruesse Hubert

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Mon, 9 Nov 2009 19:20:48 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Relationen besser als Tags?


> es gibt ja auch den Fall, dass oben mehrere Ways laufen, da waere es
> schoen,
> diese unterscheiden zu koennen in mehrere parallele Bruecken und mehrere
> Ways ueber eine gemeinsame Bruecke. Ich zeichne derzeit (vereinzelt) den
> Brueckenumriss und tagge das mit bridge=area.

Freilich gibts das alles, aber die Masse der Brücken folgt 
einfachen Regeln, die sich automatisieren lassen sollten. So eine 
Vorgabe kann man automatisch rechnen und wenns mal nicht ins 
Schema passt, löst man die Automatik auf und verbessert manuell,
um auch noch die letzten Exoten abzubilden.

Wenn z.B. 90% aller Strassenbrücken symmetrisch sind, kann das 
für diese 90% der Rechner viel exakter berechnen als ich das je
mit josm und geübten Auge hinbekommen würde.

Ein (GPL-lizensierter-) Editor ist in Arbeit, aber bei 
max. 0.5h/Tag Zeit dafuer gehts eben nur langsam voran. 

Gruesse Hubert 
-- 
DSL-Preisknaller: DSL Komplettpakete von GMX schon für 
16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 07 Nov 2009 19:52:27 +0100
> Von: Tirkon 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Relationen besser als Tags?


> Voraussetzung dafür ist natürlich eine sehr breite Zustimmung für ein
> neues Konzept innerhalb der Community. 

Oder eben man macht einen begrenzten Feldtest mit einem eigenen
Datensatz an dem man die Vorteile demonstrieren kann.
 
> So könnte das Umdenken der User so langsam wie erforderlich
> stattfinden und mögliche Konzeptkorrekturen am lebenden Modell erprobt
> werden. Ich denke aber mal, dass ein gutes Konzept, das dem User als
> auch dem Programmierer der Anwendungen von vielen Beschwerlichkeiten
> und Begrenzungen eines alten Konzeptes befreit und zudem
> durchsichtiger ist, dem neuen OSM die User in Scharen zutreiben würde.
> Wenn dann OSM 1.0 verwaist, dann wird die Umschaltung auf OSM 2.0
> schneller erfolgen, als mancher zu träumen gewagt hätte.

So sehe ich auch meine eigenen Arbeiten - Brainstorming für 
eine mögliche 2.0 oder irgendeine Mischform. Derzeit teste ich
mit einem Geometrielayer rum, der über das Knoten-Link-Konzept
noch hinausgeht. Ich will keine Brüecken mehr mit zig 
Einzelelementen abbilden, sondern als Objekt in Abhängigkeit
einer Kreuzung zweier Geometrieelemente. Was oben ist und was
unten und die Breite der Brücke (ein bool und ein real) reichen 
zur Beschreibung, alles andere ist geometrisch bestimmt, 
zumindest in guter Annäherung. Mal schaun obs klappt.

Gruesse Hubert

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Relationen besser als Tags?

[qbert biker]

 Original-Nachricht 
> Datum: Sat, 07 Nov 2009 14:32:00 +0100
> Von: Tirkon 
> An: talk-de@openstreetmap.org
> Betreff: [Talk-de] Relationen besser als Tags?

Hallo
 
> Man mappt die Straßen zunächst einmal als Grundgerüst. Jede Straße
> verläuft grundsätzlich ungeteilt zwischen den zwei nächsten
> Abzweigungen (bzw Kreuzungen). Eine Teilung der Straße ist also nur
> noch möglich, wenn eine neue Abzweigung eingefügt wird. Ansonsten ist
> eine Straße unteilbar. Die Straßen erhalten grundsätzlich keine Tags.

Entspricht der gaengigen graphenorientierten Abbildung, die
sich anderswo sehr bewaehrt hat. Ein Strassen- oder Wegstueck ist 
dabei die Verbindung zwischen zwei Netzknoten. Es bleibt das
Problem der Fragmentierung, wenn sich wichtige Eigenschaften
innerhalb einer Verbindung ändern. 

Damals vor API 0.5 habe ich das Konzept von Segment/Way 
mal als Lösungsansatz gesehen, aber das Problem der Fragmentierung
wurde damit ebensowenig gelöst wie mit der heutigen Abbildung.
Im Prinzip hat man den damaligen Fehler nur eine Stufe weiter
geschoben und der war schon immer, dass alles Attribute haben
kann, die auch konkurrieren können. Damals warens Segment und way
und heute sinds way und relation (und die node-Attribute wurschteln
ja auch noch mit rein).

Deshalb finfde ich deinen eigenschaftsorientierten Ansatz 
absolut klasse, denn Attribute werden immer komplexer und
es sollten auch Attributsgruppen- und Bäume möglich sein. 

> Von hier bis dort heißt die Straße XY-Straße.

Also Relationen die sich entweder auf ein Stück einer 
Verbindung beziehen oder Verbindungen verknüpfen (aktuell
die einzige Möglichkeit) oder Verbindungsstücke verknüpfen -
klingt gut.

> 1) Funktioniert das Eigenschaftskonzept grundsätzlich?

Davon kann man wohl ausgehen, aber die Sache hat einen Haken.
Das Konzept ist sehr mächtig, mächtiger als die aktuellen
Relationen. Ohne eine Richtschnur, die vorgibt, wohin man 
eigentlich will, läuft das Konzept Gefahr, die alten Fehler 
nochmal zu wiederholen und ein noch schlimmeres Dickicht zu
schaffen. 

Gruesse Hubert

-- 
DSL-Preisknaller: DSL Komplettpakete von GMX schon für 
16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] Relevanzregeln für OpenStreetMap?

[qbert biker]

 Original-Nachricht 
> Datum: Mon, 9 Nov 2009 15:02:41 + (UTC)
> Von: Sven Geggus 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Relevanzregeln für OpenStreetMap?

> Nop  wrote:
> 
> > Zu guter letzt haben wir es bisher nicht geschafft, uns auf das Tagging
> > von Basiselementen wie Radwegen zu einigen, da möchte ich nicht wirklch
> > versuchen einen Konsens für Relevanzregeln auszudiskutieren. :-)
> 
> Ich halte eine solche Diskussion für Unfug, weil das Problem bei OSM so
> nicht existiert.

Na ja, Definitionssache ;)

Sobald man in die Anwendungsebene wechselt, steht man exakt vor
dem Problem, was man als relevant auswertet. Es ist ja heute 
schon faktisch unmoeglich, alles in der Form auszuwerten, in der
es mal vorgesehen war, da die Selbstreinigungskraft der DB 
dafuer nicht ausreicht.

Die reale Relevanz besteht also auch darin, ob meine Eintragungen 
von allen Applikationen, von wenigen oder von keinen ausgewertet
werden...


-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?

[qbert biker]

 Original-Nachricht 
> Datum: Sun, 08 Nov 2009 10:37:23 +0100
> Von: Frederik Ramm 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?


> Angenommen, der Reiseveranstalter "Sunny Travel" hat fuer alle Hotels in 
> seinem Katalog eine interne Hotel-Id. Um die nun huebsch auf einer 
> OSM-Karte eintragen zu koennen, versieht er die betr. Hotels in OSM mit 
> dem Tag "sunny_travel:id=1234".
> 
> Grundsaetzlich ist das zwar von der "Tag-Freiheit" gedeckt, aber man 
> kann sich leicht ausmalen, dass das nicht skaliert und das OSM hier 
> unter der Faulheit oder Unfaehigkeit des Anbieters leidet, die Sache 
> besser zu organisieren.
> 
> Ich neige dazu, zu fordern, dass alle Information in OSM zumindest 
> theoretisch fuer jeden Menschen verstaendlich und nuetzlich sein muss. 
> Andererseits waere u.U. selbst die Information, dass ein bestimmtes 
> Hotel by "Sunny Travel" die ID 1234 hat, fuer mich nuetzlich, koennte 
> sie doch eventuell eine Buchungsanfrage vereinfachen...


Also das vom grossen Verteidiger des regellosen Eintragens noch
lesen zu dürfen ;)

Genau auf das wollte ich doch immer raus und habe dafür nicht gerade
nette Kommentare geerntet. Jeder kann zwar 'stone in my shoe'
eintragen, aber es bleibt für alle anderen eine Dateileiche.

Damit die Informationen fuer jeden verstaendlich und nützlich sein
können, ginbts aber nur zwei Wege. Entweder schreibt man Prosa rein,
so dass die Kommunikation über die normale Sprache geht oder man
entwickelt eine gemeinsame Sprache für die Inhalte, also ein
Beschreibungsmodell. Mit deinen Aussagen wie 'niemand bei OSM will
ein Modell entwicklen' und Forderungen nach der Abschaffung oder
Entmachtung des Wikis, gehen die Forderungen nach Verständlichkeit
und Nützlichkeit nicht gut zusammen.

Wenn ich kein Nachschlagewerk für die Bedeutung habe, muss ich mir
selber ausmalen, was gemeint sein könnte und zumindest aus meiner
Sicht bleiben dann Verständlichkeit und Nützlichkeit auf der Strecke.
Tagnamen alleine sind nicht sprechend genug. 

Grüsse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

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

Re: [Talk-de] Strassenklassifizierung

[qbert biker]

 Original-Nachricht 
> Datum: Fri, 6 Nov 2009 09:03:34 +0100 (CET)
> Von: "Dirk Stöcker" 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Strassenklassifizierung

 
> Die Frage ist, was die Highway-Klassifizierung sein soll. 

*seufz* Was von Anfang an das Problem war. Niemand weiss,
was es sein soll und jeder interpretiert munter rein.
Dass die meisten die Bedeutung reininterpretieren sah man
letztens bei der Abstimmung recht gut und man sieht es 
auch in der Karte. 

> Dein Gegenüber 
> sucht eine 1:1-Umsetzung der englischen Verhältnisse. Das geht nicht.

Was genau geht nicht? Sind die engl. Verwaltungsklassen
wirklich so aussagekraeftig, dass man sie blind anwenden
kann oder gibts auch auf der Insel Konflikte wie wir sie
hier haben?

> Ich
> habe eine Klassifizierung in Deutschland gesucht, die dem Original 
> entspricht, intuitiv ist und der gelebten Kartenrealität entsprach. 
> Diese
> nutzt JOSM jetzt.

Die gelebte Kartenrealitaet ist, dass es keinen Sinn macht,
sich gross gedanken drueber zu machen, was man wie eintragen
soll. Der naechste interpretiert was anderes rein, nutzt
einen anderen Editor oder was auch immer der Grund ist, dass
er die Klasse aendert. Egal, wer sich wenig Muehe bei den 
Klassen gibt und sich nicht daran stoert, dass die Karte 
nicht die vor Ort wahrgenommene Realitaet wiedergibt, hats 
bei OSM leichter. 

Strassen, die ich mal eingetragen habe, kann jedenfalls 
jeder aendern, wie er lustig ist. Ich werde da weder
nacheditieren, noch Kontakt aufnehmen. Warum auch? Bei OSM
ist laut Definition ja immer alles richtig ;)

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Strassenklassifizierung

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 3 Nov 2009 16:34:38 +0100
> Von: Falk Zscheile 
> An: m...@koppenhoefer.com, Openstreetmap allgemeines in Deutsch 
> 
> Betreff: Re: [Talk-de] Strassenklassifizierung


> Was mich stört ist die Darstellung der Verwaltungsklasseneinteilung.
> Liest man den einen oder anderen Beitrag so scheint es die Einteilung
> in die Verwaltungsklassen (Bundesstraße, Landes-/Staatsstraße,
> Kreisstraße, Ortsverbindungsstraße) sei eine vom Himmel herabgefallene
> Entscheidung ohne jeden Bezug zur Realität. 

Was wohl eher der Laenge der Diskussion geschuldet ist als 
der tatsaechlichen Aussage. Den Zusammenhang zwischen 
Verwaltungsklasse, Bedeutung und Ausbau bestreitet ja so gut
wie keiner. Es geht eher darum, wie man vorgehen soll, wenn
die mal auseinanderdriften und es passiert eben oft genug,
dass man sich bei der von den Verwaltungsklassen vorgegebenen
Wegfuehrung den Kopf kratzt.

> Tatsache ist aber, dass
> zwischen der Einteilung in eine Straßenklasse und dem
> Verkehrsaufkommen ein enger Zusammenhang besteht. Auf einer Straße die
> dem weiträumigen Verkehr dient (Bundes- oder Landes-/Staatsstraße)
> herrscht in der Regel ein höheres Verkehrsaufkommen  als auf Straßen
> die dem Verkehr zwischen Kreisen oder aber nur Gemeinden dienen. Bund
> und Länder achten sehr genau auf die Verkehrsbedeutung (Verkehr und
> Ausbauzustand). Verliert eine Straße ihre Bedeutung so kann man sie
> herabstufen und ein anderer Straßenbaulastträger muss sich um die
> Unterhaltung kümmern. Das schont den Haushalt des bisherigen
> Baulastträgers.

Reiche Kommunen wollen aber nicht immer warten und 
uebernehmen die Bautraegerschaft fuer eine Entlastungsstrasse
oder eine alte Staatsstrasse gammelt vor sich hin, weil ihr
eine Bundesstrasse die Bedeutung geraubt hat. Es ist eben
nur eine typische Zuordnung aber keine absolute.

> Nur den Verkehr in  Ballungsräumen und Städten bilden die eben
> aufgezeigten Definitionen nicht ab, weil hier das hohe
> Verkehrsaufkommen nur lokal zu bewältigen ist. Nur in diesem Bereich
> ist also eine zusätzliche Attributierung oder eine Loslösung von einer
> Eintragung nach Verwaltungsklasse geboten. 

Es gibt auch auf dem Land genug Beispiele für Verschiebungen.
Bei Bundesstrassen funktionierts ja noch, aber Staats- und
Kreisstrassen driften oft gewaltig. Scheinbar ists nur wirklich
lukrativ, dem Bund die Kosten zuzuschieben. 

> Die meisten Mapper wohnen
> in Städten und Ballungsräumen. Das darf aber nicht dazu führen dort
> auftretende Probleme auch auf ländliche Regionen zu beziehen und
> Lösungen auch auf diese zu verallgemeinern.

Innerhalb der Stadtgrenzen sind normalerweise nur noch 
Bundesstrassen sichtbar und das auch nur, weil die an
Vorfahrtsschildern und Wegweisern herausgehoben beschildert
sind. 'secondary', 'tertiary' und 'unclassified/residential'
werden da ja schon lang anhand der Bedeutung eingetragen.
Aber auf dem Land aergerts mich eben, dass ich weder die
kreuzungsfrei (1 Spur/Richtung) ausgebaute Kreisstrasse 
gut beschreiben kann, noch die total heruntergekommene
Staatsstrasse mit rein lokaler Verkehrsbedeutung. Und über
solche Relikte stolpere ich auf dem Land nur zu oft.

Gruesse Hubert
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Back to the roots? war: Semikolon als Trenner

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 3 Nov 2009 14:42:16 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Back to the roots? war: Semikolon als Trenner

> darum gings hier ja: Gebäudeebene. Randbemerkung: Wenn Du Dich auf
> Sketchup
> beziehst: das hat eher den Fokus einfach als mächtig. Im 3D-Bereich ist
> die
> meiste Software mächtiger als Sketchup, aber es hat halt den Vorteil,
> dass
> man mit wenig Einarbeitungszeit schon was zu Stande bringen kann, und dass
> es ohne Ende kostenlose Modelle (Ausstattung, Personen, Pflanzen, etc.)
> dafür gibt. Professionelle 3D-Software erfordert ansonsten meist monate-
> bis
> jahrelanges Erlernen.

Professionelle 3D-SW ist auch nicht gefragt, denn es geht ja 
um sinnvolle Vereinfachung und normale User als Eintragende.
 
> ja, das Problem der verschiedenen Stockwerke bleibt daher auch ungelöst.

Wenn man ein Problem darin sieht. Die Adresse ist eben und
passt gut ins Konzept einer 2D Erfassung. Das Konzept: Hier
ist das Gebaeude, das hat eine Adresse und darauf beziehen 
sich alle POIs darin ist ja nicht unpraktisch fuer Eintragende
und Nutzer. Dahinter kann man ja einen unformatierten 
beschreibenden Text setzen, so wie der aufpoppt wenn man
bei Google einen POI anklickt. Dann kommt eben "Arztpraxis
Dr. Wimmermeier 2. Stock links" im Klartext. 
 
> tun sie ja, in der Höhe.

Sind aber bestimmt ueber lat/lon und nicht ueber die Hoehe,
das finden manche Leute ziemlich verwirrend und unlogisch,
z.B. ich ;) 

> > Und wer bestimmt, ob er jetzt berechtigt oder unberechtigt
> > meckert?
> 
> der Mapper.

Und wenn der das gar nicht will, sondern sich vom Validator
eine Hilfestellung erhofft?

Gruesse Hubert

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Back to the roots? war: Semikolon als Trenner

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 3 Nov 2009 13:43:58 +0100
> Von: Martin Koppenhoefer 
> An: qbert biker 
> CC: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Back to the roots? war: Semikolon als Trenner

nochn Versuch...

> > Nur mal so als Frage: Denkt eigentlich einer von euch noch
> > an den armen Mappinganfaenger, der das alles verstehen soll?
> >
> > Letztens gabs ja die Diskussion, warum andere mehr POIs haben
> > und OSM da nicht ganz so gut in die Puschen kommt. Wer hier
> > und bei anderen aehnlichen Diskussionen mitliest, ist doch
> > wohl eher verunsichert als alles andere.
>
>
> hm, das ist doch eher ein seltenes Problem, dass man mehrere POIs für
> verschiedene Stockwerke hat, und das ist auch bei Google und anderen ein
> Problem: 3D-Daten in 2D-Darstellung. Darauf habe ich geantwortet.

Es gab mal einen ausfuehrlichen Beitrag ueber den oeffentlichen
3D Modellierer bei Google in der c't. Das ist ein sehr
maechtiges Werkzeug und es arbeitet in echtem 3D und versucht
nicht, 3D mit einem 2D Werkzeug in den Griff zu bekommen.
Aber das ist die Gebaeudeebene.

Bisher habe ich keine Anhaltspunkte gefunden, dass Google die
3D Konstruktion mit den POIs verknuepft, sondern es sieht eher
nach einer Abstraktion ueber die Adressen aus.

> unerheblich, sehr nahe beieinander ist wohl einfacher zu editieren und
> sonst
> wird vermutlich die eine oder andere Applikation wegen doppeltem Node
> meckern.

Das Problem dabei ist, dass man normalerweise bei zwei Nodes
zwei Objekte erwartet, die sich oertlich (lat,lon) voneinander
unterscheiden und auch unterscheidbar sind. Ab welcher Neahe
soll ich sie als ein Objekt mit verschiedenen Leveln (und
Pseudokoordinaten?) betrachten oder brauche ich eine Relation,
die mir erklaert, dass die zwei Punkte in Wirklichkeit nur
einer sind, weils in die dritte Dimension geht?
 
> unerheblich, der meckert auch so öfters mal, ohne dass es stimmt.

Und wer bestimmt, ob er jetzt berechtigt oder unberechtigt
meckert?

Aber egal, ich wollte nur zum Ausdruck bringen, dass Dinge,
die feur die einen ganz einfach und logisch erscheinen, andere
ganz locker zur Verzweiflung bringen koennen. Fuer
anwenderfreundlich halte ich aber keines der hier
diskutierten Konstrukte.

Gruesse Hubert



-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

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

Re: [Talk-de] Back to the roots? war: Semikolon als Trenner

[qbert biker]

Der wollte mich doch nur aergern ("glaubt zu wissen") ;)



-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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

Re: [Talk-de] Back to the roots? war: Semikolon als Trenner

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 3 Nov 2009 00:24:24 +0100
> Von: Martin Koppenhoefer 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)

> Am 3. November 2009 00:11 schrieb Florian Gross :
> 
> >
> > Und was macht man dann, wenn es im Stockwerk darüber ein
> Bastelgeschäft
> > ist und darüber noch eine Pizzeria?
> >
> 
> in diesem Fall definitiv verschiedene Nodes, da ja auch die Layer-Tags
> unterschiedlich sind (so wie alle anderen Tags auch). Falls sich Deine
> Frage
> auf die Adresstags bezieht: sauber wäre wohl eine Relationslösung, wo
> man
> diese gemeinsamen Tags als "Haus" zusammenfasst und nur der Relation
> mitgibt, gehackt könnte man wohl auch jedem der Nodes (oder Polygone) die
> kompletten Adressdaten mitgeben, zur Unterscheidung ggf. mit einem Tag
> für
> das Stockwerk.

Nur mal so als Frage: Denkt eigentlich einer von euch noch
an den armen Mappinganfaenger, der das alles verstehen soll? 

Letztens gabs ja die Diskussion, warum andere mehr POIs haben
und OSM da nicht ganz so gut in die Puschen kommt. Wer hier
und bei anderen aehnlichen Diskussionen mitliest, ist doch
wohl eher verunsichert als alles andere. Bei aller Liebe
zur Detailversessenheit - die Mapper muessen begreifen koennen,
was sie machen koennen und machen sollen. Gerade POIs koennen
gut von Gelegenheitsmappern kommen, denn die uebliche
Vorstellung davon ist, dass es ein einfacher Ort ist, den
man mit einer Node abbilden kann. Da ist etwas und das ist
genau dort, Punkt.

Also zwei, drei, oder mehr Nodes fuer einen Ort (lat,lon),
die dann die Hoehe (=Stockwerk) beschreiben? Am gleichen Ort
oder nur nahe beieinander? Wie nahe und meckert da dann der 
Validator? Mehrere Nodes fuer mehrere Funktionen an einem Ort?

Nicht nur die Auswertung ueber die Maschinen wird da zum 
Problem, sondern auch die Verwirrung bei den potentiellen
Mappern, die dann vielleicht lieber garnix eintragen, bevor 
sie sich mit diesem Dickicht auseinandersetzen.

Nur so meine Gedanken beim Durchlesen des Threads

Gruesse Hubert
-- 
DSL-Preisknaller: DSL Komplettpakete schon für 16,99 Euro mtl.!*
http://portal.gmx.net/de/go/dsl02

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

Re: [Talk-de] Strassenklassifizierung

[qbert biker]

 Original-Nachricht 
> Datum: Tue, 3 Nov 2009 08:41:06 +0100
> Von: Martin Simon 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Strassenklassifizierung


> Loswerden muss man es ja nicht komplett, aber eine gewisse
> "Demokratisierung" oder "Entmachtung" des verwirrten Königs Highway der
> XIII. wäre schon wünschenswert. ;-)

Runter mit dem Kopf! ;)
 
> Tumulte in der "das sieht in Mapnik nicht richtig aus"-Fraktion. Teilweise
> könnte ich das auch nachvollziehen - man müsste halt sicherstellen, daß
> die
> Verbindungsklasse angemessen berücksichtigt wird und trotzdem in der
> Übergangszeit das Rendering von highway=* ohne connection_level=* nicht
> vollkommen "kaputt" ist - obwohl wir nicht für den Renderer mappen ;-)

Einfache Regel: Wenn connection_level nicht vorhanden ist, wird
highway wie bisher verwendet. Ich sehe auch keinen zwingenden
Grund, connection_level flaechendeckend einzufuehren. Er wird ja
hauptsaechlich dann gebraucht, wenn highway nicht konfliktfrei
vergeben werden kann. Also die alte unwichtige Staatsstrasse
bleibt z.B. bei highway=secondary, aber bekommt die 
Verbindungsklasse tertiary oder unclassified, bzw. einem
Ersatz dafuer (unclassified passt als Beschreibung zu 
untergeordneter Verbindung eher schlecht) 

Wie siehts eigentlich mit dem neuen deutschen (na ja, besser 
Festlandseuropaeischen) Mappingstil aus? Der waere doch eine 
ideale Spielwiese fuer sowas.  

> Nun ja, wenn die Darstellung plötzlich in der Gesamten Welt bescheiden
> ist,
> außer in einem "kleinen germanischen Dorf, das tapfer die Renderregeln
> umgekrempelt hat", dürfte es schwierig sein, die Leute *nicht* gegen sich
> aufzubringen... ;-)

Ein weicher Uebergang, der ohne das Aufmischen von Roemischen
Legionen auskommt, sollte moeglich sein.

Gruesse Hubert

PS. Bin noch nicht dazu gekommen, mich um die Wikiseite
zu kuemmern, aber ich habs nicht vergessen.

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

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