Laternen etc auf einer karte einzeichnen?

lworch · 2010-11-02T07:55:07.000Z

MHohmann:

… gibt es ein unbestechliches Argument für das Mappen von Laternen: Weil sie da sind. Es wird so vieles gemappt, einfach nur weil es in der Realität vorhanden ist, …

Die Datenflut, die bei solcher Art mapping zustande kommt, soll ja auch irgendwie durch Prozessoren und Speicher gehandelt werden (siehe thread: Garmin-Karte Europa AiO erreicht 4 GB-Grenze). Da ich mit dem C64 angefangen habe zu arbeiten, sträuben sich mir immer die Nackenhaare ob solchen Speichergebrauchs.
Wäre es evtl. sinnvoll, solche - die Mehrheit wohl eher nicht interessierende - micromapping-Objekte in eigene Karten oder layer auszulagern, wie es z.B. bei der AIO-Karte mit maxspeed, keepright, boundary … geschieht. Stellt sich natürlich sofort die Frage, wo micromapping anfängt.

Tschüß Lutz

wambacher · 2010-11-02T11:45:49.000Z

lworch:

Die Datenflut, die bei solcher Art mapping zustande kommt, soll ja auch irgendwie durch Prozessoren und Speicher gehandelt werden (siehe thread: Garmin-Karte Europa AiO erreicht 4 GB-Grenze). Da ich mit dem C64 angefangen habe zu arbeiten, sträuben sich mir immer die Nackenhaare ob solchen Speichergebrauchs.

na ja, soo teuer ist Speicher ja auch nicht mehr
aber so richtig Sorgen würd ich mir nicht machen. Die Anzahl der “LMM” (Laternen-Mast-Mapper) dürfte wohl relativ klein bleiben.
Viel sinnvoller halte ich es allerdings, die lit-sache auf Straßenebene durchzuziehen.
gruss
Walter

FK270673 · 2010-11-02T11:49:10.000Z

wambacher:

Viel sinnvoller halte ich es allerdings, die lit-sache auf Straßenebene durchzuziehen.

Habe ich bereits als Projekt des Monats Dezember vorgeschlagen …

Gruß FK270673

Noframe · 2010-11-02T12:11:40.000Z

FK270673:

Habe ich bereits als Projekt des Monats Dezember vorgeschlagen …

Oh, bitte nicht.

Bei dem ganzen detailverliebten Aufnehmen (Neudeutsch mirco mapping) von Objekten macht sich hoffentlich derjenige mal Gedanken darüber, wer das alles pflegen soll.
Was nützt uns OSM, wenn in ein paar Jahren irgendwelche Fragmente enthalten sind, auf die man sich nicht mehr verlassen kann und die Detailversessenen die Lust verloren haben?

Ich fange demnächst an in unsere Straße die Anzahl und Beschaffenheit der Zaunpfähle zu erfassen, Kettenhunde (bissig:yes/no) und Bewegungsmelder…

wambacher · 2010-11-02T12:24:01.000Z

Noframe:

Ich fange demnächst an in unsere Straße die Anzahl und Beschaffenheit der Zaunpfähle zu erfassen, Kettenhunde (bissig:yes/no) und Bewegungsmelder…

Du hast die sehr wichtige information vergessen, in welche richtung die schlitze der gullideckel liegen (parallel oder anti-parallel zur straßenrichtung). bei runden deckeln bitte die abweichung zu norden in grad.

lworch · 2010-11-02T13:24:43.000Z

wambacher:

na ja, soo teuer ist Speicher ja auch nicht mehr
…

Den Speicherpreis find ich nicht so bedenklich, sondern eher, dass wir an den Grenzen des Dateisystems arbeiten.

http://forum.openstreetmap.org/viewtopic.php?id=9684

Zudem ist bei der rasanten Vergrösserung der gmapsupp.img zu erwarten, dass sie in Kürze die 4 GB-Grenze überschreitet. Da die Micro-SD-Karten mit FAT32 formatiert sind, können Dateien maximal mit 4 GB adressiert werden.
Wir laufen also auf ein Problem zu.

Tschüß Lutz

lworch · 2010-11-02T13:29:29.000Z

wambacher:

…
Du hast die sehr wichtige information vergessen, in welche richtung die schlitze der gullideckel liegen …

Wohl eher quer zur Fahrtrichtung, da sich sonst Fahrradfahrer urplötzlich aus voller Fahrt heraus im “Fahrradständer” wiederfinden…

Tschüß Lutz

KatjaH · 2010-11-02T13:43:10.000Z

HiHo,

also das geht garnicht mal um laternen sondern allgemein.
die wollen halt wie beschrieben eine funktion um sich aus ihren daten alles einzutragen
egal was egal wie

naja und da muss ich halt symbolisch irgendwelche positionen errechnen die die anzahl dinge (laterne bäume parkplätze und wo anbesten mülleimer aufgestellt werden) die halt auf soeiner strasse verteilt werden sollen können

dadrum geht es halt eher
hmm ganricht mal so leicht zubeschreiben

und das ist nicht für die allgemeinheit nützlich
ich würde es daher einfach mit openlayers einzeichnen

also ich brauch nur die positionen haben
da muss es doch einen weg geben die zuerrechnen

Noframe · 2010-11-02T13:48:44.000Z

lworch:

wambacher:

…
Du hast die sehr wichtige information vergessen, in welche richtung die schlitze der gullideckel liegen …

Wohl eher quer zur Fahrtrichtung, da sich sonst Fahrradfahrer urplötzlich aus voller Fahrt heraus im “Fahrradständer” wiederfinden…

Tschüß Lutz

Die absolute Richtung gegen Nord ist interessant (wenn es sich nicht um die speziellen Runden, mit den kleinen Löchern handelt): wenn Du auf dem Radweg fährst und der Router Dich vor einer Laterne ausweiche lässt, muss überprüft werden, welchen Winkel Du einschlagen musst, damit Du nicht im Fahrradständer landest.

Oder, wenn Du einer Laterne ausweichst, damit Du nicht in den Gulli geleitet wirst, sonder noch schnell die Richtung ändern kannst…

Ach ja, in diesem Zusammenhang auch die Höhe der Bordsteine sowie die Bereiche der Absenkung mit erfassen (bicycle=slow; wheelchair=no)!!!

Und da das alles in meiner Freizeit passiert alles als leisure=* taggen

Schöne neue Technik so 'ne Datenbank (waste=no).

MHohmann · 2010-11-02T15:23:39.000Z

Noframe:

Ach ja, in diesem Zusammenhang auch die Höhe der Bordsteine sowie die Bereiche der Absenkung mit erfassen (bicycle=slow; wheelchair=no)!!!

Das kann ich als Rollstuhlfahrer nur begrüßen. Pilotprojekte dazu gibt es ja bereits. Es ist extrem nervig, wenn man einem Bürgersteig folgt, der nach 250m einfach so hinter einer Einmündung endet, ohne zwischendrin irgendwo abgesenkt zu sein.

Der Speicherbedarf kann und sollte kein Argument gegen eine genaue Erfassung von in der Realität vorhandenen Objekten wie z.B. Straßenlampen sein. Zum einen steigt die Kapazität von Speichermedien ständig an, zum anderen kann man sich für jeden Anwendungszweck die Daten extrahieren, die man benötigt - sowohl nach Datenkategorie (Straßen, Landschaftsnutzung, POIs…) als auch nach Region begrenzt. Es war bei OSM schon immer so, dass jeder das mappt, was er interessant und wertvoll findet.

wambacher · 2010-11-02T17:36:33.000Z

MHohmann:

Noframe:

Ach ja, in diesem Zusammenhang auch die Höhe der Bordsteine sowie die Bereiche der Absenkung mit erfassen (bicycle=slow; wheelchair=no)!!!

Das kann ich als Rollstuhlfahrer nur begrüßen. Pilotprojekte dazu gibt es ja bereits. Es ist extrem nervig, wenn man einem Bürgersteig folgt, der nach 250m einfach so hinter einer Einmündung endet, ohne zwischendrin irgendwo abgesenkt zu sein.

ok, da habt ihr absolut recht. das vergisst man als nicht betroffener allzu leicht. ähnlich wie die akustischen ampeln für blinde.
lg
walter

MHohmann · 2010-11-02T19:08:27.000Z

Ganz genau - nur weil man den Nutzen von etwas nicht sofort sieht, bedeutet es nicht, dass keiner existiert. Apropos: Auch an Laternen kann sich ein Bilnder orientieren, indem er sie mit seinem Stock findet und abzählt.

lworch · 2010-11-03T07:25:49.000Z

MHohmann:

…Der Speicherbedarf kann und sollte kein Argument gegen eine genaue Erfassung von in der Realität vorhandenen Objekten wie z.B. Straßenlampen sein. Zum einen steigt die Kapazität von Speichermedien ständig an, zum anderen kann man sich für jeden Anwendungszweck die Daten extrahieren, die man benötigt - sowohl nach Datenkategorie (Straßen, Landschaftsnutzung, POIs…) als auch nach Region begrenzt. Es war bei OSM schon immer so, dass jeder das mappt, was er interessant und wertvoll findet.

Nicht jeder (eher die Wenigsten(?)) ist in der Lage, sich eine Karte nach Kategorien und Regionen zusammenzubasteln. Solange diese OSM-Benutzer, so wie ich, auf die fertigen Karten von AIO oder denen von Computerteddy angewiesen sind, ist die Frage nach der Dateigröße dieser Karten (mir) nicht egal.
Wenn es ein einfach zu bedienendes Programm zum Erstellen einer Karte gibt, bei dem ich mir selbst die beinhaltenden Kategorien aussuchen kann, besteht die Problematik nicht mehr.

Nichtsdestoweniger erscheint mir das Prinzip der “genauen Erfassung von in der Realität vorhandenen Objekte” konsequent zu Ende gedacht, nicht praktikabel und sinnvoll.

MHohmann · 2010-11-03T07:43:37.000Z

lworch:

Nicht jeder (eher die Wenigsten(?)) ist in der Lage, sich eine Karte nach Kategorien und Regionen zusammenzubasteln. Solange diese OSM-Benutzer, so wie ich, auf die fertigen Karten von AIO oder denen von Computerteddy angewiesen sind, ist die Frage nach der Dateigröße dieser Karten (mir) nicht egal.
Wenn es ein einfach zu bedienendes Programm zum Erstellen einer Karte gibt, bei dem ich mir selbst die beinhaltenden Kategorien aussuchen kann, besteht die Problematik nicht mehr.

Hast du schon mal vom OSM Composer gehört?

Die Problematik besteht nicht darin, dass zu viele Daten in der Datenbank vorhanden sind, sondern darin, dass diese Daten proprietär ausgewertet werden. Beispielsweise ist es die Zielsetzung der AIO Map, möglichst viele OSM-Elemente auf einer Karte darzustellen - logischerweise wächst der Speicherbedarf dann recht schnell an, je mehr Details gemappt werden. Aber dafür gibt es ja bereits den Ansatz, die einzelnen Elemente auf verschiedene Layer zu verteilen. Andere Karten wie z.B. die Reit- und Wanderkarte haben andere Schwerpunkte. Dieses Filtern und Aufteilen der Daten je nach Nutzungszweck ist Aufgabe der Kartenersteller. Aber das sollte niemanden daran hindern, weitere Informationen in die primäre Datenbasis einzutragen, aus der diese Karten erstellt werden.

lworch · 2010-11-03T10:56:23.000Z

MHohmann:

Hast du schon mal vom OSM Composer gehört?

Danke für den Hinweis. Werde mich bei Gelegenheit darum kümmern und hoffe, dass mich die Abhängigkeiten des Programms/der Programme nicht erschlagen.

Tschüß Lutz

KatjaH · 2010-11-04T13:30:59.000Z

hmm

ich will euch ja nicht stören mit den tollen bodendeckeln und schlitz richtung

aber kann mir mal einen einen denk anstoss geben?
ich beisse mich hier grad fest

wie kann ich die strasse x in 60 teilstrecken teilen und von den schnittpunkten dann die lat und lon bekommen?

wambacher · 2010-11-04T14:32:38.000Z

KatjaH:

hmm

ich will euch ja nicht stören mit den tollen bodendeckeln und schlitz richtung

aber kann mir mal einen einen denk anstoss geben?
ich beisse mich hier grad fest

wie kann ich die strasse x in 60 teilstrecken teilen und von den schnittpunkten dann die lat und lon bekommen?

hi katja,

ich hatte angenommen, dass das thema (laternen) schon vom tisch ist. daher auch der excurs…

du kannst die natürlich durchaus in osm eintragen, wenn es dir sinnvoll erscheint.
in osm sollten aber nur objekte rein, die
a) real existieren,
b) langfristigen bestand haben und
c) deren koordinaten definiert und bekannt sind - und sei es aus luftbildern.

bei deinem anliegen ist mir noch nicht klar, was du eigentlich vorhast.
auf jeden fall haben aber nach regel c keine berechneten objekte (“diese strasse ist 500m lang und hat 50 laternen → alle 10 meter eine laterne”) in osm was zu suchen.

aber auch wenn du das “nur” ausrechnen willst, wirst du wohl um richtig kompliziertes tüfteln und programmieren nicht herumkommen. “gerade” deshalb, weil strassen nicht “gerade” sind.
ich würde mir dabei richtig einen abbrechen, falls ich das machen sollte.

an anfang dieses threads hast du geschrieben, “dass die das gerne hätten”. wer sind “die”? und warum können “die” das nicht selber, falls es “die vom katasteramt” sind?
lg
walter

MHohmann · 2010-11-10T14:52:36.000Z

Gestern habe ich das Mappen von Laternen (bzw. Lampen ganz allgemein) mit ein paar Leuten vom Hamburger Stammtisch diskutiert und jetzt folgendes Proposal erarbeitet:

http://wiki.openstreetmap.org/wiki/Proposed_features/lamp

Einige Gründe, warum ich Lampen in der Karte für sinnvoll halte, hatte ich schon einmal genannt: Sie sind weithin sichtbar, daher hilfreich bei der nächlichen Orientierung. Davon abgesehen erlauben detaillierte Informationen über die Standorte von Laternen den Ausleuchtungszustand von Straßen besser abzuschätzen als ein reines lit=yes, und damit z.B. dunkle Stellen / Wege / Gegenden zu finden und evtl. zu meiden. Außerdem sind die Informationen statistisch wertvoll, wenn man z.B. wissen möchte, wie viele Laternen an einer Straße stehen oder in einem Wohngebiet.

Und wie wambacher schon festgestellt hat, erfüllen sie die Kriterien a) real existent zu sein, b) langfristigen Bestand zu haben und c) definierte Koordinaten zu haben (die natürlich gemappt und nicht errechnet werden müssen).

Kommentare und Verbesserungsvorschläge sind natürlich immer willkommen.

GeorgFausB · 2010-11-10T15:27:04.000Z

Moin, (soviel Zeit muss sein)
aber Himmel - liest sich auch mal jemand durch, was Katja schreibt?

wambacher:

KatjaH:

hmm

ich will euch ja nicht stören mit den tollen bodendeckeln und schlitz richtung

aber kann mir mal einen einen denk anstoss geben?
ich beisse mich hier grad fest

wie kann ich die strasse x in 60 teilstrecken teilen und von den schnittpunkten dann die lat und lon bekommen?

hi katja,

ich hatte angenommen, dass das thema (laternen) schon vom tisch ist. daher auch der excurs…

du kannst die natürlich durchaus in osm eintragen, wenn es dir sinnvoll erscheint.
in osm sollten aber nur objekte rein, die

wo schreibt sie denn, dass die Daten in OSM rein sollen?
Sie will sie auf einer Karte darstellen - mit OpenLayers.
Sie benötigt nur mathematische Hilfe, die Lampen auf der Straße zu verteilen.

MHohmann:

Gestern habe ich das Mappen von Laternen (bzw. Lampen ganz allgemein) mit ein paar Leuten vom Hamburger Stammtisch diskutiert und jetzt folgendes Proposal erarbeitet:

Dein Einsatz in allen Ehren - aber ist das ein Grund, KatjaHs Thread trotz Ihrer dezenten Zwischenbemerkung weiterhin zu kapern?

Leider kann ich selbst Dir (KatjaH) mathematisch nicht helfen - aber vielleicht halten sich die Vielschreiber dann mal etwas zurück, damit Du eine evtl. Antwort nicht aus dem ganzen Rauschen filtern musst …

Gruß
Georg

MHohmann · 2010-11-10T16:40:00.000Z

GeorgFausB:

Dein Einsatz in allen Ehren - aber ist das ein Grund, KatjaHs Thread trotz Ihrer dezenten Zwischenbemerkung weiterhin zu kapern?

Das ist kein “Kapern”, schließlich bezieht sich das Proposal genau auf die Aussagen aus diesem Thread:

FK270673:

Ich finde diesen Vorschlag sehr vernünftig. Wenn man den Standort der Straßenlaternen kennt, dann kann man ungefähr abschärtzen, wie gut oder schlecht dieser Weg abends beleuchtet wird.

!i!:

Nun wie ein Baumkataster kann natürlich auch ein Straßenbeleuchtungs-Kastaster geführt werden. Das ist für die Wartung der Beleuchtung ziemlich praktisch.

Fabi2:

highway=street_lamp ist ja ähnlich schlimm wie highway=traffic_lights. Der Tag ist sicher mal wieder historisch begründet, weil amenity=* wäre da besser gewesen, sollte man mal bei Gelegenheit integrieren.

Deshalb habe ich es hier verlinkt, um die Leser / Beteiligten dieses Threads darauf aufmerksam zu machen. Das hat nichte mit “Zurückhaltung von Vielschreibern” zu tun, sondern ist nur eine Antwort auf die Diskussion, die sich hier entwickelt hat.

Bezüglich der Originalfrage: Um die Position von Laternen entlang eines Weges zu berechnen, der aus stückweise geraden Abschnitten besteht, kann man wie folgt vorgehen:

Beginne am Anfang der Straße und ordne dem Node dort den Wert 0 zu.

Folge der Straße und ordne jedem folgenden Node den Wert des vorherigen Node zu, plus den Abstand der beiden Nodes.

Der Wert jedes Nodes gibt dann an, wie weit man vom Anfang der Straße laufen muss, um zu diesem Node zu gelangen.

Der Wert des letzten Nodes ist die Länge der Straße.

Der Abstand zwischen zwei Lampen ist die Länge der Straße geteilt durch die Anzahl der Lampen.

Betrachte alle Vielfachen dieses Lampenabstandes.

Für jedes Vielfache des Lampenabstandes: Suche das die beiden Nodes heraus, zwischen denen dieses Vielfache liegt.

Berechne aus den Werten der beiden Nodes, wo auf der Verbindungsgeraden dieses Vielfache einzutragen ist.

Zeichne die Lampe genau dort ein.

Das setzt natürlich voraus, dass die Lampen 1. gleichmäßig verteilt und 2. vom Beginn der Straße an aufgestellt sind. Es könnte aber genau so gut sein, dass die erste Lampe 10m vom Beginn der Straße entfernt steht - nur wenn man diese Zusatzinformation hat, kann man wirklich die Position von gleichmäßig verteilten Objekten ausrechnen.