[Talk-de] OSM-Buildings in SchwarzRotGold
Und passend zum heutigen Tag: die OSM-Buildings mal in SchwarzRotGold ;-) https://twitter.com/OSMBuildings/status/486797766325436416/photo/1 mikeE., der geoObserver. http://www.geoObserver.de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier= e.g. bollard / ohne access
On Sun, Jul 13, 2014 at 07:08:02PM +0200, 715371 wrote: > Moin Florian, > > Am 13.07.2014 18:54, schrieb Florian Lohoff: > > Irgendwie f???nd ich es ja sch??n wenn die regel w???re das ein barrier > > immer die Verkehrsarten listed die erlaubt sind/bzw physikalisch durch > > gehen. > > Ich w??rde davon ausgehen, dass folgendes immer gilt, wenn nicht n??her > spezifiziert: > > foot=yes > bicycle=yes > > Im Wiki sagen die das auch so und anders. > https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dbollard > > Auf jeden Fall m??sste/k??nnte man dann motorcar=permissive taggen, wenn > der Poller herausnehmbar ist, denke ich. Ich bin ja eher noch anders unterwegs. Wenn explizit getagged wird welche typen von Fahrzeugen dort passieren k�nnen und d�rfen) dann kann eine routing software alle barrier=* gleich behandeln. Und im zweifelsfalle weil hier wieder zwischen k�nnen und d�rfen unterschieden wird. Im zweifelsfalle aus sich des routings ist mir das herzlich egal ob ich kann aber nicht darf, darf aber nicht kann oder nicht kann und nicht darf. Kommt auf das selbe heraus - Dieser weg wird nicht benutzt. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag neuer Geometrie (relationen)-Typ: node-relation
On Thursday, 10 July 2014 15:41:03 +0200,
Martin Koppenhoefer writes:
> Am 10. Juli 2014 14:55 schrieb Tobias Knerr :
>
> > Dein Beispiel mit den Verkehrsschildern ist zudem nicht sinnvoll,
> > da – wie bereits von anderen erwähnt – hier schon eine
> > dokumentierte Lösung existiert: Semikolons. Da ist die Nutzung
> > einer Relation keineswegs bequemer.
>
> Das Problem ergibt sich in der Tat nicht mit Objekten, die durch
> ein einziges tag beschrieben werden können, er ergibt sich aber,
> wenn man mehrere tags hat, die sich nicht auf alle sondern nur auf
> einen Teil der Objekte beziehen (z.B. Verkehrsschild und
> Tourismushinweiser am selben Mast, aber unterschiedlicher
> operator-tag, vermutlich gibt es bessere Beispiele, das
> Grundproblem sollte aber klar sein).
Das Problem hat man immer, wenn ich mehrere Tags zur Beschreibung
eines Objekts benoetige und diese Tags selbst noch einen "inneren"
Zusammenhang haben. Beispielsweise hat man dies bei den
Zusatzschildern von Verkehrszeichen wie ein allgemeines
Geschwindigkeitsbeschraenkungsschild "120" und ein zweites mit "100",
das nur von 22-6 Uhr gilt. Dies kann man alles irgendwie durch
Ergaenzung des Tag-Keywords (also durch ein neues Keyword) ausdruecken
oder durch eine Strukturierung des Tag-Wertes ... aber so richtig
"natuerlich" ist das alles bei etwas komplizierteren Beschraenkungen
nicht mehr.
In GDF gibt es hierzu die Unterscheidung zwischen Simple Attributes
und Composite Attributes. Dort wird einer Entitaet dann mehrere
Attribute zugewiesen, die wiederum entweder einzelne Simple-Attributes
sind oder die jeweils ein Composite-Attribute bestehend aus einigen
Simple-Attributes sind.
Mit so etwas wie "taggroup" (oder "tagset") als Strukturierung der
bisherigen "flachen" Tag-Menge zu einem Objekt koennte man dies
deutlich einfacher handhaben:
statt wie bisher dies in den Tag-Keys und Tag-Values zu kodieren, also
maxspeed=120
maxspeed:conditional:hgv=80 @ (22:00-06:00)
oder so aehnlich.
Taggroups, die nur aus einem Tag bestehen, kann man wie bisher ohne
die "taggroup" schreiben - das waere gleichzeitig der Weg um das
Protokoll aufwaertskompatibel zu halten.
Der Vorschlag deckt aber nur ab die Eigenschaft _eines_ Objekts zu
beschreiben und nicht die Eigenschaften zweier Objekte ...
> > Das ebenfalls genannte Beispiel, dass ein Objekt an einem Baum
> > (oder einem Mast, einer Mauer, ...) befestigt ist, deckt deine
> > Relation hingegen gar nicht zufriedenstellend ab – dafür bräuchte
> > man eher eine "befestigt an"-Relation mit entsprechender
> > Semantik.
>
>
> Dass beides am selben Mast hängt, könnte man z.B. dadurch mappen,
> dass der node man_made=pole bekommt, und alles was dran hängt dann
> über die Relation angehängt wird. Z.B. auch Ampeln, an denen
> Verkehrsschilder hängen (bzw. hängt Ampel und Schild am selben
> Mast). Ggf. ist die Relation hier noch nicht ausreichend
> spezifiziert/definiert.
... wenn man naemlich genauer hinsieht, redet ihr von zwei
unterschiedlichen Dingen:
1. Wollte ihr die semantische Bedeutung, also eher die Auswirkung von
Verkehrschildern, Ampeln etc. beschreiben, die sich auf die
jeweilige Kreuzung bzw. die nachfolgende Strasse beziehen?
Dann reicht die Repraesentation in einem Objekt (Kreuzung oder
Strasse) und eine Menge von Attributen dieses Objekts aus.
2. Wollt ihr die Existenz von mehren Objekten und deren raeumliche
Beziehung untereinander beschreiben?
Dann benoetigt ihr auch wirklich mehrere Objekte mit eigenen
Attributen und deren Beziehung ("haengt an", "ist oberhalb von")
wird durch eine Relation mit weiteren Attributen der Relation
beschrieben.
In den meisten Faellen reicht 1. aus.
Wenn man etwas detailreicher mappen will, geht es in Richtung 2.,
wobei ich bei den meisten Verkehrschildern auch die semantische
Bedeutung auf die nachfolgende Strecke mit mappen wuerde, da nicht
immer so eindeutig ableitbar ist, bspw. wie weit eine
Geschwindigkeitsbeschraenkung wirklich gilt.
> Mauern sind wieder ein anderes Thema, die werden bisher (und wohl
> auch auf absehbare Zeit) als Linien gezeichnet, mit dem Problem,
> dass die Seiten nicht klar sind (kann man abstrahieren, indem man
> einen leichten Versatz mappt für das gehängte Punkt-objekt, und auf
> die Information verzichten, ob es an der Mauer hängt oder kurz
> davor an einer eigenen Befestigung, meist dürfte das nicht
> interessieren).
Da jede Linie eine _Digitalisierungsrichtung_ aufweist und diese auch
in OSM existiert, gibt es auch hier ein Vorwaerts/Rueckwaerts und ein
Links/Rechts. Man kann also sehr wohl mappen, ob sich etwas links
oder rechts von einer Linie befindet. Nur bei Punkten wird es
schwieriger, aber auch hier koennte man einen Abstand und den
Kompasswinkel (analog zum Heading/Nordwinkel) angeben.
Gruss,
Bernd
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://l
Re: [Talk-de] Vorschlag neuer Geometrie (relationen)-Typ: node-relation
Am 14. Juli 2014 14:03 schrieb Bernd Raichle : > Wenn man etwas detailreicher mappen will, geht es in Richtung 2., > wobei ich bei den meisten Verkehrschildern auch die semantische > Bedeutung auf die nachfolgende Strecke mit mappen wuerde, da nicht > immer so eindeutig ableitbar ist, bspw. wie weit eine > Geschwindigkeitsbeschraenkung wirklich gilt. > ja klar, die Auswirkungen / Interpretation der Verkehrsschilder (zum Beispiel) sollte auf jeden Fall _auch_ an den highway getaggt werden, trotzdem macht das (parallele) Mappen von Verkehrsschildern (oder z.B. auch Straßenschildern) manchmal durchaus Sinn. > > > > Mauern sind wieder ein anderes Thema, die werden bisher (und wohl > > auch auf absehbare Zeit) als Linien gezeichnet, mit dem Problem, > > dass die Seiten nicht klar sind (kann man abstrahieren, indem man > > einen leichten Versatz mappt für das gehängte Punkt-objekt, und auf > > die Information verzichten, ob es an der Mauer hängt oder kurz > > davor an einer eigenen Befestigung, meist dürfte das nicht > > interessieren). > > Da jede Linie eine _Digitalisierungsrichtung_ aufweist und diese auch > in OSM existiert, gibt es auch hier ein Vorwaerts/Rueckwaerts und ein > Links/Rechts. Man kann also sehr wohl mappen, ob sich etwas links > oder rechts von einer Linie befindet. > aha, und wie mappst Du z.B., ob ein Bankautomat, der sich in der Aussenwand eines Gebäudes befindet (node), ob er von innen oder von aussen zugänglich ist? Oder ein Briefkasten? Normalerweise gehen die Mapper (mich eingeschlossen) einfach intuitiv davon aus, dass er von aussen zugänglich ist, und falls er innen liegt lassen sie das Detail der Position "in der Aussenwand" unter den Tisch fallen. Problem ist, dass Linien zwar Richtungen haben, und Polygone innen und aussen, aber nodes die sich auf der Grenze (auf dem Way) befinden haben keinen "Zugriff" auf diese Richtung. Ggf. bräuchte man einen workaround wie "indoor=yes" oder man zeichnete wirklich die Wand als Fläche im Schnitt, und selbst kleine Objekte als Polygone (nicht direkt maßstabskonform in Bezug auf das, was der normale Mapper als den üblichen (derzeitigen) Maßstab von OSM ansieht). Letzteres würde auch neue Probleme schaffen, da in der Detaillierung wiederum auch Höhen wichtiger würden, und ein einfaches Layermodell nicht mehr ausreichen würde. > Nur bei Punkten wird es > schwieriger, aber auch hier koennte man einen Abstand und den > Kompasswinkel (analog zum Heading/Nordwinkel) angeben. > Abstand zu was? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Dachformen bei Obelisken??
Gerade aufgefallen, 3D-Tags an einem Obelisken: http://www.openstreetmap.org/way/43699902 roof:colour lightyellow roof:height 3 roof:shape pyramidal Ich meine, man kann mit beide Augen zudrücken und viel gutem Willen evtl. ja noch "building" und "building:material" akzeptieren (in einer weiten Auslegung als "bauliche Anlage" und die spezifischen "obelisk:material" tag-Duplizierung ignorierend), aber "Dach" geht dann doch ein bisschen zu weit bei einem massiven, bearbeiteten Steinblock, oder was denkt Ihr? Wenn der Dach-tag nicht auf alle oberen Abschlüsse anwendbar ist, muss man eben den tag ändern. Dass der rote Granit als "hellgelb" beschrieben wird, finde ich zwar merkwürdig, aber das liegt vielleicht an den spezifischen Lichtbedingungen, die der Mapper bei seinem Survey angetroffen hat... Hier ein Referenzbild http://upload.wikimedia.org/wikipedia/commons/c/cf/0_Place_Saint-Pierre_-_Vatican.JPG Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wie tagge ich Zeltplätze?
Am 08.07.2014 15:30, schrieb Martin Koppenhoefer: Am 8. Juli 2014 07:16 schrieb Markus : Moin Henning, gute Idee: osm-Dateien ins wiki laden oder man taggt ein Beispiel in OSM Service "Render mir mal die folgende osm-Datei in " Zu jedem Tagging-Vorschlag gehört immer auch ein *Rendering-Vorschlag* mit Rendering-Regeln, Icons, Flächen-Farben und -Mustern. Das halte ich für Quatsch. Einerseits gibt es viele Dinge, die viele Leute zwar in der db haben wollen, die aber nicht gerendert werden (z.B. "note", "wikipedia", "operator", "opening_hours", "ref" auf vielen Objekten die keine Straßen sind, "network", ...) Gerade das ist ja das, was benutzt wird, um nachher auch mit den Daten arbeiten zu können. Viele Dinge sind nur dafür da um überhaupt Selektionskriterien zu haben, es wird nie eine Karte geben die alles zur gleichen Zeit darstellen kann, aber wenn ich zum Beispiel am Briefkasten keinen Operator habe laufe ich zum Falschen weil dor leider der falsche Anbieter ist. Wobei ich bisher nur in Dresden Kästen anderer Anbieter sah und auch nicht weiß wie die Regen bei Falscheinwurf sind. Bei den Karten handelt es sich ja inzwischen hauptsächlich um Onlinekarten und da gibt es viele, die schon einiges können. Bei vielen anderen Dingen kann man durchaus über eine Darstellung nachdenken, nur dass die sich dann auf eine Karte beziehen wird, d.h. die Icons und Farben, Umrisse, Strichstärken sollten sich in Abhängigkeit vom Thema der Karte, vom Zoomlevel, etc. in das einpassen, was schon da ist. OSM ist nunmal keine "Karte", auch wenn das immer mal wieder vereinfachend so gesagt wird. Es sind Daten, und Daten haben kein "Aussehen", eines vorzuschlagen ist m.E. erstmal Zeitverschwendung, solange man sich nicht auf eine bestimmte (aus OSM Daten generierte) Karte bezieht. Wenn man letzteres macht, dann am besten dort wo dieser Stil gepflegt wird, und nicht im tagging-Vorschlag. sicher sind das alles nur Daten, aber ein Taggingvorschlag macht meineserachtens schon Sinn, denn damit trennt man Gedanklich sinnvolle Daten von sinnlosen. Der Vorschlag sollte nicht dazu dienen, ein bestimmtes Icon vorzugeben oder Farben, er dient auch nicht einer bestimmten Karte, sondern bringt für den Beschreibenden die Möglichkeit verstanden zu werden und er kann auch für sich die aus den Daten ein Bild sehen welches ja wieder die Wirklichkeit darstellen soll. Jeder kann ja machen was er will, also auch beliebig Rendering Vorschläge vorbringen, nur zu behaupten, das gehörte zwingend dazu, halte ich wie eingangs bereits festgestellt für Quatsch. sicher sind das alles nur Daten, aber ein Taggingvorschlag macht meineserachtens schon Sinn, denn damit trennt man Gedanklich sinnvolle Daten von sinnlosen. Der Vorschlag sollte nicht dazu dienen, ein bestimmtes Icon vorzugeben oder Farben, er dient auch nicht einer bestimmten Karte, sondern bringt für den Beschreibenden die Möglichkeit verstanden zu werden und er kann auch für sich die aus den Daten ein Bild sehen welches ja wieder die Wirklichkeit darstellen soll. Nur so kann man sehen, wie das "Grün" vom Campingplatz mit dem "Grün" von Wald, Wiese, Fussballplatz, Kinderspielplatz, etc. zusammenspasst. Und was es für einen Unterschied macht, welche Flächen man wie "übereinander" zeichnet oder ausschneidet (Teilmenge, Schnittmenge, Vereinigungsmenge, A ohne B, Differenzmenge). Das hängt alles von den Details bei der Kartenerstellung ab. Selbst wenn man einen bestimmten Stil wie z.B. osm-carto im Auge hat, dann ist das nicht durchgängig gleich, sondern permanent in Änderung begriffen. Natürlich hängt es hinterher von der Kartendarstellung ab, aber das ist ja gerade, der Vorteil. Der Renderer, der in diesem Falle Camping-, Zelt- und Wohnmobilplätze darstellen will, wird die Daten fast vollständig nutzen, der andere braucht eventuell nur den Haupttag und eine spezielle Campingkarte braucht alles und sucht anderswo noch Zusatzdaten. Im Tagging geht es darum, sich zu überlegen was man wie festhalten kann. Im Rendering geht es darum, was von den gemappten Dingen man wie und wann darstellen will (und was nicht). Das sehe ich auch so. Gruß Gisbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mittwoch: Open Mapping Happy Hour at Open Knowledge Festival
Für alle, die diese Woche in Berlin sind! Aus Anlass des Open Knowledge Festivals das diese Woche in Berlin stattfindet, gibt es eine Open Mapping Happy Hour am Mittwoch Abend im Pratergarten, 19 Uhr: http://openmappingberlin.splashthat.com/ Es würde mich freuen den einen oder die andere dort zu treffen! Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] place=municipality für Gemeinden verwenden?
Moin, place=municipality kommt englischen Wiki vor, im deutschen jedoch nicht: http://wiki.openstreetmap.org/wiki/Key:place http://wiki.openstreetmap.org/wiki/DE:Key:place In Deutschland kommt das Tag weniger als 30 Mal vor. Wäre es nicht das treffendere Tag für Gemeinden, die derzeit zumeist mit place=village getaggt werden? place=village scheint mir eher dann zutreffend, wenn es innerhalb eines offiziellen place=suburb weitere baulich geschlossene Ortsteile laut Ortseingangsschildern gibt. Das Problem bei place=municipality für Gemeinden ist aber, dass dann der Gemeindename selbst in der höchsten Zoomstufe auf osm.org nicht mehr gerendert wird, deren Ortsteile (place=suburb) hingegen schon. Wir taggen zwar nicht für den Renderer aber damit wäre die Orientierung in den höheren Zoomstufen komplett weg. Wenn municipality für Gemeinden verwendet werden soll, müssten sie spätestens zusammen mit den suburbs gerendert werden, besser noch früher. Für place=town ist angegeben, dass es für Orte mit mehr als 10.000 Einwohner angemessen sei. Darüber hinaus soll es sich um Städte handeln. Was aber ist mit einer "Gemeinde", die 20.000 Einwohner hat und dort die Großklinik für die umliegenden (auch kreisfreien) "Städte" (und einen Landkreis) angesiedelt ist, die alle kein Krankenhaus aufweisen und die Gemeinde zudem Einkaufszentren und große Gewerbegebiete aufweist? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] post_office im deutschen Wiki
Martin Koppenhoefer wrote: >https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dpost_office Sowohl die englische Wikipedia als auch die Kurzbeschreibung im deutschen OSM Wiki sind sich einig, dass "post-office" ein Ort ist, wo man Briefe !UND! Pakete aufgeben kann, egal von wem es betrieben wird. In aller Regel ist das in Deutschland nur bei der Deutschen Post AG möglich. Wenn es sich aber um eine Stelle handelt, wo man nicht Briefe !UND! Pakete aufgeben kann, wäre das demnach kein "post-office", egal von wem es betrieben wird. Ergo kann eine Stelle der DPAG, die nur Briefe annimmt und/oder Briefmarken verkauft, nicht mehr als post-office bezeichnet werden. Allerdings spricht das deutsche "Gefühl" dagegen. Intuitiv ist es sowohl für Mapper und User eine Filiale der DPAG, egal mit welchem Leistungsumfang. (Inzwischen sind diese aber schon recht divers. Man muss schon genau im Internet recherchieren, was (z.B. Einschreiben) bei der anzusteuernden Filiale möglich ist und was nicht.) Mich würde interessieren, wie ein Italiener ein post-office intuitiv auffasst. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=municipality für Gemeinden verwenden?
Hallo Tirkon, Am 15.07.2014 00:09, schrieb Tirkon: > Moin, > > place=municipality kommt englischen Wiki vor, im deutschen jedoch > nicht: > http://wiki.openstreetmap.org/wiki/Key:place > http://wiki.openstreetmap.org/wiki/DE:Key:place > > In Deutschland kommt das Tag weniger als 30 Mal vor. Wäre es nicht das > treffendere Tag für Gemeinden, die derzeit zumeist mit place=village > getaggt werden? place=village scheint mir eher dann zutreffend, wenn > es innerhalb eines offiziellen place=suburb weitere baulich > geschlossene Ortsteile laut Ortseingangsschildern gibt. > > Das Problem bei place=municipality für Gemeinden ist aber, dass dann > der Gemeindename selbst in der höchsten Zoomstufe auf osm.org nicht > mehr gerendert wird, deren Ortsteile (place=suburb) hingegen schon. Die Ortsteile von place=village sollten nicht mit place=suburb getaggt werden. Es genügt place=neighbourhood. > Wir taggen zwar nicht für den Renderer aber damit wäre die > Orientierung in den höheren Zoomstufen komplett weg. Wenn municipality > für Gemeinden verwendet werden soll, müssten sie spätestens zusammen > mit den suburbs gerendert werden, besser noch früher. place=municipality scheint aus meiner Sicht ein Sammeltag für Orte zu werden, die nicht in place=town oder place=village passt. Ich bin da noch nicht überzeugt von, aber beim rendern sollte place=municipality aus meiner Sicht wie place=town gerendert werden. Bei höheren Zoomstufen sollte es aber eher verschwinden. > Für place=town ist angegeben, dass es für Orte mit mehr als 10.000 > Einwohner angemessen sei. Darüber hinaus soll es sich um Städte > handeln. > Was aber ist mit einer "Gemeinde", die 20.000 Einwohner hat > und dort die Großklinik für die umliegenden (auch kreisfreien) > "Städte" (und einen Landkreis) angesiedelt ist, die alle kein > Krankenhaus aufweisen und die Gemeinde zudem Einkaufszentren und große > Gewerbegebiete aufweist? Dann ist es nach dem bisherigen Schema place=town. Wäre es aus meiner Sicht nach deiner Beschreibung auch noch mit 9000 Einwohnern (einige würden das auch noch doller aufweichen). Die Ortsteile wären nach dem alten Schema dann place=suburb. Aus meiner Sicht ist place=municipality eine Verwaltungseinheit, die mehrere Ortskerne hat und die Verwaltung auf diese aufteilt. Beispiel: https://de.wikipedia.org/wiki/Hiddenhausen#Gemeindegliederung Ich vermute mal, dass place=municipality nun nicht place=town ersetzt, sondern ähnlich wie place=county (Kreis) benutzt wird. Das würde dann auch heißen, dass Ortsteile die sonst als place=suburb getaggt wurden nun wieder als place=town/village/hamlet etc getaggt werden. LG 715371 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=municipality für Gemeinden verwenden?
On Tue, Jul 15, 2014 at 01:52:16AM +0200, 715371 wrote: > Hallo Tirkon, > > Am 15.07.2014 00:09, schrieb Tirkon: > > Moin, > > > > place=municipality kommt englischen Wiki vor, im deutschen jedoch > > nicht: > > http://wiki.openstreetmap.org/wiki/Key:place > > http://wiki.openstreetmap.org/wiki/DE:Key:place > > > > In Deutschland kommt das Tag weniger als 30 Mal vor. Wäre es nicht das > > treffendere Tag für Gemeinden, die derzeit zumeist mit place=village > > getaggt werden? place=village scheint mir eher dann zutreffend, wenn > > es innerhalb eines offiziellen place=suburb weitere baulich > > geschlossene Ortsteile laut Ortseingangsschildern gibt. > > > > Das Problem bei place=municipality für Gemeinden ist aber, dass dann > > der Gemeindename selbst in der höchsten Zoomstufe auf osm.org nicht > > mehr gerendert wird, deren Ortsteile (place=suburb) hingegen schon. > > Die Ortsteile von place=village sollten nicht mit place=suburb getaggt > werden. Es genügt place=neighbourhood. Woran machst du dieses fest? Neighbourhood ist von der bedeutung im Englischen eher deutlich unter suburb angesiedelt, zumindest nach meinem Sprachverständnis. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
