Am 12.09.2011 09:26, schrieb Georg Feddern:
Wären alle dafür notwendigen Flächennutzungen bereits definiert,
eingetragen und auch noch an den passenden Stellen parzelliert, wäre
es möglich, diese Informationen daraus abzuleiten - so existiert aber
in meinen Augen derzeit durchaus ein Bedarf
Am 12.09.2011 13:15, schrieb Martin Koppenhoefer:
-1, ich würde nicht reinschreiben, was _nicht_ erfasst wird, sondern
das, was erfasst wird.
Ja, da bin ich eigentlich bei Dir. Evtl. macht aber eine Definition von
beiden Seiten (was wird eingeschlossen, was wird ausgeschlossen) Sinn,
Am 12.09.2011 13:35, schrieb Martin Koppenhoefer:
Christian, da Du gerne die Wikipedia zitierst hier 2 Links, die Dich
interessieren dürften:
http://de.wikipedia.org/wiki/Stadtviertel
Ein Stadtviertel ist ein überschaubares, häufig nur aus einigen
Straßenzügen bestehendes, soziales Bezugssystem,
Am 12.09.2011 13:24, schrieb Martin Koppenhoefer:
-1, diese schmale Flächenverbrauchsseite in der Wikipedia, ohne
vernünftige Quellenangaben, ist für mich nicht die Bibel.
Da Du Wikipedia's Defintion von Flächenverbrauch nicht traust, schaust
Du vielleicht mal auf die Seite des statistischen
Am 12.09.2011 13:24, schrieb Martin Koppenhoefer:
..Fantasy-Computerspiele..
Das war etwas arg pauschal, sorry. Meistens mag ich es nicht, wenn
meine Argumente mit solchen pauschalen Aussagen weggewischt werden, hier
also nochmal kurz die Beweggründe hinter dieser Aussage:
-
Hi,
Am 11.09.2011 16:11, schrieb Martin Koppenhoefer:
Ist die Folge von was anderem: die Einteilung die wir haben spiegelt
die amerikanische Realität wieder, daher haben wir in Deutschland
Probleme. Wir hätten bei einem deutschen Schema neben industrial was
für Gewerbegebiet erfunden. Könnte
Am 10.09.2011 22:42, schrieb Frederik Ramm:
(*) landuse=* ist _nicht_ an einen admin.-rechtlichen Raum gekoppelt
(reale Flächennutzung ohne Katasterbezug, Flächengrenzen dort, wo der
Mapper den Wechsel der Flächennutzung vermutet/beobachtet)
Was davon ist denn realistisch durch eine Horde von
Am 11.09.2011 02:40, schrieb Frederik Ramm:
Die, die sich fuer mehr interessieren, koennen ja auch mehr mappen.
Sie koennen bloss nicht erwarten, dass, die, die sich nicht dafuer
interessieren, sich an komplizierte Regeln halten.
Ja, aber die, die mehr mappen, können von denen die weniger
Am 11.09.2011 09:13, schrieb Georg Feddern:
Moin,
Christian Müller schrieb:
Auf unser Problem übertragen: Auf dem Land wird es (i.d.R.) wenige
Menschen interessieren, dass es ein Unterschied macht, ob man die
administrative Grenze eines Wohngebietes betrachtet, oder seine
Flächennutzung
Am 11.09.2011 11:31, schrieb Martin Koppenhoefer:
Zum einen hat unser Tagging sehr wenig mit dem deutschen Recht zu tun,
Das trifft insbesondere für border=administrative _nicht_ zu. Das ist
ja das ganze Argument. Wenn admin-rechtliche Gebiete teilweise bis zur
Gemarkungsgrenze in OSM
Am 11.09.2011 12:14, schrieb Martin Koppenhoefer:
Am 10. September 2011 19:57 schrieb Christian Müllercmu...@gmx.de:
Am 10.09.2011 14:46, schrieb Martin Koppenhoefer:
Wieso sollten wir erst alles andere drum rum taggen müssen, nur damit man
dann durch komplexe Operationen auf die Ausdehnung
Hallo Rhinhold,
Am 10.09.2011 12:06, schrieb Rhinhold:
Da die administrativen Grenzen logischerweise nur die Gemarkungsgrenzen darstellen, nicht
aber die Siedlungsschwerpunkte, benötige ich nun noch die Siedlungsflächen (v.a.
residential).
Wie Frederik schon schrieb, dürftest Du dazu in
Hi,
um den /Flächennutzungscharakter eines Wohngebiets (WG)/
---
genauer zu beschreiben, könnte OSM der Tabelle der Nutzungskombinationen
in [1] folgen. Die BauNVO teilt WG nach ihrem Charakter in
- /Baufläche/ ist eine mögliche Interpretation
- /Baugebiet/ ist eine andere
.. natürlich nur in Bezug auf landuses, die baulichen Charakter haben.
Für landuse=farmland müsste man sich sprachlicher Konstruktionen
bedienen, die nicht allg. Sprachgebrauch entstammen (i.e. An_bau_ von
Am 10.09.2011 14:46, schrieb Martin Koppenhoefer:
Selbst wenn da etwas Redundanz da
wäre, dann machte das die Daten stabiler in einem Projekt, wo zig
Tausend Leute unkoordiniert editieren.
So ein Unsinn, dazu gibt es die history und nicht umsonst werden
Changesets erstellt, so dass sich
Am 10.09.2011 14:46, schrieb Martin Koppenhoefer:
Wieso sollten wir erst alles andere drum rum taggen müssen, nur damit
man dann durch komplexe Operationen auf die Ausdehnung der Siedlung
schließen kann?
Du kannst die Siedlungsfläche auch einfach als Relation erfassen, in die
Du alle
Hi,
Am 10.09.2011 15:12, schrieb Frederik Ramm:
Ich stehe place-Polygonen auch kritisch gegenueber. Traditionell ist
place ein Node, und ja, wir haben oft eine Dopplung eines place mit
einer zugehoerigen Admin-Boundary. In manchen Laendern ist es sogar
ueblich, den Place dann in die
Hi,
Am 09.09.2011 07:52, schrieb Georg Feddern:
Aber während Wohngebiete oder Stadtviertel in der Gründungsphase recht
scharf umgrenzte Gebiete sind, verschwimmen die Grenzen im Laufe der
Jahrzehnte und Jahrhunderte allerdings immer mehr, so dass eine
trennscharfe Grenzziehung hier
Am 09.09.2011 13:20, schrieb Martin Koppenhoefer:
Das tut er aber nicht, wenn ich die parallele Diskussion hier
zusammenfassend betrachte. Es bestand Einigkeit darin, dass in einem
Wohngebiet/-siedlung auch andere landuses vorkommen können, daher ist
die Siedlung kein landuse-feature, auch
Am 09.09.2011 16:27, schrieb Martin Koppenhoefer:
Von daher würde man wohl den landuse vom place-polygon abspalten müssen.
Ja, genau so ist das.
Ich schlage vor, die Dopplung der tags im Polygon zu entfernen, da
-1. Ich würde auf keinen Fall den Namen vom place-polygon entfernen,
da das
Hi,
Am 09.09.2011 17:39, schrieb Martin Koppenhoefer:
Auch empfinde ich es als groben Unfug /Siedlungsfläche/ als place=* getaggte
area zu erfassen. I.A. lassen sich für die meisten place=* _nodes_
zugehörige, administrative Grenzen angeben, eine Zuordnung...
das ist auch Dein gutes
Hier noch ein heißer Hinweis, was mit administrativen Grenzen
eingemeindeter Gebiete passiert:
http://de.wikipedia.org/wiki/Gemarkung
Die Gemarkungsgrenze wird dort als nächste Hierachieebene unterhalb der
Gemeindegrenze verkauft. Der Artikel erklärt, dass viele Dörfer als
Gemarkungsgrenze
Hi,
ich denke wir bewegen uns aufeinander zu, obwohl deine Lösungsansätze
umwälzender und unverträglicher mit bisherigem sind, als meine. Ich bin
nicht der Meinung, dass wir das gewonnen Verständnis in der Mailingliste
begraben sollte, denn ein geringeres Maß an Interpretationsfreiheit
Noch eine Anmerkung zu diesem Beispiel
- .. und das dort, wo das tatsächlich der Fall ist, z.B. in kleinen
villages, dieses gemeinsame Polygon ausreicht
- admin_centre des Wohngebietes wäre dann identisch mit
admin_centre des Dorfgebietes
- also, komplett im Überblick
Hi,
in [1] wird z.B. admin_level=10 für 'Stadtteile' und admin_level=11 für
'Stadtviertel' verwendet. Evtl. ließen sich dort level 20, 21, 22, 23
(*gebiet, Flur, Grundstück, Flurstück) einrichten. Ich bin mir
unschlüssig, ob sich die *gebiete, welche durch Gemeinden beplant
werden, sich
Noch ein Nachtrag:
in [1] taucht der Begriff neighbourhood zusammen mit der Übersetzung
'Stadtviertel' auf. place=neighbourhood gehört also bisher (als
admin_centre) zu admin_level=11 einer border=administrative.
Da ein 'Stadtviertel' nicht gleich einem Wohngebiet entspricht (oder?),
bin
Hi,
Am 07.09.2011 02:38, schrieb Martin Koppenhoefer:
hier kann ich nicht mehr folgen. Es ging ja nie um Grundstücksflächen
sondern zum einen darum, welche wo die landuse-Grenzen gezeichnet
werden sollen und zum anderen dann um Wohngebiete.
Insbesondere /Dir/ ging es tatsächlich um
Hi Martin,
Hallo Frederik,
hallo Liste,
die links unten sind in Ordnung, sie helfen, zu verstehen, wie die
Terminologie land use außerhalb von OSM genutzt wird. Bei manchen
Karten ist man sich unsicher, ob die Datenrepräsentation nicht doch
gröber ist und die Straßen einfach nur drüber
Hi,
Original-Nachricht
Datum: Sun, 28 Aug 2011 10:50:24 +0200
Von: Joerg Fischer o...@jfis.de
An: talk-de@openstreetmap.org
Betreff: Re: [Talk-de] wieder mal - Flächen und Wege
Nochmal, es gibt auf jedem Markt den ich kenne nicht nur eine große
asphaltierte und völlig
Original-Nachricht
Datum: Sun, 28 Aug 2011 10:43:34 +0200
Von: Martin Koppenhoefer dieterdre...@gmail.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de] wieder mal - Flächen und Wege
Der key landuse ist in OSM als Gebiet
Hi Martin,
Original-Nachricht
Datum: Sun, 28 Aug 2011 11:11:25 +0200
Von: Martin Koppenhoefer dieterdre...@gmail.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug
zu Straßen,
Hi,
Original-Nachricht
Datum: Sun, 28 Aug 2011 14:26:46 +0200
Von: Wolfgang wolfg...@ivkasogis.de
An: talk-de@openstreetmap.org
Betreff: Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu
=?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal -
Original-Nachricht
Datum: Sun, 28 Aug 2011 14:45:22 +0200
Von: Martin Koppenhoefer dieterdre...@gmail.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug
zu
Original-Nachricht
Datum: Sun, 28 Aug 2011 15:59:06 +0200
Von: Frederik Ramm frede...@remote.org
An: talk-de@openstreetmap.org
Betreff: Re: [Talk-de] Wohngebiete landuse=residential und ihr Bezug zu
=?iso-8859-1?q?Stra=DFen?=, einheitliche Erfassung (war Re: wieder mal -
Original-Nachricht
Datum: Sun, 28 Aug 2011 16:46:42 +0200
Von: Martin Koppenhoefer dieterdre...@gmail.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug
zu
Hi,
Original-Nachricht
Datum: Sun, 28 Aug 2011 17:28:02 +0200
Von: Martin Koppenhoefer dieterdre...@gmail.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug
zu
Original-Nachricht
Datum: Mon, 29 Aug 2011 01:22:44 +0200
Von: Martin Koppenhoefer dieterdre...@gmail.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: [Talk-de] Wohngebiete als Siedlungsteile (place) (war Re:
Wohngebiete landuse=residential
Original-Nachricht
Datum: Mon, 29 Aug 2011 02:15:24 +0200
Von: Martin Koppenhoefer dieterdre...@gmail.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de]Wohngebiete landuse=residential und ihr Bezug
zu Straßen, einheitliche
Hi,
Am 27.08.2011 16:55, schrieb Martin Koppenhoefer:
Am 27. August 2011 14:45 schrieb Wolfgangwolfg...@ivkasogis.de:
Ich habe das Gefühl, dass bei der ganzen Diskussion vergessen wird, dass wir
keine Grundstücke wie beim Kataster erfassen, sondern mit landuse nur Gebiete.
es geht nicht nur
Am 27.08.2011 19:51, schrieb Johannes Huesing:
footways und residentials auf denselben nodes ist natürlich Unsinn.
+1
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Am 23.08.2011 15:11, schrieb Georg Feddern:
Unscharf begrenzte Flächen wie residential, industrial klebe ich
durchaus an die begrenzende Straße.
Andere, eher scharf begrenzte Flächen wie Weide- oder Ackerflächen,
die durch Zaun oder Knick zur Straße begrenzt sind oder neben einem
ländlichen
Hi,
Am 23.08.2011 17:23, schrieb Joerg Fischer:
Ich lege zwischen die beiden Straßen einen highway=service, und zwar
da, wo üblicherweise die Belieferung des Marktes erfolgt.
Wenn es diesen highway gar nicht gibt, erfindest Du deine Realität..
Solche Hilfswege, die real nicht existieren,
Am 26.08.2011 12:41, schrieb Garry:
Ansonsten führt vielfach jede Genauigkeitsverbesserung eines Objekts
zu Lageungenauigkeiten eines anderen Objektes.
man erstmal erfassen muss oder zu ungenau wenn zu wenig Stützpunkte
vorhanden sind.
Versteh ich nicht
Eine Aussage Die Strassebreite ist
Hi,
Am 25.08.2011 15:18, schrieb Martin Koppenhoefer:
Am 24. August 2011 22:34 schrieb Paul Hartmannphaau...@googlemail.com:
On 08/24/2011 09:04 PM, Christian Müller wrote:
Tools Simplify Way ist eine JOSM-core Funktion und benutzt
Douglas-Peucker (genau wie Merkaator). Dieser Algorithmus
Am 24.08.2011 10:28, schrieb Hartmut Holzgraefe:
On 08/23/2011 09:19 PM, Dimitri Junker wrote:
In OSM würde dann die Telefonzelle im Park stehen, eigentlich steht sie
aber auf der Straße.
Nein, denn wenn der Abstand Straßenmittellinie - Telefonzelle kleiner
ist
als die Straßenbreite wird
Am 24.08.2011 16:48, schrieb popp...@hm.edu:
Sehr oft bestehen Gebaeude aus bis zu 60 (!) Punkten, wenn
es 7-8 auch tun wuerden. Da ist jede Rundung und jede Ecke modelliert.
Vereinzelt habe ich das korrigiert, aber die Masse der Faelle erschlaegt
einen. Wie soll man sowas korrigieren ? Von
Hi Jörg,
Am 22.08.2011 20:30, schrieb Joerg Fischer:
Das fiel mir nur auf weil das Routing von openrouteservice
und meinem Garmin merkwürdig und unlogisch war. Da waren dann residentials
und footways übereinander gelegt, Parkpätze und Fußgängerzonen und IIRC
sogar Gebäude, alle fröhlich auf
Am 23.08.2011 02:26, schrieb Martin Koppenhoefer:
Gemeint war:
Flächenausdehnungen bewusst falsch zu zeichnen.
Schon wieder falsch ;-). Wir haben fast keine Möglichkeit, die
Flächenausdehnung korrekt zu erfassen - OSM ist keine Katasterkarte.
Hier ist warum:
1) Oft wissen wir nicht, wem
Am 22.08.2011 07:10, schrieb Joerg Fischer:
Und der Nächste, der einen fehlenden Weg ergänzt, der mit der bereits
vorhandenen, aber fälschlicherweise an die Fläche gepappten Straße
verbunden ist? Der muß entweder ganz genau hingucken (umständlich) das er
den neuen Weg mit der Straße und nicht
Am 22.08.2011 19:35, schrieb M∡rtin Koppenhoefer:
Am 22. August 2011 11:54 schrieb Dimitri Junkero...@dimitri-junker.de:
Aber nenn mir doch mal ein konkretes Bsp wo die getrennten Linien Sinn
machen, also folgende Bedingungen erfüllt sind:
...
Gegenfrage: wieso sollte man es beim Rendern dem
Am 21.08.2011 18:59, schrieb M∡rtin Koppenhoefer:
Am 14. August 2011 16:40 schrieb Christian Müller cmu...@gmx.de:
Am 14.08.2011 15:57, schrieb Bartosz Fabianowski:
Wegesrand an. Ein Aneinanderkleben ist daher IMHO geographisch nicht
korrekt.
Geographisch evtl. nicht, topologisch hingegen
Am 21.08.2011 19:08, schrieb M∡rtin Koppenhoefer:
Am 15. August 2011 02:14 schrieb Christian Müller cmu...@gmx.de:
Um nochmal auf den Zaun zurückzukommen. Einfach gesprochen, wenn der
eine Fläche einsäumt, lassen Mapper m.W. auch keinen Platz zur Fläche -
hier ist das Verkleben ein
Am 21.08.2011 20:06, schrieb Dimitri Junker:
Also meiner Meinung nach gibt es nur 2 Möglichkeiten, entweder wir bleiben
bei 1D-Straßen und nehmen diese auch als Flächenbegrenzung oder wir zeichnen
die Straßenränder und nehmen diese dann als Grenzen. Bei Flüssen benutzen wi
ja beide
Am 14.08.2011 15:57, schrieb Bartosz Fabianowski:
Es gibt hier keinen etablierten Standard. Ich selbst habe lange Zeit
Wege und Landnutzungsflächen aneiandergeklebt bis mir die Probleme zu
denen das führt erklärt wurden und ich aufgehört habe. Das gängige
Argument fürs Aneinanderkleben ist daß
Am 14.08.2011 16:50, schrieb Bartosz Fabianowski:
Absolut unverständlich ist es mir jedoch, wenn Wald und Wiese (ohne Weg
dazwischen) aneinander stoßen und es dennoch keine gemeinsamen Punkte
gibt.
Das stimmt. Da klebe ich auch. Ein Fall den ich öfters diskutiert habe
und immer noch nicht
Am 15.08.2011 00:53, schrieb Garry:
Am 14.08.2011 16:40, schrieb Christian Müller:
Geographisch evtl. nicht, topologisch hingegen schon. Der Wegesrand
beginnt, topologisch gesehen, links und rechts des Weges, welcher in OSM
durch eine Linie repräsentiert wird. Ein Standard ist nicht
Am 13.08.2011 09:49, schrieb Bodo Meissner:
Am 12.08.2011 22:34, schrieb Christian Müller:
Grundsätzlich sollten Löcher in Vielecken (eine innere Linie ist Grenze
eines Lochs im Polygon) andere Tag-Werte haben, als das äußere Vieleck
des Multipolygons - denn nur dann macht es i.d.R. Sinn
Am 12.08.2011 15:23, schrieb Albrecht Will:
Ich vergaß noch zu erwähnen, dass beim Hochladen von natural=tree_row eine
Fehlermeldung kam, die Fläche sein nicht geschlossen. Ich habes trotzdem
erstmal hochgeladen.
IIRC unterstützt JOSM natural=tree_row noch nicht. Ähnliches gilt für
Mapnik -
Möglich, dass die Daten aus dem anderen Ort auch schon unkorrekt sind.
Grundsätzlich sollten Löcher in Vielecken (eine innere Linie ist Grenze
eines Lochs im Polygon) andere Tag-Werte haben, als das äußere Vieleck
des Multipolygons - denn nur dann macht es i.d.R. Sinn, ein Loch zu
erfassen.
Am 11.08.2011 21:13, schrieb Albrecht Will:
Hallo Martin und Tobias,
das ist doch schon was. ABER: Ich denke, die Information ist nicht
ausreichend. Gutes Kartenmaterial macht es vor - Baumreihe links oder rechts
oder beidseitig. So müßte es sein.
Von CAD her gedacht, sind solche
Es gibt
natural=tree_row
welches Du auf ways verwenden kannst. Das ist in der DB zwar häufig
anzutreffen, aber wird von Mapnik oder den Josm-Vorlagen noch nicht
unterstützt. Die Bäume einer so erfassten Baumreihe dann nochmal
einzeln mit nodes auf dem way zu erfassen ist unüblich, aber nicht
Am 08.08.2011 12:50, schrieb Albrecht Will:
Danke Christian,
und zum selben Ort noch eine weitere Frage:
Der tag barrier=gate steht für eine Tor, das der Passant selbst öffnen und
schließen kann. Ich habe einen 2. tag mit acces= no gesetzt, da das Betreten
nur autorisierten Personen erlaubt
disused=yes
*http://wiki.openstreetmap.org/wiki/DE:Key:disused
*evtl. noch
http://wiki.openstreetmap.org/wiki/Key:start_date
und
http://wiki.openstreetmap.org/wiki/Key:end_date
Gruß,
Christian
Am 07.08.2011 14:08, schrieb Albrecht Will:
Hallo in die Runde,
was müßte ich bei einer
Am 01.04.2011 21:05, schrieb Ulf Lamping:
Am 01.04.2011 20:18, schrieb Philip Gillißen:
Am 01.04.2011 20:08, schrieb Gary68:
wie finde ich weitere in deutschland? oder sind das alle???
Ich würde einfach die Liste der Wikipedia nehmen.
Daraus darfst du auch in OSM eintragen, da beide Projekte
Am 20.03.2011 14:35, schrieb Markus:
PS: Vor allem die flächigen Attribute sind m.E. oft ziemlich
willkürlich und ohne konkrete valide Aussage.
Hi Markus,
meist sind sie schon konkrete Luftbild-Schätzungen von Wohngebieten, die
einem Wanderer oder Geocacher sehr genau sagen, wo er mit
Am 10.03.2011 21:16, schrieb o...@tappenbeck.net:
hi !
ich habe zwei kleine Fragen auf die ich bisher keine Antworten im Netz
gefunden habe.
* wie kann man die Karten updaten ?
Ich nehme an, Du willst Dir aktuelle Vektordaten zusammenstellen:
1) hole
Noch ein Gedanke zur Trennung von Verwendbarkeit/Rechtmäßigkeit:
Wenn dürfen und können in den Schlüsseln so strikt unterschieden
würden, wie die Liste das macht, hätten wir schon
access:bicycle=known_values
usability:bicycle=yet_to_be_defined_values or vote counts on usability
oder
Am 02.03.2011 08:23, schrieb Ulf Lamping:
Ich halte es auch nicht für sonderlich intuitiv, für jeden einzelnen
Fahrzeugtyp erraten zu müssen, ob man da langfahren kann / will, wenn
ein anderer eingetragen wurde.
Wenn du jetzt ein bicycle:trek=yes gesetzt hast:
- will ich da auf einer Radtour
Am 02.03.2011 08:39, schrieb Heiko Jacobs:
Am 02.03.2011 03:27, schrieb Ulf Lamping:
[1] Natürlich könnte man eine Art wissenschafliche Untersuchung
starten (Welligkeit,
Löcher, Rillen, ..., jeweils mit Höhe, Abstand, Form, Größe, Tiefe).
Will sich aber wohl keiner antun.
... weil Ergebnis
Hallo Rainer,
Wenn die existierenden Tags (highway, tracktype, bicycle, surface,
smoothness) korrekt und konsequent verwendet werden sind Renn- und
Trekkingfahrer optimal versorgt. Oder anders ausgedrückt: für Renn-
und Trekkingradler kann man eine Klassifizierung, wie Christian sie
Am 02.03.2011 09:28, schrieb Chris66:
Am 02.03.2011 02:13, schrieb Christian Müller:
Hallo,
Alles schön und gut aber wie willst Du garantieren dass die Mapper sich
dran halten wenn sie schon das einfache Schema nicht kapieren und
wild taggen ?
Guter Punkt. Wenn man aber davon ausgeht, dass
Am 02.03.2011 09:32, schrieb Henning Scholland:
Hallo,
du hast sicher recht, dass tracktype und smoothness subjektiv sind.
Allerdings sollte man dabei nicht vergessen, was es bedeuten würde,
dass ganze in objektive Kriterien zu gießen. Kaum einer würde mit
einem Zentimetermaß die tiefe der
Am 02.03.2011 12:45, schrieb M∡rtin Koppenhoefer:
Am 2. März 2011 09:15 schrieb Frederik Rammfrede...@remote.org:
Zugleich ist es aber nicht nach der Art von OSM, irgendwelche
Schwammkategorien zu verwenden. (= also kein smoothness=bad - was fuer
den einen bad, ist fuer den anderen superb)
Am 02.03.2011 16:41, schrieb M∡rtin Koppenhoefer:
Am 2. März 2011 16:29 schrieb Christian Müllercmu...@gmx.de:
1) es geht nicht um 10 tags, sondern um 3
3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt,
würdest Du feststellen, dass durch die Implikationen tatsächlich sehr
Am 02.03.2011 16:43, schrieb M∡rtin Koppenhoefer:
Am 2. März 2011 15:18 schrieb Rainer Klugerklug...@web.de:
Das hatte ich schon befürchtet. Meine positive Meinung zu Tracktype muss ich
wohl revidieren.
Ob ein Weg befestigt ist, also asphaltiert, betonniert oder mit glatten
Betonsteinen
Am 02.03.2011 17:10, schrieb M∡rtin Koppenhoefer:
Am 2. März 2011 17:04 schrieb Christian Müllercmu...@gmx.de:
Nochmal, es geht mir nicht darum, smoothness=* abzuschaffen, oder dessen
Definition in Frage zu stellen. Fakt ist, dass es sich nicht selbst
erklärt, so wie es aber fast jedes
Am 02.03.2011 17:19, schrieb Frederik Ramm:
Hallo,
On 03/02/2011 12:45 PM, M?rtin Koppenhoefer wrote:
bad ist genau definiert. Das bedeutet, dass man stabile Räder
benötigt, und mit Trekking-Rädern und Autos noch den Weg benutzen kann
(robust_wheels) trekking bike, normal cars, Rickshaw and
Am 02.03.2011 17:57, schrieb Frederik Ramm:
Hi,
On 03/02/2011 05:50 PM, Christian Müller wrote:
Der surface=* key z.B. ist in einem wesentlichen Punkt auch überladen:
1) Unterscheidung paved | unpaved (dt. befestigt | unbefestigt)
2) Materialien (manche Programme hinterlegen Listen, um best
Am 02.03.2011 18:11, schrieb Henning Scholland:
Da versteh ich dich nicht so ganz...
paved und unpaved sind allgemeine Werte, die man weiter spezifizieren
kann, in dem man stattdessen das Material explizit erfasst. Hier gibt
es keinen Widerspruch.
Wenn Programme Listen führen, können diese
Am 02.03.2011 18:16, schrieb Simon Poole:
Ein trekking bike ist in etwa so Englisch wie ein handy.
Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone).
Und nochmals: es ist nicht sinnvoll die Eignung für bestimmte
Fahrzeugtypen zu taggen, wenn die Fahrzeugtypen selber nicht
Am 02.03.2011 18:22, schrieb M∡rtin Koppenhoefer:
Am 2. März 2011 18:02 schrieb Christian Müllercmu...@gmx.de:
in demselben etablierten Maße, wie für bestehende
Beförderunsmittel - das ist ja gerade der Vorteil. Die meisten Mapper
müssen nichts hinzulernen, denn sie kennen den Katalog
Am 02.03.2011 19:07, schrieb Andreas Perstinger:
On 2011-03-02 18:46, Christian Müller wrote:
Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt,
dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus
dem Grund, dass der Gesetzgeber nur das Fahrrad kennt
Am 02.03.2011 19:35, schrieb Andreas Perstinger:
On 2011-03-02 18:27, Christian Müller wrote:
Am 02.03.2011 18:16, schrieb Simon Poole:
Ein trekking bike ist in etwa so Englisch wie ein handy.
Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone).
Und nochmals: es ist nicht
Am 02.03.2011 20:55, schrieb Peter Wendorff:
Am 02.03.2011 16:32, schrieb Christian Müller:
Am 02.03.2011 08:39, schrieb Heiko Jacobs:
Am 02.03.2011 03:27, schrieb Ulf Lamping:
[1] Natürlich könnte man eine Art wissenschafliche Untersuchung
starten (Welligkeit,
Löcher, Rillen, ..., jeweils
Am 02.03.2011 21:39, schrieb M∡rtin Koppenhoefer:
Am 2. März 2011 21:26 schrieb Christian Müllercmu...@gmx.de:
Ein Fußgänger wird kaum für einen MTB-Profi Daten erfassen, weil er
_nicht
weiß_ inwiefern die Strecke für MTB geeignet ist. Also gibt es den mtb:
namespace. Warum dort aufhören
Am 02.03.2011 21:39, schrieb M∡rtin Koppenhoefer:
Der mtb-namespace ist klar getrennt vom
rechtlichen Aspekt des Verbots für bestimmte Fahrzeugtypen und lädt
nicht zu Verwechslungen ein.
Vielleicht sollte man generell von bicycle=yes Abstand nehmen, wenn man
bicycle=permitted meint..
Am 02.03.2011 22:15, schrieb Andreas Perstinger:
Gilt das nur für Nachtfahrten, oder müssen in D Rennräder auch am Tag
ein Licht mitführen?
In AT braucht man das eben nicht AFAIK (ich bin zumindest noch nie
deswegen angehalten worden).
Laut
Am 02.03.2011 22:31, schrieb Simon Poole:
Am 02.03.2011 18:27, schrieb Christian Müller:
Weiterhin musst Du wohl feststellen, auch wenn Du dich gerade an
trekking aufhängst, dass das keine Fahrradmarke, sondern -klasse
ist. Und ein Engländer kennt doch sehr wohl auch den Unterschied
Moin,
Am 02.03.2011 23:35, schrieb Simon Poole:
Ich wollte ja eigentlich noch was dazu schreiben, hab es aber dann
sein gelassen, jetzt aber trotzdem noch:
Eins der Probleme an deinem Vorschlag ist das du die Art des
Fahrradfahrens krampfhaft versuchst am Fahrzeugtyp festzumachen (was
bei
Am 02.03.2011 23:55, schrieb Ulf Lamping:
Am 02.03.2011 17:37, schrieb Christian Müller:
Am 02.03.2011 16:41, schrieb M∡rtin Koppenhoefer:
Am 2. März 2011 16:29 schrieb Christian Müllercmu...@gmx.de:
1) es geht nicht um 10 tags, sondern um 3
3) hättest Du dich vernünftig mit meinem Vorschlag
Am 03.03.2011 00:31, schrieb Heiko Jacobs:
Am 02.03.2011 18:13, schrieb Christian Müller:
Und was macht man z.B. mit Holz? Ich würde schon sagen, dass manche
hölzerne Wege
als befestigt gelten können (Hausbrücken z.B.), andere, wo nur ein
paar logs verstreut im Sumpf
liegen, eher nicht
Hallo,
kurz zu mir selbst. Ich lese ab und an die Diskussionen auf dieser
Liste mit und versuche gute Vorschläge bei meiner Arbeit an OSM
umzusetzen. Ich tagge seit 2008 im Südraum Leipzig und lege mehr Wert
auf Qualität (so wie die Masse, schätze ich), als schnell die DB zu
stopfen. Über das
Am 02.03.2011 03:27, schrieb Ulf Lamping:
Am 02.03.2011 02:13, schrieb Christian Müller:
smoothness=*
) hilft mir nicht zu entscheiden, ob ich z.B. mit trekking bike dort
fahren kann, weil
a) die subjektive Ansicht des Taggenden im Wert steckt und
b) ich die Entscheidungsbasis
Am 26.12.2010 13:56, schrieb Heiko Jacobs:
Am 23.12.2010 22:38, schrieb Michael Kugelmann:
Am 23.12.2010 21:29, schrieb Norbert Kück:
im Open Data Blog von Zeit-Online gibts einen Beitrag über die
Nutzung von OSM für die Amsterdamer Feuerwehr:
Am 14.12.2010 13:00, schrieb talk-de-requ...@openstreetmap.org:
Message: 1
Date: Tue, 14 Dec 2010 12:10:39 +0100
From: Wolfgang wolfg...@ivkasogis.de
To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Subject: Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Am 14.12.2010 21:24, schrieb talk-de-requ...@openstreetmap.org:
Message: 1
Date: Tue, 14 Dec 2010 18:04:08 +0100
From: Bernd Wurst be...@bwurst.org
To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Subject: Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Kleiner Typo
es ist tatsächlich flood_prone=yes
_nicht_ flood_prones=yes
.. ist aber auch durch den Wiki-Link der gleichen mail ersichtlich.
Gruß,
cmuelle8
Am 09.12.2010 11:08, schrieb talk-de-requ...@openstreetmap.org:
und Eisenbahnunterfuehrungen, die gerne mal unter Wasser stehen, mit
201 - 297 of 297 matches
Mail list logo
