from:"André Reichelt"

Hallo,
ich sehe das Problem eher darin begründet, dass unsere Editoren nicht
besonders gut für den Einsatz mehrerer Tags optimiert sind. Man müsste
bei diesen Namensraumkonstruktionen mit dem Doppelpunkt dazu übergehen,
mehrere Tags gleichen Namensraumes in der Software zusammenzuziehen und
aufklappbar zu machen.

Wenn es zu viele Tags werden kann es doch nicht ernsthaft die Lösung
sein zu sagen, wir erlauben diese nicht mehr oder nur noch unter
bestimmten Bedingungen. Das ist doch Käse!

Als weiteren Schritt sollten wir uns überlegen eine Möglichkeit zu
schaffen, bestimmte Tags komplett ausblenden zu lassen. Wer sagt denn,
dass TMC-Tags überhaupt angezeigt werden müssen? Es muss ein Schalter im
Optionsdialog her, mit dem man komplette Namensräume direkt wegblenden
kann. Tags wie TMC dürfen auch gerne von Hause aus ausgeblendet sein, da
nur die Wenigsten an diesen Tags Änderungen vornehmen werden und dann
eine manuelle Aktivierung einfacher ist.

Sollte ein Objekt mit versteckten Tags verändert oder gelöscht werden
müsste der User über eine Warnmeldung darauf hingewiesen werden. Das ist
aber, denke ich, obligatorisch.

Im Übrigen sollten im selben Zuge auch direkt ein System implementieren,
mit denen man als historic getaggte Objekte direkt ausblenden kann,
sodass diese den Mapper nicht mehr stören. Im nächsten Schritt muss es
dann auch möglich sein ganze Taggruppen auszublenden, da es im
innerstädtischen Bereich mitunter schon recht unübersichtlich wird.

Jedenfalls ist das Löschen der TMC-Tags für mich *keine* Lösung, zumal
diese, wie ja hier mehrfach gut begründet wurde, eine außerordentliche
Relevanz haben.


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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm:
 Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt 
 hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade 
 machen willst, kann Folgen haben, die Du nicht verstehst und die wir 
 hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des 
 Problems.

Das wird sich aber auch nicht durch eine ID in eine externe Datenbank
lösen lassen, da auch hier der User zunächst überprüfen muss, was das
Tag bedeutet und wie er hier vorgehen muss. Also bringt uns auch die
Geforderte ID in eine externe Datenbank keinen Schritt weiter.

Außerdem haben wir bereits festgestellt, dass man von einer anderen
Datenbank nicht in die OSM-Datenbank linken kann, da hier die Gefahr
groß ist, dass irgendwer ein paar Nodes/Wege löscht und dadurch die
externe Datenbank ständig korrigiert werden müsste.

Wir stehen hier meiner Meinung nach vor einem schwerwiegenden Problem,
für das wir gegenwärtig keine Lösung parat haben. Nun einfach ohne
Rücksicht auf Verluste zu fordern all diese Tags wieder zu löschen wäre
falsch und destruktiv.

 Es mag sein, dass es manchmal einfach nicht anders geht, und dann kann 
 man mal einen Kompromiss machen, aber es sollte wenigstens klar sein, 
 *dass* solche Tags schaedlich sind und dass man, wenn es irgend geht, an 
 ihrer Vermeidung arbeiten sollte statt an ihrer Vermehrung.

Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten
belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft
vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal
ist.

Wir stehen nun also an dem Punkt, an dem wir dazu angehalten sind eine
*bessere* Lösung zu finden. Dieses Ziel werden wir nicht erreichen,
indem wir hier in Wikipedia-Manier irgendwelchen relevanzkriterien-
ähnlichen Mist veranstalten.

Ich möchte das Problem noch einmal allgemein gefasst darstellen:
Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden
werden soll. Eine direkte Verbindung mit der OSM-ID des Objektes nicht
nicht möglich, da es in der OSM-Datenbank keinen »Fertig«-Zustand gibt,
der ein Löschen oder Verändern des Objektes dauerhaft ausschließt. Daher
muss ein Weg gefunden werden unabhängig von zukünftigen Änderungen an
der OSM-Datenbasis zuverlässig eine Verknüpfung von OSM-Daten mit einer
externen Datenquelle zu gewährleisten.

Ich behaupte, dass wir hier von einem komplexeren Problem sprechen, dass
sich durch blinden Aktionismus nicht lösen lässt. Bevor jedoch keine
zuverlässige und stabile, weniger »schädliche« Lösung gefunden ist kommt
eine Löschung der TMC-Daten nicht in Frage, da dadurch die
Datennutzbarkeit in erheblichem Umfang eingeschränkt wird.

Gruß
André



*Anhang:* Meine Idee für einen Lösungsansatz

Ein Lösungsansatz könnte es sein, nicht nur auf das Objekt in der OSM-DB
selbst zu verweisen sondern zusätzlich auf den Revisionsstand. Auch hier
könnte es allerdings zu konflikten mit zukünftigen Änderungen kommen.
Von unserer Seite aus müsste bei diesem Ansatz also ein System
geschaffen werden dass zwar die Datenbasis *möglichst* aktuell zur
Verfügung stellt. Wird jedoch in der Dump-Abfrage ein Objekt mit
Revision abgefragt muss die Blackbox in der Lage sein alle involvierten
zukünftigen Änderungssätze zu ermitteln, dort eventuelle Konflikte
feststellen und die betroffenen Daten vor der Ausgabe auf einen
konsistenten Revisionsstand zurücksetzen.

Als Zwischen-/Notlösung könnte man sich auch vorstellen, dass einfach
nur eine Liste von Objekten und deren Revisionsstand an die Blackbox
übergeben wird. Diese gibt dann für jedes Objekt zurück, ob es
mittlerweile einen neuen Revisionsstand hat. Diese Lösung hat allerdings
den Nachteil, dass ich als Betreiber der externen Datenquelle, die in
OSM linkt zunächst meinen Datensatz überprüfen muss und im Konfliktfall
meine Verknüpfungen zu korrigieren habe.


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

[Talk-de] Fehlerkorrektur in Crailsheim

Hallo zusammen,
ich habe vor einigen Wochen das alte Residental-Area auf Landsat-Basis
um Crailsheim herum mit mehr Details versehen und auf einen Stadtteil
verkleinert. Den anderen Stadtteilen habe ich neue Areas spendiert. Aus
irgend einem Grund wurde nun das veränderte Area zurückgesetzt.

Könnte bitte jemand dem nachgehen und wieder die neue Version
herstellen?

http://www.openstreetmap.org/browse/way/39696094

Das Are sollte eigentlich z.B. unten bündig mit den Gebäuden sein.

Gruß,
André


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

Re: [Talk-de] Fehlerkorrektur in Crailsheim

PS: Offenbar hat das nur wer verschoben, was man an noch nicht neu
gerenderten Kacheln sehr schön sehen kann:

http://www.bilder-space.de/show_img.php?img=c1bc4d-1296950851.pngsize=original

Kann das jemand zurücksetzen?


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

Re: [Talk-de] Fehlerkorrektur in Crailsheim

Am Samstag, den 05.02.2011, 16:27 -0800 schrieb Walter Nordmann:
 alle Änderungen seit Januar 2010 (zweitausend-zehn) wurden von dem User
 AndreR gemacht.
 
 Wer könnte das wohl sein?

Genau das ist ja das Seltsame an der Sache: Das Polygon wurde definitiv
erst in den letzten paar Tagen oder gar Stunden verschoben (wie man
zweifelsfrei an meinem Kartenausschnitt sehen kann).

Gibt es denn eine Möglichkeit, Daten »um ein Changeset herum« zu
manipulieren? Anders kann ich mir diesen Fehler nämlich nicht erklären.

Hat jemand eine Erklärung für dieses Phänomen?

Gruß,
André


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

Re: [Talk-de] Fehlerkorrektur in Crailsheim

Am Sonntag, den 06.02.2011, 03:02 +0100 schrieb Frederik Ramm:
 Und die Nodes scheinen mir allesamt am Freitag um 17:25 von einem 
 gewissen AndreR verschoben worden zu sein - mit dem Changeset-Kommentar 
 Turn Restriction ;)

Danke Euch beiden.

Ich habe am Freitag mit Mapzen herumgespielt, da ich den
Turn-Restrictions-Editor ausprobieren wollte. Dabei habe ich wohl
versehentlich auch den Way verschoben.

Kann man die Verschiebung irgendwie rückgängig machen? Oder geht es
schneller, das Ding von Hand wieder hinzuschieben?


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

Re: [Talk-de] Fehlerkorrektur in Crailsheim

Am Sonntag, den 06.02.2011, 04:48 +0100 schrieb Michael Bemmerl:
 Ich hab' deine letzte Änderung an den Nodes des landuse-ways rückgängig
 gemacht. Auf der (bereits neugerenderten) Karte schaut es passend aus.

Vielen Dank, scheint zu passen!


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

Re: [Talk-de] Eintragung historischer Obejkte (was: Darstellung von landuse=military in Mapnik-Karte)

2011-01-29 Diskussionsfäden André Reichelt

Am Freitag, den 28.01.2011, 21:16 +0100 schrieb Christian H. Bruhn:
 Vielleicht sollte man einen Prefix für die Tags zur Beschreibung
 historischer Objekte verwenden. Also z.B. 'historic'. Dann hieße es
 nicht 'barrier=fence' sondern 'historic:barrier=fence'.

Dann sollte man allerdings auch noch angeen können von wann bis wann das
gegolten hat. Die Angabe historic alleine ist nicht viel Wert. War das
gestern oder vor 1000 Jahren?


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

Re: [Talk-de] Eintragung historischer Obejkte

2011-01-29 Diskussionsfäden André Reichelt

Am Samstag, den 29.01.2011, 02:26 +0100 schrieb M∡rtin Koppenhoefer:
 Im Ernst, ein gewesenes Militärgelände interessiert schon, aber Wald
 war früher überall mal, das wird kaum einer machen. Ackerflächen, die
 es nicht mehr gibt, wird man auch selten einzeichnen.

Genau so sehe ich das auch. Ob da früher ein Wald oder Feld war ist
relativ irrelevant. SO etwas wird mit Sicherheit nur an ausgewählten
Stellen Sinn ergeben, wo ein ehemaliges Waldstück vielleicht eine
berühmte Geschichte hat (was es wiederum zu einem historischen
Schauplatz macht).

Hingegen ist ein ehemaliges Militärgelände, dass auch noch heute fast
vollständig erhalten ist durchaus interessant zu erfassen.


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

Re: [Talk-de] Darstellung von landuse=military in Mapnik-Karte

2011-01-28 Diskussionsfäden André Reichelt

Mir ist noch ein anderes Defizit betreffend dem Rendering von
Militärarealen aufgefallen: Als aufgegeben markierte Militärareale
werden dennoch rot schraffiert.

Könnte das bitte behoben werden?

Siehe z.B. hier:
http://www.openstreetmap.org/?lat=49.13273lon=10.05143zoom=16layers=M

Danke,
André


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

Re: [Talk-de] Darstellung von landuse=military in Mapnik-Karte

2011-01-28 Diskussionsfäden André Reichelt

Am Freitag, den 28.01.2011, 17:51 +0100 schrieb M∡rtin Koppenhoefer:
 Am 28. Januar 2011 17:41 schrieb André Reichelt andr...@online.de:
  Mir ist noch ein anderes Defizit betreffend dem Rendering von
  Militärarealen aufgefallen: Als aufgegeben markierte Militärareale
  werden dennoch rot schraffiert.
 
  Könnte das bitte behoben werden?
 
  Siehe z.B. hier:
  http://www.openstreetmap.org/?lat=49.13273lon=10.05143zoom=16layers=M
 
 
 Taggingfehler (oder zumindest schreit es nach Missinterpretation), das
 ist immer noch als Militärareal gekennzeichnet. ;-)

Kannst Du das vielleicht ausformulieren?


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

[Talk-de] Eine Insel im Fluss [Reparaturanfrage]

2011-01-21 Diskussionsfäden André Reichelt

Hallo!
Könnte sich bitte jemand dieser Stelle hier zuwenden: Die Inseln werden
nicht gerendert obwohl ich nach meinem Kenntnisstand alles korrekt
gemacht habe. Dem Flusslauf nach Norden folgend ist noch so eine Insel.

http://www.openstreetmap.org/?lat=49.13586lon=10.06868zoom=17layers=M

Vielen Dank!

André


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

Re: [Talk-de] Straßen-Tags für Luftbildstraßen

2011-01-05 Diskussionsfäden André Reichelt

Am Sonntag, den 02.01.2011, 11:04 +0100 schrieb o...@tappenbeck.net:
 Wie denkt Ihr darüber und wie sollten Eurer Meinung nach die Ways aus 
 Luftbildaufnahmen gekennzeichnet werden um diese möglicht gut nutzen 
 zu können?

Ich verfahre da derzeit so, wie ich schon damals bei den Luftbildern aus
der Oberpfalz vorgegangen bin: Ich versuche aus den Informationen des
Bildes abzuleiten um welchen Straßentyp es sich wohl handelt und trage
diesen dann ein. Bin ich mir bei einer Strecke unschlüssig wähle ich
stets den am niedrigsten eingestuften Weg, der in Frage kommt.

Das Vorgehen hat mehrere Vorteile: Zunächst ist die Wahrscheinlichkeit,
dass eine Person über einen irrtümlich als Straße gekennzeichneten
Feldweg gejagt wird recht gering. Wichtig ist aber auch, dass die Router
die Leute an diese Straßen heranführen, was bei road bekanntlich aus
gutem Grund nicht passiert. Dadurch fallen die Fehler vor Ort auf uns
der Fehlgeleitete kann über Applikationen wie MapDust oder OSB dem
Fehler zügig an uns melden. Ich habe meine Region in einem Umkreis von
ca. 20 km abonniert und bessere offensichtliche Fehler dann zeitnah aus.

Ich bin nun schon seit einigen Jahren dabei und die Mapperlage hier in
meiner Gegend hat sich nicht gerade verbessert. Daher rechne ich auch in
mittelfristiger Zukunft nicht mit einem Schwall neuer Aktiver und nehme
daher alles selbst in die Hand.

Ein Netz aus Roads ist verschwendete Zeit, da diese hier in der Gegend
in den nächsten Monaten (und Jahren) sicherlich nicht verschwinden
würden. Wenn allerdings jemand falsch navigiert wird ist die
Wahrscheinlichkeit dass ein (unwahrscheinlicher) Fehler auffliegt
deutlich höher.

Ich denke, dass durch diese Strategie die besten Ergebnisse erzielt
werden können, da die Daten einerseits sofort brauchbar sind,
andererseits Fehler viel schneller auffallen.

Gruß,
André


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

[Talk-de] Externe Datenbank für Gebäudemodelle (was: Image of the week - kurios - nur russische Inf ormation)

2010-12-22 Diskussionsfäden André Reichelt

Am Mittwoch, den 22.12.2010, 09:25 +0100 schrieb Schorschi:
 Moin
 
 Hat jemand eine Ahnung, wie das mit den 3D-Gebäuden funktioniert, was zur 
 Zeit im Bild der Woche angepriesen wird? Es sieht ja gut aus, aber alle 
 weiteren Informationen scheinen nur auf russisch vorhanden zu sein. Wäre 
 das Bild der Woche mal nur mit einer Information auf deutsch erschienen, 
 die Reaktionen wären wohl ziemlich heftig ausgefallen ...

Hallo,
ich finde das Ganze ja schon spektakulär. Ich habe mir unterdessen die
englischsprachige Beschreibung von diesem Jongleur durchgelesen und
möchte noch meine Gedanken zu einer externen Datenbank los werden.

An sich halte ich ein dreigliedriges Vorgehen für sinnvoll. Die dort
vorgestellte Methode gefällt mir schon gut. Dumme renderer legen einfach
alle Flächen übereinander und kommen so auf die komplette grundfläche
des Gebäudes. Komplexere Renderer können diese Von-Bis-Werte verwenden
um ein abstrahiertes 3D-Modell zu erzeugen. Wir sollte die einzelnen
Ebenen aber auf jeden Fall in eine Relation packen um zu zeigen, dass es
sich hier um ein Teil handelt.

Im nächsten Schritt sollten wir aber irgendwo tatsächlich eine
hauseigene Datenbank hinterlegen, in die jeder nach bekannter Manier
Gebäudemodelle (auch mit Texturen) hochladen kann. Diese könnten dann
beispielsweise eine ID bekommen und werden dann über die Relation (oder
den Gebäudeumriss als Area, sofern keine Relation vorhanden) mit dieser
ID verlinkt.

Von der bisherigen Idee, die Daten einfach über einen externen Link über
HTTP einzubinden halte ich sehr wenig, da hier Virenschleudern usw. Tür
und Tor geöffnet wird. Außerdem kann es sein, dass personalisierte
Server ausfallen oder Daten plötzlich verschwinden. Insgesamt also kein
gutes Konzept für eine hohe Datenverfügbarkeit.

Einzig über das Datenformat müsste sich noch der Kopf zerbrochen werden.
Ich selbst bin eher für die Entwicklung eines eigenen Tools, da mir
bisher kein vernünftig bedienbares quelloffenes 3D-Programm einfällt.
Ich kenne nur Blender und sich darin einzuarbeiten halte ich für
unzumutbar, selbst für einen OSM-Experten, da die Hürde nochmal um den
Faktor Zehn höher ist als bei Josm (nach meinem Verständnis).

Mir schwebt ein Programm ähnlich Google Sketchup vor. Dabei soll es
irgendwo eine zentrale Texturendatenbank geben, in die man allgemeine
Texturen packen kann (z.B. »verputzte Wand« oder »Holzwand« oder
»U-Dachziegel«). Spezifische Texturen, welche z.B. über Photographien
gewonnen wurden, sollen dann aber in dem jeweiligen Gebäudemodell
gespeichert werden. Die Datenbanktexturen sollen dann über eine
individuelle Färbung überblendet werden können, sodass man mit wenig
Speicherverbrauch möglichst alle Standardfälle abdecken kann.

Die Texturendatenbank hat den Vorteil, dass Navihersteller jene
Datenbank bereits fest in die Software integrieren können. Dadurch sinkt
der Datenverkehr enorm und unsere Server werden entlastet.

Was haltet Ihr von der Idee? Sind natürlich nur alles grobe Skizzen,
aber an sich halte ich das für den besten Weg, um vom einfachsten
Renderer bis zur kompletten 3D-Umgebung alle zufriedenzustellen.

Gruß,
André


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

Re: [Talk-de] Externe Datenbank für Gebäudemodelle

2010-12-22 Diskussionsfäden André Reichelt

Am Mittwoch, den 22.12.2010, 18:31 +0100 schrieb Tobias Knerr:
 In der neuen Version soll Blender etwas zugänglicher sein. Habs aber
 noch nicht wieder ausprobiert.

Wie viel ist etwas? Bisher war das Programm ohne wochenlanges Studium
irgendwelcher Fachbücher völlig unbedienbar. Selbst nach einem halben
Jahr hat man noch das Gefühl gehabt, nicht angekommen zu sein. Etwas
ist hier also sehr dehnbar und klingt wenig verheißungsvoll. Des
Weiteren ist Blender für unsere Zwecke völlig überproportioniert und
volgestopft.

Wichtig ist mir, dass das Programm quelloffen ist. Dadurch fallen die
meisten Möglichkeiten kostenloser Programme (wie z.B. SketchUp) bereits
heraus. An brauchbarer Software bleibt nach meinem Kenntnisstand
eigentlich nur der Blender übrig, bei welchen die genannten
Einstiegshürden völlig unzumutbar sind (und ich übertreibe hier in
keinster Weise).

Gruß,
André


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

Re: [Talk-de] Externe Datenbank für Gebäudemodelle

2010-12-22 Diskussionsfäden André Reichelt

Am Mittwoch, den 22.12.2010, 18:35 +0100 schrieb Peter Wendorff:
 Von der Idee her finde ich das gar nicht so schlecht - abgesehen, wie 
 gesagt, von der zentralen Datenbank, bei der ich erstmal skeptisch bin.
 
 Das Ganze wird nicht meine Baustelle werden; eine Entlastung, was den 
 Missbrauch der Multilevel Building Shapes angeht, würde ich aber begrüßen.
 
 Gruß
 Peter (dieser Jongleur)

Hallo Peter,
mir war nicht klar, wer hinter dem Spitzname steckt. Jetzt weiß ich
es ;). Dass man Scripting in jenem Datenformat unterbinden kann ist
natürlich wahr.

Dennoch möchte ich mich als kommerzieller Verwender von OSM-Daten nicht
darauf verlassen müssen, dass tausende privater Server verfügbar sind.
Des weiteren wird es unzählige Mapper geben, die keinen eigenen
Datenspeicher auszuweisen haben. Sind diese vom Modellieren von Gebäude
ausgeschlossen oder müssen sie sich an andere Mapper mit Speicher
hängen? Wer wird, wenn die ganze Sache gewachsen ist den Datendschungel
noch durchblicken. Was passiert, wenn ein Server temporär über einen
längeren Zeitpunkt ausfällt. Wie können Benutzer Verbesserungen der
Gebäudemodelle beitragen, wenn ich doch keine Schreibrechte auf dem
Quellort besitze.

Das sind alles Fragen, die so eine dezentrale Speicherung mit sich
bringt. Alles in allem sehe ich hier nur Probleme und keine Lösungen.
Sinnvoll wäre jedoch die Überlegung, ob man nicht das Ganze weitläufiger
planen sollte. Man könnte es beispielsweise ermöglichen, dass bestimmte
räumlich abgegrenzte Areale oder der komplette Datenbestand auf privaten
Servern gespiegelt werden kann. Unser OSM-Server würde dann auf die
Anfrage nach dem Gebäudemodell XY in seiner Datenbank nachsehen, wo er
das Modell finden kann und dann einen Link zum Download zurücksenden.
Wichtig ist in dem Falle natürlich wieder, wie die Fremdquellen mit
aktualisierten Dateiversionen umgehen.

Jedenfalls hätte das Vorgehen den Vorteil, dass man einen
Speicherplatzanbieter, der Schindluder treibt, sehr leicht ausschließen
könnte. Trotzdem hätte man aber weniger Last am eigenen Server.

Zum jetztigen Zeitpunkt halte ich jedoch Diskussionen über die angelegte
Last für völlig übertrieben, da es noch keine Modelle gibt. Bis wir das
an den Servern wirklich sehen würden werden sicher noch Jahre ins Land
ziehen – und dann haben wir wieder ganz andere Kapazitäten.

Daher bin ich eher für eine vernünftige zentrale Datenhaltung als für
solch eine Fummelei mit einer unübersehbaren Zahl externer Links in der
Datenbank. Nicht zuletzt sollte man natürlich auch die
Datenschutzbedenken nicht vergessen, denn die Zugriffe auf jene URL
können geloggt und die IPs abgeglichen werden. Da bei einer späteren
Verwendung nur dort Daten geladen werden, wo man entlang fährt könnte
dies zu unerwünschten Erkenntnissen führen. Man könnte aus den
Datenzugriffen in Verbindung mit der IP sehr leicht ableitern wo entlang
sich eine Person bewegt und noch vieles mehr.

Im Übrigen finde ich die Idee, einzelne Punkte des Gebäudes an das
Modell zu binden (z.B. Türen) ebenfalls toll.

Gruß,
André


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

Re: [Talk-de] zeitweise was ausblenden

2010-12-19 Diskussionsfäden André Reichelt

Am Samstag, den 18.12.2010, 14:47 +0100 schrieb Frederik Ramm:
 Weil ich das gleiche Problem hatte, gibt es seit zwei Wochen oder so
 bei 
 den Darstellungs-Einstellungen auch ein Haekchen, mit dem man die 
 Flaechenfuellung komplett abschalten kann. 

Kann man dem Ganzen eventuell noch einen Meüeintrag (z.B. unterhalb von
»Drahtgitterdarstellung« und einen Shortcut spendieren?

Danke,
André


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

Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung

2010-12-13 Diskussionsfäden André Reichelt

Am 13.12.2010 16:34, schrieb Bernd Wurst:
 Ich fände es sinnvoll, wenn der Editor beim Changeset automatisch Tags 
 aufgrund der aktivierten Ebenen setzen würde, also welchen WMS ich benutzt 
 habe oder ob ich GPS-Tracks geladen/geöffnet habe.

Ich hänge den Source-Tag eigentlich nur noch an das jeweilige Changeset.
Ich stimme Dir vollumfänglich zu, dass das genannte Vorgehen eigentlich
nur dann sinnvoll ist, wenn man von sehr schlechtem Bildmaterial wie
Landsat abzeichnet.



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] josm 3695

2010-12-07 Diskussionsfäden André Reichelt

Am 07.12.2010 16:43, schrieb Wolfgang:
 Hallo,
 
 bin ich eigentlich der einzige, der Probleme damit hat? Josm lädt nur noch ab 
 und zu Daten hoch. Bricht man ab, kann man später alles manuell 
 synchronisieren, bricht man nicht ab, kommt er nicht weiter...
 
 Gruß, Wolfgang

Ich habe das Problem mit mit mehreren Versionen der letzten Tage und
Wochen und offenbar hat es sich bisher nicht gebessert. Du bist also auf
jeden Fall nicht alleine damit.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] josm 3695

2010-12-07 Diskussionsfäden André Reichelt

Am 07.12.2010 19:24, schrieb SLXViper:
 Dann macht doch bitte einer von euch ein Ticket auf
 josm.openstreetmap.de auf und postet dort, wie _ihr_ es reproduzieren
 könnt, falls möglich, oder wann es gehäuft auftritt. Und vergesst nicht,
 nützliche Details wie Betriebssystem/Version, betroffene
 Josm-Version(en), Java-Version, etc. zu erwähnen. So lässt sich das
 ganze deutlich einfacher verfolgen.

Das Ganze zu reprouzieren ist mir bisher noch nicht gelungen. Es scheint
völlig zufällig aufzutreten und auch ein Neustart hilft nicht weiter.
Ich dachte ursprünglich, die Datenbank lahmt mal wieder, aber nachdem
nun offenbar nur sehr wenige dieses Problem haben macht mich das doch
etwas stutzig. Ich werde mal ein Ticket aufmachen.

André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Tempolimit innerorts

2010-12-04 Diskussionsfäden André Reichelt

Hallo,
ich habe hier gerade wieder eine Fehlermeldung betreffend Tempolimit
innerorts 50 km/h bekommen. Soll man das denn explizit eintragen (und
die innerörtlichen Straßen abtrennen) oder soll das die Software und
anhand der Stadtgrenzen vorgehen?

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Lizenzwechsel: Liste der bisherigen Zustimmungen veroeffentlicht

2010-10-10 Diskussionsfäden André Reichelt

Ich hätte ja nicht im Ansatz geglaubt, dass ich so weit oben in der
Liste auftauche. Das ist ja erstaunlich. 0,05 % des Datenbestandes sind
also von mir… Wow! Und das ganz ohne irgendwelche Bots!

Nochmals mein Appell: Ich war lange Zeit gegen die neue Lizenz, aber ich
möchte auf keinen Fall, dass wir auseinanderreißen, denn davon hat
keiner was. Daher habe ich auch der neuen Lizenz unterdessen zugestimmt
und bitte auch alle Anderen, dies zu machen.

Gruß,
André


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Werden Baumreihen gerendert?

2010-09-05 Diskussionsfäden André Reichelt

Am Samstag, den 04.09.2010, 20:25 +0200 schrieb M∡rtin Koppenhoefer:
 Am 4. September 2010 18:51 schrieb NopMap ekkeh...@gmx.de:
  das magst Du so sehen. Jeder trägt das ein, was ihm wichtig vorkommt.
  Solange man nicht die Dinge löscht, die einem selbst nicht wichtig
  vorkommen, ist das kein Problem.
 
 
  Genau das passiert hier aber. Indem ein etabliertes Tag anders verwendet
  wird, werden alle vorher erfaßten Objekte, die bis zu diesem Zeitpunkt
  eindeutig waren, invalidiert.
 
 
 Das ist m.E. übertrieben, da der Zustand den Du beschreibst vermutlich
 nie existiert hat.

Genau das ist das Problem: Der im Wiki beschriebene Zustand hat – bis
auf wenige Extrema – nie existiert. Und selbst jene wenigen Ausnahmen
stellten keinen großen Datenverlust dar, da aufgrund der schwammigen
Formulierung nicht eindeutig ausgesagt wird, worum es sich denn nun
eigentlich genau handelt.

Die Formulierung spricht von einzeln stehenden ODER markanten Bäumen;
Ist das nun exklusiv oder inklusiv zu verstehen? OR oder XOR, würde der
Informatiker fragen. Fällt der einzelne Baum einer Allee unter diese
Definition? Ab wann steht ein Baum einzeln? Welche Meterangabe ist hier
relevant? Ein markanter Baum kann auch eine uralte und meterdicke Eiche
mitten in einem dichten Laubwald sein, denn die Definition schreibt ja
ausdrücklich nicht vor, dass beide Bedingungen erfüllt sein müssen.

Ich könnte jetzt noch stundenlang auf der definition dieses Tags
herumreiten und zahlreiche Beispiele aufzählen, wo nicht klar ist, ob
der Tag nun gesetzt werden dürfte oder nicht – das wäre allerdings
müßig. Wer nach dem obenstehenden Absatz nämlich nicht verstanden hat
worauf ich hinaus will, wird es auch mit hundert weiteren Beispielen
nicht kapieren (wollen).

Lasst uns die Fakten analysieren: Fakt ist, dass der deutlich
überwiegende Großteil der bisher getaggten Bäume NICHT der Definition
entsprechen, wie sie seit Jahren im Wiki steht. Ein weiterer Fakt ist,
dass der Aufbau des Tags (natural=tree) nahe legt, dass es sich schlicht
um einen Baum handelt. Eine besondere Eigenschaft des Baumes oder eine
Rolle als Orientierungspunkt drückt das Tag in keinster Weise aus.
Weiters ist zu vermuten, dass die schwammige Definition, die bereits
seit Jahren im Wiki steht, zu einer Zeit geschrieben wurde als noch
niemand ernsthaft daran glaubte, dass eines Tages einzelne Bäume gemappt
werden würde.

Neben diesen rein strukturellen Problemen gibt es auch keinerlei
technische Notwendigkeit, diese stark eingeschränkte definition
beizubehalten. Orientierungsrelevante Bäume können sehr leicht mit
geeigneten Zusatztags hervorgehoben werden; Diese sind nach Bedarf noch
zu definieren.

Eine Abstraktion ist Aufgabe der Auswertungssoftware und nicht die
Aufgabe des Mappers. Dies hat schon alleine jenen Grund, dass Mapper
Menschen sind und daher jedes Individuum eine andere Art der Abstraktion
bevorzugen würde, weswegen die Daten mit der Zeit extrem inkonsistent
werden würden. Hingegen kann ich in meinem Auswerteprogramm sehr einfach
definieren, ab wann für mich der einzelne Baum im Wald zählt oder wann
ich den Wald als einzelne Fläche darstellen möchte, ab welcher Zoomstufe
es sinnvoll ist, die Straße flächig zu rendern und wann die
Vereinfachung zu einem bloßen Linienstrang angebracht ist.

Genau wie der Erfinder der Baumdefinition können wir heute überhaupt
nicht abschätzen, was in zwei oder drei Jahren sein wird. Vielleicht
gibt es dann wirklich eine Karte mit Zoomlevel 30 und erste Gebäude mit
einem Innenplan. Spätestens dann bin ich zwingend darauf angewiesen,
dass eine Straße flächig erfasst ist. Wir sollten uns nicht mit den
heutigen Anforderungen beschränken und sagen, dass es für die
Autonavigation irrelevant ist und daher nicht in die Datenbank gehört.

Die Filterung der relevanten Informationen liegt stets beim Ersteller
der Karte. Das bin aber weder ich, noch bist das Du. Wir pflegen nur
eine Datenbank mit Geodaten. Die Karte wird vom Osmarender- bzw. vom
Mapnik-Team und von zahlreichen Dritten bewerkstelligt; Wieder andere
konvertieren das Material für die unterschiedlichsten PNA-Lösungen, die
sich wiederum in Leistungsfähigkeit und Anwendungsgebiet unterscheiden.
Daher ist die Abstraktion vom Konverter oder Renderer vorzunehmen, denn
nur dieser kennt die genauen Spezifikationen des Anzeigegerätes und die
Anforderungen.

Eine Applikation für ein Mobiltelefon wird in der Regel mit der
Darstellung jedes einzelnen Baumes im Wald HEUTZUTAGE überfordert sein.
Ein Anderer möchte aber vielleicht den Baumbestand in einem gedruckten
Katasterplan einbauen. Das Ausblenden der irrelevanten Bäume (oder
anderer Objekte) auf Basis von Tags oder Algorithmen (z.B. Entfernung
zum nächsten Baum, Baumdichte im Gebiet, …) ist relativ einfach, eine
nicht vorhandene Information kann ich allerdings nicht aus dem Hut
zaubern.

Daher bin ich dafür die alte Definition möglichst bald aufzugeben und
geeignete Zusatztags zu definieren um in Zukunft auch die aktuelle
Definition

Re: [Talk-de] Zeichnen von Flüssen

2010-09-04 Diskussionsfäden André Reichelt

Am Freitag, den 03.09.2010, 14:50 +0200 schrieb Fabian Schmidt:
 Ich habe etliche Kilometer von Bächen gemappt, die nur selten bepaddelbar 
 sind, indem ich das Ufer abgelaufen bin. Die Tracks habe ich bewusst nicht 
 hochgeladen, da aus dem reinen Track nicht hervorgeht, wo der Bach 
 verläuft, auf welcher Bachseite ich mich befinde, wo das Ufer schlecht 
 oder gar nicht zugänglich ist, wie breit der Bach ist und welche 
 Entfernung ich vom Bach hatte.

In so einem Fall sollte man dann aber unbedingt das Source-Tag sauber
ausfüllen, sodass für andere Mapper erkennbar ist, woher die Daten
stammen. Ohne dieses Wissen könnte man sehr leicht folgern, dass jemand
das Ganze vielleicht nur grob nach Sat-Bild abgezeichnet hat oder
ähnliches.

Gruß,
André


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Werden Baumreihen gerendert?

2010-09-04 Diskussionsfäden André Reichelt

Am Samstag, den 04.09.2010, 13:47 +0200 schrieb Peter Wendorff:
 [...]

Ich möchte Dir vollumfänglich beipflichten!

André


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Werden Baumreihen gerendert?

2010-09-04 Diskussionsfäden André Reichelt

Am Samstag, den 04.09.2010, 04:49 -0700 schrieb NopMap:
 Daß es keinen Sinn macht, Tags die schon Jahre in Gebrauch sind wortwörtlich
 zu interpretieren, zeigt wohl am besten das verwandte natural=wood. Das
 komischerweise _nicht_ für jeden Wald verwendet wird.

Das liegt mitunter daran, dass es in Deutschland (so gut wie) keine
natürlichen Wälder gibt sondern nur vollbewirtschaftete Waldflächen. Die
Diskussion gab es aber vor zwei Jahren schon einmal.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Autobahnrouting

2010-08-29 Diskussionsfäden André Reichelt

Am Sonntag, den 29.08.2010, 19:01 +0200 schrieb Carsten Schwede:
 Ja, ich sehe hier den Fehler in der Karte, auch in den Garmin eigenen 
 Karten. An der Routingsoftware in den Garmins kann man ja nun recht 
 wenig ändern.

Das ändert leider nichts an der Tatsache, dass das offenbar
unvorteilhaft in der Applikation umgesetzt ist. Wir sollten uns nicht
mit Workarounds für die Fehler der Softwarehersteller aufhalten sondern
druck auf diese ausüben, dass jene Fehler beseitigt werden. Schlampige
Programmierung ist und bleibt schlampige Programmierung.

Gruß,
André


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Autobahnrouting

2010-08-29 Diskussionsfäden André Reichelt

Am Montag, den 30.08.2010, 01:03 +0200 schrieb Garry:
 Das klingt etwas arrogant den Herstellern hier pauschal eine schlampige 
 Implementierung vorzuwerfen.
 Die implementieren das so wie es mit den von ihnen (bzw. Auftraggeber) 
 gewählten Kartendaten funktioniert.

Hier wurde bereits mehrfach angemerkt, dass dieser Fehler durchaus, wenn
auch seltener, mit den Originalkarten auftritt. Daher bleibt für mich
nur der einzige Schluss, dass entweder schlecht/unvorteilhaft
implementiert wurde oder, dass die Verantwortlichen selbst nicht genau
wissen, was sie eigentlich wollen und wo die Spezifikationen liegen.

 Für was anderes werden sie nicht bezahlt. Je schwieriger OSM eine 
 Konvertierung für so ein System macht
 (z.B. durch zwar korrekte, aber viel zu aufwendige 
 Relationsbeschreibungen einer Situation) um so geringer
 ist die Chance dass OSM-Daten auh so einem System verfügbar werden.

Du darfst jedoch nicht außer Acht lassen, dass solch ein Flickwerk
durchaus auch dafür sorgen kann, dass wiederum mit anderen Systemen von
anderen Herstellern ein Problem auftritt, die es genau anders herum
haben möchten.

Beispielsweise wurde hier auch bereits angemerkt, dass es im Norden der
Republik einige Autobahnen gibt, bei denen eine Aufspaltung der Wege an
Abfahrten *unumgänglich* ist, da dort Umfahrungen und Ausweichstrecken
einmünden. Wir stünden hier also vor der konkreten Wahl, ob wir zu
Gunsten einer besseren Unterstützung der Garmin-Geräte das Tagging von
Umfahrungen einschränken bzw. auslassen.

Spätestens an diesem Punkt wird die Sache haarig, da wir das komplette
Projekt einschränken müssten um die Funktionstüchtigkeit für einen
Bruchteil der Anwendungen zu verbessern. Und spätestens wenn ein
einzelner Hersteller anfängt, uns indirekt zu diktieren kann ich nur
noch widersprechen. So weit darf es nicht kommen, auch wenn wir dadurch
vielleicht ein paar Helfer verlieren.

Gruß,
André


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Autobahnrouting

2010-08-29 Diskussionsfäden André Reichelt

Am Montag, den 30.08.2010, 00:03 +0200 schrieb Garry:  
 Das Problem liegt nach meinen Beobachtungen weniger an den 
 Unterbrechungen sondern am Winkel mit
 der eine Abfahrt abzweigt. Sonst würden ja auch auf freier Strecke 
 dauernd Fahrtanweisungen erfolgen - dem ist aber nicht so.

Wie wäre es denn mit einem Test statt vieler Worte?

Wer kennt eine Stelle, an der das Problem mit dem jetzt links halten
auftritt? Wer überprüft, ob dort bereits ein augenscheinlich
ausreichender Abzweigewinkel vorhanden ist? Und wenn nicht, kann
derjenige den Winkel zu Testzwecken erhöhen? Wer aktualisiert das
Material? Wer testet die Situation erneut mit dem reparierten Material?
Funktioniert es jetzt?

Damit würden wir deutlich weiter kommen als mit Spekulatius…

André


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ....ich bleib bei OSM !

2010-08-28 Diskussionsfäden André Reichelt

Ich habe mich ja bekanntlich immer gegen die neue Lizenz ausgesprochen,
aber mir ist das Projekt wichtiger als irgendwelches persönliches
Gehabe. Daher habe ich nun beschlossen, dass ich meine Daten, falls
erforderlich, auch unter der neuen Lizenz veröffentlichen werde. So
lange keiner auf die Idee kommt, die Daten public domain zu
veröffentlichen werde ich nicht die Spaltung des Projektes vorantreiben.

Liebe Grüße
André


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM für Feuerwehr

2010-05-28 Diskussionsfäden André Reichelt

Am 28.05.2010 11:58, schrieb Ulf Lamping:
 c) du schützt die Daten in der OSM Datenbank gegen editieren von 
 anderen - was aus meiner Sicht keine breite Zustimmung bei OSM finden 
 wird (weil es letztlich dem OSM Gedanken widerspricht)

Ich gehe nicht davon aus, dass dieser Widerstand eintreffen wird. Es
soll ja auch kein gewähltes Gremium dieses Recht haben sondern alle
Nutzer, die eine gewisse Anzahl an sinnvollen Edits gemacht haben und
nicht durch Vandalismus in Erscheinung getreten sind.

Des Weiteren ist es eben so, dass eine Straße nicht ständig ihren
Verlauf ändert. Deshalb sehe ich ab einer bestimmten Güte keinen Sinn
mehr, Änderungen vorzunehmen, da bereits alles gesagt wurde, was man
sagen kann. Zusätzlich sind nachträgliche Änderungen in meinem Vorschlag
bereits berücksichtigt -- diese erscheinen jedoch nicht unmittelbar
sondern müssen überprüft werden. Sofern diese Änderungen die Güte der
Daten erhöhen wird auch keiner die Änderung blockieren -- außer wir sind
der selbe Sauhaufen, der die Wikipedia seit Jahren zerstört...

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM für Feuerwehr

2010-05-28 Diskussionsfäden André Reichelt

Am 28.05.2010 14:16, schrieb Sven Geggus:
 Nun markiert man diesen als nicht verschiebbar. Nun hat aber ein Mapper
 seiner Gemeinde zum beispiel hochgenau referenzierte Luftbilder abgeschwatzt
 und kann jetzt die Straße nicht mehr verschieben, weil da ein Hydrant
 dranhängt.

Da hast Du etwas missverstanden. Es ist nicht NICHT änderbar sondern
Änderungen müssen zunächst freigeschaltet werden. Im Prinzip wird also
so lange weiterhin der alte Versionsstand ausgegeben bis der neue
Versionsstand von genügend anderen Mitgliedern bestätigt wurde.

Dadurch behälst Du die volle Flexibilität bei, verhinderst aber aktiv
Vandalismus, da solcherlei Änderungen gar nicht erst angezeigt werden.

Es wird also am aktuellen Dateneingabesystem gar nichts geändert. Einzig
die Ausgabe-API bekommt den Befehl, dass sie statt der aktuellsten immer
nur noch die aktuellste signierte Änderung ausliefern soll. Leute, die
in der Gegend wohnen bekommen dann eine Nachricht zur Verifizierung.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Was kann OSM 2020?

2010-05-28 Diskussionsfäden André Reichelt

Am 28.05.2010 23:18, schrieb Florian Gross:
 Ich darf mir also z.B. einfach so aus google maps einen Atlas basteln,
 als Quelle google maps angeben und den drucken und verkaufen?
 [...]
 Wichtiger ist mir vor allem: bei google maps und Co. sind die Daten
 nicht frei verfügbar.

Realistische Abschätzung: Wie viele Leute basteln sich einen Atlas?

Sicher, das ist ein schönes Schmankerl, aber man sollte daraus nicht das
Hauptargument machen, da man damit nur eine Minderheit anspricht.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Was kann OSM 2020?

2010-05-27 Diskussionsfäden André Reichelt

Am 27.05.2010 21:54, schrieb Lothar Emmerich:
 Wird OSM auch eine Alternative für Google Earth? 

Das wird sicher nicht passieren. Wir dürfen nicht anfangen, Äpfel mit
Birnen zu vergleichen. Wir haben keine Luftbilder, wir haben
vektorisiertes Kartenmaterial.

Ob wir eine Konkurrenz zu Google Maps werden -- ich weiss nicht. Aber zu
Earth werden wir es bestimmt nicht; höchstens unser Partnerprojekt OAM.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Was kann OSM 2020?

2010-05-27 Diskussionsfäden André Reichelt

Am 28.05.2010 00:59, schrieb Bernhard Zwischenbrugger:
 Wirklich interessant sind doch erst die Dinge die anderswo nicht 
 vorhanden sind.

Das sehe ich mittlerweile genauso.

Wir sollten uns in Zukunft nicht mehr auf die Fahne schreiben, wie
Google, nur kostenlos zu sein sondern wir sollten anfangen die Dinge zu
betonen, die man mit Google und Konsorten nicht machen kann. Dabei
müssen wir scharf unterscheiden zwischen Geschäftskunden und
Privatleuten, denn die wenigsten Normalverbraucher werden daran
interessiert sein, eigene Karten zu rendern. Für diese steht die Nutzung
im Vordergrund.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM für Feuerwehr

2010-05-27 Diskussionsfäden André Reichelt

Am 28.05.2010 03:17, schrieb Peter Körner:
 Am 28.05.2010 03:02, schrieb Tirkon:
 Das Modell eäre eines, das OSM über den privaten Bereich sinnvoll
 nutzbar machen würde.
 Gefallen tut's mir nicht aber ich sehe das Problem und auch keine 
 schönere Lösung. Fraglich ist nur, ob Rails-Port, JOSM  Co. die 
 richtigen Werkzeuge für diese Anwendung sind.

Die Idee stößt auch mir bitter auf, da dies eigentlich der Idee
widerstößt. Benutzergruppen und Wiki passen nicht wirklich zusammen. Das
Ganze wird ja eben erst deshalb gut, WEIL alle mitmachen dürfen.

Ich kann die Bedenken natürlich verstehen. Allerdings hat die
Holzhammermethode noch nie funktioniert. Man sollte vielmehr einen Weg
finden, wir man in Zukunft bestimmte Fakten schlicht festnageln kann.
Ich stelle mir das dementsprechend vor, dass man Objekte verifizieren
kann und wenn eine bestimmte Anzahl an Leuten das Ding als korrekt und
vollständig markiert haben wird es für Änderungen blockiert.

Falls dennoch etwas zu ändern ist (Baustelle usw.), dann landet dies nur
in einem Freischaltungsmodus. Die Änderungen erscheinen dann erst auf
der Karte, wenn diese von einer bestimmten Zahl an qualifizierten
Nutzern genehmigt wurden.

Im Prinzip also eine Adaption des kürzlich in der Wikipedia eingeführten
Sichtersystems.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nutzt Google (auch) die Daten von OSM?

2010-05-10 Diskussionsfäden André Reichelt

Am 06.05.2010 08:23, schrieb Andre Joost:
 Wie wärs mit ner Guhgel-Strasse?

Das kann man gerne mal machen. Sollte natürlich hier vorher (OHNE Link)
angekündigt werden und nur mit leicht verfälschtem Namen. Wer weiss, ob
die nicht hier mitlesen. Vor allen Dingen sollte man es aber auf das
Gebiet beschränken, in dem die Kopiervorwürfe stehen. Sofern das
wirklich der Wahrheit entsprechen sollte müsste man mal bei Google die
Rechtsabteilung konsultieren und darauf hinweisen, dass sie von
irgendeinem Subunternehmer OSM-Daten bekommen und diese nicht
hinreichend kennzeichnen.

Dann können zwei Dinge passieren: Die Daten verschwinden oder unten
erscheint auf der Karte Datenquelle: OpenStreetMap. Letzteres wäre in
meinen Augen ein genialer Erfolg.

Aber wir sollten der Sache ernsthaft mal nachgehen.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Arbeitsmatrix Dortmund

2010-05-10 Diskussionsfäden André Reichelt

Am 05.05.2010 09:11, schrieb Dietmar:
 Die Dortmunder wollen jetzt eine eigene Matrix erstellen, da war mal was
 geplant gewesen und dann angehalen worden.
 Nächste Woche soll evtl. was verfügbar sein.
 
 Grüße
 Dietmar

Wie ist denn der Stand?

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Frankfurt gestalten

2010-04-25 Diskussionsfäden André Reichelt

Hallo,
ist der Link eigentlich bekannt:

http://frankfurt-gestalten.de/

Da wird OSM eingesetzt.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bahnübergang in Schilda?

2010-04-25 Diskussionsfäden André Reichelt

Am 25.04.2010 23:33, schrieb Johann H. Addicks:
 Was ist das?

Hm,
vermutlich war das früher mal eine Ausfahrt eines verkehrsberuhigten
Bereiches, der dann später dicht gemacht wurde, da die Sanierung der
Überfahrt zu teuer gewesen wäre. Der Poller in der Mitte deutet das
irgendwie an, dass man da nicht rein-/rauspräscht.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Von Wikipedia lernen

2010-04-25 Diskussionsfäden André Reichelt

Am 25.04.2010 13:00, schrieb Frederik Ramm:
 [...]

Hallo,
ich habe die anderen Beiträge nicht gelesen, kann mich aber Deiner
Meinung nur anschließen: Die Wikipedia ist verkommen zu einem Haufen
weniger Machthaber, die völlig undurchschaubar Regeln vordiktieren.
Die bürokratischen Strukturen sind längst nichtmehr durchschaubar und
die Admins handeln meistens nach gutdünken. Dies können sie, da sie nur
von den 0,5% gewählt werden, die eh ihrer Meinung sind -- die Anderen
umgehen die Wahlen, da sie berechtigt alleine sowieso nichts ändern
könnten. Da müsste schon ein Sturm, eine Art Revolution losbrechen.

Ich werde mit Kräften daran arbeiten, dass so etwas bei uns nicht
passieren wird. Wir müssen alle wachsam sein und rechtzeitig
gegensteuern, wenn wir merken, dass wir in eine Sackgasse laufen, wie
dies mit der Wikipedia geschehen ist. Und ich sage das als aktiver
Autor, der schon seit einer vierstelligen Anzahl an Tagen dabei ist.

Richtig ist, dass wir auf Dauer nicht ohne Regeln klar kommen werden. Es
ist jedoch um jeden Preis zu verhindern, dass sich eines Tages ein
Gremium bilden wird, dass einen Alleinstellungsanspruch darauf hat,
irgendwelche verbindlichen Regeln vorzuschreiben. So etwas wird wie bei
der Wikipedia zwangsläufig in der Katastrophe enden.

Ein weiteres Problem der Wikipedia ist es, dass die Werkzeuge zu einer
Zeit geschaffen wurden, zu der das Projekt noch in den Kinderschuhen
steckte. Seither liegt die Entwicklung der Werkzeuge brach! Wie sonst
erklärt sich, dass seit fünf Jahren immer der selbe Editor im Einsatz
ist -- unverändert. Ich als alter Hase habe keine Probleme mit mehrfach
verschaltelten Vorlagen und rießigen Tabellen, dem Anfänger bricht das
jedoch das Genick.

Wir haben wie die Wikipedia eine gewisse Manpower zu verteilen. Diese
fließt dort, wie richtig angemerkt, zu rund 90% in die Verwaltung eines
Bürokratiemonsters.

Unser Ziel muss es sein, die Kraft zu dritteln. Ein Teil muss in der
Diskussion landen: Damit meine ich ausdrücklich nicht sinnlose
Diskussionen zu Themen bei denen von vorn herein feststeht, dass die
Diskussion ins Leere laufen wird; ich spreche von Diskussionen, wie man
Neuerungen am Besten einsetzt, was man an den Werkzeugen verbessern kann
und ähnliche Punkte. Natürlich zählt auch die Diskussion auf OSB dazu.

Ein weiteres Drittel muss in die konsequente Entwicklung der Datenbasis
fließen. Dazu zählt natürlich auch die Meldung von Fehlern bei OSB.

Das letzte Drittel ist das Wichtigste: Die konsequente Verbesserung der
Werkzeuge. Es darf nicht passieren, dass sich die Stammnutzerschaft
bewusst oder unbewusst von den neuen Nutzern abkapselt, indem sie
absichtlich oder unabsichtlich die Werkzeuge so unbedienbar gestaltet,
dass neue Nutze mit diesen nichts mehr anfangen können. Wir als alte
Hasen müssen uns immer wieder an die eigene Nase packen -- immer wieder
schauen, dass die Tools bedienbar bleiben -- uns immer wieder in die
Lage eines Neulinges versetzen. Die Vergangenheit hat gezeigt, dass wir
es besser machen als die Wikipedia. In meinen Augen sind wir aber noch
weit vom Perfekt entfernt. So ist die Bedienung durch das Aufblühen der
Relations deutlich komplizierter geworden. Eine grafische Oberfläche zu
deren Erzeugung fehlt jedoch bis auf wenige Presets noch gänzlich.

Auch im Wiki gibt es immer wieder zu tun. Wir müssen die Informationen
noch auffindbarer gestalten!

Ich halte ein Regelwerk wie die Mapfeatures für unumgänglich! Allerdings
dürfen wir uns nicht von den Wikipedianern verführen lassen, diese zu
unserer Bibel zu erklären. Die Mapfeatures müssen das bleiben, was sie
gerade sind: Der kleinste gemeinsame Nenner. Dadurch tun sie niemandem
Weh und trotzdem habe ich die Möglichkeit, mir neue Dinge auszudenken.

Wenn wir jedoch dazu übergehen würden zu sagen, nur was in den
Mapfeatures steht darf gemappt werden, alles andere wird wieder
entfernt, dann meine Freunde, dann würden wir in den selben bodenlosen
Abgrund fallen wie die Wikipedia es langsam aber sicher immer schneller tut.

In diesem Sinne,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM-Karten in Wikipedia

2010-04-03 Diskussionsfäden André Reichelt

Am 03.04.2010 12:33, schrieb Kai Krueger:
 Die Hike  Bike map ( http://hikebikemap.de/ )

Die scheint wohl bei Detailzooms größere Probleme zu haben. Das
Abrendern der fehlenden Teils dauert teils zwanzig Minuten. Ist das
beabsichtigt?

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 01.04.2010 04:22, schrieb Matthias Versen:
 Das Spurenproblem mal außen vorgelassen denn das Problem ist nur wie man 
 es am besten macht und nicht, das es mit Vektoren nicht möglich ist.
 
 Ich sehe da absolut nicht das man mit Vektoren irgendwo auf die Schnauze 
 fällt, eher schon mit Flächen.

Du kannst bei Vektoren allerdings nur Punktförmige Verbindungen
ausdrücken. Das hilft dir etwas bei einfachen Kreuzungen, bei
Einfädelspuren oder komplexeren Kreuzungsbildern ist der Ofen allerdings
ganz schnell aus.

Sicher, man kann Anfang und Ende verbinden und dann mittels
komplizierter Relations beschreiben, dass in diesem Gebiet ein
stufenloser Spurwechsel möglich ist. Allerdings liese sich dieser
Umstand mit einer Fläche um Längen intuitiver, schneller und und
sichtbarer verdeutlichen.

Deshalb plädiere ich auf längere Sicht darauf, Vektoren nur noch da
einzusetzen, wo sie wirklich sinnvoll sind und anderweitig auf Flächen
und Splines aufzuwerten. Vektoren sind nach wie vor unschlagbar bei
Überlandleitungen, bei denen die primitiven Möglichkeiten eines Vektors
ausreichen. Der Vektor kann auch zur Beschreibung von Flächengrenzen
hergezogen werden, sofern man noch keine Kurvenobjekte hat oder wenn die
Strecke exakt gerade ist. Allerdings ist und bleibt der Vektor nach dem
Punkt unser primitivstes Beschreibungsmedium, der in der Regel nur
näherungsweise arbeiten kann. Ich will hier aber keine linienförmige
Annäherung sondern eine Darstellung der Realität.



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 01.04.2010 08:22, schrieb Guenther Meyer:
 natuerlich geht das.
 mit einer flaeche kannst du sowas nicht machen...

Das Gegenteil ist der Fall.

Und trotz dass Du es offensichtlich nicht für nötig hältst, irgendwelche
Beweise für Deine Theorie anzuführen möchte ich im Sinne der Netiquette
und des guten Tones auch erläutern, warum es mit einer Fläche funktioniert:

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. Dann muss ich über abstrakte Elemente
(Relation) beschreiben, in welchem Stück eine Überfahrt möglich ist.
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. 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. 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.

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.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 01.04.2010 12:31, schrieb qbert biker:
 Warum? Rinksbuendige Referenz + Spurbreite + Spuranzahl +
 Uebergangsbeschreibung (z.B. Aufweitung auf 100m Laenge)
 und das Ding ist sauber beschrieben.

Wenn es immer so einfach wäre. Jedoch geschieht der Übergang zwische
verschiebenden Straßenbreiten nicht schlagartig. Dementsprechend müsste
ich die Breitenzunahme komplex als Funktion beschreiben, um exakt zu
sein. 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.

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.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 01.04.2010 12:58, schrieb Robert S.:
 2010/4/1 qbert biker qbe...@gmx.de mailto:qbe...@gmx.de
 
 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?

+1

André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kamerabilder auswerten

Am 25.03.2010 11:36, schrieb Fabian:
 PS hier [1] ein beispiel fuer dein vorhaben. IMHO sind da sehr viele
 unnuetze bilder bei.
 [1]
 http://openstreetview.org/?lat=51.545187436765lon=8.4299039837353zoom=11

Kann man sich die Bilder eigentlich vergrößern? Draufklicken geht nicht.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kamerabilder auswerten

Am 26.03.2010 15:58, schrieb Martin Koppenhoefer:
 Anzahl der Fahrspuren kann man sich gerade noch vorstellen, aber
 Brücken? Die erkennt man auf der Autobahn ja oft nichtmal (wenn man
 die entspr. Schilder nicht hätte) als menschl. Autofahrer, der von
 höher und nach vorne raus blickt. Schilder hat man mit der
 Rückfahrcamera immer nur von hinten oder der Gegenseite, richtig?

Doch, Du wirst sie im Videofilm in beide Fahrtrichtungen erkennen.
Merkenswerte Brücken sind grundsätzlich beweglich gelagert und haben
deshalb an beiden Enden Gitterroste, die je nach Brückenlänge und
aktueller Position durchaus auch mal zwei Meter lang sein können. Man
beachtet diese während der Fahrt zwar nicht, aber im Film würde man sie
sehen und könnte so metergenau die Position bestimmen.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 22.03.2010 17:40, schrieb olvagor:
 Momentan schon. Aber meiner Meinung nach ist das Fernziel in OSM, dass
 highway=residential ne Fläche ist und Vektoren nur noch die Fahrspuren
 darstellen. Mir ist klar, dass wir da noch weit von weg sind und will
 das jetzt auch nicht auf Biegen und Brechen einführen.

Das sehe ich auch so und habe das auch schon vor zweieinhalb Jahren so
kundgetan.

Aktuell ist es leider noch notwendig, Flächen und Wege getrennt zu
erfassen. Früher oder später muss diese Tätigkeit der Erzeugung einer
Mittellinie jedoch von den Konvertern übernommen werden, sofern der
Router keine flächigen Straßen unterstützt.

Wir haben im Prinzip noch nicht damit begonnen, weil es noch keine Daten
gab, die genau genug waren. Dank der Luftbilder von Aerowest können wir
nun aber zum ersten Mal metergenaue Abbilder der realen Straße erzeugen.
Wir sollten das auch nutzen.

Jedoch, ich sage es nochmals, bleibt auf einer separaten ebene und
verwurstet es nicht mit den normalen Wegen. Verwendet wie gewohnt einen
Vektor für die Straße und legt eine Fläche drum herum. Der Vektor kann
später leicht automatisch gelöscht werden, sobald genügend
Anwendersoftware flächige Straßen unterstützt.

Aber grundsätzlich eine sehr förderliche Tätigkeit, das Pilotprojekt zu
nutzen, um unsere eigenen Modelle weiterzuentwickeln.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 22.03.2010 19:26, schrieb Martin Koppenhoefer:
 Am 22. März 2010 17:53 schrieb Chris-Hein Lunkhusen chris66...@gmx.de:
 olvagor schrieb:

 Ich denke, ich werde das über nen eigenen Namespace lösen.
 +1
 Vielleicht einfach

 area:highway=residential
 area:highway=footway

 ich fände highway_area=residential schöner, aber egal, ist ja
 syntaktisch äquivalent. ;-)
 
 wie wärs mit landuse=highway ? Ist kürzer und entspricht z.B.
 landuse=railway. Wozu man da zwischen residential, unclassified etc.
 unterscheiden sollte, ist mir allerdings unklar, m.E. reicht ein
 landuse=highway für alle Straßen.

Die beiden oberen Vorschläge gefallen mir sehr gut. Bedenken habe ich
mit Deinem Vorschlag, Martin. Das Landuse für die Bahn wurde nicht aus
dem Grund eingeführt, Strecken flächig zu mappen (was im Übrigen auch
schwachsinnig wäre, da diese grundsätzlich ein Vektor bzw. Spline mit
einer festen Breite von 1440mm sind). Ziel war es viel mehr, die von der
Bahn genutzte Fläche zu kennzeichnen. Das ist beispielsweise Bahngelände
oder brachliegende Landfläche zwischen den Gleisen eines Güterbahnhofs.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 22.03.2010 20:13, schrieb Guenther Meyer:
 und wie waers mit der einfachen abstraktion, strassen als linie zu mappen, 
 und 
 die breite als attribut anzugeben?

Das entspricht nicht dem, was hier bezweckt werden soll: Die Erstellung
einer WeltKARTE. Für mich ist das in erster Linie ein vektorisiertes
Luftbild. Das schließt implizit auch flächige Straßenkörper mit ein
(zumal Diese entgegen der öffentlichen Wahrnehmung entlang der Strecke
doch sehr stark variieren kann).

Navigationssysteme aller Art sind nur ein Anwendungsgebiet unserer
Karten. Wenn ich allerdings die B999 in meinen Fahrsimulator einbinden
möchte, genügt mir ein Vektor mit statischer Breite definitiv nicht.
Gerade auf Bundesstraßen wird beispielsweise in Kurven die Straßenbreite
häufig erhöht, um das Kurvenschneiden zu verhindern.

Ich kann mir durchaus auch vorstellen, dass wir eines Tages auch
einzelne Bäume in der Landschaft oder am Straßenrand erfassen werden
(was schließlich an so mancher Stelle bereits getan wird).

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 22.03.2010 21:14, schrieb Torsten Leistikow:
 Oder geht es nicht viel mehr darum, dass man die Wirklichkeit abstrahiert und
 einzelne Objekte entsprechend ihrer Funktion beschreibt.

Die Abstraktion der Daten ist ein zweiter Schritt, den man nicht mit dem
Mappen vermischen darf! Der Grad der benötigten Abstraktion hängt
vollständig von der Anwendung ab. Für eine Deutschlandkarte aller
Autobahnen zum Ausdrucken auf A4 brauche ich eine deutlich geringere
Präzision als wenn ich einen Plan des örtlichen Marktplatzes brauche,
auf dem ich Marktstände vermerken will.

Ich habe das Gefühl, einige hier haben noch nicht genau verstanden,
worin das eigentliche Ziel unserer Datenbank besteht: Ein möglichst
hoher Detailgrad. Welche und wie viele Details ich für meine Anwendung
brauche ist dann eine andere Frage. Wir erstellen aber
_ausdrücklich_nicht_ eine Datenbank für Garmin und Skobbler sondern eine
freie Wiki-Weltkarte.

Jedes Anwendersystem muss daher in der Lage sein, selbst eine
Abstraktion herzustellen. Dies kann natürlich und ausdrücklich auch
dadurch geschehen, dass wir das Projekt OpenRoutingMap starten und dort
eine Kopie der aktuellen Daten einspielen und diese speziell auf die
Bedürfnisse von Routern ausrichten.

Jedoch dürfen wir uns _nicht_ dazu verleiten lassen, dass wir aufgrund
des derzeitigen Hauptanwendungsgebietes (Routing) unsere Karte in diese
Richtung trimmen. Dies würde dazu führen, dass wir alle anderen
Anwendungsbeispiele behindern oder ausschließen würden -- und das darf
nicht unser Ziel sein!

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 26.03.2010 15:16, schrieb Chris-Hein Lunkhusen:
 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.

Entschuldigung wenn ich mich wiederhole, aber ein paar Schreiber dieser
Liste, Du eingeschlossen, haben sich in eine extrem einseitige Polemik
verrannt.

OpenStreetMap ist eben _keine_ Karte für Router sondern eine freie
Wiki-Weltkarte. Man darf sich nicht auf Router beschränken.

Ziel muss es viel mehr sein, mehrere Abstraktionsebenen zu schaffen:
Zunächst die Hauptkarte (Datenebene) mit allen Daten darauf (u.A. auch
Gullydeckel) und dann mehrere abstrahierte Unterebenen, von denen eine
speziell für Router für Kraftfahrzeuge vorgesehen ist.

In der Datenebene sind Straßen, sofern möglich, grundsätzlich flächig zu
erfassen. Erst in der Abstraktionsebene für
Kraftfahrzeugnavigationsgeräte ist die Fläche durch einen Vektor zu
ersetzen, solange wir noch keine Router haben, die auf neuronalen Netzen
basieren.

Ich möchte unseren alten Leitsatz etwas aufpoliert ins Gedächtnis rufen:

 Wir mappen nicht nur(!) für Navigationssysteme.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 30.03.2010 10:57, schrieb qbert biker:
 Ich frage mich z.B. bei diesen Diskussionen immer, warum
 keiner Kreissegmente fordert, denn einen Bogen in einzelne 
 Segmente aufzuloesen, ist auch ungenau. 

Das habe ich bereits vor zwei Jahren ;). Allerdings hat die Diskussion
damit geendet, dass wir bisher keine Ausgangsdaten haben, die das
rechtfertigen würden. Bei einem GPS-Signal kann ich genaue
Kurvenverläufe nur abschätzen. Die Sache wird dementsprechend erst jetzt
dank Aerowest wieder akut, da uns _erstmals_ Bilder in einem solchen
Detailgrad zur Verfügung stehen, dass man ernsthaft über echte
Kurvenobjekte nachdenken kann.

Jetzt ist die Stunde der Entwickler und Tüftler, die eine saubere
Implementierung anbieten können.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 25.03.2010 10:45, schrieb Sven Geggus:
 Dann darfst Du schon mal Sponsoren für einen Server mit 200Terrabyte
 Plattenplatz suchen.

Das ist das geringste Problem. Speicher kostet heute so gut wie gar
nichts mehr. Im Übrigen neigst Du hier zur Übertreibung, da sich die
Datensammelgeschwindigkeit nicht merklich erhöhen wird. Wenn jedoch
eines Tages tatsächlich ein solch großer Server nötig wäre, würde ich
mich selbstverständlich daran mit Spenden beteiligen.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 31.03.2010 20:35, schrieb Bernd Wurst:
 Ich glaube er meint die Speicherkapazität für die Luftbilder. :)

Die müssen wir erstmal bekommen. Und selbst wenn Aerowest Bilder von
ganz Deutschland zur Verfügung stellen würde, könnten wir diese in
Etappen abarbeiten.

Gruß,
André

PS: Steht eigentlich die Arbeitsmatrix unterdessen?



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 31.03.2010 19:21, schrieb Chris-Hein Lunkhusen:
 Am 31.03.2010 18:51, schrieb André Reichelt:
 In der Datenebene sind Straßen, sofern möglich, grundsätzlich flächig zu
 erfassen. 
 
 Und der Algorythmus soll die Mittellinie zB. eines Kreises wie
 berechnen? ;-)

Genau deshalb eine separate Ebene, die die Mittellinien enthält auf
lange Sicht. Bis das klappt, kann man ja beide parallel auf die selbe
Ebene packen und die Fkächen, wie bereits vorgeschlagen, mit einem
Präfix versehen.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Details mappen in Dortmund

Am 31.03.2010 20:08, schrieb Guenther Meyer:
 strassen sind erstmal lineare gebilde, die lassen sich wunderbar als vektoren 
 mit entsprechenden attributen abbilden, inkl. allem was noetig ist.

Das mag auf Autobahnen fast immer und außerorts gelegentlich gelten,
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.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Aerowest-Luftbilder von Dortmund jetzt v erfügbar

2010-03-20 Diskussionsfäden André Reichelt

Direkt die Frage, ob es denn schon eine Arbeitsmatrix gibt.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Mapzen!?

2010-03-08 Diskussionsfäden André Reichelt

Hallo,
bin gerade bei CloudMade über ein Tool namens Mapzen gestoßen. Weiss da
jemand etwas Näheres zu?

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mapzen!?

2010-03-08 Diskussionsfäden André Reichelt

Am 08.03.2010 19:50, schrieb Frederik Ramm:
 Ist alles im Wiki dokumentiert.

 [...]

Mir ging es auch eher um Erfahrungen damit und einen kleinen Vergleich
zu JOSM und Potlach. Optisch sieht das Ganze ja recht ansprechend aus.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mapzen!?

2010-03-08 Diskussionsfäden André Reichelt

Am 09.03.2010 00:05, schrieb Nick Black:
Hi André,

Hey!

I hope you don't mind me answering in English - my German is non
existant.

No problem... I'm definitely not the best English speaker, but I'll try
my best ;).

I'm glad you have found Mapzen and have been enjoying it so far. The
idea of Mapzen is to provide an easy, fun to use map editor for people
who are new to OpenStreetMap. It was released in its current Beta
form in November 2009 and has been developed since then.

You can read more about the latest release of Mapzen including the
roadmap here:
http://blog.cloudmade.com/2010/02/20/mapzen-updates-and-sneak-preview-of-the-next-release/

Ah, ok. Thank you so far. My question was if it's a professional tool or
if it's better for beginners. The UI quiet impressed me and it seems to
be very intuitive, so I asked myself as advanced user if I should use it
in the future. I saw this screenshot of the turn restrictions editor and
it looked very usable to me. My first impression: Let's keep that piece
of software in your viewport.

Therefore I asked for some kind of a comparison between JOSM, Potlach
and Mapzen. I'll try it in any case if I find some free minutes.

If you need some tips (in English only for now, I'm afraid) there are
some CloudMade people using Mapzen who can help:

Thea - http://mapzen.cloudmade.com/user/149327783
Me (Nick) - http://mapzen.cloudmade.com/user/654502734
Yuliya - http://mapzen.cloudmade.com/user/106573939

Ok, I'll keep those persons in my mind. Thank you.

Best regards,
André

signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] ORS mit Trojaner?!

Hallo,
liegt das an mir, oder ist da was faul? Wenn ich auf ORS gehe, meldet
avast! einen Trojaner und trennt die Verbindung.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] KML-Export

Am 13.02.2010 22:22, schrieb Andreas Neumann:
 http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=-25.4,35.3,48.1,71.7])

Selbst bei nem winzigen Bereich wie

http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=9.99,10.0,49.0,49.01]

Lädt der mir 100 MB Daten runter. Was mache ich falsch?

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] KML-Export

Am 14.02.2010 21:38, schrieb Carsten Gerlach:
 Nabend,
 
 Am Sonntag 14. Februar 2010 21:27:09 schrieb André Reichelt:
 http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=9.99,10.0,49.0
 ,49.01]
 
 Syntax beachten! [bbox=west,süd,ost,nord]

So? Habs direkt aus JOSM rauskopiert (oben-links, unten-links,
oben-rechts, unten-rechts).

http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=49.05407025156395,49.19067925930702,9.6514892578125,10.15411376953125]

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] KML-Export

Am 14.02.2010 23:37, schrieb Carsten Gerlach:
 Am Sonntag 14. Februar 2010 22:42:26 schrieb André Reichelt:
 Syntax beachten! [bbox=west,süd,ost,nord]

 So? Habs direkt aus JOSM rauskopiert (oben-links, unten-links,
 oben-rechts, unten-rechts).
 
 Vielleicht reden wir aneinander vorbei. Deine Angabe oben-links wäre ja 
 schon eine Koordinatenangabe ala 47,11 Außerdem hast du oben und links 
 usw. je zwei mal drin.

Damit war die Reihenfolge im Fenster Koordinaten in JOSM gemeint.

Gruß,
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] KML-Export