[Talk-de] weeklyOSM #760 06/02/2025-12/02/2025
Die Wochennotiz Ausgabe Nr. # 760, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17741/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS-OSM-Communitytreffen im Linuxhotel vom 16.-18.05.2025
Diese Mail geht an mehrere Listen, Mehrfachempfang bitten wir zu entschuldigen. Liebe OSM- und FOSSGIS-Aktive, wir freuen uns, am Wochenende vom 16.-18. Mai 2025 wieder zu einem FOSSGIS-OSM-Communitytreffen im Linux-Hotel in Essen einzuladen. Das Linuxhotel mit seiner guten technischen Ausstattung und dem parkähnlichen Grundstück mit Panoramablick auf die Ruhr bietet einen idealen Rahmen für kreatives Arbeiten und produktiven Austausch in lockerer, ungezwungener Atmosphäre. Weitere Informationen findet Ihr auf der Wiki-Seite: https://www.fossgis.de/wiki/FOSSGIS_OSM_Communitytreffen_2025_Nummer_23 Ihr könnt als Übernachtungsgast im Hotel, als Tages- oder auch als Campingast teilnehmen. Tragt Euch einfach in die entsprechende Tabelle auf der Wiki-Seite ein. Das Treffen bietet auch eine gute Gelegenheit für Einsteiger, die OSM- und FOSSGIS-Community kennen zu lernen. Wir freuen uns auf ein schönes Treffen mit Euch Katja & Oliver Mastodon: https://mastodon.online/@FOSSGISeV/114002809215076126 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #759 30/01/2025-05/02/2025
Die Wochennotiz Ausgabe Nr. # 759, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17731/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #758 23/01/2025-29/01/2025
Die Wochennotiz Ausgabe Nr. # 758, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17723/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #757 16/01/2025-22/01/2025
Die Wochennotiz Ausgabe Nr. # 757, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17700/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #756 09/01/2025-15/01/2025
Die Wochennotiz Ausgabe Nr. # 756, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17693/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Mittwoch, 15. Januar 2025 um 17:50 > Von: "Christian Müller" > An: talk-de@openstreetmap.org > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > *** > https://github.com/zerebubuth/openstreetmap-cgimap/blob/80e60f04466eada14f92854da9ef54a9005edc53/src/backend/apidb/changeset_upload/node_updater.cpp#L33 > > .. double lat, double lon > [..] > Wer hier double zugunsten höherer Genauigkeit > ersetzen will kann das wahlweise mit > mpdecimal / libmpdec++ (worauf auch python's Decimal basiert..) > oder z.B. num7 tun. Referenzen: > In dem Zusammenhang relevant und erwähnenswert: Einige C Compiler unterstüzten Decimal von Haus aus, z.B. der Fall bei GNU libstdc++ : * https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html * https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html * https://gcc.gnu.org/onlinedocs/gcc-5.4.0/libstdc++/api/a01722.html * https://gcc.gnu.org/onlinedocs/gcc-14.2.0/libstdc++/api/a01657.html Seit GCC7 und CLANG6 implementiert Boost.Decimal gleich zwei Varianten, eine IEEE-konform mit DPD https://en.wikipedia.org/wiki/Densely_packed_decimal und eine ohne (mit Suffix "_fast"), siehe * https://cppalliance.org/decimal/decimal.html#decimal64_fast (die _fast Typen werden damit beworben, um den Faktor 3 schneller zu arbeiten, als die IEEE- konformen) Angesichts der besseren Portabilität, sowohl Betriebssystem-, als auch Compiler-seitig und der BSD-Lizenzierung wäre m. E. die be- reits erwähnte Bibliothek mpdecimal aber die näher liegendere Wahl. Sofern man den decimal support nicht aus libboost herausoperieren kann, wäre mp- decimal überdies ein wesentlich schmaler- er Quellenimport. Zudem sind z.B. Zeichenkettenkonstruktoren Decimal(const char *const s) Decimal(const std::string &s) bei mpdecimal enthalten, die beim ISO/IEC TR 24733 basierten GNU GCC ad hoc nicht zu entdecken waren. Da der praktische Gewinn eher klein wäre, ist m.M.n. davon auszugehen, dass die Be- trachtungen zum Thema aber theoretischer Natur bleiben. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSMF - Abhängigkeiten, Bedrohungen und Lösungen
Liebe Kolleg:innen, In USA tut sich ja gerade - und für die nächsten Jahre - Ungeheuerliches. Wie ist die Abhängigkeit und die Bedrohungslage für die OSMF? Welche Szenarien sind möglich bzw. wahrscheinlich? Wie sind wir darauf vorbereitet? Was sind die Strategien? Mit besorgtem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Mittwoch, 15. Januar 2025 um 13:15 > Von: "Frederik Ramm" > An: "Christian Müller via Talk-de" > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > Hallo Christian, > > Wenn Du aber so tief einsteigen möchtest, dass Du genau analysierst, ob > und wann ein Wert zwischendurch vielleicht mal ein Float ist, dann > verlässt Du den Berech der "Referenz-Implementation" [..] > [..] siehe https://wiki.openstreetmap.org/wiki/CGImap. > > Es ist natürlich durchaus möglich, dass Deine Anmerkungen dort genauso > gelten, ich habe mir das nicht genau angeschaut. > Danke. Du merkst, dass ich diese Entwicklung nicht im Detail verfolgt habe. Die meisten meiner Aktivitäten befassten sich in der Vergangenheit eher mit JOSM. Falls CGImap anhand der Ruby-Implementation geschrieben wurde, sind die Aussagen sicherlich auch dort zutreffend. Das DB-Schema und der Umstand der Ganzzahlwandlung hin zu 4byte ints für die PostgreSQL-DB von inputseitig an die API übergebenen Dezimalzahlen als String-Typ machen da Vorgaben, die nicht allzu viel Spiel- raum lassen. Es würde mich überraschen, wenn man auf die float64 Wandlung als Interim zwischen String- Input und dem Ganzzahl-Typ für die DB ver- zichtet hat. Der Grund der Portierung ist/war die bessere Performance und der geringere Speicherbedarf. Auf diesem Weg wird niemand daran gedacht haben, den nativen Maschinentyp zugunsten höherer Genauig- keit durch einen stärker softwareabhängigen Daten- typen zu ersetzen: *** https://github.com/zerebubuth/openstreetmap-cgimap/blob/80e60f04466eada14f92854da9ef54a9005edc53/src/backend/apidb/changeset_upload/node_updater.cpp#L33 .. double lat, double lon siehe Funktionssignaturen von add_node, modify_node new_node.lat = round(lat * global_settings::get_scale()); [..] entspricht der Ruby-Referenz ziemlich genau. Wer hier double zugunsten höherer Genauigkeit ersetzen will kann das wahlweise mit mpdecimal / libmpdec++ (worauf auch python's Decimal basiert..) oder z.B. num7 tun. Referenzen: * https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software * https://www.bytereef.org/mpdecimal/doc/libmpdec++/decimal.html#_CPPv4NK7decimal6scalebERK7DecimalR7Context * https://www.bytereef.org/mpdecimal/doc/libmpdec++/decimal.html#_CPPv4NK7decimal11to_integralER7Context *** https://github.com/zerebubuth/openstreetmap-cgimap/blob/80e60f04466eada14f92854da9ef54a9005edc53/include/cgimap/backend/apidb/changeset_upload/node_updater.hpp#L48 Interessanterweise sind die Felder lat und lon bereits als int64_t deklariert. *** https://github.com/zerebubuth/openstreetmap-cgimap/blob/80e60f04466eada14f92854da9ef54a9005edc53/src/backend/apidb/changeset_upload/node_updater.cpp#L277 führt einen cast dieser Felder auf int, also kleineren Typ durch (equiv. postgre int4). Mir ist unbekannt, ob das Postgre- C++ Binding hier einen Überlauf erkennen würde (Ausnahmebehandlung?); relevant, falls in den global_settings eine größere SCALE verwendet wird, ohne das DB-Schema ebenfalls anzupassen. Ab ruby 2.3.0 stand ein Weg zur Verfügung, Ruby-Code vorzukompilieren, in bytecode für die RubyVM; dennoch langsamer als ein gut optimiertes C++ Programm. Der Memory-Foot- print bei verschiedenen Ruby-Implementation- en scheint stark zu variieren: https://programming-language-benchmarks.vercel.app/ruby-vs-cpp (peak-mem Wert) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Hallo Christian,
ich habe Dich mit meinem Link zur Ruby-Dokumentation da ein bisschen in
die falsche Richtung geschickt. Die Ruby-basierte Webseite ist zwar
unsere "Referenz-Implementation", was die API-Funktionen anbetrifft und
auch solche Fragen wie "was für ein Datenbanktyp wird für die
Eigenschaft X genutzt".
Wenn Du aber so tief einsteigen möchtest, dass Du genau analysierst, ob
und wann ein Wert zwischendurch vielleicht mal ein Float ist, dann
verlässt Du den Berech der "Referenz-Implementation" und musst in den
Code gucken, der in der Praxis auf openstreetmap.org eingesetzt wird.
Das ist aber für die allermeisten daten-bezogenen API-Funktionen (nicht
für alle) inzwischen "cgimap", welches in C++ und nicht in Ruby
geschrieben ist, siehe https://wiki.openstreetmap.org/wiki/CGImap.
Es ist natürlich durchaus möglich, dass Deine Anmerkungen dort genauso
gelten, ich habe mir das nicht genau angeschaut.
Bye
Frederik
On 15/01/2025 10:05, Christian Müller via Talk-de wrote:
Gesendet: Montag, 13. Januar 2025 um 11:45
Von: "Frederik Ramm"
An: "Christian Müller via Talk-de"
Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
(Nachkommastellen)
In OSM werden die Daten intern nicht als float-Werte gespeichert,
sondern als Ganzzahlen, und vorher mit 1E7 multipliziert:
https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/concerns/geo_record.rb#L17-L20
Bevor die Wandlung in eine Ganzzahl erfolgt,
führt die API mit den Upload-Daten das hier
durch:
https://github.com/openstreetmap/openstreetmap-website/blob/914fff9d4dec3d502d524f5b0f60797f66f8af65/app/models/node.rb#L91
(node.lat = OSM.parse_float...)
https://github.com/openstreetmap/openstreetmap-website/blob/914fff9d4dec3d502d524f5b0f60797f66f8af65/lib/osm.rb#L510
(parse_float def)
Float(..) in der Funktion parse_float
wandelt eingehende Längen- und Breitengradwerte,
die als Zeichenkette an die API übermittelt werd-
en in den Ruby-Typ Float (laut Ruby-Dok ist das
nativ float64)
Neben der in der vorigen mail bereits erwähnten
"Alternative mittels Zeichenkettenoperationen"
zur Wandlung dieser Werte in das von der DB
verwendete Ganzzahlformat, bestünde noch die
Alternative mittels Decimal (in Ruby BigDecimal):
--
def to_int(l):
... r = Decimal(l) * Decimal('1e7')
... r = r.quantize(Decimal('1.'), rounding=ROUND_HALF_UP)
... return int(r)
...
to_int(1.67772165)
16777217
to_int(1.67772175)
16777217
Decimal(1.67772175) * Decimal('1e7')
Decimal('16777217.400637703831')
to_int('1.67772175')
16777218
Quellen:
https://docs.python.org/3/library/decimal.html
https://ruby-doc.org/stdlib-3.1.0/libdoc/bigdecimal/rdoc/BigDecimal.html
Die letzten beiden Beispiele unterscheiden
sich darin, welcher Typ dem Konstruktur von
Decimal übergeben wird. Beim ersten wird das
Literal 1.67772175 zunächt in den nativen
Fließkommazahltyp gewandelt und dessen Wert
von Decimal übernommen. Dieser Zwischenschritt
enfällt, wenn Decimal direkt mit der Zeichenket-
te konstruiert wird (die bei der OSM-API während
des Uploads so vorliegt..).
Die Ruby-Dokumentation, siehe letzte Quellen-
angabe, zu BigDecimal schreibt:
"Decimal arithmetic is also useful for general
calculation, because it provides the correct
answers people expect–whereas normal binary
floating point arithmetic often introduces
subtle errors because of the conversion between
base 10 and base 2."
Für Java existieren Angaben, dass BigDecimal
um den Faktor 1000 langsamer sein kann, als
Double. Außerdem wäre der Speicherbedarf etwas
höher, während die API die Anfrage bearbeitet.
Im Kontext Ruby lassen sich ad hoc keine brauch-
baren Benchmarks finden, aber es ist anzunehmen,
dass die Situation ähnlich ist.
Man könnte im Ruby-Code beide (bzw. alle drei)
Varianten parallel implementieren und auf einem
Testserver messen, ob der Unterschied produktiv
relevant wäre.
Falls sich herausstellt, dass der Einsatz von
Float für die Performance nicht kritisch ist,
kann man die Wiedergabetreue von Werten, die
an die DB übermittelt wurden, erhöhen. Ob das
beim praktischen Einsatz bemerkt würde, ist
eine andere Frage.
Der Effekt müsste sich unabhängig davon ein-
stellen, wie groß SCALE gewählt wird, also
auch unter Beibehaltung des derzeitigen Werts
samt 'int4'-Typ für die Datenhaltung (mini-
male) Vorteile bringen.
Gruß
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Montag, 13. Januar 2025 um 11:45
> Von: "Frederik Ramm"
> An: "Christian Müller via Talk-de"
> Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
> (Nachkommastellen)
>
> In OSM werden die Daten intern nicht als float-Werte gespeichert,
> sondern als Ganzzahlen, und vorher mit 1E7 multipliziert:
>
> https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/concerns/geo_record.rb#L17-L20
Bevor die Wandlung in eine Ganzzahl erfolgt,
führt die API mit den Upload-Daten das hier
durch:
https://github.com/openstreetmap/openstreetmap-website/blob/914fff9d4dec3d502d524f5b0f60797f66f8af65/app/models/node.rb#L91
(node.lat = OSM.parse_float...)
https://github.com/openstreetmap/openstreetmap-website/blob/914fff9d4dec3d502d524f5b0f60797f66f8af65/lib/osm.rb#L510
(parse_float def)
Float(..) in der Funktion parse_float
wandelt eingehende Längen- und Breitengradwerte,
die als Zeichenkette an die API übermittelt werd-
en in den Ruby-Typ Float (laut Ruby-Dok ist das
nativ float64)
Neben der in der vorigen mail bereits erwähnten
"Alternative mittels Zeichenkettenoperationen"
zur Wandlung dieser Werte in das von der DB
verwendete Ganzzahlformat, bestünde noch die
Alternative mittels Decimal (in Ruby BigDecimal):
--
>>> def to_int(l):
... r = Decimal(l) * Decimal('1e7')
... r = r.quantize(Decimal('1.'), rounding=ROUND_HALF_UP)
... return int(r)
...
>>> to_int(1.67772165)
16777217
>>> to_int(1.67772175)
16777217
>>> Decimal(1.67772175) * Decimal('1e7')
Decimal('16777217.400637703831')
>>> to_int('1.67772175')
16777218
Quellen:
https://docs.python.org/3/library/decimal.html
https://ruby-doc.org/stdlib-3.1.0/libdoc/bigdecimal/rdoc/BigDecimal.html
Die letzten beiden Beispiele unterscheiden
sich darin, welcher Typ dem Konstruktur von
Decimal übergeben wird. Beim ersten wird das
Literal 1.67772175 zunächt in den nativen
Fließkommazahltyp gewandelt und dessen Wert
von Decimal übernommen. Dieser Zwischenschritt
enfällt, wenn Decimal direkt mit der Zeichenket-
te konstruiert wird (die bei der OSM-API während
des Uploads so vorliegt..).
Die Ruby-Dokumentation, siehe letzte Quellen-
angabe, zu BigDecimal schreibt:
"Decimal arithmetic is also useful for general
calculation, because it provides the correct
answers people expect–whereas normal binary
floating point arithmetic often introduces
subtle errors because of the conversion between
base 10 and base 2."
Für Java existieren Angaben, dass BigDecimal
um den Faktor 1000 langsamer sein kann, als
Double. Außerdem wäre der Speicherbedarf etwas
höher, während die API die Anfrage bearbeitet.
Im Kontext Ruby lassen sich ad hoc keine brauch-
baren Benchmarks finden, aber es ist anzunehmen,
dass die Situation ähnlich ist.
Man könnte im Ruby-Code beide (bzw. alle drei)
Varianten parallel implementieren und auf einem
Testserver messen, ob der Unterschied produktiv
relevant wäre.
Falls sich herausstellt, dass der Einsatz von
Float für die Performance nicht kritisch ist,
kann man die Wiedergabetreue von Werten, die
an die DB übermittelt wurden, erhöhen. Ob das
beim praktischen Einsatz bemerkt würde, ist
eine andere Frage.
Der Effekt müsste sich unabhängig davon ein-
stellen, wie groß SCALE gewählt wird, also
auch unter Beibehaltung des derzeitigen Werts
samt 'int4'-Typ für die Datenhaltung (mini-
male) Vorteile bringen.
Gruß
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Montag, 13. Januar 2025 um 11:45
> Von: "Frederik Ramm"
> An: "Christian Müller via Talk-de"
> Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
> (Nachkommastellen)
>
> In OSM werden die Daten intern nicht als float-Werte gespeichert,
> sondern als Ganzzahlen, und vorher mit 1E7 multipliziert:
>
> https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/concerns/geo_record.rb#L17-L20
[..] welche die Funktion "round" nach der
Skalierung verwenden.
Noch fortführend dazu:
==
Zwei Beispiele bei denen das Runden vor
Skalierung von Vorteil ist (single float
wegen der überschaubareren Demonstrierbar-
keit):
>>> import numpy as np
>>> np.single(round(1.677721705, 7))
1.6777217
>>> np.single(round(1.677721705, 7))*1e7
16777217.388153076
>>> np.single(round(1.677721705, 7))*np.single(1e7)
16777218.0
>>> np.single(round(1.677721705*1e7))
16777216.0
>>> np.single(round(1.677721749, 7))
1.6777217
>>> np.single(round(1.677721749, 7))*np.single(1e7)
16777218.0
>>> np.single(round(1.677721749*1e7))
16777216.0
Gegenbeispiel:
>>> np.single(round(1.677721655, 7))
1.6777217
>>> np.single(round(1.677721655, 7))*np.single(1e7)
16777218.0
>>> np.single(round(1.677721655*1e7))
16777216.0
Rein mathematisch, also falls jeder reelle Wert re-
präsentierbar wäre, stellt sich die Frage nach dem
Rundungszeitpunkt nicht: Man würde vermeiden, Rund-
ungsfehler zu skalieren.
Alternative mittels Zeichenkettenoperationen:
-
Womöglich ohne obige Probleme, aber weit weniger performant,
kann der Umweg über Zeichenkettentypen sein, wobei es die
Randbedingung gibt, dass die Eingabe-Fließkommazahl in der
jew. Programmierumgebung möglichst ohne Rundung in eine
Zeichenkette wandelbar ist:
>>> def to_int(l):
... s = str(l)
... s = s + ('.' if s.find('.')<0 else '') + '0'*15
... d = s.find('.')
... e = d+1+7
... r = int(s[e:e+1])
... n = int(s[0:d] + s[d+1:e])
... return n + (0 if r<5 else (-1 if n<0 else 1))
...
(hier mit "away from zero" Rundungsstrategie;
Aufruf ggf. mittels struct.pack('i', to_int(l))
um das Ergebnis in den Maschinentyp zu packen
– https://docs.python.org/3.7/library/struct.html)
Zur Problematik, floats in Zeichenketten zu wandeln,
um sie ohne builtin-Rundung abzuschneiden gibt es
noch fortführend diesen post von vor 15+ Jahren:
https://stackoverflow.com/questions/783897/how-to-truncate-float-values
Das entfernt sich aber vom Thema der Mailingliste.
Gruß
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewässer kartieren
Hallo, wenn du den waterway einträgst, solltest du zunächst die Geometrie des Fuss-Rad-Wegs korrigieren (mit Bing oder Strava Global Heatmap) und außerdem die tags korrigieren: highway=path; bicycle=designated; foot=designated; segregated=no. Ich würde auch die Verklebung des landuse mit dem Fuss-Rad-Weg und der Strasse entfernen. Da steht z. B. eine Baumreihe im Feld. Volker On Mon, 13 Jan 2025 at 20:46, Tom Pfeifer wrote: > Und natürlich kannst du die Geometrie anhand eines anderen Objektes auch > schätzen, das würde ich > dann im Fixme vermerken. > > Tom > > On 13.01.2025 19:27, Heinz-Jürgen Oertel wrote: > > Gabriel > > > > der Bach ist auch auf Bing zu sehen. Diese Bilder darf man zum Kartieren > > nutzen. Ich habe es einmal versucht. Auf dem Weg vom Ort zum See ist der > > Verlauf gut zu sehen. Im Dorf eher schlecht. > > > > Heinz > > > > Am Montag, 13. Januar 2025, 17:30:27 CET schrieb Gabriel Bandow: > >> Hallo in die Runde, > >> > >> eigentlich wollte ich bloß einen harmlosen neuen Radweg einzeichnen. Nun > >> wird das Projekt wohl etwas größer, denn mit dem Radweg wurde auch eine > >> Brücke über einen kleinen Bach gebaut, der in den OSM-Daten noch nicht > >> enthalten ist. Nun frage ich mich: Wie stelle ich das Kartieren des > >> Gewässers am besten an? Soll ich es mit GPS-Aufzeichnung entlang laufen, > >> soweit es geht? Der Bach mündet in den Rühner See und ist bei Google > Maps > >> dargestellt. > >> > >> Hier zur Orientierung mal der Straßenabschnitt, an dem der Radweg > verläuft: > >> Weg: 35326419 | OpenStreetMap > >> <https://www.openstreetmap.org/way/35326419#map=16/53.84361/11.94231> > . Der > >> Bach kreuzt die Straße L14 kurz hinter dem Ortsausgang von Steinhagen. > >> > >> Ich freue mich auf eure Ideen. > >> > >> > >> > >> Beste Grüße, Gabriel > >> > >> > >> _______ > >> Talk-de mailing list > >> Talk-de@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk-de > > > > > > > > > > ___________ > > Talk-de mailing list > > Talk-de@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-de > > > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [EXT] Re: [EXT] Re: Grenze Jordanien / Syrien
Hallo Markus, keine (echte) Ahnung, ich kann nur auf die Historie des Datensatzes verweisen, vgl. https://www.openstreetmap.org/way/996965134/history Nach Google-Übersetzung heißt es dort: * Version Nr. 1: ungefähre Grenzen der Bezirke und Unterbezirke Jordaniens * Version Nr. 2: Die Grenzen von Syrien und Jordanien * Version Nr. 3: Auffällige Inkongruenz der Randsegmente mit der Quelle. * Version Nr. 4: Hinzufügen von Details zur Grenze zwischen Joran und Syrien, um ihren Ursprung zu verfeinern. Der Quelltag war ein Überbleibsel von vor 13 Jahren und vor 12 Jahren wurde die Grenze neu kartiert, um der Grenze vor Ort zu folgen, aber der Quelltag wurde nicht entfernt. BG, mikeE. -Ursprüngliche Nachricht- Von: Markus Gesendet: Samstag, 11. Januar 2025 10:10 An: Elstermann, Mike Betreff: [EXT] Re: [Talk-de] [EXT] Re: Grenze Jordanien / Syrien Hallo Mike, Ja, das sehe ich auch so - aber woher kommt die Änderung? - durch internationalen Vertrag? - Krieg (das wäre ja keine Grenzänderung) - Mappingunfall? Gruss, Markus Am 09.01.2025 um 08:45 schrieb Elstermann, Mike: > In den Daten sind die Grenzen gleich, vgl. > https://www.openstreetmap.org/#map=13/32.37489/36.93913&layers=D > Möglicherweise wurde bei Openseamap noch nicht neu gerendert? > > BG, mikeE. > > -Ursprüngliche Nachricht- > Von: Thomas Butz via Talk-de > Gesendet: Mittwoch, 8. Januar 2025 14:46 > An: Markus via Talk-de > Cc: Thomas Butz > Betreff: [EXT] Re: [Talk-de] Grenze Jordanien / Syrien > > ACHTUNG : Diese E-Mail stammt von einem externen Absender (außerhalb der > SWH-Gruppe). Bitte höchste Vorsicht mit Dateianhängen und Hyperlinks! Im > Zweifelsfall wird empfohlen, den Absender (z.B. per Telefon) zu kontaktieren > und die Echtheit der E-Mail zu prüfen. > Tippe auf Caching der Tiles > > >> Liebe Kollegen, >> >> Hier verändert sich die Grenze zwischen z=14 und z=13: >> https://map.openseamap.org/?zoom=13&lon=36.91750&lat=32.33137&mlat=32.335&mlon=37.00&mtext=Trinkwasserreservoir&layers=TFTTFTTFFTFFTF >> >> >> Hier aber nicht: >> https://www.openstreetmap.org/#map=13/32.33137/36.91750 >> >> Welche Grenze ist richtig? >> Woher kommt der Unterschied? >> >> Gruss, Markus >> >> _______ >> Talk-de mailing list >> Talk-de@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Montag, 13. Januar 2025 um 11:45
> Von: "Frederik Ramm"
> An: "Christian Müller via Talk-de"
> Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
> (Nachkommastellen)
>
> In OSM werden die Daten intern nicht als float-Werte gespeichert,
> sondern als Ganzzahlen, und vorher mit 1E7 multipliziert:
>
> https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/concerns/geo_record.rb#L17-L20
>
> Bye
> Frederik
In derselben ruby Datei finden sich ab Zeile 40
Umrechnungsfunktionen für Fließkommaeingabewerte,
welche die Funktion "round" nach der Skalierung
verwenden.
Nachtrag: Details zu Python's round()
==
The rounding half to even strategy is the strategy that Python’s built-in
round() function uses, and it’s the default rounding rule in the IEEE-754
standard. This strategy works under the assumption that there’s an equal
probability of rounding a tie in a dataset down or up. In practice, this is
usually the case.
Quelle:
https://realpython.com/python-rounding/#better-rounding-strategies-in-python
Daraus resultieren die Fragen, ob diese Rundungs-
strategie auch bei ruby verwendet wird, und ob
sie für Geoanwendungen sinnvoll ist.
Am Quelltext allein lässt sich nicht zweifelsfrei
erkennen, ob Skalierung und Rundung bei den Setter-
Funktionen mit double oder single precision erfolgen.
self.latitude = (l * SCALE).round
Zum Beispiel würden sowohl 179.9995 als auch
179.9985 unter Verwendung von single floats
schon vor der Rundung in 180 gewandelt werden,
leicht nachprüfbar u. a. mittels
https://www.h-schmidt.net/FloatConverter/IEEE754.html
oder
https://evanw.github.io/float-toy/
(zusätzlich mit float64 support)
Die Ruby-Dokumentation schreibt
"Float objects represent inexact real numbers using the
native architecture's double-precision floating point
representation."
Quelle(n):
https://ruby-doc.org/core-2.5.9/Float.html
https://rubyapi.org/3.3/o/float
..womit l vor der Wandlung nach int4 als float64 be-
handelt werden dürfte.
Die round Funktion ist konfigurierbar:
If keyword argument half is given, and self is equidistant
from the two candidate values, the rounding is according
to the given half value:
:up or nil: round away from zero:
Quelle(n):
https://rubyapi.org/3.3/o/float#method-i-round
Python ist/war also ungeeignet für eine Simulation, da
es standardmäßig "half to even" als Rundungsstrategie,
statt "round away from zero" einsetzt:
Verschiebungen finden also westlich von Greenwich
im ungünstigsten Fall um 5cm nach Westen, und
östlich von Greenwich um 5cm nach Osten statt.
(".. wenn hochgeladene und anschließend wieder abge-
rufene Längenangaben mittig zweier benachbarter, von
der DB repräsentierbaren Werte lagen")
Der Zeitpunkt der Rundung
(vor/nach Multiplikation mit SCALE) ist damit ein-
hergehend, /praktisch/ weniger entscheidend, als wenn
float32 benutzt würde. Dennoch kann man hier überlegen,
ob eine Rundung vor Skalierung besser wäre, da nach IEEE
zum nächstgelegenen, repräsentierbaren Wert gerundet wird
und diese nahe 0 dichter gelegen sind, als bei größeren
Zahlen, die nach der Skalierung vorliegen.
Siehe dazu u. a.
https://en.wikipedia.org/wiki/Floating-point_arithmetic#Rounding_modes
Gruß
_______
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Montag, 13. Januar 2025 um 11:45 > Von: "Frederik Ramm" > An: "Christian Müller via Talk-de" > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > In OSM werden die Daten intern nicht als float-Werte gespeichert, > sondern als Ganzzahlen, und vorher mit 1E7 multipliziert: > > https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/concerns/geo_record.rb#L17-L20 > > Bye > Frederik In derselben ruby Datei finden sich ab Zeile 40 Umrechnungsfunktionen für Fließkommaeingabewerte, welche die Funktion "round" nach der Skalierung verwenden. Das kann merkwürdige Effekte haben: >>> round(0.0095*1e7) 10 >>> round(0.0085*1e7) 8 >>> round(179.9995*1e7) 18 >>> round(179.9985*1e7) 179998 >>> float(int(round(179.9995*1e7)))/1e7 180.0 >>> float(int(round(179.9985*1e7)))/1e7 179.998 >>> float(int(round((-3+.9995)*1e7)))/1e7 -2.0 >>> float(int(round((-2+.9995)*1e7)))/1e7 -1.001 Die letzten Zeilen simulieren (hier mit python) Wandlung zu int4 und Rückwandlung zu float für den Datenabruf. Für einen Nutzer wird dieses Phänomen so deutlich, dass manche Koordinaten nach Osten, manche leicht nach Westen verschoben werden, wenn ein hochge- ladener und anschließend wieder abgerufener Daten- satz Längenangaben ursprünglich so enthielt, dass sie nahe oder auf der Mitte zweier benachbarter, von der DB repräsentierbaren Werte lagen. (bei Editoren, welche keine höhere Präzision als die der DB bei der Erfassung und Darstellung ver- wenden oder zulassen ist das irrelevant) Mit der angesprochenen Präzision von 10 cm am Äquator, läge der Fehler der dadurch entsteht im ungünstigsten Fall bei 5 cm, rundungsbezogen wie angesprochen mal nach Osten, mal nach Westen ver- setzt. Dieses Problem bestünde bei der Einführung einer oder mehrerer weiterer Nachkommastellen fort, dann kleinere Distanzen betreffend. Die Ursache liegt darin begründet, dass nicht alle reellen Werte mit IEEE-Fließkommazahlen darstellbar sind. Da die Lücken nicht gleichverteilt sind, spielt es z.B. auch eine Rolle, ob vor oder nach der Skalierung gerundet wird: >>> float(int(round(3+.9995, 7)*1e7))/1e7 3.999 >>> float(int(round((3+.9995)*1e7)))/1e7 4.0 Anschauungsbeispiel(e): https://commons.wikimedia.org/wiki/File:FloatingPointPrecisionAugmented.png https://commons.wikimedia.org/wiki/File:Denormalized_numbers_on_a_line.svg Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen) (Korrekturnachträge)
[..] Mit int4 und dem Skalierungsfaktor 10.000.000 liegt demnach der Maximalwert für eine Längen/Breitenangabe bei (2^31-1) / 1E7 = 2.147.483.647 / 1E7 = 214,7483647 (Grad) (EDIT: 2^31-1 geklammert) [..] was weder für Breitengrad- (-90 ≤ x ≤ 90) noch Längen- gradwerte (-180.0 ≤ x ≤ 180.0) ausreichend wäre. (EDIT: upper bound für Längengrad enthielt copy+paste Fehler) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Montag, 13. Januar 2025 um 11:45 > Von: "Frederik Ramm" > An: "Christian Müller via Talk-de" > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > In OSM werden die Daten intern nicht als float-Werte gespeichert, > sondern als Ganzzahlen, und vorher mit 1E7 multipliziert: > > https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/concerns/geo_record.rb#L17-L20 > > Bye > Frederik Danke für den Link. Interessanterweise trifft das nicht alle Strukturen der DB: https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/db/structure.sql#L1006 https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/node.rb (Wiederholung im header comment) Dort ist zu erkennen, das für die Tabellen * nodes (obige links), gps_points und notes integer, aber für * gpx_files, diary_entries (link unten) double precision verwendet wird. https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/db/structure.sql#L716 Die Bedeutung/Länge des Typs integer im Kontext SQL ist implementations-abhängig. Bei MS ACCESS wurden beispielsweise 2 byte verwendet, bei MSSQL, MySQL u.ä. 4 byte. Quelle: https://www.w3schools.com/sql/sql_datatypes.asp Bei Oracle ist INTEGER (entgegen ANSI) gar ein Alias für NUMBER(38): The INTEGER data type is an ANSI standard data type, which means it is in all SQL databases. However, in Oracle, it's a synonym for NUMBER(38). This means that if you declare an INTEGER column, Oracle is actually declaring a NUMBER column with 38 digits and 0 decimal places. Quelle: https://www.databasestar.com/oracle-data-types/#Numeric_Data_Types (dort erhält man den 4 byte Typ mit Alias BINARY_INTEGER) Seit April 2009 wird für OSM PostgreSQL verwendet. Quelle: https://wiki.openstreetmap.org/wiki/Database Und laut dem dort angegebenen Schema, siehe https://wiki.openstreetmap.org/wiki/File:OSM_DB_Schema_2016-12-13.svg werden latitude und longitude der Tabelle nodes als Spalten vom Typ "int4" definiert. Falls das noch so ist, trifft diese Erläuterung zu: "SQL only specifies the integer types integer (or int), smallint, and bigint. The type names int2, int4, and int8 are extensions, which are also used by some other SQL database systems." Quelle: https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-INT Mit int4 und dem Skalierungsfaktor 10.000.000 liegt demnach der Maximalwert für eine Längen/Breitenangabe bei 2^31-1 / 1E7 = 2.147.483.647 / 1E7 = 214,7483647 (Grad) Soll eine weitere Nachkommastelle abspeicherbar sein, also der Skalierungsfaktor 1E8 verwendet werden, ändert sich der Wertebereich unter Beibehaltung von int4 auf -21,47483648 ≤ x ≤ 21,47483647 was weder für Breitengrad- (-90 ≤ x ≤ 90) noch Längen- gradwerte (-180.0 ≤ x ≤ 90) ausreichend wäre. Die ursprüngliche Rechnung, die sich auf die Mehrin- anspruchnahme bei Verwendung von "float64" anstatt "float32" bezog, ist also 1:1 übertragbar, falls das DB-Schema statt "int4" die Typen "bigint" bzw. "int8" zum Abspeichern von latitude und longitude einsetzen würde. Gruß _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewässer kartieren
Und natürlich kannst du die Geometrie anhand eines anderen Objektes auch schätzen, das würde ich dann im Fixme vermerken. Tom On 13.01.2025 19:27, Heinz-Jürgen Oertel wrote: > Gabriel > > der Bach ist auch auf Bing zu sehen. Diese Bilder darf man zum Kartieren > nutzen. Ich habe es einmal versucht. Auf dem Weg vom Ort zum See ist der > Verlauf gut zu sehen. Im Dorf eher schlecht. > > Heinz > > Am Montag, 13. Januar 2025, 17:30:27 CET schrieb Gabriel Bandow: >> Hallo in die Runde, >> >> eigentlich wollte ich bloß einen harmlosen neuen Radweg einzeichnen. Nun >> wird das Projekt wohl etwas größer, denn mit dem Radweg wurde auch eine >> Brücke über einen kleinen Bach gebaut, der in den OSM-Daten noch nicht >> enthalten ist. Nun frage ich mich: Wie stelle ich das Kartieren des >> Gewässers am besten an? Soll ich es mit GPS-Aufzeichnung entlang laufen, >> soweit es geht? Der Bach mündet in den Rühner See und ist bei Google Maps >> dargestellt. >> >> Hier zur Orientierung mal der Straßenabschnitt, an dem der Radweg verläuft: >> Weg: 35326419 | OpenStreetMap >> <https://www.openstreetmap.org/way/35326419#map=16/53.84361/11.94231> . Der >> Bach kreuzt die Straße L14 kurz hinter dem Ortsausgang von Steinhagen. >> >> Ich freue mich auf eure Ideen. >> >> >> >> Beste Grüße, Gabriel >> >> >> ___ >> Talk-de mailing list >> Talk-de@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-de > > > > > ___________ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewässer kartieren
Gabriel der Bach ist auch auf Bing zu sehen. Diese Bilder darf man zum Kartieren nutzen. Ich habe es einmal versucht. Auf dem Weg vom Ort zum See ist der Verlauf gut zu sehen. Im Dorf eher schlecht. Heinz Am Montag, 13. Januar 2025, 17:30:27 CET schrieb Gabriel Bandow: > Hallo in die Runde, > > eigentlich wollte ich bloß einen harmlosen neuen Radweg einzeichnen. Nun > wird das Projekt wohl etwas größer, denn mit dem Radweg wurde auch eine > Brücke über einen kleinen Bach gebaut, der in den OSM-Daten noch nicht > enthalten ist. Nun frage ich mich: Wie stelle ich das Kartieren des > Gewässers am besten an? Soll ich es mit GPS-Aufzeichnung entlang laufen, > soweit es geht? Der Bach mündet in den Rühner See und ist bei Google Maps > dargestellt. > > Hier zur Orientierung mal der Straßenabschnitt, an dem der Radweg verläuft: > Weg: 35326419 | OpenStreetMap > <https://www.openstreetmap.org/way/35326419#map=16/53.84361/11.94231> . Der > Bach kreuzt die Straße L14 kurz hinter dem Ortsausgang von Steinhagen. > > Ich freue mich auf eure Ideen. > > > > Beste Grüße, Gabriel > > > _______ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gewässer kartieren
Hallo in die Runde, eigentlich wollte ich bloß einen harmlosen neuen Radweg einzeichnen. Nun wird das Projekt wohl etwas größer, denn mit dem Radweg wurde auch eine Brücke über einen kleinen Bach gebaut, der in den OSM-Daten noch nicht enthalten ist. Nun frage ich mich: Wie stelle ich das Kartieren des Gewässers am besten an? Soll ich es mit GPS-Aufzeichnung entlang laufen, soweit es geht? Der Bach mündet in den Rühner See und ist bei Google Maps dargestellt. Hier zur Orientierung mal der Straßenabschnitt, an dem der Radweg verläuft: Weg: 35326419 | OpenStreetMap <https://www.openstreetmap.org/way/35326419#map=16/53.84361/11.94231> . Der Bach kreuzt die Straße L14 kurz hinter dem Ortsausgang von Steinhagen. Ich freue mich auf eure Ideen. Beste Grüße, Gabriel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Hallo, On 11/01/2025 23:33, Christian Müller via Talk-de wrote: Auch wenn die OSM-DB "nur" mit einer float Genauigkeit Daten ab- speichert, In OSM werden die Daten intern nicht als float-Werte gespeichert, sondern als Ganzzahlen, und vorher mit 1E7 multipliziert: https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/concerns/geo_record.rb#L17-L20 Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #755 02/01/2025-08/01/2025
Die Wochennotiz Ausgabe Nr. # 755, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17687/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
sent from a phone > On 11 Jan 2025, at 19:29, Christian Müller via Talk-de > wrote: > > Die Diskussion ist übertragbar auf die Sinnhaftigkeit von SUVs die SUVs bzw. deren Mitführen in der Öffentlichkeit sollte sofort verboten werden, und regelmäßig kontrolliert, damit sind nun wirklich schon genug Attentate verübt worden, ich weiß nicht wielange die Politik noch untätig zusehen will (und als Miteigner von VW ggf. sogar davon profitiert dass diese Mordwaffen produziert und gekauft werden). ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Die Links https://de.wikipedia.org/wiki/Gleitkommazahl#Ung%C3%BCltigkeit_der_Assoziativ-_und_Distributivgesetze https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems https://en.wikipedia.org/wiki/Floating-point_arithmetic#Minimizing_the_effect_of_accuracy_problems beschreiben das Problem, dass mathematisch gleich- wertige Formeln in ihrer algorithmischen Umsetzung für die Maschine, und basierend auf den IEEE Fließ- kommazahltypen, unter Umständen deutlich unter- schiedliche Ergebnisse erzielen. Für die Berechnung von pi stellt der dritte Link exemplarisch zwei Wege dar, wovon nur einer in der maschinellen IEEE-Umsetzung hin zur korrekten Lösung konvergiert. Die Wahl des Datentyps ist nicht allein ausschlag- gebend für die Koordinatengenauigkeit oder den Er- halt selbiger bei Erfassung, Änderung und ggf. Wiederverwendung eines Datensatzes. Bei ungeschickter Wahl der Rechenverfahren z.B. für die Editieroperationen kann es zu Auslöschungen https://de.wikipedia.org/wiki/Gleitkommazahl#Ausl%C3%B6schung Absorptionen, Unter- oder Überläufen kommen. Da die beschriebenen Probleme vollumfänglich auf alle IEEE Typen zutreffen, darf man aber m. E. schließen, dass eine ausgereifte Funktion, die bereits dahingehend optimiert wurde, solche Genauigkeitsprobleme zu mini- mieren, nicht weniger präzise arbeitet, wenn sie mit Variablen vom doppelt breiten Datentyp aus der gleich- en Familie arbeitet. Demnach wäre der Aufwand vertretbar, solche Anwendungen, die nicht mit "double" OSM-Daten verarbeiten, umzustell- en, falls eine (hypothetische..) Umstellung des OSM-Back- ends in dem Modus erfolgt, dass man Rückwärtskompatibilität ausschließt. Dieser Ausschluß könnte dann Sinn machen, wenn alle Daten- sätze an einem Tag x konvertiert wurden, und zu befürchten ist, dass alte Editoren im Zyklus Laden-Editieren-Speichern eine höhere Genauigkeit überschreiben, wenn/solange sie intern auf float32 Datentypen operieren.. .. alternativ dazu, allerdings mit höherem programmatischen Aufwand, könnte die OSM-API wahlweise den Edit von Koord- inaten solange zulassen, wie sie im Bestandsformat vor- liegen. D.h. eine Aktualisierung durch float32 Anwendungen würde erst dann von der API abgelehnt, nachdem eine float64 Anwendung lat/lon Werte mit höherer Genauigkeit für eine bestimmte Koordinate übermittelt hat und damit den Daten- satz "befördert" hat bzw. intern ein dafür vorgesehenes Flag gesetzt hat. (In diesem Modus ließe man intern die Koexistenz beider Formate zu, bis die letzte Koordinate per Edit konvertiert wurde.) .. oder man führt einen weiteren Elementtyp ein, etwa "node64", sofern man der Überzeugung ist, dass höhere Präzision dauerhaft nur eine untergeordnete Rolle spielt. Auch in diesem Fall müssten alle Tools den Umgang damit lernen, da ansonsten wegen des Sichtproblems (die einen sehen und bearbeiten Daten diesen Typs; die anderen er- halten sie gar nicht..) mit Doppeleinträgen, also sowohl als "node" als auch als "node64" zu rechnen ist. (daher sei von diesem Vorschlag gleich wieder Abstand genommen..) Referenz dazu: https://wiki.openstreetmap.org/wiki/API_v0.6#Elements_2 Die v0.6 API wird seit April 2009 genutzt, Änderungen daran müssen wohlüberlegt sein. Da sie das interne DB-Format nicht veröffentlicht, wäre denkbar, intern double zu verwenden, aber nur 8 oder 9 Nachkomma- stellen bei der Kommunikation über die API zu ver- äußern, womit der Zuwachs an übertragenen Daten über- schaubar bliebe. Für die ebenfalls veröffentlichten DB-Abzüge gilt dies aber nicht und Leute die einen privaten OSM-Server in Kopie betreiben wären im Zug- zwang eine solche Backend-Entscheidung mitzutragen, sprich u.U. mehr Speicherplatz für die Instanz be- reitzustellen. Laut https://taginfo.openstreetmap.org/sources/db existieren derzeit ca. 9,634 Milliarden nodes in der Datenbank. Ohne Optimierung oder Kompression würde die DB bei einer Umstellung von float (4 byte) auf double (8 byte) damit statt ca. 71.8 GB also 143.6 GB für die Datenhaltung der Koordinaten in Anspruch nehmen. Für mobile Offline-Nutzung auf PDAs und Smart- phones erscheint das erstmal als nicht hinnehm- bar, aber man muss bedenken, dass die DB nicht unverändert auf solchen Geräten genutzt wird und die bereits vorhandenen Toolchains zur Vor- verarbeitung lediglich mit dem geänderten Ein- gabe-Format umgehen müssten, während die Ausgabe unverändert bliebe und somit keine Mehr-Inanspruch- nahme auf den mobilen Datenträgern bedeutet. Ein Mehraufwand serverseitig besteht. Wenn man nur die IEEE-Typen betrachtet, welche von den verbreiteten Datenbanksystemen unter- stützt werden, fallen für die Möglichkeit, eine weitere Nachkommastelle abzuspeichern, +8 bytes pro Koordinate an. Bei einer Mischlösung mit einem weiteren Elementtyp weniger, die aber weitreichendere und aufwendigere Software- anpassungen zur Folge hätte, als eine vollständige Umstellung. Gruß __________
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Sonntag, 12. Januar 2025 um 00:50 > Von: "Christian Müller" > An: talk-de@openstreetmap.org > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > Der bisherige Software-Stack ist eher mächtig, die Bearbeitungs- > und Filterwerkzeuge sind zahlreich. Ein Datentrafo, der vorhandene > Präzision vernichtet, also float32 mittels float16 beschneidet, > ist einfach geschrieben. Korrektur: "float64 mittels float32 beschneidet" war gemeint Gruß ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Samstag, 11. Januar 2025 um 22:26 > Von: "Bernhard Weiskopf via Talk-de" > An: "Markus via Talk-de" > CC: "Bernhard Weiskopf" > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > Wegen der Kontinentaldrift sind die Koordinaten umso schneller veraltet, > je "genauer" sie angegeben sind. > > Und bei einem Erdbeben können große Flächen schon mal mehrere Meter > verschoben werden. > > Auch Bodenhöhen "ele=" haben teilweise sehr viele Nachkommastellen. > > Bernhard +1 Gleichzeitig ein Argument für Präzision, im Zusammenhang mit seismographischen Anwendungen. Es ist denkbar, dass ähnlich der automatischen Datenerfassung in der Hydrologie (Pegel-Mess- stationen), auch bestimmte Daten in der OSM-DB durch bots aktualisiert werden - z.B. die "ele=" Angaben entlegener Gebiete, oder Gletscher- Ausdehnungen. Automatische Datenimporte von verschiedenen Quellen mit Kooperationsvereinbarungen gab es in der Vergangenheit immer wieder: https://wiki.openstreetmap.org/wiki/Import Bisher bezog sich das auf eher statische Datensammlungen, aber warum sollen zukünftig Werkzeuge ausgeschlossen werden, die im Inter- val geographische Daten automatisiert er- heben. _Falls_ sich solche Importe als zu- verlässig herausstellen, könnten die dem Humanitarian Project evtl. Basis-Arbeit abnehmen (rein spekulativ!). Das soll keine Werbung für einen Rund- umschlag solcher Automatismen sein, denn zum einen braucht auch das menschliche Ressourcen für Wartung und stichproben- artiger Prüfung der Korrektheit solcher Importe, und zum anderen gibt es Bereiche, wie z.B. den der Öffnungszeiten, wo Mit- wirkende weit besser Altdaten prüfen und aktualisieren als ein Automatismus das könnte, m. M. n. - allerdings handelt es sich in solchen Fällen auch nicht um ent- legene Gebiete. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Samstag, 11. Januar 2025 um 21:12 > Von: "Markus via Talk-de" > An: "Florian Lohoff" , "Markus via Talk-de" > > CC: Markus > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > Übrigens: Meter-Angaben mit 15 Nachkommastellen entsprechen der > Genauigkeit, die mit einem Elektronenmikroskop maximal erzielbar sind > und das ist ja nicht so geeignet fürs Mapping - auch nicht für > Mikromapping ;-) > Es geht im Kontext OSM nicht um diese 15 Nachkommastellen, diese werden hier nur deshalb theoretisiert, weil mit der Einführung einer achten Nachkommastelle, der Datentyp double statt float gewählt wird. Die Rechner wurden nicht mit OSM im Hinterkopf, und der Maßgabe gebaut, dass es Fließkommazahltypen mit Längen zwischen denen von float und double bräuchte. https://en.wikipedia.org/wiki/Double-precision_floating-point_format ordnet den Begriff "float" keiner spezifischen Präzision (mehr) zu, dort wird unterschieden zwischen half - 16bit single - 32bit double - 64bit quadruple - 128bit octuple - 256bit Synonym dazu wird "float" mit den Bitbreiten ge-suffixed, also float16, float32, etc. - was eindeutiger ist, als zu riskieren, dass "float" von einem neueren Compiler beispielsweise in einen breiteren Typ als 32-bit umdefiniert wird (das gab es bereits mit int - ursprünglich 16bit breit, später ohne Namensänderung auf 32bit aufgebohrt) Zumindest nativ gibt es auf den populären Rechnern keinen Fließkomma- zahltyp der, hypothetisch für OSM nützlich, zwischen 32bit und 64bit angesiedelt wäre. Die zwei Gründe, die ad hoc einfallen, die API der OSM Datenbank so anzupassen, dass sie eine weitere Nachkommastelle unterstützt, wären imho: - Vermeidung von Fehlerfortpflanzung, ungewollte Verschiebungen durch Maschinenrundung - der Wunsch auch am Äquator höher als 10cm aufzulösen Ob der Aufwand den Nutzen rechtfertigt, müssen diejenigen be- urteilen, die eine Änderung dahingehend bewirken wollen. Allerdings wirkt es auch nicht sonderlich kunstfertig, wenn große Teile der Toolchain komplett mit "double", also float64 arbeiten, aber gerade das Datengrab/Backend nicht: Die Frage nach der Sinnhaftigkeit lässt sich aus diesem technischen Blickwinkel auch umgekehrt aufzäumen: Welchen Sinn macht es, diese historisch gewachsenen 7 Nachkomma- stellen im Backend zu halten, wenn das restliche Ökosystem mit 15 arbeitet? Das erscheint aus technischer Sicht wenig ästhetisch. Andererseits kann aus anderen Gründen eine höhere Präzision auch unerwünscht sein, weil dies evtl. als Einladung zu Anwendungen und Applikationen verstanden wird, die ethisch nicht mit den Grundsätz- en von OSM vertretbar sind. Da es für die eine oder die gegenteilige Design-Entscheidung nicht zwangsläufig einen singulären, lapidaren Grund gibt, kann auch die einfach formulierte Frage nach der Sinnhaftigkeit zu Antworten führen, die zunächst nicht offensichtlich oder gar widersprüchlich sind. OpenStreetMap hat als wichtiger Konkurrent zum kommerziellen Google Maps damals wie heute Optionen, eine Alternative bereitgestellt. Damals haben viele gefragt: "Wieso OpenStreetMap?" .. es gibt doch Google Maps. Als es um die Vereinnahmung _öffentlicher_ Daten durch Tech-Konzerne ging, hat auch kein Beteiligter im Projekt nach der "Sinnhaftigkeit" gefragt. Wichtig war es, Leute zu befähigen, selbst Initiative zu ergreifen und sich Themen wie informationelle Selbst- bestimmung nicht aus der Hand nehmen zu lassen. Womit ein weiterer Aspekt genannt wäre, unter dem die ursprüngliche Frage beleuchtet werden kann: Soll das Backend Nutzern die Fähig- keit nehmen, Daten mit einer Präzision im 1cm oder im Millimeter- bereich abzuspeichern? Wenn die Technik dadurch nicht in Mitleidenschaft gezogen wird, ließe sich hier argumentieren, dass die Technik nicht _limitierend_ sondern _befähigend_ wirken solle. D. h. keine technische Vorgabe soll abschließend entscheidend, sondern derjenige, der die Tools verwendet. Unter der Maßgabe, dass es sich um ein Ökosystem mit zahlreichen Teilnehmern handelt, wird es so sein, dass eine große Gruppe keine höhere Genauigkeit bei der Speicherung der Koordinaten im Backend braucht, oder sich nicht vorstellen kann, wozu diese nützlich sein könnte. Andererseits bedeutet die Nicht-Verfügbarkeit derselben auch, dass niemand zeigen könnte, wozu das evtl. doch öffentlich nützlich ist. Der bisherige Software-Stack ist eher mächtig, die Bearbeitungs- und Filterwerkzeuge sind zahlreich. Ein Datentrafo, der vorhandene Präzision vernichtet, also float32 mittels float16 beschneidet, ist einfach geschrieben. Die Umkehrung, Präzision hinzuzufügen, wo sie ggf. doch benötigt wird, ist schwieriger. Projekte, welche z.B. 3D-Modelle in andere Datenbanken ausgelagert haben, zeigen auf, dass es mit Verlinkung/Referenzierung
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Samstag, 11. Januar 2025 um 20:58 > Von: "Markus via Talk-de" > An: talk-de@openstreetmap.org > CC: Markus > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > Danke Jochen, > > Dann stimmt also die Angabe im Wiki noch :-) > > Das ist für Mapping im Feld auch nach Rundungen immer noch ausreichend. > > Das bedeutet aber auch, dass Indoor-, Architektur-- Inneneinrichtungs- > und Spielzeugeisenbahnmapping noch eine 8. Nachkommastelle bräuchte? > > Und dass Genauigkeiten /echter/ Lasermessungen verloren gehenNiemand > hier, der Genaueres weiss? Es wurde gesagt, dass es Bestandteile in der Toolchain gibt, welche mit einer größeren Genauigkeit arbeiten. Das bedeutet, dass beim Abspeichern / Upload hin zur OSM-DB Genauigkeit ver- loren geht, wenn die ursprüngliche Datenerhebung und der ver- wendete Software-Stack für das Editing genauer ist. Es bedeutet nicht, dass z.B. bei der Arbeit mit einem anderen Server, die gleichen Einschränkungen bestehen (müssen). Ohne es geprüft zu haben, ist aber zu vermuten, dass die Aussage auch auf die andere öffentliche Instanz, https://www.openhistoricalmap.org zutrifft. Man muss sich die ganze Toolchain anschauen, um abzuschätzen, ob es einen Teil gibt, der Daten verlusthaft weiterverarbeitet. Populär ist die Overpass API, sieht man sich z.B. https://github.com/drolbr/Overpass-API/blob/master/src/lib/overpass.h an, sieht man, dass sowohl die Strukturen Overpass_C_Node als auch Coord mit dem Datentyp "double" arbeiten. Gleiches gilt für den Editor JOSM, siehe https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/coor/ILatLon.java Auch wenn die OSM-DB "nur" mit einer float Genauigkeit Daten ab- speichert, kann es nützlich sein (lies: nicht "sinnlos"), bei der Verarbeitung und Änderung den Datentyp double zu nutzen, da das Resultat von mehreren Edit-Operationen (z.B. Verschieben) damit genauer ausfällt, als wenn durchgehend mit float gerechnet wird, da sich Rundungsfehler nach jeder weiteren Operation verstärken können, Referenzen dazu: https://en.wikipedia.org/wiki/Floating-point_arithmetic#Representable_numbers,_conversion_and_rounding https://de.wikipedia.org/wiki/Gleitkommazahl#Gleitkommaarithmetik (Einige der angesprochenen Probleme sind zudem auch bei Verwendung des Datentyps double präsent.) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Hola, On Sat, Jan 11, 2025 at 09:12:27PM +0100, Markus wrote: > Danke Flo, > > Das mit dem Variablentyp float bzw. double erklärt die aufgeblähten > Nachkommastellen. Aber dann müssten doch Zahlenfolgen mit vielen > folgenden Nullen zu finden sein, oder etwas Periodisches...? > Denn Sensoren bieten ja auch keine so "riesigen" Genauigkeiten. > > Übrigens: Meter-Angaben mit 15 Nachkommastellen entsprechen der > Genauigkeit, die mit einem Elektronenmikroskop maximal erzielbar sind > und das ist ja nicht so geeignet fürs Mapping - auch nicht für > Mikromapping ;-) Warum sollten da in den Nachkommastellen nullen oder periodisches Auftauchen? Dafür müsste man ja mal gucken die denn Koordinaten überhaupt zustandekommen. Du nimmst eine schöne WGS84 koordinate mit 2 Nachkommastellen und machst eine Koordinatentransformation in ein anderes Bezugssystem - was im GIS Bereich Standard ist. Dieses Koordinatensystem hat einen anderen Bezugspunkt, und sehr Wahrscheinlich ein anderes generalisiertes Elipsoid der Erde. Dann hast du in den Nachkommastellen einfach "rauschen". Wenn du dann nicht wirklich absichtlich "abschneidest" sondern den float/double Behälst hast du halt da Zahlen die eine fiktive Präzision haben. > Zusatzfrage: > > Gibt es inzwischen eigentlich einen tag für: > - Lage-Genauigkeit der Koordinate > - Form-Genauigkeit einer Linie Gemessen an was? Das sind ja total subjektive kriterien - und wenn du Dinge der Realität mit abschnittsweiser Näherung abbildest hast du IMMER einen Fehler. Da wir aber keinen "Vergleichswert" haben (Ausser das Menschliche Auge) wird man das nicht quantifizieren können. Dazu kommt ja die "absolute Lage" von etwas bezogen auf Welches Koordinatensystem - zu welcher Zeit? Denn es gibt Referenzsysteme die eine Kontinentaldrift quasi "mit einschliessen" und andere die eine absolute Position auf einem Elipsoid darstellen (Wie z.b. WGS84) D.h. eine Koordinate erfasst um 1900 ist in einem Koordinatensystem auch in 2025 noch super, in einem anderen aber mehrere Meter daneben. Und je nach Position und Zeit ist der Fehler mehrere Zentimeter im Jahr. Dinge die ich in OSM 2008 aus dem ALKIS übernommen habe, liegen heute etwa 40cm daneben. Denn das ALKIS hat ein UTM32 Bezug - d.h. ist von der Kontinentaldrift nicht betroffen. IIRC haben aber so 2.5cm/Jahr Hab ich also 2008 eine Koordinatentransformation von UTM32 -> WGS84 gemacht driftet diese Koordinate seit dem nicht mehr mit. Und das ganze ist positions d.h. Land/Kontinent und Zeit abhängig. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Samstag, 11. Januar 2025 um 20:25 > Von: "Norbert Kück" > An: talk-de@openstreetmap.org > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > Am 11.01.2025 um 19:23 schrieb Christian Müller via Talk-de: > > Die Suggestion ist hier, dass_alle_ Koordinatenangaben auf > > derlei Messverfahren beruhen. > > Mir ist schleierhaft, wie man diese Einschränkung in meinen Text > hineinlesen kann. Das Wort "Suggestion" kann man auch als Vorwurf verstehen. > nk > Du sprachst von Fehlern im Meter-Bereich, die so recht eindeutig in Verbindung mit der GPS-Messtechnik stehen, im hier besprochenen Kontext. Wenn Du nicht missverstanden werden willst, musst Du dich präziser ausdrücken, was Du nicht getan hast. Gruß _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Wegen der Kontinentaldrift sind die Koordinaten umso schneller veraltet, je "genauer" sie angegeben sind. Und bei einem Erdbeben können große Flächen schon mal mehrere Meter verschoben werden. Auch Bodenhöhen "ele=" haben teilweise sehr viele Nachkommastellen. Bernhard Am 2025-01-11 um 21:12 schrieb Markus via Talk-de: Danke Flo, Das mit dem Variablentyp float bzw. double erklärt die aufgeblähten Nachkommastellen. Aber dann müssten doch Zahlenfolgen mit vielen folgenden Nullen zu finden sein, oder etwas Periodisches...? Denn Sensoren bieten ja auch keine so "riesigen" Genauigkeiten. Übrigens: Meter-Angaben mit 15 Nachkommastellen entsprechen der Genauigkeit, die mit einem Elektronenmikroskop maximal erzielbar sind und das ist ja nicht so geeignet fürs Mapping - auch nicht für Mikromapping ;-) Zusatzfrage: Gibt es inzwischen eigentlich einen tag für: - Lage-Genauigkeit der Koordinate - Form-Genauigkeit einer Linie Mit herzlichem Gruss, Markus Am 11.01.2025 um 16:19 schrieb Florian Lohoff: On Sat, Jan 11, 2025 at 03:50:51PM +0100, Markus via Talk-de wrote: Liebe DB-Spezialisten, Mit wie vielen Nachkommastellen speichern wir Koordinaten? Im Wiki steht: 7 (~ 1cm) https://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten#OSM-Datenformat Es scheint aber Geo-Tools zu geben, die 15 Nachkommastellen schreiben. das liegt im atomaren Bereich: ~ 0,001mm ;-) Wie könnte das Sinn machen? In dem man einfach einen Variablentyp nimmt den deine CPU Nativ kann - Also float oder double. Dann kommt das dabei raus. Flo ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Danke Flo, Das mit dem Variablentyp float bzw. double erklärt die aufgeblähten Nachkommastellen. Aber dann müssten doch Zahlenfolgen mit vielen folgenden Nullen zu finden sein, oder etwas Periodisches...? Denn Sensoren bieten ja auch keine so "riesigen" Genauigkeiten. Übrigens: Meter-Angaben mit 15 Nachkommastellen entsprechen der Genauigkeit, die mit einem Elektronenmikroskop maximal erzielbar sind und das ist ja nicht so geeignet fürs Mapping - auch nicht für Mikromapping ;-) Zusatzfrage: Gibt es inzwischen eigentlich einen tag für: - Lage-Genauigkeit der Koordinate - Form-Genauigkeit einer Linie Mit herzlichem Gruss, Markus Am 11.01.2025 um 16:19 schrieb Florian Lohoff: On Sat, Jan 11, 2025 at 03:50:51PM +0100, Markus via Talk-de wrote: Liebe DB-Spezialisten, Mit wie vielen Nachkommastellen speichern wir Koordinaten? Im Wiki steht: 7 (~ 1cm) https://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten#OSM-Datenformat Es scheint aber Geo-Tools zu geben, die 15 Nachkommastellen schreiben. das liegt im atomaren Bereich: ~ 0,001mm ;-) Wie könnte das Sinn machen? In dem man einfach einen Variablentyp nimmt den deine CPU Nativ kann - Also float oder double. Dann kommt das dabei raus. Flo _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Danke Jochen,
Dann stimmt also die Angabe im Wiki noch :-)
Das ist für Mapping im Feld auch nach Rundungen immer noch ausreichend.
Das bedeutet aber auch, dass Indoor-, Architektur-- Inneneinrichtungs-
und Spielzeugeisenbahnmapping noch eine 8. Nachkommastelle bräuchte?
Und dass Genauigkeiten /echter/ Lasermessungen verloren gehenNiemand
hier, der Genaueres weiss?
Mit herzlichem Gruss,
Markus
Am 11.01.2025 um 19:53 schrieb Jochen Topf:
OSM speichert Koordinaten intern mit 7 Nachkommastellen, am Equator
entspricht das etwa 10cm Genauigkeit.
Viele Grüße
Jochen
On Sat, Jan 11, 2025 at 06:23:51PM +, Christian Müller via Talk-de wrote:
Date: Sat, 11 Jan 2025 18:23:51 +
From: Christian Müller via Talk-de
To: talk-de@openstreetmap.org
Cc: Christian Müller
Subject: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
(Nachkommastellen)
Gesendet: Samstag, 11. Januar 2025 um 16:18
Von: "Norbert Kück"
An: talk-de@openstreetmap.org
Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
(Nachkommastellen)
Die Sinnfrage ist wirklich entscheidend. Ich lese sie als: "Wie nützlich
sind auf 1 cm genaue Koordinatenangaben, wenn sie auf einem
Messverfahren mit einem Konfidenzintervall im Meterbereich beruhen?"
Scheinbare Präzision täuscht außerdem gerne Richtigkeit vor.
Die Suggestion ist hier, dass _alle_ Koordinatenangaben auf
derlei Messverfahren beruhen. Dem ist nicht so.
Es gibt eher viele Beispiele, bei denen ein GPS-Messverfahren
_nicht_ Datenquelle ist. Z.B. sind für das Indoor-Mapping laser-
gestützte Messverfahren, oder schlicht das Ausmessen mit Zoll-
stock denkbar.
Auch OSM-3D, sofern der Datensatz dazu nicht auf ein extern ge-
speichertes Modell verlinkt, kann diese Präzision nützlich aus-
werten.
Für OSM ist die Frage, was in die DB aufzunehmen ist, gerade beim
Micromapping, nicht abschließend objektiv entscheidbar. Es dreht
sich dabei nämlich um eine Antwort auf die Frage, wie dauerhaft
ein Objekt vor Ort ("on the ground") verfügbar ist. Zum Beispiel
werden Litfaßsäulen gemappt, die durchaus mal den Standort wechseln,
neu aufgebaut, oder demontiert werden.
Im Indoor-Bereich hingegen ist es, imho, usus, Mobiliar nicht zu
mappen, Fenster und Türen des Objekts hingegen schon (zumindest
existieren dafür Anleitungen im Wiki).
Ein anderes Beispiel sind Zäune und Hecken, die je nach Gutdünken
des Besitzers verschwinden, oder auch mal die Länge wechseln.
Es kann so erscheinen, als wenn die Frage danach, was gemappt wird
nicht unmittelbar etwas mit der oben besprochenen Frage nach der
Messgenauigkeit zu tun hat, aber dies täuscht. Wer sich die
Historie anschaut, also explizit wann Indoor-Mapping Einzug ge-
halten hat, der versteht auch, warum die Daten-Tools heute mit
einer präziseren Messgenauigkeit Daten verarbeiten als zur Ge-
burt des Projekts.
Anfänglich waren beispielsweise hochauflösende Orthofotos nicht
für das Projekt verfügbar, die Daten in 10 bis 20 cm Auflösung
abbilden. Mit dem Aufkommen dieser Auflösungen und dem Mappen
anhand solcher Orthofotos als Alternative zu GPS-gesammelten
Daten hat(te) sich die Frage nach der Sinnhaftigkeit zugunsten
von Detail damals schon einmal entschieden, so dass man das
angesprochene übersteuern (Genauigkeit im "subatomare Bereich")
auch als Vorarbeit werten kann:
Man muss es nicht gebrauchen, aber es ist schön,
den Stauraum für Eventualitäten da zu haben.
Die Diskussion ist übertragbar auf die Sinnhaftigkeit von SUVs,
bevor es die gab, haben es auch die kleineren, deutlich ressourcen-
schonenderen Automobile getan. Aber nun, wo sie einmal auf die
Welt gebiert sind, werden sie mit derselben Maxime angeschafft:
In der Regel ist der Stauraum leer und nur eine Person fährt
mit dem Gefährt um her, aber die Eventualität, dass mal 5 Personen
plus Gepäck transportiert werden müssen, die rechtfertigt die
Anschaffung. (Und da geht es um bedeutend größere Energie-
mengen, auf die Stückzahlen der SUVs gerechnet, als wenn OSM
float oder double für die Datenverarbeitung nutzt..)
Gruß
___________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
___________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Am 11.01.2025 um 19:23 schrieb Christian Müller via Talk-de: Die Suggestion ist hier, dass_alle_ Koordinatenangaben auf derlei Messverfahren beruhen. Mir ist schleierhaft, wie man diese Einschränkung in meinen Text hineinlesen kann. Das Wort "Suggestion" kann man auch als Vorwurf verstehen. nk _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
OSM speichert Koordinaten intern mit 7 Nachkommastellen, am Equator
entspricht das etwa 10cm Genauigkeit.
Viele Grüße
Jochen
On Sat, Jan 11, 2025 at 06:23:51PM +, Christian Müller via Talk-de wrote:
> Date: Sat, 11 Jan 2025 18:23:51 +
> From: Christian Müller via Talk-de
> To: talk-de@openstreetmap.org
> Cc: Christian Müller
> Subject: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
> (Nachkommastellen)
>
>
> > Gesendet: Samstag, 11. Januar 2025 um 16:18
> > Von: "Norbert Kück"
> > An: talk-de@openstreetmap.org
> > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
> > (Nachkommastellen)
> >
> > Die Sinnfrage ist wirklich entscheidend. Ich lese sie als: "Wie nützlich
> > sind auf 1 cm genaue Koordinatenangaben, wenn sie auf einem
> > Messverfahren mit einem Konfidenzintervall im Meterbereich beruhen?"
> > Scheinbare Präzision täuscht außerdem gerne Richtigkeit vor.
>
> Die Suggestion ist hier, dass _alle_ Koordinatenangaben auf
> derlei Messverfahren beruhen. Dem ist nicht so.
>
> Es gibt eher viele Beispiele, bei denen ein GPS-Messverfahren
> _nicht_ Datenquelle ist. Z.B. sind für das Indoor-Mapping laser-
> gestützte Messverfahren, oder schlicht das Ausmessen mit Zoll-
> stock denkbar.
>
> Auch OSM-3D, sofern der Datensatz dazu nicht auf ein extern ge-
> speichertes Modell verlinkt, kann diese Präzision nützlich aus-
> werten.
>
> Für OSM ist die Frage, was in die DB aufzunehmen ist, gerade beim
> Micromapping, nicht abschließend objektiv entscheidbar. Es dreht
> sich dabei nämlich um eine Antwort auf die Frage, wie dauerhaft
> ein Objekt vor Ort ("on the ground") verfügbar ist. Zum Beispiel
> werden Litfaßsäulen gemappt, die durchaus mal den Standort wechseln,
> neu aufgebaut, oder demontiert werden.
>
> Im Indoor-Bereich hingegen ist es, imho, usus, Mobiliar nicht zu
> mappen, Fenster und Türen des Objekts hingegen schon (zumindest
> existieren dafür Anleitungen im Wiki).
>
> Ein anderes Beispiel sind Zäune und Hecken, die je nach Gutdünken
> des Besitzers verschwinden, oder auch mal die Länge wechseln.
>
>
> Es kann so erscheinen, als wenn die Frage danach, was gemappt wird
> nicht unmittelbar etwas mit der oben besprochenen Frage nach der
> Messgenauigkeit zu tun hat, aber dies täuscht. Wer sich die
> Historie anschaut, also explizit wann Indoor-Mapping Einzug ge-
> halten hat, der versteht auch, warum die Daten-Tools heute mit
> einer präziseren Messgenauigkeit Daten verarbeiten als zur Ge-
> burt des Projekts.
>
> Anfänglich waren beispielsweise hochauflösende Orthofotos nicht
> für das Projekt verfügbar, die Daten in 10 bis 20 cm Auflösung
> abbilden. Mit dem Aufkommen dieser Auflösungen und dem Mappen
> anhand solcher Orthofotos als Alternative zu GPS-gesammelten
> Daten hat(te) sich die Frage nach der Sinnhaftigkeit zugunsten
> von Detail damals schon einmal entschieden, so dass man das
> angesprochene übersteuern (Genauigkeit im "subatomare Bereich")
> auch als Vorarbeit werten kann:
>
> Man muss es nicht gebrauchen, aber es ist schön,
> den Stauraum für Eventualitäten da zu haben.
>
> Die Diskussion ist übertragbar auf die Sinnhaftigkeit von SUVs,
> bevor es die gab, haben es auch die kleineren, deutlich ressourcen-
> schonenderen Automobile getan. Aber nun, wo sie einmal auf die
> Welt gebiert sind, werden sie mit derselben Maxime angeschafft:
>
> In der Regel ist der Stauraum leer und nur eine Person fährt
> mit dem Gefährt um her, aber die Eventualität, dass mal 5 Personen
> plus Gepäck transportiert werden müssen, die rechtfertigt die
> Anschaffung. (Und da geht es um bedeutend größere Energie-
> mengen, auf die Stückzahlen der SUVs gerechnet, als wenn OSM
> float oder double für die Datenverarbeitung nutzt..)
>
>
> Gruß
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
--
Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
> Gesendet: Samstag, 11. Januar 2025 um 16:18
> Von: "Norbert Kück"
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB
> (Nachkommastellen)
>
> Die Sinnfrage ist wirklich entscheidend. Ich lese sie als: "Wie nützlich
> sind auf 1 cm genaue Koordinatenangaben, wenn sie auf einem
> Messverfahren mit einem Konfidenzintervall im Meterbereich beruhen?"
> Scheinbare Präzision täuscht außerdem gerne Richtigkeit vor.
Die Suggestion ist hier, dass _alle_ Koordinatenangaben auf
derlei Messverfahren beruhen. Dem ist nicht so.
Es gibt eher viele Beispiele, bei denen ein GPS-Messverfahren
_nicht_ Datenquelle ist. Z.B. sind für das Indoor-Mapping laser-
gestützte Messverfahren, oder schlicht das Ausmessen mit Zoll-
stock denkbar.
Auch OSM-3D, sofern der Datensatz dazu nicht auf ein extern ge-
speichertes Modell verlinkt, kann diese Präzision nützlich aus-
werten.
Für OSM ist die Frage, was in die DB aufzunehmen ist, gerade beim
Micromapping, nicht abschließend objektiv entscheidbar. Es dreht
sich dabei nämlich um eine Antwort auf die Frage, wie dauerhaft
ein Objekt vor Ort ("on the ground") verfügbar ist. Zum Beispiel
werden Litfaßsäulen gemappt, die durchaus mal den Standort wechseln,
neu aufgebaut, oder demontiert werden.
Im Indoor-Bereich hingegen ist es, imho, usus, Mobiliar nicht zu
mappen, Fenster und Türen des Objekts hingegen schon (zumindest
existieren dafür Anleitungen im Wiki).
Ein anderes Beispiel sind Zäune und Hecken, die je nach Gutdünken
des Besitzers verschwinden, oder auch mal die Länge wechseln.
Es kann so erscheinen, als wenn die Frage danach, was gemappt wird
nicht unmittelbar etwas mit der oben besprochenen Frage nach der
Messgenauigkeit zu tun hat, aber dies täuscht. Wer sich die
Historie anschaut, also explizit wann Indoor-Mapping Einzug ge-
halten hat, der versteht auch, warum die Daten-Tools heute mit
einer präziseren Messgenauigkeit Daten verarbeiten als zur Ge-
burt des Projekts.
Anfänglich waren beispielsweise hochauflösende Orthofotos nicht
für das Projekt verfügbar, die Daten in 10 bis 20 cm Auflösung
abbilden. Mit dem Aufkommen dieser Auflösungen und dem Mappen
anhand solcher Orthofotos als Alternative zu GPS-gesammelten
Daten hat(te) sich die Frage nach der Sinnhaftigkeit zugunsten
von Detail damals schon einmal entschieden, so dass man das
angesprochene übersteuern (Genauigkeit im "subatomare Bereich")
auch als Vorarbeit werten kann:
Man muss es nicht gebrauchen, aber es ist schön,
den Stauraum für Eventualitäten da zu haben.
Die Diskussion ist übertragbar auf die Sinnhaftigkeit von SUVs,
bevor es die gab, haben es auch die kleineren, deutlich ressourcen-
schonenderen Automobile getan. Aber nun, wo sie einmal auf die
Welt gebiert sind, werden sie mit derselben Maxime angeschafft:
In der Regel ist der Stauraum leer und nur eine Person fährt
mit dem Gefährt um her, aber die Eventualität, dass mal 5 Personen
plus Gepäck transportiert werden müssen, die rechtfertigt die
Anschaffung. (Und da geht es um bedeutend größere Energie-
mengen, auf die Stückzahlen der SUVs gerechnet, als wenn OSM
float oder double für die Datenverarbeitung nutzt..)
Gruß
_______
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
On Sat, Jan 11, 2025 at 03:50:51PM +0100, Markus via Talk-de wrote: > Liebe DB-Spezialisten, > > Mit wie vielen Nachkommastellen speichern wir Koordinaten? > > Im Wiki steht: 7 (~ 1cm) > https://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten#OSM-Datenformat > > Es scheint aber Geo-Tools zu geben, die 15 Nachkommastellen schreiben. > das liegt im atomaren Bereich: ~ 0,001mm ;-) > Wie könnte das Sinn machen? In dem man einfach einen Variablentyp nimmt den deine CPU Nativ kann - Also float oder double. Dann kommt das dabei raus. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Hallo Markus, Am 11.01.2025 um 15:50 schrieb Markus via Talk-de: Mit wie vielen Nachkommastellen speichern wir Koordinaten? Im Wiki steht: 7 (~ 1cm) https://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten#OSM- Datenformat Es scheint aber Geo-Tools zu geben, die 15 Nachkommastellen schreiben. das liegt im atomaren Bereich: ~ 0,001mm ;-) Wie könnte das Sinn machen? Die Sinnfrage ist wirklich entscheidend. Ich lese sie als: "Wie nützlich sind auf 1 cm genaue Koordinatenangaben, wenn sie auf einem Messverfahren mit einem Konfidenzintervall im Meterbereich beruhen?" Scheinbare Präzision täuscht außerdem gerne Richtigkeit vor. Gruß nk _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
Liebe DB-Spezialisten, Mit wie vielen Nachkommastellen speichern wir Koordinaten? Im Wiki steht: 7 (~ 1cm) https://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten#OSM-Datenformat Es scheint aber Geo-Tools zu geben, die 15 Nachkommastellen schreiben. das liegt im atomaren Bereich: ~ 0,001mm ;-) Wie könnte das Sinn machen? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [EXT] Re: Grenze Jordanien / Syrien
In den Daten sind die Grenzen gleich, vgl. https://www.openstreetmap.org/#map=13/32.37489/36.93913&layers=D Möglicherweise wurde bei Openseamap noch nicht neu gerendert? BG, mikeE. -Ursprüngliche Nachricht- Von: Thomas Butz via Talk-de Gesendet: Mittwoch, 8. Januar 2025 14:46 An: Markus via Talk-de Cc: Thomas Butz Betreff: [EXT] Re: [Talk-de] Grenze Jordanien / Syrien ACHTUNG : Diese E-Mail stammt von einem externen Absender (außerhalb der SWH-Gruppe). Bitte höchste Vorsicht mit Dateianhängen und Hyperlinks! Im Zweifelsfall wird empfohlen, den Absender (z.B. per Telefon) zu kontaktieren und die Echtheit der E-Mail zu prüfen. Tippe auf Caching der Tiles > Liebe Kollegen, > > Hier verändert sich die Grenze zwischen z=14 und z=13: > https://map.openseamap.org/?zoom=13&lon=36.91750&lat=32.33137&mlat=32.335&mlon=37.00&mtext=Trinkwasserreservoir&layers=TFTTFTTFFTFFTF > > > > Hier aber nicht: > https://www.openstreetmap.org/#map=13/32.33137/36.91750 > > Welche Grenze ist richtig? > Woher kommt der Unterschied? > > Gruss, Markus > > _______ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de -- Mit freundlichen Grüßen / Best regards Thomas Butz ___ OPTITOOL GmbH Im Gewerbepark D 85 D - 93059 Regensburg Phone: +49-941-59578-14 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grenze Jordanien / Syrien
Tippe auf Caching der Tiles Liebe Kollegen, Hier verändert sich die Grenze zwischen z=14 und z=13: https://map.openseamap.org/?zoom=13&lon=36.91750&lat=32.33137&mlat=32.335&mlon=37.00&mtext=Trinkwasserreservoir&layers=TFTTFTTFFTFFTF Hier aber nicht: https://www.openstreetmap.org/#map=13/32.33137/36.91750 Welche Grenze ist richtig? Woher kommt der Unterschied? Gruss, Markus _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Mit freundlichen Grüßen / Best regards Thomas Butz ___ OPTITOOL GmbH Im Gewerbepark D 85 D - 93059 Regensburg Phone: +49-941-59578-14 _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Grenze Jordanien / Syrien
Liebe Kollegen, Hier verändert sich die Grenze zwischen z=14 und z=13: https://map.openseamap.org/?zoom=13&lon=36.91750&lat=32.33137&mlat=32.335&mlon=37.00&mtext=Trinkwasserreservoir&layers=TFTTFTTFFTFFTF Hier aber nicht: https://www.openstreetmap.org/#map=13/32.33137/36.91750 Welche Grenze ist richtig? Woher kommt der Unterschied? Gruss, Markus _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS 2025 - Konferenzanmeldung ist freigeschaltet
Liebe FOSSGIS- und OSM-Interessierte, das Konferenzteam wünscht ein gesundes und frohes neues Jahr 2025. Die Anmeldung für die FOSSGIS 2025 ist freigeschaltet und hier zu finden: https://fossgis-konferenz.de/2025/anmeldung/#Anmeldeformular Wie jedes Jahr brauchen wir Menschen, die sich ein oder mehreren Sessionleitungen annehmen oder an der Videoaufnahme unterstützen. Nur wenn jemand an der Kamera sitzt und die Aufnahme startet, gibt es später eine Aufzeichnung des Beitrages sowie eine Übertragung im Livestream. Viele Grüße Katja für das Konferenzorgateam -- ... Katja Haferkorn Koordinierungsstelle FOSSGIS e.V. E-Mail: katja.haferk...@fossgis.de Telefon: +49 30-62932037 Mobil: +49 176 51194732 Matrix: @katjahafi:matrix.org Web: fossgis.de Adresse: Bundesallee 23, 10717 Berlin Eintragung im Vereinsregister. Registergericht: Stadt Mainz. Registernummer: 90 VR 3594. Vertreten durch Jörg Thomsen, Pirmin Kalberer, David Arndt, Falk Zscheile . Vereinstermine: https://fossgis.de/aktivit%C3%A4ten/termine/ ... FOSSGIS-Konferenz - OSM-Event - 26. - 29. März 2025 Münster https://www.fossgis-konferenz.de - @FOSSGISeV@mastodon.online . ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #754 26/12/2024-01/01/2025
Die Wochennotiz Ausgabe Nr. # 754, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17673/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #753 19/12/2024-25/12/2024
Die Wochennotiz Ausgabe Nr. # 753, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17664/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #752 12/12/2024-18/12/2024
Die Wochennotiz Ausgabe Nr. # 752, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17655/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weihnachtskarten 2024
Hallo Frederik, Danke für das Angebot. Ich werde in diesem Jahr verzichten. Vielleicht 2025 Weihnachten wieder. Alles gute, gute Weihnachtszeit, guter Rutsch usw. Heinz Am Montag, 16. Dezember 2024, 14:52:54 CET schrieb Frederik Ramm: > Hallo, > > es gibt wieder eine Geofabrik-Weihnachtskarten-Aktion! > > Wie in den vergangenen Jahren bieten wir Euch hier auf der deutschen > Mailingliste und im deutschen Forum an, kostenlos eine große Karte von > einem Gebiet Eurer Wahl auszudrucken und Euch zu schicken. > > Das Angebot gilt nur bis morgen (Dienstag) mittag. Wir drucken alle > Aufträge in der Reihenfolge, in der sie reinkommen, und nur so lange, > bis wir am Dienstag abend nach Hause gehen. Da bringen wir dann auch > gleich alles zur Post. > > Wenn ihr eine Karte zugeschickt haben möchtet, brauchen wir von Euch: > > * entweder ein fertiges PNG (bzw Link zum Download desselben) > * oder einen Link zu einer Karte, die ihr auf Hartmuts MyOSMatic-Seite > erstellt habt (https://print.get-map.org/) > * oder die Koordinaten eines Ausschnitts (alternativ Link zu einem > Rechteck auf tools.geofabrik.de/calc), dann erzeugen wir ein Bild im > Standard-Carto-Stil oder im deutschen OSM-Stil > > und außerdem > > * das Papierformat - wenn nicht anders angegeben, drucken wir "Super A0" > mit 15035x10559 Pixel, ca 1,30x0,90m > * die Adresse, wo es hingehen soll. Wir verschicken nur an deutsche > Adressen, sonst wird der Spaß zu teuer! > > Das ganze per Email an weihnachtsdr...@geofabrik.de > > Wir drucken die Karte, falten sie, und verschicken sie in einem Umschlag > im Format B4. Wir übernehmen alle Kosten, auch das Porto. > > Die Aktion ist als Dankeschön für die unermüdliche Arbeit der > Mapperinnen und Mapper in OSM gedacht. Bitte verzichtet darauf, das > ganze in sozialen Medien weiterzuverbreiten - bis sich das rumspricht, > ist die Warteschlange eh voll, und es gibt nur lange Gesichter. > > Bye > Frederik > > PS: Wer die Karte gern gerollt und nicht gefaltet haben will oder einen > Versand ins Ausland wünscht oder es eilig hat und fürchtet, dass ein > normaler Brief nicht rechtzeitig kommt: Das geht auch, aber dann müsst > ihr uns eine entsprechende Post-Briefmarke oder DHL-Paketmarke "Paket > bis 5kg" (für den aufgerollten Versand in einer quaderförmigen Schachtel > - die Größenbeschränkungen beim "2kg"-Paket sind zu knapp) als PDF > generieren und zuschicken und so die Portokosten selber tragen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Weihnachtskarten 2024
Hallo, es gibt wieder eine Geofabrik-Weihnachtskarten-Aktion! Wie in den vergangenen Jahren bieten wir Euch hier auf der deutschen Mailingliste und im deutschen Forum an, kostenlos eine große Karte von einem Gebiet Eurer Wahl auszudrucken und Euch zu schicken. Das Angebot gilt nur bis morgen (Dienstag) mittag. Wir drucken alle Aufträge in der Reihenfolge, in der sie reinkommen, und nur so lange, bis wir am Dienstag abend nach Hause gehen. Da bringen wir dann auch gleich alles zur Post. Wenn ihr eine Karte zugeschickt haben möchtet, brauchen wir von Euch: * entweder ein fertiges PNG (bzw Link zum Download desselben) * oder einen Link zu einer Karte, die ihr auf Hartmuts MyOSMatic-Seite erstellt habt (https://print.get-map.org/) * oder die Koordinaten eines Ausschnitts (alternativ Link zu einem Rechteck auf tools.geofabrik.de/calc), dann erzeugen wir ein Bild im Standard-Carto-Stil oder im deutschen OSM-Stil und außerdem * das Papierformat - wenn nicht anders angegeben, drucken wir "Super A0" mit 15035x10559 Pixel, ca 1,30x0,90m * die Adresse, wo es hingehen soll. Wir verschicken nur an deutsche Adressen, sonst wird der Spaß zu teuer! Das ganze per Email an weihnachtsdr...@geofabrik.de Wir drucken die Karte, falten sie, und verschicken sie in einem Umschlag im Format B4. Wir übernehmen alle Kosten, auch das Porto. Die Aktion ist als Dankeschön für die unermüdliche Arbeit der Mapperinnen und Mapper in OSM gedacht. Bitte verzichtet darauf, das ganze in sozialen Medien weiterzuverbreiten - bis sich das rumspricht, ist die Warteschlange eh voll, und es gibt nur lange Gesichter. Bye Frederik PS: Wer die Karte gern gerollt und nicht gefaltet haben will oder einen Versand ins Ausland wünscht oder es eilig hat und fürchtet, dass ein normaler Brief nicht rechtzeitig kommt: Das geht auch, aber dann müsst ihr uns eine entsprechende Post-Briefmarke oder DHL-Paketmarke "Paket bis 5kg" (für den aufgerollten Versand in einer quaderförmigen Schachtel - die Größenbeschränkungen beim "2kg"-Paket sind zu knapp) als PDF generieren und zuschicken und so die Portokosten selber tragen. -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #751 05/12/2024-11/12/2024
Die Wochennotiz Ausgabe Nr. # 751, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17641/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #750 28/11/2024-04/12/2024
Die Wochennotiz Ausgabe Nr. # 750, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17625/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #749 21/11/2024-27/11/2024
Die Wochennotiz Ausgabe Nr. # 749, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17610/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #748 14/11/2024-20/11/2024
Die Wochennotiz Ausgabe Nr. # 748, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17600/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #747 07/11/2024-13/11/2024
Die Wochennotiz Ausgabe Nr. # 747, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17587/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS 2025 - Community Voting (Öffentliche Abstimmung)
Liebe FOSSGIS und OSM-Interessierte, der Call for Participation zur FOSSGIS 2025 ist beendet. Es gibt mehr interessante Einreichungen, als wir jemals hatten. Das Community-Voting (Öffentliche Abstimmung) ist eröffnet. Das Ergebnis wird vom Programm-Komitee als Meinungsbild aus der Community in die Bewertung einbezogen. Vorgehensweise: 1. Den Link zur Öffentlichen Abstimmung klicken, um sich dafür anzumelden: https://pretalx.com/fossgis2025/p/voting/signup/ 2. Sie erhalten eine E-Mail mit Ihrem persönlichen Link zur Öffentlichen Abstimmung 3. Einreichungen anschauen und bewerten - dies kann in Etappen erfolgen. Das Community-Voting ist bis zum 17.11.2024 möglich. Vielen Dank an alle, die mitmachen. Freundliche Grüße Katja für das Programm-Komitee der FOSSGIS 2025 Social Media Post: https://mastodon.online/@FOSSGISeV/113437028368907589 -- ... Katja Haferkorn Koordinierungsstelle FOSSGIS e.V. E-Mail: katja.haferk...@fossgis.de Telefon: +49 30-62932037 Mobil: +49 176 51194732 Matrix: @katjahafi:matrix.org Web: fossgis.de Adresse: Bundesallee 23, 10717 Berlin Eintragung im Vereinsregister. Registergericht: Stadt Mainz. Registernummer: 90 VR 3594. Vertreten durch Jörg Thomsen, Pirmin Kalberer, David Arndt, Falk Zscheile . Vereinstermine: https://fossgis.de/aktivit%C3%A4ten/termine/ ... FOSSGIS-Konferenz - OSM-Event - 26. - 29. März 2025 Münster https://www.fossgis-konferenz.de - @FOSSGISeV@mastodon.online . ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #745 24/10/2024-30/10/2024
Die Wochennotiz Ausgabe Nr. # 745, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17568/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Reminder Call for Participation - FOSSGIS-Konferenz 2025 - noch bis 05.11.2024 einreichen
Liebe FOSSGIS- und OSM-Interessierte, die Einreichung eines Beitrags für die FOSSGIS 2025 ist noch bis zum 05.11.2024 möglich. Es können Vorträge, Vorträge im Academic Track, Demosessions, Lightning Talks, Workshops, Expert:innenfragestunden und Anwendertreffen und neuerdings auch Poster eingereicht werden. Sämtliche Infos sind im Call for Participation Text aufgeschrieben: https://fossgis-konferenz.de/2025/callforpapers/ Insbesondere sei hiermit auf die Beitragskatagorie "25 Jahre FOSSGIS e.V." verwiesen. Dieser wohnt die Idee inne, dass Vereinsmitglieder oder Vereinsaktive Beiträge zum Thema 25. Jahre FOSSGIS e.V. beisteuern. Dies können Geschichten aus den Anfangszeiten oder Gedanken und Geschichten zum Verein, den Erfolgen, Nichterfolgen, Aktivitäten, Highlights, Erinnerungen, Erfahrungen oder was auch immer sein. Das Programm und die Anmeldung werden Anfang Januar 2025 freigeschaltet. Bei Fragen schreiben Sie gerne eine Mail an progr...@fossgis.de Freundliche Grüße Katja PS: gerne weitersagen auch @ Social Media: https://mastodon.online/@FOSSGISeV/113396049660673140 https://bsky.app/profile/fossgis-verein.bsky.social/post/3l7pyyw57px23 https://www.linkedin.com/events/fossgis-konferenz20257212084795340668929/comments/ -- ... Katja Haferkorn Koordinierungsstelle FOSSGIS e.V. E-Mail: katja.haferk...@fossgis.de Telefon: +49 30-62932037 Mobil: +49 176 51194732 Matrix: @katjahafi:matrix.org Web: fossgis.de Adresse: Bundesallee 23, 10717 Berlin Eintragung im Vereinsregister. Registergericht: Stadt Mainz. Registernummer: 90 VR 3594. Vertreten durch Jörg Thomsen, Pirmin Kalberer, David Arndt, Falk Zscheile . Vereinstermine: https://fossgis.de/aktivit%C3%A4ten/termine/ ... FOSSGIS-Konferenz - OSM-Event - 26. - 29. März 2025 Münster https://www.fossgis-konferenz.de - @FOSSGISeV@mastodon.online . _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #744 17/10/2024-23/10/2024
Die Wochennotiz Ausgabe Nr. # 744, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17560/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Admin für Community-Forum
Hallo, Am 25.10.24 um 18:45 schrieb Markus via Talk-de: Im Forum gibt es eine DS-Verletzung. Das kommentiere öffentlich nur in so weit, dass der Vorwurf nicht zutrifft und die Bitte nicht eilbedürftig war. Als Admin wird "nakaner" angegeben. Wo steht das? Für alle die es noch nicht wissen: Im Forum kann man Beiträge melden, wenn man angemeldet ist. Dazu unter dem zu meldenden Beitrag auf die drei Punkte klicken, dann auf das Fahnen-Symbol klicken und das Anliegen als "Sonstiges" schildern, wenn es keine besser passende Kategorie gibt. Wenn Beiträge darüber gemeldet werden, kann die Meldung von mehreren Personen bearbeitet werden. Viele Grüße Michael OpenPGP_signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Admin für Community-Forum
Im Forum gibt es eine DS-Verletzung. Als Admin wird "nakaner" angegeben. Aber ich kann ihn unter seiner Mailadresse nicht erreichen. Kannst du dich bitte mal bei mir melden? Danke, Markus _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #743 10/10/2024-16/10/2024
Die Wochennotiz Ausgabe Nr. # 743, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17545/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #742 03/10/2024-09/10/2024
Die Wochennotiz Ausgabe Nr. # 742, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17536/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich suche nach Peda
Hat jemand eine Idee, wie ich ihn erreichen kann. Versuch's mal über/bei ToniE, vielleicht sind die sich mal beim Münchner Stammtisch über den Weg gelaufen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ich suche nach Peda
Hallo zusammen, ich habe ihn schon über seinen OSM-Account angeschrieben. Fehlanzeige. Hat jemand eine Idee, wie ich ihn erreichen kann. Vielen Dank im Voraus -- ## Manfred Reiter - - ## www.weeklyOSM.eu ## https://wiki.openstreetmap.org/wiki/EuYoutH_OSM ## https://wiki.openstreetmap.org/wiki/EuYoutH_OSM/Saarburg ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
On 10/7/24 20:06, lars lingner wrote: Hallo, es gibt https://apps.kde.org/de/itinerary/ Ich kenne es noch nicht, habe es erst am letzten Wochenende installiert und probiere es gerade aus. Auf der Webseite steht "Fahrkartenverwaltung für Mehrpersonenreisen und Buchungen mit mehreren Fahrkarten", ich kann aber nicht sagen was genau es bedeutet. So wie ich das verstehe verwaltet man damit nur bereits getätigte Buchungendie man aus den entsprechenden Buchungsbestätigungen importiert, hat aber keine eigenen Planungs- und Buchungsfunktionen ... _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
Hallo, es gibt https://apps.kde.org/de/itinerary/ Ich kenne es noch nicht, habe es erst am letzten Wochenende installiert und probiere es gerade aus. Auf der Webseite steht "Fahrkartenverwaltung für Mehrpersonenreisen und Buchungen mit mehreren Fahrkarten", ich kann aber nicht sagen was genau es bedeutet. Viele Grüße Lars _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
Am 07.10.24 um 12:15 schrieb Katja Haferkorn: Bestimmt gibt es etwas. Ich kenne keins. Ich würde es witzig finden, wenn wir sowas anzetteln. Natürlich gibt es diverse Platformen, wie z.B. blablacar oder drive2day, usw. .. einfach mal nach Mitfahrzentrale/Mitfahrgelegenheit suchen. Aber ich könnte mir auch vorstellen, dass übers Wiki oder einer uMap laufen zu lassen. Hier sprechen wir ja explizit von der FOSSGIS Konferenz in Münster, sprich es ist nichts anderes wie eine Art "Sternfahrt" zu einem Zielort. Jeder der definitiv mit dem Auto nach Münster fährt, könnte seine Route in einer uMap hinzufügen. Genauso könnten auch Teilnehmer, die mitgenommen werden möchten, einfach ihren Marker auf die Karte setzen. Und schon hat man Biete und Suche. _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
On 10/7/24 12:15, Katja Haferkorn wrote: Bestimmt gibt es etwas. Ich kenne keins. Um dich, Hartmut standen Florian und Mirko, oder? Ich würde es witzig finden, wenn wir sowas anzetteln. schnelle Suche ergab das hier: https://www.merkur.de/reise/mein-rechter-platz-frei-blind-dates-zr-680670.html Aber leider ist der Artikel schon über 10 Jahre alt und den Dienst gibt es nicht mehr :( ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
Bestimmt gibt es etwas. Ich kenne keins. Um dich, Hartmut standen Florian und Mirko, oder? Ich würde es witzig finden, wenn wir sowas anzetteln. Viele Grüße Katja -- mobil gesendet. Am 7. Oktober 2024 11:53:21 MESZ schrieb Hartmut Holzgraefe : >On 10/7/24 10:55, Katja Haferkorn wrote: >> Ich weiß nicht, ob der Hartmut hier auch mit liest und da vielleicht sogar >> ein Tool kennt oder seine Gedanken dau teilen möchte? > >Ich kenne kein konretes Tool für die Koordination von Bahn-Reservierungen, ich >hab mir so etwas zwar immer irgendwie >gewünscht als ich noch häufiger Bahn gefahren bin als heute, >aber das Thema nie wirklich weiter verfolgt. > >Irgendjemand anderes meinte gestern es gäbe tatsächlich so etwas, aber ich >weiß nicht mehr wer ... > > >___________ >Talk-de mailing list >Talk-de@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
On 10/7/24 10:55, Katja Haferkorn wrote: Ich weiß nicht, ob der Hartmut hier auch mit liest und da vielleicht sogar ein Tool kennt oder seine Gedanken dau teilen möchte? Ich kenne kein konretes Tool für die Koordination von Bahn-Reservierungen, ich hab mir so etwas zwar immer irgendwie gewünscht als ich noch häufiger Bahn gefahren bin als heute, aber das Thema nie wirklich weiter verfolgt. Irgendjemand anderes meinte gestern es gäbe tatsächlich so etwas, aber ich weiß nicht mehr wer ... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
Hallo Markus, was meinst Du mit wie viele TN sind es jährlich? Bei der FOSSGIS-Konferenz oder wo? FOSSGIS-Konferenz hat so um die 650 TN, online sind zw. 200 und 300 dabei. Ein Tool für gemeinsames und nachhaltiges Reisen kenne ich nicht, finde es jedoch eine ganz gute Idee. Wir hatten ein ähnliches Thema am Wochenende beim Arbeitstreffen, da ging es darum, wie man sich Mitfahrende organisieren könnte, um nicht so viel alleine zu sitzen. Ich weiß nicht, ob der Hartmut hier auch mit liest und da vielleicht sogar ein Tool kennt oder seine Gedanken dau teilen möchte? Also, wenn es sowas geben sollte und es in irgendeiner Weise einsetzbar erscheint, können wir das gerne im Rahmen der Konferenz anzetteln, also die TN informieren, es auch der Konferenzhomepage erwähnen usw. Viele Grüße Katja -- ... Katja Haferkorn Koordinierungsstelle FOSSGIS e.V. E-Mail: katja.haferk...@fossgis.de Telefon: +49 30-62932037 Mobil: +49 176 51194732 Matrix: @katjahafi:matrix.org Web: fossgis.de Adresse: Bundesallee 23, 10717 Berlin Eintragung im Vereinsregister. Registergericht: Stadt Mainz. Registernummer: 90 VR 3594. Vertreten durch Jörg Thomsen, Pirmin Kalberer, David Arndt, Falk Zscheile . Vereinstermine: https://fossgis.de/aktivit%C3%A4ten/termine/ ... FOSSGIS-Konferenz - OSM-Event - 26. - 29. März 2025 Münster https://www.fossgis-konferenz.de - @FOSSGISeV@mastodon.online . Am 06.10.24 um 19:37 schrieb Markus via Talk-de: Liebe Katja, Danke für die Doku-Folien über die Programmtools! Wieviele TN (von bis) sind das jährlich? Ich bin in einer Arbeitsgruppe "Nachhaltige Veranstaltungen". Reiseaufwand macht einen Grossteil des Fussabdrucks aus. Kennst du ein Tool, um gemeinsames Reisen für eine Veranstaltung zu organisieren? Welche Erfahrungen hast du damit? Gewinn: - Gemeinsam reisen wir intensiver: gegenseitiges Kennenlernen, einstimmen auf den Anlass Informationen und Fragen tauschen, vorbereiten auf den Anlass. Idealerweise entspannt bei einer Bahnfahrt - Gemeinsam reisen ist Klimaschutz Idealerweise per Bahn oder Bus oder zumindest als Fahrgemeinschaft im Auto, Tempo 30-80-100 Freue mich über jeden Tip! Gern auch weitere Ansprechpartner... Mit herzlichem Gruss, Markus Am 06.10.2024 um 15:49 schrieb Katja Haferkorn: Hallo Harald, vielen Dank für Deine Nachfrage. Wir haben die Session nicht aufgezeichnet. Die Folien sind auf dieser Wikiseite verlinkt: https://www.fossgis.de/wiki/Konferenz_2025/technischeInfrastruktur#Team_technische_Infrastruktur Wenn Du Fragen hast, schreibe gerne. Wenn Du an irgendeiner Stelle etwas mit unterstützen magst, melde Dich gerne. Viele Grüße Katja _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
Liebe Katja, Danke für die Doku-Folien über die Programmtools! Wieviele TN (von bis) sind das jährlich? Ich bin in einer Arbeitsgruppe "Nachhaltige Veranstaltungen". Reiseaufwand macht einen Grossteil des Fussabdrucks aus. Kennst du ein Tool, um gemeinsames Reisen für eine Veranstaltung zu organisieren? Welche Erfahrungen hast du damit? Gewinn: - Gemeinsam reisen wir intensiver: gegenseitiges Kennenlernen, einstimmen auf den Anlass Informationen und Fragen tauschen, vorbereiten auf den Anlass. Idealerweise entspannt bei einer Bahnfahrt - Gemeinsam reisen ist Klimaschutz Idealerweise per Bahn oder Bus oder zumindest als Fahrgemeinschaft im Auto, Tempo 30-80-100 Freue mich über jeden Tip! Gern auch weitere Ansprechpartner... Mit herzlichem Gruss, Markus Am 06.10.2024 um 15:49 schrieb Katja Haferkorn: Hallo Harald, vielen Dank für Deine Nachfrage. Wir haben die Session nicht aufgezeichnet. Die Folien sind auf dieser Wikiseite verlinkt: https://www.fossgis.de/wiki/Konferenz_2025/technischeInfrastruktur#Team_technische_Infrastruktur Wenn Du Fragen hast, schreibe gerne. Wenn Du an irgendeiner Stelle etwas mit unterstützen magst, melde Dich gerne. Viele Grüße Katja _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS 2025 - Call for Participation läuft bis 5.11.2024
Liebe FOSSGIS- und OSM-Interessierte, der Call for Participation ist veröffentlicht. Einreichungen sind bis zum 05.11.2024 möglich: https://fossgis-konferenz.de/2025/callforpapers/ Die FOSSGIS, größte deutschsprachige Anwenderkonferenz für freie Geoinformationssysteme und freie Geodaten, wird vom gemeinnützigen FOSSGIS e.V., der OpenStreetMap-Community gemeinsam mit dem Institut für Geoinformatik der Universität Münster organisiert und findet vom 26.-29. März 2025 im Schloss Münster statt. Freie quelloffene Software, Open Data und Open Science leisten einen wichtigen Beitrag zur Stärkung der Digitalen Souveränität. Ziel der jährlich stattfindenden Konferenz ist die Verbreitung von Freier Open Source Software (FOSS) für Geoinformationssysteme (GIS) und Open Data. Hier treffen sich Anwender:innen, Entwickler:innen, Forscher:innen und Interessierte zum gemeinsamen Austausch über GIS-Software, OpenStreetMap und neue Projekte mit Geodatenbezug. Das Programmkomitee der FOSSGIS-Konferenz freut sich auf interessante Einreichungen bis zum 05.11.2024, eine Verlängerung wird es nicht geben. Die FOSSGIS-Konferenz bietet eine Plattform für neue Ideen, Projekte und Erfahrungsberichte und wird größtenteils ehrenamtlich organisiert. Teilnehmer:innen der Konferenz sind sowohl professionelle Anwender:innen genauso wie Begeisterte und Interessierte und Forschende aus dem GIS-Umfeld, OpenStreetMap und anderen Projekten. Die Veranstaltung vermittelt Wissen zu Freier und Open Source Software für Geoinformationssysteme (FOSSGIS), Open Data und OpenStreetMap. In Form von Vorträgen, Lightning Talks, Demo-Sessions, Workshops, Anwendertreffen, spontanen Treffen oder Expert:innenfragestunden bietet die Veranstaltung die Möglichkeit, Wissen zu erweitern und sich zu vernetzen. Neu: Postersession - reichen Sie gern Ihr Poster ein. Das Programmkomitee der FOSSGIS-Konferenz freut sich auf interessante Einreichungen bis zum 05.11.2024, eine Verlängerung wird es nicht geben. Weitere Informationen zur FOSSGIS-Konferenz sind auf der Konferenzhomepage zu finden: https://www.fossgis-konferenz.de/2025. Das Programm und die Anmeldung werden Anfang Januar 2025 freigeschaltet. Bitte beachten Sie, dass die Anzahl der Teilnehmenden beschränkt ist. Melden Sie sich rechtzeitig an! Wenn Sie helfen wollen, lesen Sie die Informationen dazu hier: https://fossgis-konferenz.de/2025/helfen/ Wir freuen uns auf Ihre Teilnahme! Freundliche Grüße vom Konferenzorganisationsteam https://mastodon.online/@FOSSGISeV/113260967881659966 -- ... Katja Haferkorn Koordinierungsstelle FOSSGIS e.V. E-Mail: katja.haferk...@fossgis.de Telefon: +49 30-62932037 Mobil: +49 176 51194732 Matrix: @katjahafi:matrix.org Web: fossgis.de Adresse: Bundesallee 23, 10717 Berlin Eintragung im Vereinsregister. Registergericht: Stadt Mainz. Registernummer: 90 VR 3594. Vertreten durch Jörg Thomsen, Pirmin Kalberer, David Arndt, Falk Zscheile . Vereinstermine: https://fossgis.de/aktivit%C3%A4ten/termine/ ... FOSSGIS-Konferenz - OSM-Event - 26. - 29. März 2025 Münster https://www.fossgis-konferenz.de - @FOSSGISeV@mastodon.online . ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
Hallo Harald, vielen Dank für Deine Nachfrage. Wir haben die Session nicht aufgezeichnet. Die Folien sind auf dieser Wikiseite verlinkt: https://www.fossgis.de/wiki/Konferenz_2025/technischeInfrastruktur#Team_technische_Infrastruktur Wenn Du Fragen hast, schreibe gerne. Wenn Du an irgendeiner Stelle etwas mit unterstützen magst, melde Dich gerne. Viele Grüße Katja -- ... Katja Haferkorn Koordinierungsstelle FOSSGIS e.V. E-Mail: katja.haferk...@fossgis.de Telefon: +49 30-62932037 Mobil: +49 176 51194732 Matrix: @katjahafi:matrix.org Web: fossgis.de Adresse: Bundesallee 23, 10717 Berlin Eintragung im Vereinsregister. Registergericht: Stadt Mainz. Registernummer: 90 VR 3594. Vertreten durch Jörg Thomsen, Pirmin Kalberer, David Arndt, Falk Zscheile . Vereinstermine: https://fossgis.de/aktivit%C3%A4ten/termine/ ... FOSSGIS-Konferenz - OSM-Event - 26. - 29. März 2025 Münster https://www.fossgis-konferenz.de - @FOSSGISeV@mastodon.online . Am 06.10.24 um 10:53 schrieb Harald Hartmann: Hallo Katja, wurde dieser Videotermin aufgezeichnet? ... Leider habe ich den Termin verpasst :-( Viele Grüße, Harald Hartmann Am 27.08.24 um 16:39 schrieb Katja Haferkorn: Hallo, für die Organisation und Programmgestaltung der FOSSGIS-Konferenz nutzt das Konferenzorganisationsteam verschiedene technische Tools. Diese werden am 05.10.2024 um 17 Uhr in einem Videotermin präsentiert. Vorgestellt werden: Wiki, Gitlab, Pretalx-Programmverwaltung, Zammad, Matrix, Pretix-Ticketing und Helfersystem. Raum: https://osmvideo.cloud68.co/user/gis-i1w-c3r-yyx Wer also schon immer mal etwas dazu wissen oder fragen wollte, ist herzlich eingeladen teilzunehmen. https://mastodon.online/@FOSSGISeV/113034390965953188 Für Fragen stehe ich gern zur Verfügung. Viele Grüße Katja ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #741 26/09/2024-02/10/2024
Die Wochennotiz Ausgabe Nr. # 741, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17520/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstellung - Technische Tools für die Organisation und Programmgestaltung der FOSSGIS-Konferenz
Hallo Katja, wurde dieser Videotermin aufgezeichnet? ... Leider habe ich den Termin verpasst :-( Viele Grüße, Harald Hartmann Am 27.08.24 um 16:39 schrieb Katja Haferkorn: Hallo, für die Organisation und Programmgestaltung der FOSSGIS-Konferenz nutzt das Konferenzorganisationsteam verschiedene technische Tools. Diese werden am 05.10.2024 um 17 Uhr in einem Videotermin präsentiert. Vorgestellt werden: Wiki, Gitlab, Pretalx-Programmverwaltung, Zammad, Matrix, Pretix-Ticketing und Helfersystem. Raum: https://osmvideo.cloud68.co/user/gis-i1w-c3r-yyx Wer also schon immer mal etwas dazu wissen oder fragen wollte, ist herzlich eingeladen teilzunehmen. https://mastodon.online/@FOSSGISeV/113034390965953188 Für Fragen stehe ich gern zur Verfügung. Viele Grüße Katja ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und OAuth
Moin Markus, am 04.10.2024 um 19:04 schrieb Markus via Talk-de: Hat niemand eine Idee? Das Weitere in deiner Nachricht passt perfekt zu dem, was ich bereits am 26. Sept. schrieb: Vermutung: Alte JOSM-Version. Der API-Server akzeptiert seit längerem nur noch OAuth 2.0. Da werden keine Daten eingetragen, sondern per Klick vom Server geholt (wenn man bei openstreetmap.org angemeldet ist). Neuere JOSM-Versionen bieten Anmeldung mit Benutzername und PW _NICHT MEHR_ an. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und OAuth
Welche JOSM Version hast du installiert? Am 04.10.24 um 19:04 schrieb Markus via Talk-de: Hat niemand eine Idee? Mit meinen OSM-Benutzerdaten kann ich mich auf osm.org anmelden. JOSM findet noch nicht gespeicherte Daten und meldet für OAuth fehlgeschlagene Zugangsdaten. Ich soll auf Einstellungen neue anfordern. Einstellungen meldet, dass es bereits Zugangdaten gebe. Diese kann ich testen, oder neue anfordern. Test: fehlgeschlagen. Neue: wünscht Benutzername und PW (hat ja auf OSM funktioniert) also "Jetzt autorisieren": fehlgeschlagen... ich soll in "Einstellungen" neue Daten beantragen --> Dauerschleife Was nun? Gruss, Markus Am 26.09.2024 um 19:04 schrieb Markus via Talk-de: JOSM scheint mich nicht mehr zu kennen... Ich soll die Daten unter Einstellungen eintragen. Dort kann ich Prüfen -> Fehler JOSM friert ein Über Win-TaskManager geschlossen. Nach Neustart lädt JOSM die eben gemachte Arbeit :-) Auf Einstellungen fordert er Benutzername und PW Meint er damit die OAuth-Kennung? oder das geheime OAuth-PW? (je 40 Stellen) oder noch etwas anderes? (Die verlinkte Hilfe bringt nur fremde Sprachen) Kann ich irgendwo mit meinem Nutzernamen neue Daten anfordern? Gruss, Markus _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und OAuth
Hat niemand eine Idee? Mit meinen OSM-Benutzerdaten kann ich mich auf osm.org anmelden. JOSM findet noch nicht gespeicherte Daten und meldet für OAuth fehlgeschlagene Zugangsdaten. Ich soll auf Einstellungen neue anfordern. Einstellungen meldet, dass es bereits Zugangdaten gebe. Diese kann ich testen, oder neue anfordern. Test: fehlgeschlagen. Neue: wünscht Benutzername und PW (hat ja auf OSM funktioniert) also "Jetzt autorisieren": fehlgeschlagen... ich soll in "Einstellungen" neue Daten beantragen --> Dauerschleife Was nun? Gruss, Markus Am 26.09.2024 um 19:04 schrieb Markus via Talk-de: JOSM scheint mich nicht mehr zu kennen... Ich soll die Daten unter Einstellungen eintragen. Dort kann ich Prüfen -> Fehler JOSM friert ein Über Win-TaskManager geschlossen. Nach Neustart lädt JOSM die eben gemachte Arbeit :-) Auf Einstellungen fordert er Benutzername und PW Meint er damit die OAuth-Kennung? oder das geheime OAuth-PW? (je 40 Stellen) oder noch etwas anderes? (Die verlinkte Hilfe bringt nur fremde Sprachen) Kann ich irgendwo mit meinem Nutzernamen neue Daten anfordern? Gruss, Markus _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Karte für Mitfahrgelegenheiten bei Veranstgaltungen
1. https://nominatim.openstreetmap.org wäre eine Möglichkeit, dort NUR die PLZ einzugeben, dann erhält man den Center-Point des PLZ Gebietes, das war's dann aber auch schon 2. https://overpass-turbo.eu/ wäre eine weitere Möglichkeit, z.B. mit der Abfrage [out:json][timeout:25]; area[postal_code="96052"]->.a; node(area.a)[place]; out geom; werden einem alle "place" Nodes eines PLZ-Gebietes zurückgeliefert, dann muss man sich halt überlegen, wie man diese Places noch einschränkt bzw. weiter verarbeitet: village, neighbourhood, suburb, quarter, city, town, usw. Um aber dein a) und b) unterscheiden zu können, wirst du wohl nicht herumkommen, dir selbst eine Datenbank aufzusetzen und dann entsprechende Spatial Abfragen zu machen. Weil die Abgrenzung "grosse Städte" und "vom Land" sind halt schon sehr unscharf. Am 01.10.24 um 10:24 schrieb Markus via Talk-de: So - ich fang jetzt nochmal von vorne an mit meinem Projekt :-) (Taggingfragen, Lizenzen, Quellen und Co. --> bitte in Extra-Thead diskutieren! - danke.) Am 28.09.2024 um 13:18 schrieb Markus via Talk-de: Hintergrund: Bei Veranstaltungen wäre es sinnvoll, wenn TN sich zu Fahrgemeinschaften zusammenschliessen und das selbständig organisieren könnten: - Karte mit TN-Wohnort (PLZ) und Veranstaltungsort damit man intuitiv erkennt, wo es Möglichkeiten gibt (Zugang über PW) - Klick auf TN-Ort liefert Kontaktdaten (eMail sowie suche und/oder biete) - Orga erfolgt dann individuell Am 28.09.2024 um 15:23 schrieb Rainer via Talk-de: >> https://postcode.wambachers-osm.website >> stellt PLZ-Grenzen dar. Und gestern schrieb ich: Ich habe: PLZ und Ortsname (XLS). Nach etwas Nachdenken und Beispieladressen prüfen, kann ich die Anforderung noch etwas genauer beschreiben: Für jeden Datensatz hätte ich gern einen Marker auf der Karte: a) Für Daten aus grossen Städten (mit mehreren PLZ) hätte ich gern einen Marker in der PLZ-Grenze. b) Für Daten vom Land (mit vielen Orten in der PLZ-Grenze) hätte ich gern einen Marker im Ort. c) und dafür muss man a) und b) "irgendwie" unterscheiden... Ich suche also eine Methode, wie ich für a) und für b) mit den XLS-Daten per Abfrage eine Liste mit Koordinaten bekomme. Und eine Methode, mit der ich Fall-a von Fall-b unterscheiden kann. (ich hoffe, das ist verständlich? sonst gern nachfragen!) Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Obermain
On Thu, 26 Sept 2024 at 13:51, Norbert Kück wrote: > > Hallo Markus, > > am 26.09.2024 um 09:45 schrieb Markus via Talk-de: > > Wie finde ich die Relation "Obermain"? > Das wird wohl nicht gehen. > Es gibt eine Relation "Main" [1], die vermutlich auch in der Fundliste > steckt. Sie hat 196 Mitglieder – alles Ways kein "Obermain" dabei. > Gruß > Norbert > > [1] https://www.openstreetmap.org/relation/412876#map=8/49.918/9.844 Es gibt in Deutschland 11 Relationen mit dem Wort "Obermain". Das sind meistens Wander- und Radrouten. siehe https://download.bbbike.org/bbbike/tmp/obermain.png https://search.bbbike.org -Wolfram -- Wolfram Schneider https://wolfram.schneider.org Planet.osm extracts: https://extract.bbbike.org BBBike Map Compare: https://mc.bbbike.org/mc ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [EXT] PLZ-Karte
Hei, ich stelle mir die Frage: wer vergibt primär eine Adresse? Es die jeweilige Amts- oder Gemeindeverwaltung oder ähnliches. Daraus folgt für mich, daß deren Angabe in die primär zu verwenden ist (vor allem, wenn man die entsprechende Datennutzungsmöglichkeiten hat, wie wir in Brandenburg). Daraus folgt für mich auch, daß einzig die PLZ-Angabe (addr:postcode=*) eine postalische Angabe ist. Der User lberges macht diese Edits deutschlandweit. Ich glaube nicht, daß er deutschlandweit das Allgemeinwissen hat, um diese Angaben aus den Stehgreif heraus machen zu können... Ich vermute, da er weiterhin nicht zulässige Drittquellen nutzt, die er nicht mehr angibt, auch auf Nachfrage nicht. Die PLZ-Karte als Quelle anzugeben, passt hier nicht, da diese nur das anzeigt, was in OSM erfasst ist... Verbiegt man Namen, werden diese angezeigt und danach werden die restlich Daten verbogen... Ich sehe OSM nicht als eine Pseudokopie irgendeiner PLZ-Datenbank wo einer vom anderen kopiert und eventuelle Fehler mitgeschleift werden und sich fortsetzen. Nutzbare amtlich Adressangaben sind mir da wesentlich näher. Eventuell davon abweichende postalischen Angaben können dann entsprechend erfasst werden: z.B.: postal:addr:*=* [ausgenommen addr:postcode=*] Sven -Ursprüngliche Nachricht- Von: OSM Gesendet: Dienstag, 1. Oktober 2024 09:30 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] [EXT] PLZ-Karte Moin, Am 30.09.2024 um 21:59 schrieb Sven Kasparz (OSM): > Hierdraus und damit im Zusammenhang geht auch daraus hervor, daß > Adressen primär amtlich sind, lediglich die PLZ-Angabe selbst wird > nach Gutdünken der Post vergeben. > > Einer der wichtigsten Zuträger der aktuellen PLZ-Karte ist der User > lberges > > Er ignoriert aber jegliche Angaben, wonach er die Daten (seiner > Meinung und deinen Edits nach) stammen. Meiner Meinung nach aus so in > der Form für OSM nicht nutzbaren und irgendwelchen PLZ-Datenbanken. > Daten verbiegt er nach dieser Sichtweise. > > Wahllos herausgegriffenes Beispiel: > https://overpass-api.de/achavi/?changeset=157270758 > > Woran sieht er bei Bing den falschen Namen? Die Quellen-Angabe Bing würde ich hier primär auf die Positionierung der Spielplätze beziehen und nicht auf die Adressangaben. Die Angaben der Adresse sind aber doch ganz normaler Standard: Mörz ist nunmal seit 1975 ein Ortsteil der Gemeinde Münstermaifeld. Dafür braucht es doch keine weiteren Datenquellen ... das ist doch schon Allgemeinwissen. Damit ergeben sich die addr:-Angaben doch ganz automatisch: addr:city = Münstermaifeld addr:suburb = Mörz Ich dachte, das hätte sich allgemein als Konsens durchgesetzt - da es sonst Probleme in der Adressfindung geben würde. Denn die Älteren bzw. Örtlichen kennen das unter der alten (postalischen) Ortsangabe "Mörz" und die jüngeren bzw. Externen unter der modernen (postalischen) Ortsangabe "Münstermaifeld". Und die Benutzer arbeiten nunmal mit den jeweils ihnen bekannten (postalischen) Adressangaben. Gruß Georg -- Diese E-Mail wurde von AVG-Antivirussoftware auf Viren geprüft. www.avg.com _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [EXT] PLZ-Karte
Moin, Am 30.09.2024 um 21:59 schrieb Sven Kasparz (OSM): Hierdraus und damit im Zusammenhang geht auch daraus hervor, daß Adressen primär amtlich sind, lediglich die PLZ-Angabe selbst wird nach Gutdünken der Post vergeben. Einer der wichtigsten Zuträger der aktuellen PLZ-Karte ist der User lberges Er ignoriert aber jegliche Angaben, wonach er die Daten (seiner Meinung und deinen Edits nach) stammen. Meiner Meinung nach aus so in der Form für OSM nicht nutzbaren und irgendwelchen PLZ-Datenbanken. Daten verbiegt er nach dieser Sichtweise. Wahllos herausgegriffenes Beispiel: https://overpass-api.de/achavi/?changeset=157270758 Woran sieht er bei Bing den falschen Namen? Die Quellen-Angabe Bing würde ich hier primär auf die Positionierung der Spielplätze beziehen und nicht auf die Adressangaben. Die Angaben der Adresse sind aber doch ganz normaler Standard: Mörz ist nunmal seit 1975 ein Ortsteil der Gemeinde Münstermaifeld. Dafür braucht es doch keine weiteren Datenquellen ... das ist doch schon Allgemeinwissen. Damit ergeben sich die addr:-Angaben doch ganz automatisch: addr:city = Münstermaifeld addr:suburb = Mörz Ich dachte, das hätte sich allgemein als Konsens durchgesetzt - da es sonst Probleme in der Adressfindung geben würde. Denn die Älteren bzw. Örtlichen kennen das unter der alten (postalischen) Ortsangabe "Mörz" und die jüngeren bzw. Externen unter der modernen (postalischen) Ortsangabe "Münstermaifeld". Und die Benutzer arbeiten nunmal mit den jeweils ihnen bekannten (postalischen) Adressangaben. Gruß Georg -- Diese E-Mail wurde von AVG-Antivirussoftware auf Viren geprüft. www.avg.com ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Karte für Mitfahrgelegenheiten bei Veranstgaltungen
So - ich fang jetzt nochmal von vorne an mit meinem Projekt :-) (Taggingfragen, Lizenzen, Quellen und Co. --> bitte in Extra-Thead diskutieren! - danke.) Am 28.09.2024 um 13:18 schrieb Markus via Talk-de: Hintergrund: Bei Veranstaltungen wäre es sinnvoll, wenn TN sich zu Fahrgemeinschaften zusammenschliessen und das selbständig organisieren könnten: - Karte mit TN-Wohnort (PLZ) und Veranstaltungsort damit man intuitiv erkennt, wo es Möglichkeiten gibt (Zugang über PW) - Klick auf TN-Ort liefert Kontaktdaten (eMail sowie suche und/oder biete) - Orga erfolgt dann individuell Am 28.09.2024 um 15:23 schrieb Rainer via Talk-de: >> https://postcode.wambachers-osm.website >> stellt PLZ-Grenzen dar. Und gestern schrieb ich: Ich habe: PLZ und Ortsname (XLS). Nach etwas Nachdenken und Beispieladressen prüfen, kann ich die Anforderung noch etwas genauer beschreiben: Für jeden Datensatz hätte ich gern einen Marker auf der Karte: a) Für Daten aus grossen Städten (mit mehreren PLZ) hätte ich gern einen Marker in der PLZ-Grenze. b) Für Daten vom Land (mit vielen Orten in der PLZ-Grenze) hätte ich gern einen Marker im Ort. c) und dafür muss man a) und b) "irgendwie" unterscheiden... Ich suche also eine Methode, wie ich für a) und für b) mit den XLS-Daten per Abfrage eine Liste mit Koordinaten bekomme. Und eine Methode, mit der ich Fall-a von Fall-b unterscheiden kann. (ich hoffe, das ist verständlich? sonst gern nachfragen!) Mit herzlichem Gruss, Markus ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ankündigung FOSSGIS 2025 in Münster (26.-29. März 2025)
Liebe Freunde der FOSSGIS und OSM Community, die nächste FOSSGIS-Konferenz wird vom 26. bis 29. März 2025 im Schloss Münster stattfinden, gemeinsam organisiert vom FOSSGIS e.V. in Kooperation mit dem Institut für Geoinformatik der Universität Münster. Mit dem alljährlichen Ziel der Verbreitung von Freier und Open Source Software für Geoinformationssysteme sowie Open Data laden wir Anwender:innen, Entwickler:innen, Forscher:innen und Interessierte ein, sich zum gemeinsamen Austausch über Anwendungs-, Arbeits- und Weiterentwicklungsmöglichkeiten sowie neuesten Entwicklungen und Themen in diesem Bereich auszutauschen. Konferenzhomepage: https://fossgis-konferenz.de/2025 Wer sich mit einem Beitrag zum Programm beteiligen will, reicht im Rahmen des Call for Participation einen Beitrag ein, dieser startet am 05.10. und ist bis zum 05.11.2024 für Einreichungen geöffnet. Neu: Community Sprint - Einige Teilnehmende wünschen sich für den Samstag einen Community Sprint, diesen wird das Konferenzorgateam parallel zum OSM-Samstag planen. Wie jedes Jahr benötigen wir Unterstützung durch freiwillige Helfer:innen bei den Videoaufzeichnungen, der Moderation der Sessions sowie der Umsetzung der hybriden Formate. Wer helfen möchte, findet Informationen auf der Konferenzhomepage unter "Helfen". Sponsoren sind willkommen. Informationen zum Sponsoring sind auf \[Konferenzhomepage\](https://fossgis-konferenz.de/2025/#Sponsoring) zu finden. Das Programm und die Anmeldung werden Anfang Januar 2025 freigeschaltet. Da die Zahl der Teilnehmenden begrenzt ist, raten wir sich rechtzeitig anzumelden. Hashtag für Social Media: #FOSSGIS2025 Freundliche Grüße Katja für das Konferenzorganisationsteam -- ... Katja Haferkorn Koordinierungsstelle FOSSGIS e.V. E-Mail: katja.haferk...@fossgis.de Telefon: +49 30-62932037 Mobil: +49 176 51194732 Matrix: @katjahafi:matrix.org Web: fossgis.de Adresse: Bundesallee 23, 10717 Berlin Eintragung im Vereinsregister. Registergericht: Stadt Mainz. Registernummer: 90 VR 3594. Vertreten durch Jörg Thomsen, Pirmin Kalberer, David Arndt, Falk Zscheile . Vereinstermine: https://fossgis.de/aktivit%C3%A4ten/termine/ ... FOSSGIS-Konferenz - OSM-Event - 26. - 29. März 2025 Münster https://www.fossgis-konferenz.de - @FOSSGISeV@mastodon.online . _______ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [EXT] PLZ-Karte
Guten Abend, ich bin ja eher kein Mailing-Listen-Nutzer, ich hab hier aber doch Kommentare. Für Brandenburg sind ja bekanntlich die Geodaten nutzbar, das betrifft auch die Adressdaten. Der User https://www.openstreetmap.org/user/hfs hat für JOSM auch einen dafür nutzbaren mvt-Dienst: mvt:https://hfs.github.io/brandenburg-addresses/style.json Hierzu ist https://wiki.openstreetmap.org/wiki/Brandenburg/Geoportal zu beachten. Hierdraus und damit im Zusammenhang geht auch daraus hervor, daß Adressen primär amtlich sind, lediglich die PLZ-Angabe selbst wird nach Gutdünken der Post vergeben. Einer der wichtigsten Zuträger der aktuellen PLZ-Karte ist der User lberges Er ignoriert aber jegliche Angaben, wonach er die Daten (seiner Meinung und deinen Edits nach) stammen. Meiner Meinung nach aus so in der Form für OSM nicht nutzbaren und irgendwelchen PLZ-Datenbanken. Daten verbiegt er nach dieser Sichtweise. Wahllos herausgegriffenes Beispiel: https://overpass-api.de/achavi/?changeset=157270758 Woran sieht er bei Bing den falschen Namen? Fazit für mich: alle von lberges geänderten Adressangaben für die PLZ-Karte ziehe ich in Zweifel. Sven -Ursprüngliche Nachricht- Von: Markus via Talk-de Gesendet: Montag, 30. September 2024 20:18 An: Elstermann, Mike ; Openstreetmap allgemeines in Deutsch Cc: Markus Betreff: Re: [Talk-de] [EXT] PLZ-Karte Hallo Mike, danke für den interessanten Artikel! Historie: Vor vielen Jahren hat uns Jan Gerhke seine Gemeindegrenzen zur Verfügung gestellt. 2010 kamen die PLZ von Arnulf hinzu und später Analysen von Jan zu unserem Datenbestand bis 2016: https://wiki.openstreetmap.org/wiki/DE:Konsolidierung_der_PLZ-Relationen_in_ Deutschland_2013 Walter hat damals seine PLZ-Karte gemacht und hält sie bis heute aktuell. Zu meinem Projekt: Ich habe: PLZ und Ortsname (XLS). Nach etwas Nachdenken und Beispieladressen prüfen, kann ich die Anforderung noch etwas genauer beschreiben: Für jeden Datensatz hätte ich gern einen Marker auf der Karte: a) Für Daten aus grossen Städten (mit mehreren PLZ) hätte ich gern einen Marker in der PLZ-Grenze. b) Für Daten vom Land (mit vielen Orten in der PLZ-Grenze) hätte ich gern einen Marker im Ort. c) und dafür muss man a) und b) "irgendwie" unterscheiden... Ich suche also eine Methode, wie ich für a) und für b) mit den XLS-Daten per Abfrage eine Liste mit Koordinaten bekomme. Und eine Methode, mit der ich Fall-a von Fall-b unterscheiden kann. (ich hoffe, das ist verständlich? sonst gern nachfragen!) Mit herzlichem Gruss, Markus Am 28.09.2024 um 21:48 schrieb Elstermann, Mike: > Hallo zusammen, > > ich hatte dazu im August 2024 mal einen Artikel im #geoObserver > geschrieben, vgl. > https://geoobserver.de/2024/08/02/plz-postleitzahlen-eine-neverending- > story-ein-aufruf/ > <https://geoobserver.de/2024/08/02/plz-postleitzahlen-eine-neverending > -story-ein-aufruf/> Befriedigend ist die Situation bis heute nicht, > aber das steht ja alles dort drin ;-) Schaut auch mal in die > Kommentare. > > BG aus HAL, mikeE., der #geoObserver. > >> Am 28.09.2024 um 21:06 schrieb Markus via Talk-de >> : >> >> Danke Rainer, das ist genau das was ich gesucht habe :-) >> >> Am 28.09.2024 um 15:23 schrieb Rainer via Talk-de: >> >>> https://postcode.wambachers-osm.website >>> stellt PLZ-Grenzen dar. >> >> Hast du eine Idee, wie ich für jeden TN einen Marker in einen Layer >> bekomme? >> Der Marker soll nicht Adress-genau stehen, sondern nur ungefähr, z.B. >> in grösseren Städten im Zentrum der PLZ-Grenze und in kleineren Orten >> (viele Orte in mit gleicher PLZ) in der Mitte des Ortes. >> Durch die Anmeldung der TN habe ich PLZ und Ort Gibt es da ein Tool, >> das daraus eine Koordinate macht? >> Oder geht das auch direkt? >> (mit Koordinate wüsste ich wie es geht) >> >> Gruss, Markus >> >> >> >> >>> Am 28.09.24 um 13:18 schrieb Markus via Talk-de: >>>> Wenn ich das Wiki richtig verstehe, haben wir seit 2013 alle >>>> Postleitzahlen als Relationen vollständig? >>>> >>>> Haben wir dafür auch eine Karte? >>>> oder sogar einen Layer? >>>> gefunden habe ich ein PNG: >>>> https://wiki.openstreetmap.org/w/images/e/ef/2013-12-de-postals.png >>>> >>>> Gibt es schon Anwendungen dafür? >>>> >>>> Hintergrund: >>>> Bei Veranstaltungen wäre es sinnvoll, wenn TN sich zu >>>> Fahrgemeinschaften zusammenschliessen und das selbständig organisieren könnten: >>>> - Karte mit TN-Wohnort (PLZ) und Veranstaltungsort >>>> damit man intuitiv erkennt, wo es Möglichkeiten gibt >>>> (Zugang über PW) >>>> - Klick auf TN-Ort lie
Re: [Talk-de] [EXT] PLZ-Karte
Hallo Mike, danke für den interessanten Artikel! Historie: Vor vielen Jahren hat uns Jan Gerhke seine Gemeindegrenzen zur Verfügung gestellt. 2010 kamen die PLZ von Arnulf hinzu und später Analysen von Jan zu unserem Datenbestand bis 2016: https://wiki.openstreetmap.org/wiki/DE:Konsolidierung_der_PLZ-Relationen_in_Deutschland_2013 Walter hat damals seine PLZ-Karte gemacht und hält sie bis heute aktuell. Zu meinem Projekt: Ich habe: PLZ und Ortsname (XLS). Nach etwas Nachdenken und Beispieladressen prüfen, kann ich die Anforderung noch etwas genauer beschreiben: Für jeden Datensatz hätte ich gern einen Marker auf der Karte: a) Für Daten aus grossen Städten (mit mehreren PLZ) hätte ich gern einen Marker in der PLZ-Grenze. b) Für Daten vom Land (mit vielen Orten in der PLZ-Grenze) hätte ich gern einen Marker im Ort. c) und dafür muss man a) und b) "irgendwie" unterscheiden... Ich suche also eine Methode, wie ich für a) und für b) mit den XLS-Daten per Abfrage eine Liste mit Koordinaten bekomme. Und eine Methode, mit der ich Fall-a von Fall-b unterscheiden kann. (ich hoffe, das ist verständlich? sonst gern nachfragen!) Mit herzlichem Gruss, Markus Am 28.09.2024 um 21:48 schrieb Elstermann, Mike: Hallo zusammen, ich hatte dazu im August 2024 mal einen Artikel im #geoObserver geschrieben, vgl. https://geoobserver.de/2024/08/02/plz-postleitzahlen-eine-neverending-story-ein-aufruf/ <https://geoobserver.de/2024/08/02/plz-postleitzahlen-eine-neverending-story-ein-aufruf/> Befriedigend ist die Situation bis heute nicht, aber das steht ja alles dort drin ;-) Schaut auch mal in die Kommentare. BG aus HAL, mikeE., der #geoObserver. Am 28.09.2024 um 21:06 schrieb Markus via Talk-de : Danke Rainer, das ist genau das was ich gesucht habe :-) Am 28.09.2024 um 15:23 schrieb Rainer via Talk-de: https://postcode.wambachers-osm.website stellt PLZ-Grenzen dar. Hast du eine Idee, wie ich für jeden TN einen Marker in einen Layer bekomme? Der Marker soll nicht Adress-genau stehen, sondern nur ungefähr, z.B. in grösseren Städten im Zentrum der PLZ-Grenze und in kleineren Orten (viele Orte in mit gleicher PLZ) in der Mitte des Ortes. Durch die Anmeldung der TN habe ich PLZ und Ort Gibt es da ein Tool, das daraus eine Koordinate macht? Oder geht das auch direkt? (mit Koordinate wüsste ich wie es geht) Gruss, Markus Am 28.09.24 um 13:18 schrieb Markus via Talk-de: Wenn ich das Wiki richtig verstehe, haben wir seit 2013 alle Postleitzahlen als Relationen vollständig? Haben wir dafür auch eine Karte? oder sogar einen Layer? gefunden habe ich ein PNG: https://wiki.openstreetmap.org/w/images/e/ef/2013-12-de-postals.png Gibt es schon Anwendungen dafür? Hintergrund: Bei Veranstaltungen wäre es sinnvoll, wenn TN sich zu Fahrgemeinschaften zusammenschliessen und das selbständig organisieren könnten: - Karte mit TN-Wohnort (PLZ) und Veranstaltungsort damit man intuitiv erkennt, wo es Möglichkeiten gibt (Zugang über PW) - Klick auf TN-Ort liefert Kontaktdaten (eMail sowie suche und/oder biete) - Orga erfolgt dann individuell Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weeklyOSM #740 19/09/2024-25/09/2024
Die Wochennotiz Ausgabe Nr. # 740, ist nun verfügbar - wie immer mit vielen Nachrichten aus dem OSM-Universium: https://www.weeklyosm.eu/de/archives/17509/ Viel Spaß beim Lesen. Euer Wochennotizteam Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [EXT] PLZ-Karte
Hallo zusammen, ich hatte dazu im August 2024 mal einen Artikel im #geoObserver geschrieben, vgl. https://geoobserver.de/2024/08/02/plz-postleitzahlen-eine-neverending-story-ein-aufruf/ Befriedigend ist die Situation bis heute nicht, aber das steht ja alles dort drin ;-) Schaut auch mal in die Kommentare. BG aus HAL, mikeE., der #geoObserver. Am 28.09.2024 um 21:06 schrieb Markus via Talk-de : Danke Rainer, das ist genau das was ich gesucht habe :-) Am 28.09.2024 um 15:23 schrieb Rainer via Talk-de: https://postcode.wambachers-osm.website stellt PLZ-Grenzen dar. Hast du eine Idee, wie ich für jeden TN einen Marker in einen Layer bekomme? Der Marker soll nicht Adress-genau stehen, sondern nur ungefähr, z.B. in grösseren Städten im Zentrum der PLZ-Grenze und in kleineren Orten (viele Orte in mit gleicher PLZ) in der Mitte des Ortes. Durch die Anmeldung der TN habe ich PLZ und Ort Gibt es da ein Tool, das daraus eine Koordinate macht? Oder geht das auch direkt? (mit Koordinate wüsste ich wie es geht) Gruss, Markus Am 28.09.24 um 13:18 schrieb Markus via Talk-de: Wenn ich das Wiki richtig verstehe, haben wir seit 2013 alle Postleitzahlen als Relationen vollständig? Haben wir dafür auch eine Karte? oder sogar einen Layer? gefunden habe ich ein PNG: https://wiki.openstreetmap.org/w/images/e/ef/2013-12-de-postals.png Gibt es schon Anwendungen dafür? Hintergrund: Bei Veranstaltungen wäre es sinnvoll, wenn TN sich zu Fahrgemeinschaften zusammenschliessen und das selbständig organisieren könnten: - Karte mit TN-Wohnort (PLZ) und Veranstaltungsort damit man intuitiv erkennt, wo es Möglichkeiten gibt (Zugang über PW) - Klick auf TN-Ort liefert Kontaktdaten (eMail sowie suche und/oder biete) - Orga erfolgt dann individuell Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Karte
Danke Rainer, das ist genau das was ich gesucht habe :-) Am 28.09.2024 um 15:23 schrieb Rainer via Talk-de: https://postcode.wambachers-osm.website stellt PLZ-Grenzen dar. Hast du eine Idee, wie ich für jeden TN einen Marker in einen Layer bekomme? Der Marker soll nicht Adress-genau stehen, sondern nur ungefähr, z.B. in grösseren Städten im Zentrum der PLZ-Grenze und in kleineren Orten (viele Orte in mit gleicher PLZ) in der Mitte des Ortes. Durch die Anmeldung der TN habe ich PLZ und Ort Gibt es da ein Tool, das daraus eine Koordinate macht? Oder geht das auch direkt? (mit Koordinate wüsste ich wie es geht) Gruss, Markus Am 28.09.24 um 13:18 schrieb Markus via Talk-de: Wenn ich das Wiki richtig verstehe, haben wir seit 2013 alle Postleitzahlen als Relationen vollständig? Haben wir dafür auch eine Karte? oder sogar einen Layer? gefunden habe ich ein PNG: https://wiki.openstreetmap.org/w/images/e/ef/2013-12-de-postals.png Gibt es schon Anwendungen dafür? Hintergrund: Bei Veranstaltungen wäre es sinnvoll, wenn TN sich zu Fahrgemeinschaften zusammenschliessen und das selbständig organisieren könnten: - Karte mit TN-Wohnort (PLZ) und Veranstaltungsort damit man intuitiv erkennt, wo es Möglichkeiten gibt (Zugang über PW) - Klick auf TN-Ort liefert Kontaktdaten (eMail sowie suche und/oder biete) - Orga erfolgt dann individuell Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Karte
Hallo Markus, https://postcode.wambachers-osm.website stellt PLZ-Grenzen dar. Viele Grüße, Rainer Am 28.09.24 um 13:18 schrieb Markus via Talk-de: Wenn ich das Wiki richtig verstehe, haben wir seit 2013 alle Postleitzahlen als Relationen vollständig? Haben wir dafür auch eine Karte? oder sogar einen Layer? gefunden habe ich ein PNG: https://wiki.openstreetmap.org/w/images/e/ef/2013-12-de-postals.png Gibt es schon Anwendungen dafür? Hintergrund: Bei Veranstaltungen wäre es sinnvoll, wenn TN sich zu Fahrgemeinschaften zusammenschliessen und das selbständig organisieren könnten: - Karte mit TN-Wohnort (PLZ) und Veranstaltungsort damit man intuitiv erkennt, wo es Möglichkeiten gibt (Zugang über PW) - Klick auf TN-Ort liefert Kontaktdaten (eMail sowie suche und/oder biete) - Orga erfolgt dann individuell Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] PLZ-Karte
Wenn ich das Wiki richtig verstehe, haben wir seit 2013 alle Postleitzahlen als Relationen vollständig? Haben wir dafür auch eine Karte? oder sogar einen Layer? gefunden habe ich ein PNG: https://wiki.openstreetmap.org/w/images/e/ef/2013-12-de-postals.png Gibt es schon Anwendungen dafür? Hintergrund: Bei Veranstaltungen wäre es sinnvoll, wenn TN sich zu Fahrgemeinschaften zusammenschliessen und das selbständig organisieren könnten: - Karte mit TN-Wohnort (PLZ) und Veranstaltungsort damit man intuitiv erkennt, wo es Möglichkeiten gibt (Zugang über PW) - Klick auf TN-Ort liefert Kontaktdaten (eMail sowie suche und/oder biete) - Orga erfolgt dann individuell Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und OAuth
Hallo Markus, am 26.09.2024 um 19:04 schrieb Markus via Talk-de: JOSM scheint mich nicht mehr zu kennen... Ich soll die Daten unter Einstellungen eintragen. Dort kann ich Prüfen -> Fehler Diese Situation ist mir unbekannt. Vermutung: Alte JOSM-Version. Der API-Server akzeptiert seit längerem nur noch OAuth 2.0. Da werden keine Daten eingetragen, sondern per Klick vom Server geholt (wenn man bei openstreetmap.org angemeldet ist). Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM und OAuth
JOSM scheint mich nicht mehr zu kennen... Ich soll die Daten unter Einstellungen eintragen. Dort kann ich Prüfen -> Fehler JOSM friert ein Über Win-TaskManager geschlossen. Nach Neustart lädt JOSM die eben gemachte Arbeit :-) Auf Einstellungen fordert er Benutzername und PW Meint er damit die OAuth-Kennung? oder das geheime OAuth-PW? (je 40 Stellen) oder noch etwas anderes? (Die verlinkte Hilfe bringt nur fremde Sprachen) Kann ich irgendwo mit meinem Nutzernamen neue Daten anfordern? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Obermain
Alles gut - WP brauchen wir hier nicht diskutieren (da kenne ich mich aus). Ich habe nur die Relation gesucht und dachte, vielleicht kann sie ja jemand erstellen (damit kenne ich mich nicht aus). Damit könnte ich dann ein anschauliches Bild erstellen... Mit herzlichem Gruss, Markus Am 26.09.2024 um 18:09 schrieb Norbert Kück: Hallo Markus, am 26.09.2024 um 17:31 schrieb Markus via Talk-de: Hatte dort den Artikel bereits angeregt. Es gibt dort eine Weiterleitung von Obermain auf Obermainland (was zu Verwirrung führt). Diese Weiterleitung ist wirklich unglücklich. Dieses Sprungziel würde ich nicht erwarten. Aber ein neuer Artikel zum Gewässerabschnitt wäre als redundant angreifbar. Besser scheint mir, die Weiterleitung auf Main#Der_Obermain umzubiegen. Dort gibts schon viel Info zum Obermain. Übrigens eignet sich die Messfunktion von JOSM gut zur Bestimmung der Länge einer markierten Linie. (Womit wir wieder beim Thema dieser Liste sind.) Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Obermain
Hallo Markus, am 26.09.2024 um 17:31 schrieb Markus via Talk-de: Hatte dort den Artikel bereits angeregt. Es gibt dort eine Weiterleitung von Obermain auf Obermainland (was zu Verwirrung führt). Diese Weiterleitung ist wirklich unglücklich. Dieses Sprungziel würde ich nicht erwarten. Aber ein neuer Artikel zum Gewässerabschnitt wäre als redundant angreifbar. Besser scheint mir, die Weiterleitung auf Main#Der_Obermain umzubiegen. Dort gibts schon viel Info zum Obermain. Übrigens eignet sich die Messfunktion von JOSM gut zur Bestimmung der Länge einer markierten Linie. (Womit wir wieder beim Thema dieser Liste sind.) Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Obermain
Hallo Norbert, Hatte dort den Artikel bereits angeregt. Es gibt dort eine Weiterleitung von Obermain auf Obermainland (was zu Verwirrung führt). Bin aber nicht der Ortskundler, der den Artikel schreiben könnte. Kenne die Flussstrecke nur vom Kajakfahren. Als Illustrierung des Obermain-Verlaufs wäre die Relation halt hilfreich. (die Länge würde mich nur interessieren zum Vergleich) Mit herzlichem Gruss, Markus Am 26.09.2024 um 15:52 schrieb Norbert Kück: Hallo Markus, Am 26.09.2024 um 15:08 schrieb Markus via Talk-de: Kannst du diese erstellen? Kenna dat i scho aba meng dua i ned. ;-) Nur mit Ortskenntnis würde ich Kategorien erstellen. Braucht es einen eigenen Artikel? Siehe https://de.wikipedia.org/wiki/Main#Der_Obermain https://de.wikipedia.org/wiki/Obermainland Ohne einen geeigneten Beleg sollte die genaue Länge in Wikipedia nicht angegeben werden: https://de.wikipedia.org/wiki/Wikipedia:Belege Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Obermain
Hallo Markus, Am 26.09.2024 um 15:08 schrieb Markus via Talk-de: Kannst du diese erstellen? Kenna dat i scho aba meng dua i ned. ;-) Nur mit Ortskenntnis würde ich Kategorien erstellen. Braucht es einen eigenen Artikel? Siehe https://de.wikipedia.org/wiki/Main#Der_Obermain https://de.wikipedia.org/wiki/Obermainland Ohne einen geeigneten Beleg sollte die genaue Länge in Wikipedia nicht angegeben werden: https://de.wikipedia.org/wiki/Wikipedia:Belege Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Obermain
Hallo Norbert, Die Relation "Obermain" würde - beginnen am Zusammenfluss von Weißer Main und Roter Main also am Start der Relation "Main" (Mainzusammenfluss) - enden am Zusammenfluss von Obermain einerseits und Regnitz bzw. Main-Donau-Kanal andererseits (nördlich Bischberg, westlich vom Hafen Bamberg) Der Obermain ist eine Fränkische Paddelstrecke (WW 0-1): https://trekkingtrails.de/kanu-obermain/ und ein fränkisches Tourismusgebiet mit vielen Kulturdenkmälern, Fern-Rad- und Wanderwegen: https://www.frankentourismus.de/gebiete/obermainjura/ Wäre sinnvoll, das als Relation zu haben und die genaue Länge (~80km) zu wissen für einen neuen Wikipedia-Artikel... Kannst du diese erstellen? Mit herzlichem Gruss, Markus Am 26.09.2024 um 13:40 schrieb Norbert Kück: Hallo Markus, am 26.09.2024 um 09:45 schrieb Markus via Talk-de: Wie finde ich die Relation "Obermain"? Das wird wohl nicht gehen. Es gibt eine Relation "Main" [1], die vermutlich auch in der Fundliste steckt. Sie hat 196 Mitglieder – alles Ways kein "Obermain" dabei. Gruß Norbert [1] https://www.openstreetmap.org/relation/412876#map=8/49.918/9.844 ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Obermain
Hallo Markus, am 26.09.2024 um 09:45 schrieb Markus via Talk-de: Wie finde ich die Relation "Obermain"? Das wird wohl nicht gehen. Es gibt eine Relation "Main" [1], die vermutlich auch in der Fundliste steckt. Sie hat 196 Mitglieder – alles Ways kein "Obermain" dabei. Gruß Norbert [1] https://www.openstreetmap.org/relation/412876#map=8/49.918/9.844 ___________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
