Laternen etc auf einer karte einzeichnen?

FK270673 · 2010-11-01T22:27:25.000Z

KaChing_Cacher:

Kann mir einer den Nutzen erklären?

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.

Es gibt auch, gerade in Großstädten, sehr gut beleuchtete Straßen, bei denen die Darstellung einzelner Straßenlaternen unnötog ist. Es gibt aber auch, gerade in Kleinstädten, sehr schlecht beleuchtete Fußwege. Wenn man weiß, dass es an einem angeblich beleuchteten Fußweg nur zwei oder drei trübe Funzeln gibt, die schlimmstenfalls noch um Mitternacht abgeschaltet werden, dann kann man solche Wege meiden und sich an den gut beleuchteten Straßen orientieren.

Gruß FK270673

KaChing_Cacher · 2010-11-01T23:17:47.000Z

FK270673:

KaChing_Cacher:

Kann mir einer den Nutzen erklären?

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.

Es gibt auch, gerade in Großstädten, sehr gut beleuchtete Straßen, bei denen die Darstellung einzelner Straßenlaternen unnötog ist. Es gibt aber auch, gerade in Kleinstädten, sehr schlecht beleuchtete Fußwege. Wenn man weiß, dass es an einem angeblich beleuchteten Fußweg nur zwei oder drei trübe Funzeln gibt, die schlimmstenfalls noch um Mitternacht abgeschaltet werden, dann kann man solche Wege meiden und sich an den gut beleuchteten Straßen orientieren.

Gruß FK270673

Dann könnte man aber au lit ausbauen.
Anstatt lit=yes einfach lit=bad|intermediate|good.
Das könnte dann auch ein Router berücksichtigen.

MHohmann · 2010-11-02T06:59:57.000Z

Der Sinn ist ungefähr vergleichbar mit dem Sinn von Abfalleimern oder den berühmten Hundekottütenspendern in der Karte. Viele OSM-Nutzer sehen keinen bis wenig Nutzen darin, aber für den einen oder anderen könnte es sinnvoll sein. Mal ganz davon abgesehen, dass es sich um eine Orientierungshilfe handelt (“An der dritten Laterne rechts…”), 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, also warum nicht so etwas gut und weithin sichtbares wie Laternen?

Bei der Gelegenheit könnte man sogar erfassen, um welchen Lampentyp es sich handelt, also die Art der Lichtquelle (ich denke da z.b. die gelben Natriumdampflampen), und ob / wann sie nachts abgeschaltet werden, meinetwegen auch ihre Höhe, Lampenbauform (senkrecht nach unten strahlend, kugelförmig…) etc.

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