aber die haben mir nicht eine adresse gegeben sondern die haben mir pro strasse die anzahl der laternen gegeben
bei der niedrigsten hausnummer haben die angefangen zuzählen
das kann durchaus sein das die laterne 4 bei hausnummer 12 ist
und in der nächsten strasse ist die laterne 4 bei der hausnummer 10
hier habe ich mir eins überlegt
ich würde die strasse einfach durch die anzahl der laternen teilen
und in jeden teil eine laterne stellen
aber hier brauch ich die position lat und lon
wie bekomme ich sowas raus?
gibs da eine funktion?
zumal das ja auf der strasse sein soll und nicht auf einen haus!
Nur auch da gilt, dass es vielleicht auch garnicht allen Benutzern gefällt, geschweige denn gerendert wird.
Hast du denn mal mit den Mappern vor Ort gesprochen ob die das gutheißen würden, bevor du dich an die technische Umsetzung machst?
Herzlichen Glückwunsch zu deinem guten Kontakt zum
Katasteramt.
Laternen auf der Straße wären im allgemeinen ziemlich
ungünstig. Üblicherweise stehen Laternen neben der Straße
allerdings noch auf öffentlichem Grund und Boden.
In Innenstädten können die auch mal an einer Hauswand
angebracht sein.
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.
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.
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.
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.
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.
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
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…
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.
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
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
