Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed

[Garry]

Am 27.03.19 um 00:08 schrieb Bernhard Weiskopf:

Wenn ein Schild "7" steht, tagge ich "7".
Wenn ein Schild steht, das "Schrittgeschwindigkeit" impliziert, tagge ich 
"walk".

Ich maße mir nicht an zu entscheiden, ob "walk" nun 5 km/h, 6 km/h, 7 km/h, ... 
bedeutet. Das hat weder der Gesetzgeber festgelegt, noch haben das Gerichte einheitlich 
entschieden.


Mal so ausgedrückt:

Was unter 7km/h liegt ist kein Fahren mehr, das ist Rangieren. Viele KFZ
müssen dann schon unterhalb "Leerlauf 1. Gang" betrieben werden und
Zweiradfahrer mit dem Gleichgewicht halten kämpfen - das ist kein
sicheres Fahren mehr.

Das Augenmerk liegt dann nicht mehr bei der Tachonadel sondern darauf
nicht mit der Umgebung zu kollidieren.

Mit diesem Hintergrund gibt es da auch keine Rechtssicherheit mehr durch
Gesetzgeber und Richter in Form eindeutiger Vorschriften und Urteile.
Gewünscht ist die langsamste mögliche Geschwindigkeit die sicher zu
fahren ist. Die ist technisch je nach Fahrzeug und Fahrer individuell
und somit nicht rechtssicher in Form von Messgrößen allgemein
(Fahrzeugtyp unabhängig) zu beschreiben.

7km/h ist daher ein sinnvoller Wert um dieser Thematik gerecht zu
werden. Wenn die Anwendungen dann noch eine Toleranz von 2-3 km/h
erlauben sollte man auf der sicheren Seite sein nicht wegen reiner
Geschwindigkeitsüberschreitung belangt zu werden. Das entbindet nicht
davon jederzeit bremsbereit sein zu müssen und derart vorausschauend zu
fahren dass ein Unfallrisiko minimiert wird. Das Betriebsrisiko bleibt
immer und man wird bei einem Unfall auch bei 1km/h kaum schuldfrei aus
der Sache herauskommen. Wenn man aber seine Konzentration darauf setzt
das Fahrzeug unterhalb der "passiven Mindestgeschwindigkeit" (ohne
schleifende Kupplung, "Zweiradakrobatik",.. ) zu betreiben steigt das
Risiko eines Unfalles wieder an was kaum im Sinne des Gesetzgebers sein
kann.

Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Korrektes Tagging eines Feriengebiets

[Garry]

Am 25.03.19 um 09:23 schrieb Martin Koppenhoefer:


sent from a phone


Am 25.03.2019 um 08:28 schrieb Georg Feddern :

Also "commercial_residential"? ;-)


m.E. überhaupt kein “residential“, weil dort niemand residiert (=seinen 
Wohnsitz hat). „commercial“ passt von den derzeit definierten landuse am besten.


Schwerpunktmässig geht man dort hin um dort zu wohnen, wenn auch nur für
kurze Zeit und nicht um Handel zu betreiben. Das Handeln hat man in der
Regel zuvor erledigt. Andernfalls müsste man auch Mietwohnungsbauten
unter "commercial" einordnen.


Garry



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Korrektes Tagging eines Feriengebiets

[Garry]

Am 24.03.19 um 17:20 schrieb da370...@gmail.com:

Das Gebiet ist aktuell mit landuse=residential getaggt. Ich halte das
für falsch, da es keine Häuser zur dauerhaften Miete sondern eben nur
Ferienhäuser für Kurzaufenthalte sind. Dort "wohnt" daher niemand fest.


Worin siehst Du das Problem?

Es sind ja eigentlich alle Eigenschaften da die ein Wohngebiet machen -
die Bewohner wechseln zwar etwas öfter und die Leerstände sind etwas
häufiger und synchronisierter, aber muss man das unbedingt durch einen
eigenen landuse ausdrücken?

Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM auf Arte X:enius

[Garry]

Am 17.09.2018 um 23:06 schrieb Frederik Ramm:

Hi,

On 04/25/2018 11:19 AM, Frederik Ramm wrote:

Ein Sendetermin ist noch nicht bekannt, aber ich sage bescheid, sobald
ich was erfahre.

https://www.arte.tv/de/videos/078162-009-A/xenius/ ab Minute 17 - ich
schau es mir jetzt gleich selber an und hoffe, dass es nicht zu peinlich
wird ;)

Bye
Frederik

Da schließt sich der Kreis wieder... Ersterfassung der Straßen per 
Luftbild-Unterstützung am Rastatter Flugtag 2017 - Joachim erinnert sich 
vielleicht :-)
Viel getan hat sich seither in OSM dort nichts -da sollte man dort mal 
wieder etwas tun an dem Fernseh-Vorzeigeobjekt...


Garry



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM mit Google-Lizenz? - Direktvermarkter

[Garry]

Am 23.05.2018 um 18:56 schrieb Manuel Reimer:

On 05/19/2018 03:05 PM, Harald Hartmann wrote:

Hmm, also wenn ich in der Karte von den Google Kacheln weiter reinzoome
bis die OSM Kacheln kommen (Maßstab 1km), kommt unten rechts auch der
Hinweis "Karte @ OpenStreetMap contributors, CC BY SA 4.0" ... kann man
so machen. Ich sehe da jetzt keinen "groben" Verstoß.


Ich frage mich eher warum man sich diese Mühe überhaupt gemacht hat.

Anscheinend erhofft man sich irgendeinen Vorteil davon beim weiteren 
Rauszoomen Google-Kacheln zu haben. Dieser Vorteil erschließt sich mir 
nur nicht... 
Man kombiniert die "besseren"(?)/ gewohnten Router-Eigenschaften (für 
Google-Nutzer) mit der höheren Detailschärfe von OSM?


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nutzung des "lit"-Tags in Deutschland

[Garry]

Am 21.04.2018 um 10:33 schrieb Harald Hartmann:

Berücksichtigt ihr (oder findet ihr, dass man das tun sollte) bei der
Vergabe von lit=* den "Laternenring"
(https://de.wikipedia.org/wiki/Laternenring), der angibt, dass die
Laterne nicht die ganze Nacht leuchtet?

Von diesem Laternenring habe ich übrigens auch erst etwas über die
Recherche bei lit gelesen, war mir vorher nicht bekannt, dass es sogar
ein StVO Zeichen ist.

Also bei mir in der Gegend scheinen die Gemeinden wohl nicht sparen zu
wollen, da die Laternen mit diesem Ring (und auch nicht nur jede Zweite)
durchaus die ganze Nacht durchbrennen (egal ob 23 Uhr, 1 Uhr oder 3
Uhr). Wäre vielleicht mal eine Gelegenheit direkt bei der Gemeinde
nachzufragen, was die dazu sagen...

Wurden die vielleicht auf LED-Technik umgestellt?
Achte mal darauf ob sie in der Nacht irgendwann heruntergedimmt werden.
Bei mir im Ort werden sie um Mitternacht schlagartig dunkler (unabhängig 
von Ringen die noch aus der

Zeit vor der LED-Umstellung stammen).

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nutzung des "lit"-Tags in Deutschland

[Garry]

Am 21.04.2018 um 10:02 schrieb Frederik Ramm:

Das Wiki empfiehlt, "lit=yes" auch bei unbekannter Leuchtdauer zu
verwenden, schreibt zugleich (was eigentlich dazu ein Widerspruch ist),
dass man lit=limited verwenden könne, wenn ein Laternenring dran ist.

Ich habe mal gelesen, dass Gemeinden zum Stromsparen nur jede zweite
Laterne die ganze Nacht brennen lassen. Aber ich kann doch in so einem
Fall die Straße nicht in lauter 50m lange Stücke unterteilen, die Hälte
mit lit=yes und die andre Hälfte mit "lit=". In gewisser Weise
ist ja schon die ganze Straße beleuchtet, auch wenn nur die Hälfte der
Lampen an ist. Bloß halt nich so gut...
Mit der Umstellung auf LED-Technik verzichtet man zumindest teilweise 
wieder auf die Nachtabschaltung und nutzt dafür die Möglichkeit die LEDs 
herunter dimmen zu können.

Also am besten den Helligkeitsverlauf aufnehmen und angeben :-)




Mich wundert, dass lit=no so oft explizit an Autobahnen getaggt wird,
obwohl es ja der Default zu sein scheint

In Belgien hat man gerne die Autobahn beleuchtet:
https://www.hna.de/welt/belgien-beleuchtet-autobahnen-kuenftig-auch-tagsueber-zr-8744765.html

Garry



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Diskussion: Import von Autobahn-Kilometern

[Garry]

Am 21.04.2018 um 10:19 schrieb dktue:

Hallo,

vor einiger Zeit hat mich Stefan Keller [1] auf eine große Sammlung an 
Autobahnkilometern Aufmerksam gemacht [2,3,4,5].


Ich möchte gerne hier zunächst über die Datenqualität diskutieren und 
ob diese einen Import erlauben würden. Unabhängig davon würde ich den 
Autor fragen wie er die Daten erhoben hat und ob er damit 
einverstanden wäre. 
Unabhängig von der Datenquelle: Wie fixiert man einen Autobahnkilometer 
um sicherzustellen, dass er nicht verschoben wird?
Wie wird er plaziert? zwischen die beiden Ways, auf den Way doppelt in 
beide Richtungen (Größere Gefahr dass er verschoben wird)?


Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] natural in natural / natural in landuse / multipolygon?

[Garry]

Am 13.04.2018 um 23:02 schrieb Florian Lohoff:

Hi,

On Fri, Apr 13, 2018 at 09:43:16PM +0200, Martin Koppenhoefer wrote:

Was ist mit natural=water in einem natural=wood?

das wiederum würde ich rausnehmen

Hartmut hatte eben auf osm-owl noch dieses Beispiel:

https://www.openstreetmap.org/#map=19/52.11159/8.51357=N

Da sieht man das Carto/Mapnik die Bäume halt auch in den See zeichnet
wenn man das nicht ausnimmt.

Das problem ist glaube ich das künstliche
Wasserflächen/Teiche/Wasserspiele mit natural=water getagged werden.

Im Stadtpark gehört der See ja auch dazu - Im Wald gehört der
See aber nicht zum Wald.

Ich habe so ein paar Seen aus dem umgebenden Wald/Wiese ausgeklammert
und dann hatte ich den Teich/Wasserfläche vor der Bertelsmann
Hauptverwaltung und DAS gehört ja schon zum landuse=commercial.

Leider ist das aktuell auch ein natural=water - Was in Anbetracht
des ganzen Betons eher so quatsch ist.

Gibts da was besseres als natural=water?

Geht landcover=water? man_made=water?
Vielleicht wäre liquid = water besser gewesen (als Unterscheidung von 
z.B. Jauchegruben)...
So sehe ich natural=water als Oberbegriff für Wasserflächen die näher 
bestimmt werden können.
Auf Luftbilder lassen sich Wasserflächen meist gut erkennen - diese aber 
eindeutig zu kategorisieren ist dann aber schon schwieriger.
Das ist das was meiner Meinung nach bei OSM von Anfang an etwas schief 
gelaufen ist:
Man hat häufig gleich zu spezielle Tags eingeführt anstatt den 
Oberbegriff zu wählen um den dann genauer zu spezifizieren.



Garry



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Garry]

Am 08.04.2018 um 23:43 schrieb "Christian Müller":

Gesendet: Sonntag, 08. April 2018 um 22:21 Uhr
Von: "Martin Koppenhoefer" 
An: "Openstreetmap allgemeines in Deutsch" 
Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets

im Prinzip unterschreibe ich das, nur dass ich die Befürchtung von Florian 
teile, dass es im realen OSM-Alltag leicht in der Folge zu Topologiefehlern 
kommt, weil viele Mapper die Struktur der Daten nicht richtig bzw. vollständig 
erkennen.

Auch wenn man sowas z.B. mit JOSM extrem schnell zeichnen kann (einfach schnell 
f drücken), ist das Resultat eigentlich nicht so einfach, obwohl es aufgeräumt 
aussieht, und das wegen der mehrfachen überlappenden Linien.

Die Frage die sich stellt ist doch, ob das mehr an Linien dazu führt, dass 
Mapper dann die Struktur der Daten eher/öfter richtig erfassen?
Es bietet sich die Möglichkeit z.b. landuse und highway gegenseitig 
auszublenden. Wenn ich hochgenaue Daten nur des einen Typs habe kann ich 
diese Daten einpflegen ohne den anderen Typ, über den ich keine 
Informationen habe zu beeinflußen.


Beispiel:
Markante Form einer Ackergrenze entlang eines Straßen- oder Bahndammes 
in unebenem Gelände. Der Verkehrsweg hat in der Regel einen "stetigen" 
Verlauf während die Ackergrenze "Sprungstellen"/wechselnde Abstände zum 
Verkehrsweg hat. Da stecken dann Informationen drin, die zur 
Wiedererkennung aus der Luftbildperspektive hilfreich sind.


Gerald

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Massenedit bei living_street

[Garry]

Am 26.05.2017 um 15:03 schrieb Martin Koppenhoefer:


Am 26. Mai 2017 um 10:54 schrieb Florian Lohoff <f...@zz.de 
<mailto:f...@zz.de>>:


Also meine Meinung und wie ich seit 10 Jahre Mappe und wie wir uns in
Ostwestfalen-Lippe auch geeinigt haben - living_street bekommt kein
maxspeed. Wenn da ein maxspeed drauf ist ist das ein Fehler.



naja, jetzt übertreibst Du ein bisschen finde ich. Es gibt dort 
definitiv eine Geschwindigkeitsbegrenzung, von daher ist es sicher 
kein Fehler, eine zu mappen. Nur weil man sich seit Jahren nicht 
einigen kann, ob man einen niedrigen Zahlenwert oder ein Schlüsselwort 
verwenden soll, heisst das nicht, dass es ein "Fehler" ist wenn jemand 
da was mappt.


"lustige quasi offensichtliche Fehler" gibt es z.T. übrigens auch bei 
der Beschilderung, z.B. maxspeed 30 aber 40 wenn nass ;-)
Ist auf manchen Straßen sicher plausibel wenn man mit 30 stecken bleiben 
würde, mit 40 aber durchkommt ;-)


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Massenedit bei living_street

[Garry]

Am 23.05.2017 um 16:28 schrieb Frederik Ramm:


falsche Änderungen eingeführt, nämlich an Orten, wo explizit sogar das
Vorhandensein eines abweichenden Tempolimits gemappt war!


Wie ist den die (Verkehrs-)Rechtslage dazu?

Ist es überhaupt zulässig, in einer verkehrsberuhigten Zone ein 
abweichendes Tempolimit auszuweisen?


Oder wäre hier livingstreet nicht der falsche Wert?

Unter was fallen in OSM "Wohnwege" die über eine Bordsteinkante führen 
um zum Be- und entladen direkt vor die Haustür fahren zu können, aber 
nicht explizit


durch Beschilderung abgegrenzt sind?


Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Massenedit bei living_street

[Garry]

Am 23.05.2017 um 11:22 schrieb Stephan Martens:

Hier z.B.: wurde eine Tempo-30 Zone bei der sogar die Schilderart DE:274.1 
(Tempo-30-Zone) katrografiert wurde zu maxspeed:walk
https://www.openstreetmap.org/way/305956789/history

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street

livingstreet ist auch etwas schwammig (geworden?)...

Wenn man es gleichsetzt mit verkehrsberuhigter Zone darf es dort nach 
meinem Kenntnisstand in Deutschland keine Tempo30-Beschilderung geben -

oder sehe ich das falsch?
Für Schrittgeschwindigkeit werden regelmäßig 7km/h genannt. Aus 
Fußgängersicht ein zu hoher Wert der gehend kaum zu erreichen ist - aus 
KFZ-Sicht
der kleinste praktikable Wert der für alle Fahrzeuge einhaltbar sein 
sollte da weder ein strauchelndes Motorrad noch ein Auto das mit 
schleifender
Kupplung und starren Blick auf die Tachonadel einen Sicherheitsgewinn 
für die zu schützenden Fußgänger bewirken.
Nach oben hin gibt es Weisungen, dass bis 10km/h nicht beanstandet wird 
und bis 15km/h nicht geahndet werden müssen. Toleranzen sind dabei noch 
nicht berücksichtigt so dass auf die Tachonadel bezogen alles unter 
20km/h in der Regel folgenlos bei Geschwindigkeitskontrollen bleiben dürfte.



Jetzt wird livingstreet aber wohl auch für andere Straßen verwendet, die 
baulich bedingt für nicht unmittelbare Anlieger als Verkehrsweg 
unattraktiv sind.
Das birgt dann natürlich Konfliktpotential. Da sollte man sich mal einig 
werden ob livingstreet nur für verkehrsberuhigten Bereich mit Zeichen 
*325.1* verwendet wird oder ob man dafür einen separaten Tag schafft, 
was international gesehen sinnvoller sein könnte.




Garry
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Geschwindigkeitsbegrenzungen protokollieren

[Garry]

Am 22.05.2017 um 18:00 schrieb Florian Lohoff:

On Sun, May 21, 2017 at 11:07:02AM +0200, Martin Koppenhoefer wrote:

stimmt zwar, die Schilder zu mappen ist meiner Erfahrung nach aber die
beste Methode, einigermaßen korrekte maxspeeds zu erfassen und auch
über die Zeit zu erhalten (weil sie anderen Mappern die eigenen
Beobachtungen so kommunizieren, dass sie einfach zu sehen sind).

Das ist ein wichtiger Punkt. Ich will ja Fakten bzw Beobachtungen
Dokumentieren und für andere verständlich und bearbeitbar hinterlassen.

Aus der Sichtweise, ja.
Anwendungstechnisch halte ich es für pragmatischer den highway
mit vielleicht noch nicht ganz so präzisen Geschwindigkeitsabschnitten 
zu taggen und

anschließend mit den Schildern zu verfeinern.
Einen um 20m,30m oder gar 50m verrutschter Geschwindigkeits-Abschnitt 
sich als unkritischen,
leicht korrigierbaren Fehler an. Ein um 50m verrutschtes Schild kann 
aber leicht dazu führen
das anschließend jemand die korrekte Schildpostion taggt, die falsche 
aber nicht rausnimmt
weil nicht mehr nachvollziehbar ist ob das falsch positionierte Schild 
nicht ein zusätzliches Schild ist

das nur übersehen wurde.


Und da ist einzelne Schilder mappen das einfachste. Das versteht jeder
und kann die informationen auf dem highway nachvollziehen.

Deshalb würde ich gerne alles an Schildern erfassen und wenn die noch so
blöde sind.
Spricht ja nichts dagegen, nur ist das im vorbeifahren mit üblicher 
KFZ-Geschwindigkeit schwierig


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Geschwindigkeitsbegrenzungen protokollieren

[Garry]

Am 19.05.2017 um 08:56 schrieb Martin Trautmann:

Hallo,

wie schafft ihr es, die exakte Position von 
Geschwindigkeitsbegrenzungen aufzuzeichnen und Änderungen einzupflegen?
Idealerweise mit einem Tracker der Merker setzen kann per 
Lenkradfernbedienung.


Ich muss gestehen, wenn ich selbst unterwegs bin, dann kann ich auf 
der Autobahn nicht auch noch ein Gerät bedienen, um zu sagen: ab hier 
Geschwindigkeitsbegrenzung von 80 km/h.
Kann man im GPS-log auch mit deutlichen Geschwindigkeitsänderungen 
sichtbar machen, insbesondere wenn man mit Tempomat fährt. Auf Anhieb 
fremde Strecken (die man erstmalig befährt) korrekt zu taggen wird man 
kaum schaffen, zu schnell übersieht man ein Schild bzw. bekommt es nicht 
erfasst wenn z.B. Nacht- und Tageslimits zusammenfallen (z.B. 6-20Uhr 
120km/h, 22-6Uhr 100km/h)


Smartphone-Aufnahme mit GPS-Funktion klappt vermutlich nur, wenn ihr 
wisst, dass gleich das Schild kommt und der Beifahrer aufnahmebereit 
dasitzt.


Und selbst bei Geschwindigkeiten unter 80 km/h komme ich mit einer 
Aufzeichnung nicht mit - das klappt vermutlich nur mit ständig 
mitlaufender Kamera vorne, die auch noch GPS mit aufzeichnen müsste? 
Die Kamera hilft halbwegs exakte Positionen der Verkehrsschilder zu 
finden. Die sehe ich aber ehr als Nebensache. Gedanklich ist die 
Geschwindigkeitsbeschränkung eine Eigenschaft der Strecke und die 
Schilder ein Hilfsmittel diese dem Fahrer zu vermitteln.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging

[Garry]

Am 06.04.2017 um 17:41 schrieb Butrus Damaskus:



jein, es geht dabei auch um den hypothetischen Fall, dass ein Default-limit
geändert wird, z.B. innerorts nur noch 40 oder ausserorts nur noch 90. Wenn
man anhand der Daten genau sagen kann, wo das limit herkommt, dann kann man
in so einem Fall mit einem Schlag alles umtaggen.

Gruß,
Martin


Das wird a) sowieso nie passieren, b) selbst dann muss man die Database
manuell kontrollieren und alle anders getaggte Stellen per Hand korrigieren.
Den Fall gab es schon (wenn auch vor OSM-Zeiten, ca. 1980) als in 
Frankreich die Innerorts-Geschwindigkeit von 60km/h auf 50km/h gesenkt 
wurde.
In der Schweiz wurde erst in den den letzten paar Jahren eine 
innerörtliche Beschränkung (ortssschildbezogen) eingeführt, vorher mußte 
das immer separat ausgeschildert sein.
Eine Absenkung der Default-Geschwindigkeit innerorts in DE auf 30km/h in 
den nächsten 10Jahren halte ich auch nicht für völlig ausgeschlossen.


Garry



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging

[Garry]

Am 02.04.2017 um 10:48 schrieb Martin Koppenhoefer:


sent from a phone


On 2 Apr 2017, at 10:00, Norbert <norbert.brunkha...@online.de> wrote:

maxspeed=30  --> Höchstgeschwindigkeit
zone:maxspeed=DE:30--> Es handelt sich um eine 30 Zone
source:maxspeed=DE:zone  -- Die Quelle für maxspeed


klar ist die Wiederholung der 30 redundant, wenn das aber die meisten Leute 
taggen, schaden tut es nicht.

sowohl zone:maxspeed als auch source: maxspeed zu taggen ist auch redundant, 
ich würde eins davon weglassen, aber mir ist es im Prinzip egal weil es hier 
sowieso keine 30er Zonen gibt
Für "Innerorts" gibt es ja z.B. den Fall, dass 
Geschwindigkeitsbegrenzungen angehoben werden können (über die 50km/h 
hinaus).
Da der Trend zu nächtlichen "30er Zonen" geht sollte man hier flexibel 
bleiben.


Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tagging Zuführung zur Autobahn

[Garry]

Am 11.12.2016 um 12:24 schrieb Robert:

Hallo zusammen!

Ich habe eine kurze Frage. Wie würdet ihr eine Straße (800 m lang,
eine Spur je Richtung, keine bauliche Fahrbahntrennung) taggen, welche
zur Autobahn zuführt? Zu Beginn der Straße, also an der letzten
Kreuzung, steht das Zeichen 330.1 (Autobahn), im Gegenverkehr wird
erst dort per 330.2 die Autobahn beendet. Die Straße selbst ist eine
Landesstraße.

Aktuell ist sie als trunk+motorroad=yes getaggt, wobei motorroad=yes
dann bei Navis die Ansage "fahren Sie auf die Kraftfahrstraße"
auslösen könnte, was vor Ort mangels Zeichen 331 so ja nicht
vorgefunden werden kann.

Danke für Eure Meinungen!

Hat die Straße noch eine andere Funktion außer "Autobahnauffahrt"?
D.h. dient sie auch als Zufahrt zu Forstwegen, Autobahnmeisterei o.ä.?
Wenn ausschließlich Autobahnzufahrt würde ich sie auf jeden Fall als 
motorway-link taggen um ganz klar darzustellen:
Hier geht es ausschließlich auf die Autobahn und Du hast hier nichts 
verloren wenn Dein Fahrzeug nicht für die Autobahn erlaubt ist.
Es geht ja vorrangig um die verkehrliche Bedeutung/Widmung und nicht 
darum, wer für den
Unterhalt zuständig ist. Und das wird ja in Deinem Fall eindeutig mit 
dem Zeichen 330.1 angezeigt.


Gerald


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Umstellung higway=proposed auf name space "proposed:highway=" für Straßen?

[Garry]

In letzter Zeit wird gelegentlich für geplante Straßen statt proposed = 
highway die namespace-variante proposed:highway angewendet.


Ist das so gewünscht - mit dem Ziel alles so umzustellen (was dann 
erstmal in den Kartendarstellung nicht so erscheint die auf 
proposed=highway ausgelegt sind)?


Garry



**


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Neue Farben im osm.org Kartenstil?

[Garry]

Am 01.11.2015 um 13:27 schrieb Christoph Hormann:

On Sunday 01 November 2015, Manuel Reimer wrote:

ich hatte ja erste Bedenken ich habe beim Eintragen einen Fehler
gemacht, aber das scheint sich wohl über die ganze Karte
durchzuziehen.

Aktuell werden die Straßen etwas "farbloser". Zumindest in meiner
Region gibt es so Langsam nurnoch weiße Straßen und die farbige
Unterscheidung geht verloren.

Der 'farblosere' Gesamteindruck kommt vor allem, weil highway=tertiary
jetzt weiß ist und sich nur noch in der Linienbreite von
unclassified/residential unterscheidet.  Das ist im Vorfeld kontrovers
diskutiert worden:

https://github.com/gravitystorm/openstreetmap-carto/pull/1736

und wird sicher umstritten bleiben.  Insgesamt ist es aber denke ich
klar ein enormer Gewinn für das Gesamtbild, dass grün und blau aus der
Farbpalette für die Straßen rausfallen.

Was das grün an geht, ja.
Ansonsten ist das aber eine deutliche Verwässerung des Wegenetzes, die
Strukturen zwischen "hier fahren eigentlich nur Gebiets-Anlieger" und 
"hier gehts weiter zum nächsten Ort wenn Du kein Gebiets-Anlieger bist"

saufen ab.

Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ÖPNV-Karte / Darstellung historischer Bahnstrecke

[Garry]

Am 17.10.2015 um 14:24 schrieb Michael Reichert:

Hallo Volker,

Am 2015-10-17 um 13:47 schrieb Volker Schmidt:

Ein wichtiger Unterschied zwischen railway=abandoned und railway=razed ist
ob noch Schienen vorhanden sind (abandoned) oder nicht (razed).

Das stimmt so nicht.

disused: Schienen noch vorhanden
abandoned: Schienen nicht mehr vorhanen, Schwellen vielleicht noch
vorhanden, Schotter auf jeden Fall vorhanden
razed usw.: wenn noch mehr fehlt/nicht mehr sichtbar ist

Zumindest für Deutschland bildet OSM damit leider nur ungenügend die 
Fakten bezüglich physikalischen, rechtlichen und wirtschaftlichen 
Zustand ab.
Rechtlich gibt es hierzu im wesentlichen neben dem Betriebszustand die 
Zustände "stillgelegt" (entsprechend "disused") und "entwidmet" 
("abandoned") .
Physikalisch (also bei OSM "in der Realität") ist das kaum 
unterscheidbar. "Nur" stillgelegte Strecken können bürokratisch einfach 
wieder aufgebaut werden,
die Trasse muss dafür freigehalten werden, auch wenn sie in der Praxis 
gelegentlich verbaut wird.
Eine entwidmete Trasse wird bei einer Wiederinbetriebnahme dagegen so 
behandelt, als hätte es sie nie gegeben und darf beliebig verbaut sein.
Ob Schotter, Gleise, Bauwerke noch vorhanden/verwendbar sind ist dabei 
in beiden Fällen unerheblich, eine reine Kostenfrage ob gegebenenfalls 
ob eine Wiederinbetriebnahme wirtschaftlich ist.



Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Merkmal für Unterscheidung motorway / motorway_link? (Dreieck Karlsruhe)

[Garry]

Was ist den das Unterscheidungsmerkmal zwischen motorway und motorway_link?

Konkretes Beispiel wären die Überleitungen A5/A8 Autobahndreieck Karlsruhe.
motorway_link finde ich da schon fast unterdimensioniert und sollte 
"stärker" darstellbar sein als normale Autobahnabfahrten oder die 
engeren Kleeblattverbindungen

in einem Autobahnkreuz wie z.b. A5/A6 (Walldorfer Kreuz).



Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM routet nicht über neue A71

[Garry]

Am 05.09.2015 um 20:07 schrieb Rolf Eike Beer:

Am Samstag, 5. September 2015, 20:00:32 schrieb Garry:

OSM routet nicht über die neue A71 die dieses Woche freigegeben wurde.
Sehe ich das richtig, dass die Daten fürs Routing noch nicht übernommen
wurden (kann man das anstoßen?) oder ist da am Tagging noch ein Fehler?

"OSM" routet gar nicht. Du meinst vermutlich irgendeinen (welchen?) der auf
OSM-Daten basierenden Router. Und bei denen sind die Datenbestände teilweise
Monate alt, also: höchstwahrscheinlich ist in den Daten alles in Ordnung.


Sorry, ja, OSRM auf der Openstreetmap.org - Seite...

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] OSM routet nicht über neue A71

[Garry]

OSM routet nicht über die neue A71 die dieses Woche freigegeben wurde.
Sehe ich das richtig, dass die Daten fürs Routing noch nicht übernommen 
wurden (kann man das anstoßen?) oder ist da am Tagging noch ein Fehler?


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Doppenhaushälften mappen

[Garry]

Am 02.09.2015 um 14:37 schrieb Martin Koppenhoefer:

Kenne aber auch Bauten aus den 80ern in denen Doppel/Reihenhäuser eine 
gemeinsame Trennwand haben, was unter dem
Stichwort "kostengünstiges Bauen" lief.


in der BRD?

Ja.
Umgekehrt habe ich auch schon Doppelhäuser gesehen die eigentlich 
baulich getrennt waren, aber so umgebaut wurden, dass jeweils eine 
Wohnung pro Stockwerk hausübergreifend entstanden ist.


Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Doppenhaushälften mappen

[Garry]

Am 01.09.2015 um 16:57 schrieb Harald Hartmann:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nachtrag: ich will es nicht verschweigen, aber der Standardfall ist
wohl eher, dass man "zwei" Gebäude zeichnet. Aber das wirft dann in
der Tat eben genau die Diskussion hervor, die du selbst angesprochen
hast: es ist physisch meist nur "ein" Gebäude

Was ist das Merkmal für "physisch nur "ein" Gebäude"?
Ein Baugutachter in BW hat es mir gegenüber als Bausünde früherer Jahre 
dargestellt wenn
die "zwei" Gebäude nicht schalltechnisch vollständig entkoppelt wären, 
was heute Vorschrift wäre.

Dachziegel dürfen aber wohl durchgehend gelegt werden.
Kenne aber auch Bauten aus den 80ern in denen Doppel/Reihenhäuser eine 
gemeinsame Trennwand haben, was unter dem

Stichwort "kostengünstiges Bauen" lief.
Von aussen sieht man sowas den Gebäuden aber nicht an.
Ich würde aber als Ziel sehen solche Gebäudeteile immer separat zu 
erfassen - hilfreich z.B. für den Immobilienmarkt (fast jeder kommt mal in

die Verlegenheit eine Immobilie suchen zu müssen).
Oder welche Nachteile sprechen deutlich dagegen?

Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Klassifizierung eine Straße im Gewerbegebiet

[Garry]

Am 28.07.2015 um 03:20 schrieb Michael Kugelmann:



Unclassified steht in der Hierachie höher als
residential.

Diese Definition ist mir neu - wo steht das? Ich dachte, der Unterschied
ist nicht in der Hierarchie, sondern in der Nutzung der Grundstuecke. 
Wenn

ueberwiegend Wohnhaeuser an der Srasse stehen  residential. Wenn
ueberwiegend keine Wohnhaeuser dranstehen  unclassified.

auch hier: +1  für Volker! So wurde es zumindest früher verwendet.

Nein, das wurde auch früher schon uneinheitlich verwendet.
Ich finde den Informationsgehalt nicht den ein solches Tagen bringen soll.
Aber einen Informationsverlust, da eine klare highway-Hierarchie
(residential-unclassifified-tertiary-secondary-...) gestört wird.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Klassifizierung eine Straße im Gewerbegebiet

[Garry]

Am 28.07.2015 um 17:27 schrieb christian.pietz...@googlemail.com:

Dann sollte das wiki auf jeden Fall angepasst werden und das klarer
Darstellen. Die deutsche Bezeichnung für solche Straßen ist
Anliegerstraßen. Als Englische übersetzung findet man hier neben service
road and residential road auch noch ein paar andere, aber die beiden werden
am häufigsten genannt.
Wie gesagt, ich würde im Wiki den Innerorts-Teil ändern, so dass die
Wohnbebauung nicht mehr explizit erwähnt wird, sondern das ganze als
Anliegerstraße bezeichnet wird. Ich finde, dann ist klarer, dass damit auch
Straßen ohne Verbindungscharackter auserhalb von Wohngebieten gemeint sind.

Geht auf jeden Fall in die richtige Richtung.
Es sollte dabei noch klargestellt werden, dass es ohne weitere Angaben
frei benutzbare Straßen sind und nicht die Durchfahrt verboten - 
Anlieger frei

Beschilderung gemeint ist.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Klassifizierung eine Straße im Gewerbegebiet

[Garry]

Am 28.07.2015 um 10:44 schrieb SteMo:

Hi Allerseits,

der Begriff residential ist schon nicht falsch, er wird nur von den meisten (Deutschen) 
ungenau/falsch übersetzt. Wenn man es als Residieren laut liest wird schnell klar, daß die 
kleineren Straßen an denen irgendetwas residiert, egal ob Betrieb oder Wohnanlage, 
residential sind.
Ob eine solche Straße dann verkehrsberuhigt ist oder nicht müßte dann über die 
möglichen Zusatztags beschrieben werden. Verkehrsberuhigt heißt ja nicht unbedingt, 
daß da gar nichts mehr fährt. Meist wird den Autofahren eine Spur geklaut und ein 
zusätzlicher Radweg gemalt. In HH passiert da an manchen Straßen und Kreuzungen 
unglaublicher Irrsinn. Da sind die Kreuzungen so mit Strichen und Streifen bemalt, 
daß keiner mehr weiß wo er hingehört, folglich laufen/fahren plötzlich Fußgänger 
 Radfahrer quer über stark befahrene Kreuzungen und Straßen. Aber das gehört 
ja nicht hier hin. ;)

unclassified finde ich, ist eine der unglücklichsten Möglichkeiten für das Taggen, gerade, 
weil die meisten Renderer diesen Typ sehr groß, auffällig  breit zeichnen. Es gibt aber so viele 
Möglichkeiten zum Wege taggen in OSM, daß ich in den ganzen Jahren abschließend nicht ein Mal den 
unclassified Tag brauchte.

Ich bin beim service Tag auch der Meinung, daß der für (Zubringer)wege auf 
Privatgeländen steht. Also, Rampe zum Hotel, Weg auf dem Bauernhof, Weg auf 
Firmengeländen, Tankstellen, Parkplätze. Ebenso aber private Feldwege eines Bauern zu 
seinem Acker.

Man sollte bedenken, daß (in Dtld.) bei vielen irrtümlicher Weise solche 
Straßenprioritäten gerne mit Geschwindigkeitsbeschränkungen oder regelmäßigem 
Verkehrsdurchfluß gleichgesetzt werden.
Ich kenne in Norddeutschland (insb. HH, HL, KI) einige Straßen, die sind definitiv 
mindestens secondary, sind aber nur zweispurig und haben sogar gelegentlich 
noch Kopfsteinpflaster, sind den ganzen Tag über schwach befahren, aber zur 
Hauptverkehrszeit platzen die aus den Nähten.

Ich bin gegen einen weiteren residential-Tag, egal, wie er genannt würde.


+1

So hat ich das auch nicht gemeint dass man etwas neues schaffen muss.
Residieren trifft es ganz gut - kann man das auch international so 
begründen oder ist residential in manchen Ländern ein feststehender 
Begriff für ein Wohngebietsstraße?


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Klassifizierung eine Straße im Gewerbegebiet

[Garry]

Am 26.07.2015 um 22:52 schrieb Johannes:

Guten Abend,

wie würdet ihr diese Straße hier
https://www.openstreetmap.org/way/132618493) hier taggen? Ich finde
residential passt hier irgendwie nicht.

Ganz klar residential (außer wenn es eine verkehrsberuhigte Zone wäre).

Begründung:
Die Straße nutzt weit überwiegend nur der Verkehr, der sein Start / Ziel 
in dieser Straße hat.
Also keine übergeordnete Funktion womit unclassified und aufwärts 
ausscheidet.
Service kommt nicht in Betracht, wenn es eine öffentliche Straße ist 
die viele Grundstücke ohne besondere
Zweckbindung anbindet (Zufahrtsweg einzig zu einer Schrebergartenanlage 
würde ich eventuell noch als service sehen).


Der Begriff residential ist unglücklich gewählt - auf 
Gewerbe/Indstriegebiet angewendet sollt man das

interpretieren als da wohnen die Betriebe...
Manche sind zwar der Meinung dass man residential nur in Wohngebieten 
anwenden darf.
Es macht aber keinen Sinn im highway-Tag ausdrücken zu wollen, was an 
die Straße für ein landuse angrenzt.
Dafür gibt es eigene Tags. Daher ist residential absolut OK für 
öffentliche Straßen die nahezu ausschließlich ihren

Quell-/Zielverkehr in der Straße selbst oder in der nahen Umgebung hat

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Umfrage zu Kleben von Landnutzungsflächen an Straßen (bis 11.8.)

[Garry]

Am 12.07.2015 um 18:48 schrieb Florian Lohoff:

On Sun, Jul 12, 2015 at 03:30:31PM +0200, Manuel Reimer wrote:

Danke für den Hinweis. Ich habe mal abgestimmt.

Auch wenn meine Option, nicht verkleben und nahe an die Mitte
ziehen, aktuell nicht die priorisierte ist: Ich würde das auch in
Zukunft so machen. Ich bin dann und wann auf sauber gerenderte
Karten angewiesen und aktuell ist das der einzige Weg um zwischen
Straße und Fläche keine weißen Flecken zu haben.

Aber das ist doch in der realität auch so oder?

Ich meine das eigentlich Feld d.h. der landuse=farmland fängt doch erst
nach Bankette, Graben und Schutzstreifen an. D.h. da sind oft
4-6m dazwischen bis das Feld kommt. Da gibt es keinen Landuse.


Ich sehe dafür eine Lösung in einem landuse = road
als Unterscheidung zu einem landcover=highway für die Fahrbahn.
Da kann man dann die landuse meinetwegen zusammenkleben ohne dass es so 
sehr stört wie bisher.
So kann ich z.b. als Autofahrer gut die Straßengeometrie korrigieren 
ohne in landuse eingreifen zu müssen
oder als Grundstücksbesitzer die exakten landuse-Grenzen eintragen ohne 
irgenwelche Schäden an der

Straßengeometrie zu verursachen.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tag für Fahrradzählstellen

[Garry]

Am 30.05.2015 um 22:37 schrieb Tom Pfeifer:

Hallo Frau Robert Klemm,

bevor wir einen Tag erfinden sollten wir überlegen, ob wir diese Dinge
überhaupt mappen wollen. Auch wenn es von den Fahrradsensoren erst
ein paar Handvoll gibt -- Fahrzeugsensoren, als Induktionsschleifen
oder als Bewegungsmelder von oben, gibt es ja schon zuhauf, an vielen
Kreuzungen je ankommende Spur, und unterwegs auch noch genug.

Selbst die Vorschläge, die Ampellichter pro Spur zu erfassen sind bisher
nicht übermässig erfolgreich, ich sehe daher noch nicht den tieferen
Nutzen, Fahrzeugsensoren egel welcher Ausprägung in OSM zu erfassen.

Allein schon mal um einen Eindruck davon zu bekommen was wo erfasst wird.
Ein Gesamtbild vermittelt einen anderen Eindruck als das Wissen über das 
Vorhandensein einzelner Sensoren.

Letztenendes geht es bei den Sensoren auch um politische Zwecke.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage zum Mappen von Gemüsefeldern

[Garry]

Am 20.03.2015 um 00:19 schrieb Peter:


Ein Tag das unterscheidet zwischen Getreide und anderem
wäre was. Also was grobes das jeder kann:
   Getreide/Rüben/Blattwerk.
Aber das dürfte jährlich wechseln und ist von daher
unsinnig. Schon von dem Zeitpunkt der Luftaufnahme bis
sich einer mal dranmacht das zu erfassen ist das auf'm
Acker schon wieder anders.
Spargel nimmt da aber schon einen gewissen Sonderstatus ein, den 
wechselt man nicht so schnell

und hat seine eigene Charakteristik.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage zum Mappen von Gemüsefeldern

[Garry]

Am 19.03.2015 um 13:09 schrieb Martin Simon:

Anbau von Gehölzen (zur Lebensmittelgewinnung) - orchard
Anbau von Gedöns (auch Spargel) - farmland / meadow

Platt, aber eindeutig.


Noch nie in einen holzigen Spargel gebissen?
;-)

Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage zum Mappen von Gemüsefeldern

[Garry]

Am 19.03.2015 um 04:44 schrieb Steffen Wolf:



Ok, zum Gemuese, aeh, Spargel:
 http://de.wikipedia.org/wiki/Gem%C3%BCsespargel
Darin steht
| Spargelbeete können bei richtiger Pflege und Düngung mindestens bis zu
| zehn Jahre beerntet werden.
Oder mit Hinweis auf Johannis:
| Der Hintergrund für diese Bauernregel ist die Einhaltung einer
| ausreichenden Regenerationszeit der Pflanze für eine ertragreiche
| Ernte im nächsten Jahr.

Mehrjaehrig, zwar Gemuese, aber eben doch orchardfaehig.

Gemüse definiert sich doch gerade dadurch, dass es nicht mehrjährig ist
(ein bis maximal zweijährig) und vom oberirdischen Teil der Pflanze ist 
im Gemüsespargelanbau aus dem Vorjahr ist nichts mehr da.



Und zum Abschluss noch die Bemerkung, dass asparagus farm
gebraeuchlicher ist als asparagus orchard. (8.3 Mio zu 430T) Selbst
wenn man das Verhaeltnis zwischen Farm und Orchard (1210 Mio zu 134 Mio)
mitreinrechnet, ist asparagus orchard seltener genutzt. Zahlen durch
Google.
Durch die besonderen Anforderungen beim Anbau/Pflege/Ernte sehe ich 
orchard bei Spargel als zutreffender.
Farmland sehe ich mehr in der Richtung pflügen, aussähen und zur 
Erntezeit in einem Rutsch abernten ohne dass dazwischen
zusätzliche Pflege notwendig wäre (Bewässerung/Schädlingsbekämpfung 
ausgeklammert).



Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage zum Mappen von Gemüsefeldern

[Garry]

Am 18.03.2015 um 23:04 schrieb Lothar Beck:

Und das widerspricht sich meiner Meinung nach, im deutschen Wiki wird
Gemüseanbau orchard zugeordnet. Wenn ich mir in der Wikipedia dazu die Liste
der Gemüse ansehe: http://de.wikipedia.org/wiki/Liste_der_Gem%C3%BCse
Dann müsste ich auch Salat und Kohlfelder als orchard taggen und nicht mehr
als farmland.
Gefühlt würde ich hier eventuell differenzieren ob im Jahreswechsel 
unterschiedliches angebaut wird, dann eher farmland,

oder ob über Jahre hinweg das gleiche angebaut wird, dann eher orchard...

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Garry]

Am 20.02.2015 um 15:21 schrieb Holger Jeromin:



Leute die dem Navi hinterher hin den Fluß fahren.

Aber der Router kann nicht entscheiden, ob es sinnvoll ist den Track
jetzt zu benutzen oder nicht.
Das Problem kann man immer haben, dass ein Weg aktuell nicht nutzbar 
ist, selbst auf der Autobahn, siehe Schiersteiner Brücke.

Oder willst du, dass der Router dich mit deinem Auto bis auf das
Basislager des Mt.Everest lotst, da Wenn es keine alternative Zufahrt
gibt, muss man da halt durch. auch hier gilt?




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] building = ? fuer Zweifamilienhaus

[Garry]

Am 07.03.2015 um 22:21 schrieb Bernhard Weiskopf:

Hallo an alle,

für Einfamilienhäuser soll building = house oder building = detached
verwendet werden.

Für ein „großes Gebäude mit Wohnungen. Im Erdgeschoss befinden sich
gelegentlich Läden.“ soll building = apartments verwendet werden.

Quelle: http://wiki.openstreetmap.org/wiki/DE:Key:building

Wie soll ein Zweifamilienhaus getagged werden, das oft nicht größer ist als
ein Einfamilienhaus und oft auch fast gleich aussieht? Ein Treppenhaus ist
auch nicht immer vorhanden.

Bisher habe ich ab zwei Wohnungen building = apartments verwendet, auch wenn
das Haus kleiner ist als manches Einfamilienhaus. Ist das richtig oder gibt
es andere values?


Macht es Sinn das unterschieden zu wollen?
In meinem Umfeld gibt es zahlreiche gleichartige Häuser - zweistöckig + 
Satteldach,
teilweise als Reihenhäuser, teilweise als alleinstehende Häuser. Manche 
sind so ausgeführt dass drei Parteien darin wohnen können,
werden aber nur von einem Paar oder auch nur einer Person bewohnt. 
Andere sind als Einfamilienhaus gebaut, trotzdem wohnt darin

auch noch eine fremde 2. Partei.
Es gibt also keine eindeutigen Merkmalen die eine eindeutige Zuordnung 
erlauben.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Garry]

Am 19.02.2015 um 10:46 schrieb Eifelhunde:

Am 18.02.2015 um 23:45 schrieb Garry:

Am 18.02.2015 um 13:06 schrieb chris66:

Weitere Probleme:

...
- Wichtige Infos wie maxspeed sind noch lückenhaft

??? es gilt in jedem Land ein generelles Maxspeed (in D außer
Autobahnen) Ich versteh die Anmerkung nicht, es besteht doch nicht die
Pflicht so schnell zu fahren - selbst wenn Schilder die Geschwindigkeit
weiter beschränken ist die Geschwindigkeit keine Pflicht
Sorry, war vielleicht missverständlich - ich meine die expliziten 
streckenabschnittsbezogenen Limits, nicht die generellen

landesspezifischen.



während gut ausgebaute, gerade Strecken zwar beschränkt sind, aber eine
höhere Durchschnittsgeschwindigkeit erlauben.

vielleicht erlauben *könnten*
Nein, durchaus können. Eine gut ausgebaute Bundesstraße die aber auf 
80km/beschränkt ist erlaubt in der Regel eine deutlich
höhere Geschwindigkeit als z.B. eine Passstraße die nicht explizit(!) 
beschränkt ist.


Von daher sehe ich weniger die fehlenden maxspeed-Tags als Problem als 
vielleicht zu grob erfasste Straßenverläufe die den realen Verlauf zu 
sehr begradigen.


Garry


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Garry]

Am 19.02.2015 um 11:31 schrieb Martin Vonwald:
Kein professioneller Router geht davon aus, dass man die maximal 
erlaubte Geschwindigkeit auch tatsächlich fahren kann. Je nach Verlauf 
der Straße werden deutlich niedrigere Geschwindigkeiten angenommen. 
Auf einer völlig geraden Autobahn im ebenen Gebiet nimmt ein guter 
Router eine Geschwindigkeit nahe der erlaubten an, idR ca. 5%-10% 
darunter. Auf einer Passstraße, wo sich eine Serpentine an die nächste 
reiht, interessiert einen professionellen Router die maximal


Woher hat er die Information?
Aus dem Preprocessing, Tags oder schaut er sich jedesmal den Verlauf an? 
Letzteres könnte langwierig werden, oder?


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Garry]

Am 18.02.2015 um 13:06 schrieb chris66:

Weitere Probleme:

...
- Wichtige Infos wie maxspeed sind noch lückenhaft

Sehe ich weniger problematisch, oder werden kurvenreiche Strecken auch 
berücksichtigt?
Häufig sind doch diese nicht beschränkt, erlauben aber wegen der vielen 
Kurven nur geringe Geschwindigkeiten
während gut ausgebaute, gerade Strecken zwar beschränkt sind, aber eine 
höhere Durchschnittsgeschwindigkeit erlauben.


Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Start-/Landebahn

[Garry]

Am 14.01.2015 um 16:42 schrieb fly:

Das klingt mir dann eher nach einer Lösung analog zu area:highway z.B
area:aeroway und aeroway=* nur für Linien benutzen.

Alternative sollten mal ein paar Renderer width=* unterstützen sonst
wird es schwierig beim Überzeugen, das es als Linie auch graphisch
funktioniert.

Schönes Beispiel warum es sinnvoll und notwendig ist Flächen und Linien 
zu unterstützen:

http://tools.geofabrik.de/mc/#17/47.9082/7.6249num=4mt0=mapnikmt1=nokia-satellitemt2=bing-satellitemt3=google-satellite

Die alte Millitärlandebahn wird nur noch zu einem Teil für 
Sportflugbetrieb genutzt.


Gegebenenfalls wäre so etwas auch sinnvoll im Highway-Bereich befestigte 
Fläche vs. Verkehrswege.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Start-/Landebahn

[Garry]

Am 14.01.2015 um 01:13 schrieb Martin Koppenhoefer:

fürs Flugzeugrouten fehlen in OSM AFAIK die relevanten Daten, die Frage
Fläche oder way für die Startbahn ist vor diesem Hintergrund komplett
unwichtig hinsichtlich Routing.
Für z.B. potentielle Immobilienkäufer/Mieter in Flugplatznähe ist es 
aber vielleicht schon eine relevante
Information wenn es solche beschränkte Nutzungen (nur Starts, nur eine 
Richt_ung_...) gibt.


Garry
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] F: Kreuzungsfreiheit bei trunk

[Garry]

Am 11.01.2015 um 03:20 schrieb Michael Kugelmann:

--
Im Gegensatz zu Autobahnen können Kraftfahrstraßen von anderen Straßen 
plangleich gekreuzt werden. Der Verkehr an Knotenpunkten wird dann 
meist über Ampeln oder Kreisverkehre geregelt.

--

Eine Kraftfahrstraße würde ich sehr wohl als trunk taggen...

Nur weil es eine Kraftfahrstraße ist?
Das Schild habe ich auch schon an engen, steilen Bahnunterführungen im 
ampelgesteuerten wechselseitigen Einrichtungsverkehr gesehen - 
Verkehrsbedeutung im Bereich residential oder unclassified.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Start-/Landebahn

[Garry]

Am 12.01.2015 um 12:50 schrieb Volker Schmidt:

Ich dachte dass moderne Flughaefen normalerweise symmetrische Landebahnen
haben, die Benutzungsrichtung haengt von der aktuellen Windrichtung ab.
Nicht unbedingt, es gibt durchaus auch Gründe die Benutzungsrichtung 
individuell unabhängig von der Windrichtung zu definieren.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] F: Kreuzungsfreiheit bei trunk

[Garry]

Am 12.01.2015 um 22:59 schrieb Michael Kugelmann:


Folgendes Bild als Beispiel:
https://de.wikipedia.org/wiki/Datei:B14unterVerkehr.jpg
Das ist doch wohl ein trunk, oder? 


Im abgebildeten Zustand, ja.
Und so ein Straße habe ich auch schon in eine Stadt reinlaufen sehen 
(allerdings mit entsprechend niedrigem Tempolimit) und dann mit 
einer Ampel. Die Frage war, ob sich Trunk und Ampel ausschließt. Und 
ich habe gesagt: nein. Selbst bei einer Kraftfahrstraße.
Wenn es bei einer Ampel bleibt kann man es eventuell als trunk belassen, 
wenn sich dann aber die Ampeln häufen ist das keine trunk mehr...


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

[Garry]

Am 28.02.2014 17:42, schrieb Roland Olbricht:


Schneisen sind eine schlechte Idee, da sie wiederum die Arbeit mit den Daten
dazwischen enorm erschweren. Sie erwecken zudem den Eindruck, man hätte die
Schneisen sind eine gute Idee, sie schaffen Strukturen mit einem 
Wiedererkennungswert!



genaue Straßenbreite berücksichtigt. Ich habe mehrmals die Freude gehabt,

Straßenbreite != Schneisenbreite!
Das Gebüsch/Grünstreifen am Straßenrand das regelmäßig kurz geschnitten 
wird gehört sicher nicht zum landuse=forest etc. sondern zum eigenem 
landuse (= [Straße]).

Straßen zwischen landuse-Nutzungen zu editieren, was enorm mühselig ist, weil
der Editor nicht weiß, dass man jetzt Straßennodes und nicht landuse-Nodes
anfassen möchte und schon gar nicht, dass die landuse-Nodes bei Verschiebungen
den Straßennodes folgen müssten.
Mühselig ist es, dieses schönmalen für den Renderer wieder aufdröseln 
zu müssen um in das grobe

Waldgetünche etwas Detailierung zu bekommen.

Auch da gilt: Dem Datennutzer ist durchaus bekannt, dass mitten auf der A6
keine Bäume wachsen, und die Straßenbreite ist entweder an der Straße
spezifiziert oder nicht genau bekannt.
Straßenbreite und landuse haben nichts miteinander zu tun, das sind 
eigene Welten!



Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

[Garry]

Am 28.02.2014 16:34, schrieb Martin Koppenhoefer:


Für mich wie im Wiki beschreibt Landuse die tatsächliche Bodennutzung. 
Vielleicht kann man bei der Schneise noch diskutieren, aber nimm mal 
Freudenstadt (im Schwarzwald). da passt landuse Forest sicher nicht. Liegt aber 
im Schwarzwald. Ich würde daher eher einen neuen Key für Gebiete vorschlagen, 
sowas wie georegion=forest
Auch wenn der Schwarzwald den Wald im Namen trägt so ist es doch ein 
Mittelgebirge das diesen Namen trägt und nicht ein Stück Wald. Ein 
Grundbesitzer der den (Nach)Namen Bauer hat ist deswegen ja auch noch 
lange kein Landwirt bzw. sein Grundstück landuse = farmland.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

[Garry]

Am 28.02.2014 17:00, schrieb Wolfgang Hinsch:




Für mich wie im Wiki beschreibt Landuse die tatsächliche Bodennutzung. 
Vielleicht kann man bei der Schneise noch diskutieren, aber nimm mal 
Freudenstadt (im Schwarzwald). da passt landuse Forest sicher nicht. Liegt aber 
im


Wie definierst Du die Bodenutzung bei den Grünstreifen entlang von 
(klassifizierten, ausserörtlichen) Straßen?

Der vorwiegende Nutzen ist hier der Sicherheitsaspekt als Freihaltetrasse.

Ebenso bei Pipelines deren Trasse von grösserem Wurzelwerk freigehalten 
wird.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Was ist Openstreetmap wert?

[Garry]

Am 31.01.2014 22:20, schrieb jotpe:

Hallo Roland, genau gemeint war die andere Stoßrichtung, deswegen ja wert
sein könnte. Da fällt mir was lustiges ein: Exakt dein Szenario habe ich
habe ich im Gespräch mit einem Skeptiker gebraucht.

@Michael in EUR natürlich

Vielleicht kann man es hochrechnen oder schätzen... Vernünftige Annahmen
hab ich natürlich keine zur Hand.
Ein Ansatz könnte sein Bearbeitungszeit (Vor Ort und in OSM inkl
durchschnittl Anzahl der Edits) Nodes, Ways und Relationen zu schätzen,
Massenimports (TIGER?) anzuziehen und das multipliziert mit einen
realistischen Stundenlohn.

Dürfte jedenfalls viel sein...


Einarbeitungszeit sowie Aufwand für die Toolerstellung nicht vergessen..
Harwareanteil wird dann schwierig...


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Luftbild-Versatz

[Garry]

Am 30.01.2014 10:45, schrieb Richard Z.:


im Flughafenbereich hat man genau das - idR sind von jeder Landebahn mehrere
Punkte ganz genau referenziert und auch gut von oben zu identifizieren. 
Leuchtfeuer
gibt es auch, leider sind die Sat-bilder tagsüber gemacht aber das eine oder 
andere
kann man vielleicht trotzdem identifizieren.

Vielleicht haben wir Glück und viele Sportflugplätze geben uns die Daten
frei?
Meine Aussage sollte sein: Die Flugplätze bekommt man damit vielleicht 
sehr genau, alles andere ist zu weit weg als dass

die Flugplatzkoordinaten was verbessern könnten...

Gruss

Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Luftbild-Versatz

[Garry]

Am 29.01.2014 11:52, schrieb Richard Z.:

Flughäfen und Hubschrauberlandeplätze haben diverse Punkte mit genau bekannter 
Position
die sehr gut sichtbar sind - weiß jemand ob die Koordinaten Lizenrechtlich 
unbedenklich
wären?
Für den Flughafenbereich mag das was bringen - ansonsten sollte man 
mindestens drei Punkte  mit möglichst großem Abstand im Umkreis von 
Größenordnung 100m haben um eine Aussage
über die Qualität des  Luftbilds an der aktuellen Position treffen zu 
können.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Luftbild-Versatz

[Garry]

Am 29.01.2014 23:06, schrieb Andre Hinrichs:
Warum also nochmal ein extra coordinates_* Tag erfinden? Als weitere 
Idee könnte ich mir auch ein Überprüfungs-Bot vorstellen, der einmal 
täglich sich das daily replicate anschaut und Veränderungen an 
gesperrten Nodes an den Ersteller meldet. Der kann dann entscheiden, 
was er damit tun will. 


Fazit: Ich finde die Idee von gesperrten Nodes schon irgendwie 
charmant, sehe jedoch auch, dass es dann kompliziert werden würde... 
Den Vorschlag hatte ich schon vor gefühlt ca. 2-3Jahren eingebracht, 
wurde von Frederik aber gleich aktiv bekämpft...


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Grundriss vs Dachfläche

[Garry]

Am 11.01.2014 18:37, schrieb chris66:


Pragmatische Antwort:

Luftbildabzeichner erfassen die Dachfläche, ALK (Kataster-WMS)
Abzeichner erfassen die Grundfläche.

Wie soll's auch anders gehen? :-)

Im Wiki ist angedeutet, dass tendenziell eher die Grundfläche gemappt
werden soll, aber wie will man das erzwingen?


Seit in den letzten Jahren das Abwasser auch über die versiegelte Fläche 
verrechnet wird ist für die Masse doch
ehr die Dachfläche in der Aufsicht (die man gut aus Luftbildern 
entnehmen kann) relevant als Katasterdaten, die individuell
für die Umsetzung in OSM interpretiert werden müssen und somit zu stark 
abweichenden Ergebnissen führen kann/wird.
Was sich unter einem Dach tatsächlich befindet ist für den Mapper schwer 
feststellbar.


Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Grundriss vs Dachfläche

[Garry]

Am 11.01.2014 20:08, schrieb Tobias Knerr:

Am 11.01.2014 18:37, schrieb chris66:

Pragmatische Antwort:

Luftbildabzeichner erfassen die Dachfläche

Auch beim Luftbildzeichnen kann man darauf achten, die Fläche halbwegs
korrekt am Grundriss auszurichten.

Und generell sehe ich schon, dass das oft auch so gehandhabt wird. Nur
wenige würden ein Gebäude, das neben der Straße steht, über die Straße
drüber malen, nur weil das Dach im Luftbild hineinragt.
Ein flächenhaftes Eintragen von Straßen hat sich in OSM noch nicht 
verbreitet, von daher dürfte es relativ selten sein

dass ein Dach die Mittellinie der Straße berührt!



Im Wiki ist angedeutet, dass tendenziell eher die Grundfläche gemappt
werden soll, aber wie will man das erzwingen?

Wenn man erst mal klar sagt, dass es so sein soll, wird ein vernünftiger
Mapper auch versuchen, sich daran zu halten.

Das mag funktionieren wenn ein Mapper nur eine handvoll Gebäude bearbeitet.
In der Masse und Fläche ist man aber erst mal froh überhaupt 
Einzelgebäude zu haben um diese in einer zweiten Stufe
auch mit Hausnummern/Adressen ausstatten zu können. Eine 
Unterscheidung/Detailierung zwischen Grundfläche und Dachfläche sehe ich 
da auf längere Sicht nicht.

Zumal es auch schwierig ist eindeutige Grenzen zu siehen.


Siehe z.B. in Bezug auf Einordnung von Wintergärten:
http://www.paradisi.de/Freizeit_und_Erholung/Wohnen/Wintergarten/Artikel/6826.php


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Voting landuse=highway

[Garry]

Am 04.12.2013 22:36, schrieb Florian Lohoff:


auf thematischer Ebene ja, das sind die Straßenflächen inkl. Böschung,
Graben, etc., normalerweise da, wo die Grundstücke aufhören.

Das ist aber etwas was man nicht on the ground nachvollziehen kann
wo das Grundstück aufhört.
Zu den richtigen Zeitpunkten sieht man das meist relativ gut wenn die 
Straßenränder
gemäht sind. Zwar nicht mit einer in der Vermessungstechnik üblichen 
Genauigkeit aber schon auf einem besseren OSM-Niveau.


Und ausser Das sieht im rendering dann netter aus sehe ich gerade
den zweck noch nicht.

Eine 6spurige Autobahn nebst Böschung, Entwässerungsgräben, 
Sicherheitszonen etc.

kann man nicht mehr einfach ignorieren und den umgebenden landuse zuordnen.

Allerdings würde ich für landuse=road plädieren und die eigentliche 
befestigte Fahrbahnfläche inklusive

der Sperrflächen einem landcover=highway zuordnen.



Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Garry]

Am 04.11.2013 09:55, schrieb Martin Koppenhoefer:


In Mannheim fehlen
auch ein paar Schilder, die kann man gar nicht taggen.


und wie machen Autofahrer das dann dort? Wie erkennen die die geschlossene 
Ortschaft?


An der Beschreibung in der Post vom Ordungsamt ;-)

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Garry]

Am 05.11.2013 02:24, schrieb Masi Master:

Am 04.11.2013, 20:54 Uhr, schrieb Garry garr...@gmx.de:


Am 04.11.2013 10:09, schrieb Martin Koppenhoefer:


Eine Ansammlung von residentials (ein tag!) lässt darauf schließen 
dass diese Innerorts sind.


Es gibt auch highway=residential's außerhalb geschlossener 
Ortschaften, zB in Weilern (Gehennzeichnet durch die grünen 
Ortsschilder mit gelber Schrift.) oder sicher auch ganz in der Pampa.
Residential dürften da ehr die Ausnahme sein, die durchgehenden Straßen 
sind mindestens unclassified und die Nebenstraßen ehr tracks.
Ich sehe es bei den residentials auch ehr als unerheblich an ob sie 
innerorts oder ausserorts sind da der Charakter in etwa gleich bleibt im 
Gegensatz zu den Straßen der höheren Klassen.


Wahrscheinlich wird es auf eine Fläche hinauslaufen, die in etwa dem 
Haupt-residential entspricht, muss ja nicht so genau sein, sollte nur 
die (alle) Highways dort schneiden wo das Ortsschild steht, bzw. wo 
die (Neben-)Straßen in Tracks übergehen.


Dafür brauch man kein schwer zu handhabendes Polygon dass es real gar 
nicht gibt. Innerorts bei Straßen bezieht sich nur auf den Bereich der 
StVO, also nur die öffentlichen Straßen, Wege und Parkplätze.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Garry]

Am 05.11.2013 22:30, schrieb Martin Koppenhöfer:


Am 05.11.2013 um 21:06 schrieb Garry garr...@gmx.de:


Residential dürften da ehr die Ausnahme sein, die durchgehenden Straßen sind mindestens 
unclassified und die Nebenstraßen ehr tracks.


Wenn da Leute wohnen die keine Bauern sind, dann ist es kein Track und wenn das 
keine Verbindungsstraßen sind, dann sind sie auch keine unclassifieds


Wo gibt es so etwas in nenneswertem Ausmass?
Siehst Du ein Problem wenn Anwendungen(!) residentials per default als 
innerorts interpretieren wenn (noch) nicht anderst angegeben?


Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Garry]

Am 04.11.2013 07:38, schrieb Alexander Heinlein:

On Sun, Nov 03, 2013 at 11:14:39PM +0100, Garry wrote:

Am 03.11.2013 20:10, schrieb Martin Koppenhoefer:


mit traffic_sign=city_limit neben der Straße kann man innerorts / außerorts 
darstellen, wenn alle Schilder getaggt sind, kann man die innerorts Inseln 
bilden.


Dafür gibt es zu viele Sonderfälle(so häufig, dass man sie schon
gar nicht mehr Sonderfall nennen kann) als dass man dafür sinnvoll
Inseln bilden könnte.
Dass residentials meist innerorts liegen ist ehr selbstredend und
kann in den meisten Fällen bei mehr oder weniger geschlossener
Bebauung vorausgesetzt werden.
Bei Strassen mit Verbindungscharakter sieht das anderst aus.

Ich denke selbst ohne Sonderfälle wird das oft schwierig bis unmöglich. Als
Grundvoraussetzung müssen erst mal _alle_ Schilder vorhanden sein bevor man
überhaupt anfangen kann, Inseln zu bilden. Dann ist das außerdem
berechnungstechnisch sehr aufwändig für einen Router. Und dann gibt es noch
Schilder, die als Ortsausgangsschild für den einen Ort und als
Ortseingangsschild für den anderen Ort gelten. Außerdem muss die Stadt
komplett auf der Karte vorhanden sein, für abgeschnittene Städte geht das
auch wieder nicht (gut, fällt unter Sonderfall).

Wenn man die Information stattdessen direkt an der Straße anbringt, dann
braucht man nicht groß herumrechnen. Es ist direkt ablesbar, klappt mit
allen Sonderfällen, mit halben Städten, mit von mehreren Orten benutzten
Schildern etc. Der Nachteil ist nur eben, dass eigentlich so gut wie alle
Straßen diese zusätzliche Information benötigen. Aber das ist ja bei
maxspeed und ähnlichen Tags auch nicht anders.


Für genaue statistische Auswertungen etc., ja. Aber ist es nicht gerade eine
Stärke von OSM und seinen Anwendungen auch aus wenigen und unvollständigen
Angaben etwas brauchbares zu generieren?

Garry
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Garry]

Am 04.11.2013 10:09, schrieb Martin Koppenhoefer:



Am 03/nov/2013 um 23:14 schrieb Garry garr...@gmx.de:

Dafür gibt es zu viele Sonderfälle(so häufig, dass man sie schon gar nicht 
mehr Sonderfall nennen kann) als dass man dafür sinnvoll Inseln bilden könnte.
Dass residentials meist innerorts liegen ist ehr selbstredend


Ortsschilder sind nicht hilfreich, aber residentials schon?
Eine Ansammlung von residentials (ein tag!) lässt darauf schließen dass 
diese Innerorts sind.
Aus ehr sporadisch gesetzten, verletzlichen Ortsschildern - 
insbesondere ohne weitere Angaben - wird es schwierig die Situation 
korrekt abzubilden.



Residentials kannst Du hierzulande viele finden, die außerhalb geschlossener 
Siedlungen verlaufen.

In welchem Zusammenhang? Straßen, die ein gefahrloses, schnelleres 
Fahren als innerorts zulassen würde ich

in der Regel nicht als residential klassifizieren.

Gruss
Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Garry]

Am 04.11.2013 14:54, schrieb Ronnie Soak:

Ich zeichne zudem die admin_boundary jeweils so ein, dass sie die highways
exakt in der traffic_sign=city_limit node schneidet. Liegen
Gebäude/Felder/etc. noch hinter dem Ortsschild, folgt die boundary halt der
Straße einige Meter wieder zurück. Bei Durchgangsstraßen, die nicht zur
Ortschaft gehören (und als Bundesstraßen/Autobahnen auch nicht wirklich zu
ihnem Verwaltungsbereich zählen) müsste man dann auf Multipolygone
zurückgreifen. Das ist mir aber persönlich noch nicht untergekommen.

Anhand der admin_boundary könnte man dann innen/außen bestimmen. Oder gibt
es Fälle, in denen Ein Ortsschild vor etwas steht, dass nicht mal
admin_level=10 verdient? Oder gibt es Straßen, die Verwaltungstechnisch
tatsächlich zur Ortschaft gehören, aber trotzdem kein Ortsschild haben?

Ja - genau deshalb macht es keinen Sinn zu versuchen die Ortschilder mit 
boundarys zu matchen.
Hier gibt es  Umgehungsstraßen (mit klarem ausserörtlichen Charakter) 
die zunächst ausserorts ausgeschildert waren.
Dann hat man sie nach ein paar Jahren als Innerorts umdeklariert da man 
den Unterhalt dem Ort aufgebürdet hat.
Nach ein paar weiteren Jahren - noch nicht so lange her - musste sie 
dann wieder als ausserörtliche Straße umgeschildert werden
weil der Gesetzgeber (oder Gericht?) entschieden hatte, dass ein 
innerörtlicher Charakter erkennbar sein muss um eine Straße als solche 
auszuschildern.

Grenzen haben sich deswegen nie verschoben!

Anmerkungen nebenbei:
An solchen Beispielen wird deutlich, dass einige Geschwindigkeitslimits 
(pendelten hier zwischen 30km/h und 100km/h rum) reine politische 
Willkür sind die nichts mit Verkehrssicherheit zu tun haben.


Gruss
Garry



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Garry]

Am 03.11.2013 22:22, schrieb Bernhard Weiskopf:


Dieses traffic_sign stellt die Grenze zwischen inner- und außerorts dar.
Ich komme mit dem traffic_sign-tagging aber nicht ganz klar.

Die Schilder sind mal auf der Straße getagged, mal rechts daneben und mal
dort, wo sie in Realität stehen (das ist bei mir auch manchmal auf der
linken Seite). Somit sehe ich nicht, in welche Richtung inner- oder
außerorts beginnt oder endet. (Als Mensch kann man das meistens schon, wenn
man die Umgebung betrachtet, als Router wird's aufwändig.) Manche Schilder
stehen weit vor der residential-area-Grenze, manche auch weit dahinter, wenn
der Ortsteil davor nicht als geschlossene Ortschaft zählt. Und manche Städte
stoßen direkt aneinander, dann ist beidseits innerorts. In Mannheim fehlen
auch ein paar Schilder, die kann man gar nicht taggen.

Interessant ist das, was an einen way getaggt ist. Verkehrsschilder sind 
ehr informative Daten
und setzen eine gewisse Vollständigkeit des Gesamtbildes voraus um sie 
korrekt interpretieren zu können

- sehr hohe Fehlergefahr wenn man sich darauf verlässt.
Und ob eine Streckenabschnitt inner- oder ausserorts liegt ist eine 
politische / gesetzliche Entscheidung die sich nicht exakt mit

areas Abbilden lassen.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Garry]

Am 03.11.2013 20:10, schrieb Martin Koppenhoefer:


mit traffic_sign=city_limit neben der Straße kann man innerorts / außerorts 
darstellen, wenn alle Schilder getaggt sind, kann man die innerorts Inseln 
bilden.

Dafür gibt es zu viele Sonderfälle(so häufig, dass man sie schon gar 
nicht mehr Sonderfall nennen kann) als dass man dafür sinnvoll Inseln 
bilden könnte.
Dass residentials meist innerorts liegen ist ehr selbstredend und kann 
in den meisten Fällen bei mehr oder weniger geschlossener Bebauung 
vorausgesetzt werden.

Bei Strassen mit Verbindungscharakter sieht das anderst aus.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] craft=beekeeper und Direktverkauf

[Garry]

Am 19.10.2013 19:33, schrieb Jörg Frings-Fürst:
Einen Tag für regelmäßig wiederkehrende Bauten haben wir leider noch 
nicht.

Nicht ständig vorhandene Stände würde ich nicht taggen. Hofläden
natürlich schon.




Eine Möglichkeit sollte man schon schaffen um saisonale Verkaufsstände 
zu taggen... Gibt ja so Stellen an denen es im Wechsel Weihnachtsbäume, 
Spargel, Erdbeeren, Neuen Wein... gibt.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Schienen mit abandoned

[Garry]

Am 03.10.2013 10:06, schrieb Bernhard Kuisle:

Hallo fly,
  
danke für die freundliche Antwort. Lese nun seit ca. 1 Monat mit und weiss, dass das der übliche Umgangston hier ist.

Aber wie wäre es mit nachschauen? Es handelt sich hier um eine ehemalige 
Bahnstrecke, die seit ca. 30 Jahren stillgelegt ist und eben bis auf zerfallene 
Brücken und den Schotteruntergrund fast nichts mehr da ist und wo jetzt eine 
meist ortsnahe Radstrecke eröffnet wurde.



Ist mir jetzt zwar nicht ganz klar um was es hier genau geht - aber ein 
rechtlicher Hinweis zu Bahnstrecken (in Deutschland) scheint mir hier 
angebracht:

Es gilt zu unterscheiden zwischen stillgelegten und entwidmeten Strecke.

Beiden gemeinsam ist das kein regulärer Bahnverkehr mehr stattfindet.
Über den baulichen Zustand kann damit aber keine sichere Aussage 
getroffen werden.
Beide können physikalisch noch befahrbar sein oder soweit abgebaut und 
überwuchert sein dass der ehemalige Bahnverkehr zumindest für den Laien 
nicht mal mehr erahnbar ist.
Der Unterschied besteht darin, dass eine stillgelegte Strecke jederzeit 
wieder als Bahnstrecke in Betrieb genommen werden kann, auch wenn dazu 
erhebliche bauliche Aufwendungen nötig sind. Es ist aber nach wie vor 
ein Bahngelände das für eine eventuelle Wiederinbetriebnahme 
bereitgehalten werden muss und nicht verbaut werden darf (Es soll wohl 
auch Fälle geben in denen mehr oder weniger widerrechtlich Radwege 
angelegt wurden)!
Entwidmete Strecken werden baurechtlich dagegen so behandelt wie wenn 
noch nie eine Strecke vorhanden gewesen wäre (Planfeststellungsverfahren 
etc. für eine Wiederinbetriebnahme erforderlich). Dennoch kann auf einer 
entwidmeten Strecke noch eine Gleisanlage vorhanden sein und z.B. für 
touristische Zwecke ein Fahrrad-Draisinenbetrieb stattfinden.
Leider wird das Thema in OSM sehr stiefmütterlich behandelt - das 
Löschen einer lediglich stillgelegten Bahntrasse (auch wenn keine 
Gleisanlagen mehr zu sehen/vorhanden sind) sehe ich als Vandalismus an!


Garry






___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]

[Garry]

Am 11.09.2013 17:55, schrieb Alexander Matheisen:

Ach ja und railway = funicular scheint nicht dargestellt zu werden, oder hab
ich da was vergessen zu taggen?

Dass Standseilbahnen nicht dargestellt werden, ist so gewollt. Die Karte
beschränkt sich nämlich auf die richtigen Eisenbahnen, also
schienengebundene und aus eigener Kraft fahrende Verkehrsmittel.


Warum diese Beschränkung?
Damit fehlen auch Verbindungsglieder zwischen Eisenbahnen, insbesondere 
wenn sie als Transportmittel für Eisenbahnwagen eingesetzt werden.


http://de.wikipedia.org/w/index.php?title=Datei:OBS_Aufsetzwagen_ex_EB_188_513.jpgfiletimestamp=20071118162129;

http://de.wikipedia.org/wiki/Parc_d%E2%80%99Attractions_du_Ch%C3%A2telard

Gruß

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] highway=abandoned

[Garry]

Am 21.08.2013 14:16, schrieb Alexander Lehner:


Das taete mich auch interessieren - ich hab hier eine stillgelegte, 
teils abgerissene, teils zum Radweg umfunktionierte
Bahnstrecke die als abandomed markiert ist. Ist zwar historisch 
interessant, aber ich frage mich auch, woher der Autor eigentlich 
diese Daten hat?
Ehmaligen Bahntrassen lassen sich meist relativ leicht im Gelände 
erkennnen. Dazu geben alte Karten und Bilder, Schattierungen in 
Luftaufnahmen etc. Auskunft über den ehmaligen Verlauf. Und Zeitzeugen 
gibt es meist auch noch genügend.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bauliche Trennung

[Garry]

Am 06.07.2013 15:12, schrieb fly:

Am 06.07.2013 14:56, schrieb Tirkon:

Martin Koppenhoefer dieterdre...@gmail.com wrote:


Worum es im Prinzip geht ist, den Unterschied zwischen physisch unmöglich
und lediglich verboten aber theoretisch möglich festzuhalten (hinsichtlich
eines U-Turns z.B.)

Mir ist schon klar, worum es geht. Es ist aber beispielsweise
zweifelhaft, wo physikalisch unmöglich anfängt. Ein Grünstreifen
läßt sich problemlos überfahren oder überlaufen. Dennoch reicht ein
solcher aus, um Rad- und Fußwege getrennt zu mappen. Die meisten
Fußgänger kommen auch über eine Leitplanke. Beispielsweise die im
Thread erwähnte Bordsteinkante wird hierzuort regelmässig von
Traktoren überfahren - zigmal am Tag. Von daher sähe ich den Trenner
besser im expliziten Mapping mit entsprechenden Tags aufgehoben. Dann
kann jede Anwendung selbst darüber entscheiden, welche Trenner sie wie
bewerten möchte.

Aber genau darum geht es doch: Bordsteine, Leitplanken, Grünstreifen
sind alles bauliche Trennungen und keine Linien oder Plastik-Hütchen
oder -Streifen. Dass mich das ganze mit nem BMX/Fun-Bike eher
herausfordert und nicht trennt ist eine andere Sache.


Damit wäre auch gleichzeitig das im Thread aufgeworfene Problem
gelöst, dass die Art der Trennung in verschiedenen Staaten zu einer
unterschiedlichen Definition von Fahrbahn führen könnte.


Was mich in diesem Zusammenhang stört sind vier- und mehrspurige 
Strassen bei denen  verkehrlich
die liniengetrennte Bauform der baulichgetrennten Bauform in nichts 
nachsteht.
Insbesondere wenn die baulich getrennte Doppelspur nur zu 
Hauptverkerhszeiten zur Verfügung steht
weil nur dann ein zeitlich begrenztes Halterbot für eine nicht 
zugeparkte rechte Spur sorgt.
Bei festhalten an baulicher Trennung fürs Tagen als getrennte Ways für 
die Richtungsfahrbahnen wird

somit dann die schlechtere Strasse besser dargestellt und umgekehrt.
Klar kann man jetzt dem Renderer die Schuld geben, aber 
anwenderfreundlich ist das nicht...


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] *:lanes und Straßenbahnschienen

[Garry]

Am 06.07.2013 19:20, schrieb Peter Wendorff:

Am 06.07.2013 17:25, schrieb Wilhelm Spickermann:


Die Schienenwege haben außerdem auch andere Wegenamen,
Geschwindigkeitsbegrenzungen, Einbahnregelungen, Ampeln,
Vorfahrtsregeln, Abbiegeverbote usw.

Ich führe mal Bielefeld als Gegenbeispiel an:
Straßenbahnen in der Mitte der Straße; Autos kommen z.T. außen dran
vorbei, viel häufiger aber auch nicht.
Ampeln: sind extra geschaltet für Straßenbahnen
Vorfahrtsregeln: weitgehend identisch (oder durch Ampeln entsprechend
geregelt)
Geschwindigkeitsbegrenzungen: keine Ahnung, ob die Straßenbahnen da
andere haben, aber zumindest wär das Blödsinn, da der Verkehrsfluss der
gleiche ist.

Nicht wirklich.
Strassenbahnen halten an Haltestellen, an Ampeln holen sie sich nicht 
selten die Grünphase

per Vorrangschaltung/Fernsteuerung - haben also ihren eigenen Verkehrsfluß.
Die Strassenbahn darf also durchaus (insbesondere an Haltestellen) den 
Verkehr hinter sich ausbremsen

und kann dann wieder schnell zum voranfließenden Verkehr aufschließen.
Und Schienen in der Fahrbahn sind für die gummibereiften Fahrzeuge ein 
gefährlicher Strassenbelag
der eine Geschwindigkeitsbegrenzung gerechtfertigt. Asphalt zwischen den 
Schienen stört ein

Schienenfahrzeug dagegen überhaupt nicht.
Es gibt also durchaus Gründe für unterschiedliche 
Geschwindigkeitensbegrenzungen.



Einbahnstraßen: identisch (eine Straßenbahn fährt nicht auf der Straße
gegen die Auto-Einbahn-Fahrtrichtung)
Auch das stimmt nicht, Gegenbeispiel wie Karlsruhe Schillerstr. und 
Halberstadt Gröperstr. fallen mir da aus dem Stegreif ein...

Abbiegeverbote: stimmt, die sind unterschiedlich, aber bei den
Straßenbahnen eher durch den Schienenverlauf bestimmt als durch Schilder.
Genau. Und Schienenverlauf und Fahrbahnverlauf stimmen in der Regel nur 
aus Platzgründen zufällig überein,

wo es geht versucht man es zu vermeiden.

Wegenamen: Da, wo die Straßenbahnen auf der Straße, mit in die Fahrbahn
eingelassenen Gleisen fährt, gibt's da glaub ich keine anderen Namen für
die Schienen als für die Straße darunter.

Es gibt durchaus Streckennamen wie Nordbahn, Südbahn etc.

Ich denke, dass die Schienen weiterhin außer in einfachen Fällen als
ganz getrennte Wege erfasst werden sollten. Wenn die Spuren des
Asphaltverkehrs wegen der Schienen für Radfahrer problematisch sind,
dann sollte das bei den Spuren als Gefahrenquelle völlig unabhängig
vermerkt werden.

Die Gefahrenquelle muss vermerkt werden; ob das reicht ist eine andere
Frage. Ob man die aber sinnvoll unabhängig oder sogar vor den Themen
Spurmapping und highway-area lösen kann, halte ich für fraglich.



Ich halte es für sehr sinnvoll da nahezu alle Gemeinsamkeiten von 
Strasse und Schienen
zufällig und örtlich begrenzt sind. Es passt nicht zusammen einerseits 
höchs detailiertes Micromapping zu machen
und andererseits völlig verschiedene Verkehrswegen zusammenzuwürfeln nur 
weil sie Abschnittsweise ein paar Gemeinsamkeiten haben.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] [OT] Geflashed ?

[Garry]

Am 15.06.2013 10:42, schrieb Markus:

Hallo Thomas,


kennt jemand ein deutsches Wort für geflashed?
(oder heisst das eigentlich geflasht?)



Firmware aktualisiert


danke, das hat geholfen.
(wobei aktualisiert beudetet, dass man eine aktuellere Version 
benutzt. ich meinte eher eine kommplett andere Firmware)

Aufspielen,Einspielen, drüberbügeln,
Stell doch mal die Frage in Mikrocontroller.net..

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] [OT] Geflashed ?

[Garry]

Am 14.06.2013 18:46, schrieb Markus:

Liebe Kollegen,

kennt jemand ein deutsches Wort für geflashed?
(oder heisst das eigentlich geflasht?)


In welchem Zusammenhang?

Bei EPROMS ist brennen ein üblicher Ausdruck (gewesen, sind ja etwas 
aus der Mode gekommen)...


Gruss
Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gepflegtes Gebüsch

[Garry]

Am 04.04.2013 17:03, schrieb Ronnie Soak:

Wurde nicht genau dafuer immer landcover=* propagiert?

Das hat fast keine hoehere Bedeutung neben was den Boden bedeckt, ist
also nur eine bessere Variante von mal es gruen im Renderer und dass ist
es ja wohl, wass man moechte wenn man sich Gedanken um den Bewuchs von
Parkplatztrennflächen macht. Da ist auch gar nichts schlimmes dabei, mit
landuse=* ist das systematisiert und auch nicht mehr mappen fuer den
Renderer (in der ursprünglichen Bedeutung von: ein falsches Tag benutzen
um das Rendererergebnis zu beeinflussen).
Für meinen Geschmack gibt es immer noch viel zu viel landuse=forest etc. 
Flächenbedeckungen in OSM,
Verkehrsflächen mit ihren zugehörigen Sicherheitzonen sind eben 
Verkehrsflächen (landuse=road o.ä.)und keine Forst/landwirschaftliche
Nutzflächen. Die darin eingeschloßenen Grünflächen sollten dann 
sinnvollerweise (und konflicktfrei) mit landcover getagt werden.
Je detailierter, um so besser - weglassen/vereinfachen für Anwendungen 
wo das stören würde kann man immer noch,,,


Damit umgeht man die Problematik, das landuse eher für grosse Gebiete
definiert ist und auch die leidliche natural=* Problematik im urbanen Raum.
(@Martin: fällt dir der Widerspruch unkultiviert - urban nicht im
eigenen Posting auf? Diese Büsche wachsen da wohl kaum wild, sondern
wurden sorgsam vom Besitzer angepflanzt.)
Kann man sicher auch nicht pauschalisieren. In so manchen Urbanen 
Bewuchs wird nur eingegriffen
wenn er den Verkehr gefährdert oder schon was passiert ist. Kommt ganz 
auf die Gegend an..


Ansonsten schliesse ich mich Franks Meining (fast) an. Bitte
Parkplatztrennflaechenbuesche erst dann mappen, wenn der Rest der Umgebung
einen aehnlichen Detailgrad bereits erreicht hat. Ansonsten lieber mit
Hausnummern und Turn-restrictions beschaeftigen.

OSM hat schon immer so funktioniert das jeder das mappt was er 
persönlich für wichtig hält.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] *:lanes und Straßenbahnschienen

[Garry]

Am 18.03.2013 08:27, schrieb Norbert Wenzel:


On 03/18/2013 01:03 AM, Garry wrote:

Die Straßenbahnstraße- und damit die über größere Abschnitte
einheitlichen Tags - gibt es nicht. Wo möglich/finazierbar gibt man den
Schienen einen eigenen Gleiskörper, [...]


Ich wiederhole mich aber ich sags nochmal ganz deutlich. Es geht hier 
nicht um den Fall der baulichen Trennung, der ist absolut klar 
definiert. Wenn es *keinen* eigenen Gleiskörper gibt und die Schienen 
sich räumlich absolut nicht von der Fahrbahn für alle anderen 
Fahrzeuge unterscheiden macht es imo in einer geographischen Datenbank 
keinen Sinn diese Wege zu trennen. Ganz besonders dann nicht, wenn die 
einen Wege (in dem Fall Schienen) aus irgendeinem Grund 
lagegenauestens eingezeichnet werden und die anderen Wege nur als 
näherungsweise Ideallinie erfasst werden.
Meine Aussage ist, dass es kein einheitliches Bündnis von 
Strassenbahngleisen und Strassen gibt im Gegesatz zu Gehwegen die fast 
immer neben denen Fahrbahnen
sehr häufig gleichförmig verlaufen. Kein eigener Gleiskörper heißt 
nicht dass die Schienen kein Eigenleben haben - Sie folgen eigenen 
Gesetzen.

Die reine geografische Nähe sehe ich nicht als Grund Ways zusammenzufassen.


Im Übrigen mag das mit den getrennten Gleiskörpern zwar auf viele 
Städte zutreffen, aber bei weitem nicht auf alle. Und wenn der Platz 
nicht da ist für eigene Spuren, dann teilt sich halt jeglicher Verkehr 
die eine Fahrbahn die vorhanden ist. Und da bin ich ganz stark der 
Meinung dass es, wenn es eben so ist, auch so abgebildet werden sollte.


Getrennte Gleiskörper kann man nicht an der Stadt festmachen. Der 
Verlauf der Gleise wird durch sehr viele Faktoren beeinflußt so dass 
längere gleichförmige Abschnitte ehr die Ausnahme sind.
Die Zusammenfassung bereits separat angelegter ways mit der Straße ist 
daher ein deutlicher Rückschritt mit verlust vieler Informationen die 
sich aus der Geometrie ergeben und in der zusammengelegten Form mühsam 
in Worte gefasst werden muss.
Dabei haben Schienen und Fahrbahn mehr oder weniger nur die gemeinsame 
Eigenschaften sich gegenseitig zu beeinträchtigen/beinflußen, sind in 
ihren vekehrstechnischen Eigenschaften ansonsten aber nahezu unabhängig..


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] *:lanes und Straßenbahnschienen

[Garry]

Am 16.03.2013 18:01, schrieb Martin Koppenhoefer:

Am 16. März 2013 11:02 schrieb Norbert Wenzel norbert.wenzel.li...@gmail.com:

Ich dachte dabei mehr daran, dass jemand die Ways räumlich trennt und zwei
Schienen zeichnet (für jede Fahrtrichtung eine) und diese Schienen dann mit
dem Luftbild so verortet, dass sie lagegenau sind, während die Straße als
ein Way für beide Richtungen in der Mitte der Schienen geschätzt wird.
Tatsächlich aber liegen die Schienen eben in der einen Straße und werden von
allen Fahrzeugen gleich benutzt.

Das ist kein althergebrachtes Railwaymapping und diese Mischung aus
lagegenauen Einzelways für Spezialisten (bzw. den Detailbereich
Schienenfahrzeuge) und geschätzten Sammelways macht die Daten, ohne die
zusätzliche Information des Luftbildes, unbrauchbar. Das war der Punkt der
mich stört.


Es ist halt immer nur ein Kompromiss, egal wie rum man es macht. Wenn
Du mehrere Schienenstränge und eine Straße zu einem Verkehrsweg
verquickst, und der dann auf einen way in OSM reduziert wird, dann
hast Du zwar bei manchen Anwendungen leichteres Spiel, aber dafür
gehen andere Dinge praktisch gar nicht mehr, oder nur sehr abstrakt,
z.B. Gegenstände, Hindernisse etc., die sich zwischen den beiden
Schienensträngen oder sonst auf der Straße befinden (Poller, Geländer,
Jersey-barrier etc., die nur punktuell vorhanden sind). Oder macht man
deren Nodes dann auch Teil des einen ways?

M.E. ist es in komplizierten Fällen besser (insb. einfacher zu
verstehen, zu mappen und zu überprüfen), einzelne Ways zu haben (d.h.
einen für die Straße, je einen pro Schienenstrang), und diese dann
ggf. per Fläche (so man Lust hat, alternativ auch per Relation, aber
die Fläche ist meist auch abgesehen von der Verkehrsweg-Betrachtung
ein Informationsgewinn) zusammenzufassen. Auch selbst wenn die
Zusammenfassung (noch) fehlt (d.h weder Fläche noch Relation)
funktioniert im Prinzip noch fast alles (falls man Angaben wie width
oder lanes für den highway hat könnte man sogar noch einigermaßen gut
abschätzen, ob die Schienen auf der Straße liegen oder daneben). Die
einzige Frage, wofür man in einem solchen Fall rechenintensives
Präprozessing machen müsste, ist, ob auf der Straße auch noch Schienen
liegen (IMHO eher eine nicht so besonders häufige Anwendung).

unbrauchbar finde ich eine maßlos übertriebene Einschätzung ;-)

Sehe ich auch so - geografische lagegenau Informationen sind für Mapper 
und Endnutzer einfacher und  praxisnäher als verschiedene Verkehrswege
abstrakt in einem Way zusammenzufassen und daraus eine eingeschränkte 
grafische Darstellung zu erstellen.


Die Straßenbahnstraße- und damit die über größere Abschnitte 
einheitlichen Tags - gibt es nicht. Wo möglich/finazierbar gibt man den 
Schienen einen eigenen Gleiskörper,
Mindestradien etc. setzen physikalische Grenzen wie gut Schienen einem 
Fahrbahnverlauf folgen können.
Haltestellen ergeben wieder andere Anforderungen. Teilweise setzt man 
diese gerne an den Fahrbahnrand um den
KFZ-Verkehr zur Straßenmitte hin vorbeiführen zu können, teilweise wird 
der KFZ-Verkehr auch mitten durch die Haltestelle

hindurchgeführt und im Falle einer haltenden Bahn per Ampel angehalten.
Beim heutigen Stand von OSM ist es so unabdingbar die exakte Position 
der Schienen als separate Ways festzuhalten.
Fahrbahn und Schienen haben keinerlei Zwangsverknüpfung. 
Schienenfahrzeuge können die Fahrbahn nicht nutzen und KFZ nicht die
Schienen. Sie laufen nur zufällig Abschnittsweise Deckungsgleich weil es 
die Platzverhältnisse (teilweise auch Kosten) nicht anderst zulassen
oder getrennt weil es z.B. fördergeldabhängige Zwangstrennungen der 
Verkehrswege gibt.
Wo ist das Problem jeweils Zusatztags zu verwenden dass der jeweilige 
Verkehrsweg Abschnittsweise durch andere Verkehrsmittel
beeinträchtigt wird? Gründe per Router Straßen zu vermeiden/zu 
bevorzugen die Schienen mit sich führen gibt es ohne weitere 
Differenzierung

in der Praxis ehr keine.

Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] *:lanes und Straßenbahnschienen

[Garry]

Am 16.03.2013 10:55, schrieb Norbert Wenzel:


Aber mein Punkt ist nicht, dass das Erfassen einer perfekten Straße 
mit allen Spuren einfacher wird, sondern dass das Erfassen einer 
einfachen Straße einfacher wird bzw bleibt. D.h. der einfache Mapper 
zeichnet eine Linie und macht daraus highway=xy und der versierte 
Mapper verfeinert dann Spurtags.
Andersrum kann ein Mapper zwar viele Linien zeichnen wo eine Spur, ein 
Radstreifen, ein Fußweg, etc. ist, aber je mehre Wege und Relationen 
du hast, umso weniger Mapper sind in der Lage das fehlerfrei zu 
mappen. Aber die Information, dass es sich bei den 5 Wegen um einen 
Verkehrsweg handelt fehlt und, schlimmer noch, kann von dem 
unbedarften Mapper nicht als fehlend erkannt werden. 
Und welche realenProbleme ergibt sich daraus? Ich kann zur selben Zeit 
nur einen Verkehrsweg nutzen. Dass es noch andere gibt kann ich auch
aus der geografischen Nähe erkennen ohne eine komplizierte 
Zusammenfassung generieren zu müssen die ich nur mit Informationsverlust 
wieder

für eine realitätsnahe Darstellung interpretieren kann.

Rechenintensive Operationen sind immer einfacher
(Moore'sches Gesetz) von allen zu bewerkstelligen, je mehr die Zeit
fortschreitet. Das kann im Prinzip schon jetzt jedes 2. Handy, in 10
Jahren können das auch die Kühlschränke ;-)


Das ist alles nett und halbwegs richtig aber unerheblich. Es nimmt 
zwar die Rechenleistung zu (und das auch nicht mehr in der 
Geschwindigkeit, dafür wird mehr parallelisiert, was bei OSM auch noch 
viel bringt), aber die Komplexität der notwendigen Algorithmen muss 
nicht nur von einer CPU sondern auch von dem Programmierer dahinter 
bewältigt werden. Und wenn ich als Programmierer die Wahl hab, mir 
einen aufgeräumten Routinggraphen bei einem kommerziellen Anbieter zu 
kaufen, oder mir einen komplizierten Datenwulst von OSM zu holen, der 
sich zwar schnell aktualisiert, aber Aufgrund des hochkomplexen 
Taggingsschemas praktisch laufend irgendwo fehlerhaft ist und ich mit 
irgendwelchen Heuristiken versuchen muss den zu reparieren, dann 
überleg ich mir recht schnell, ob mir die Aktualität der Daten wichtig 
genug ist und ob der Preis, denn ich für die kommerzielle Lösung zahl 
nicht deutlich günstiger ist, als die Programmierstunden die ich ins 
Feintuning meiner Heuristiken stecken muss.



Da gibt es dann immer noch den Zwischenweg von Halbprodukten.
Man kann ja auch eine Verkehrswegekarte erzeugen/anbieten die aus den 
Rohdaten erzeugt wird und deren Aktualisierung den technischen 
Möglichkeiten anpassen.
Für den Mapper sind einfache Editiermöglichkeiten und deren schnelle 
Darstellung wichtig um ein Erfolgserlebniss sicherzustellen.
Und jemand der nur Schienenwege editieren möchte soll es auch tun können 
ohne sich detailliert im Straßenmapping auskennen zu müssen und umgekehrt.



Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tags für die grüne Welle

[Garry]

Am 12.02.2013 21:15, schrieb Martin Schafran:


Die relativen Zeiten sind bis auf Rundungsfehler genau.
Die aus Fahrverhalten abgeleiteten absoluten Zeiten sind so genau, wie die
Schlafmützen im Anfahrverhalten, aber insgesamt erträglich und der SyncAlgo
ist anpassbar auf die Anzahl der Benutzer mit Durchschnittwerten usw. Es geht
auch  nicht darum auf Millimeter und Millisekunde zu fahren.


Was versprichst Du Dir für eine Anwendung?

Meine praktischen Versuche mit Ausmessen etc. und implemtieren der Daten 
in einen Bordcomputer lieferten
ein ehr ernüchterndes Ergebnis. Wenn man alleine Unterwegs ist 
funktioniert es ganz gut, mit anderen Verkehrsteilnehmern zusammen
hängt man von diesen zu sehr ab. Ein (zu)schneller vorne dran steht an 
der nächsten Ampel und bremst die nachfolgenden aus,
Zu langsame bremsen ebenfalls aus und dann gibt es noch die besonders 
sparsamen die selbst zwar noch genau die grüne Welle
schaffen, aber nachfolgende eben kaum noch. Dazu dann noch 
Geschwindigkeits- und Rotlicht-Sünder überwachende Ampelanlagen die nicht

selten das Tempo unter die grüne Welle Sollgeschwindigkeit drückt.
Ein Anwendung mit Grüne Welle in OSM sehe ich daher mehr in der Form 
Hier gibt es eine die den Verkehrsfluß verbessert und daher fürs
Routing gegenüber einer Parallel-Strecke aus der man mit einer Roten 
Welle den Durchgangsverkehr draussen haben möchte3 bevorzugt werden sollte



Gruss
Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] RFC zum Proposal winter_service

[Garry]

Am 27.11.2012 14:32, schrieb Martin Koppenhoefer:

Am 27. November 2012 12:51 schrieb Henning Scholland o...@aighes.de:

das hängt auch sehr von der Stadt ab (die entscheidet AFAIK, ob und
vor allem in welchem Umfang es Winterdienst gibt). In Berlin z.B.
erinnere ich mich, dass dort Wohnstraßen zumindest teilweise gar nicht
geräumt wurden (d.h. dass es dort nach einigen Tagen Kälte alles
vereist war), während die Hauptstraßen und die Zuwegungen zu
Krankenhäusern etc. immer schnell geräumt wurden.

Ja, das hängt auch sehr von der erwarteten Menge an Schnee an. Mein Eindruck
ist: Je schneesicherer, desto mehr wird geräumt.


ja, und von der Haushaltslage ;-)
.. und dem Verlauf des Winters...Gelegentlich sind auch mal die 
Streuvorräte erschöpft.
Von daher macht es wenig Sinn irgendwelche Streu- und Räumgewohnheiten 
zu taggen. Das ist zu grosser

Pflegeaufwand bei zu wenig Nutzen.


Besser fände ich eine Winterqualifizierung von Strassen in mehreren 
Stufen zu taggen, so etwa in den Stufen


0: Ganzjährig normalerweise keine Beeinrächtigung zu erwarten.
1: An wenigen Tagen im Jahr ist Winterdienst erforderlich
2: Während der Wintermonate häufiger beeinträchtigt / Winterdienst notwendig
3: Ausgedehnter Winterdienst erforderlich
4: Strasse wird regelmässig bei starkem Schneefall gesperrt (bis zu 
mehreren Tagen)

5: Regelmässige Wintersperre mehrere Wochen bis Monate
6. Nur wenige Wochen im Sommer nutzbar

Zusammen mit dem Wetterbericht und der Strassenkategorie kann man so 
sicher besser in konkreten Situationen

abschätzen was einem erwartet.

Garry


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Straßenbeleuchtung (lit=yes)

[Garry]

Am 15.11.2012 21:11, schrieb RalfGesellensetter:


Gibt es vielleicht dafür sogar Richtlinien, so dass
man die Beleuchtung als default voraussetzen kann,
wenn innerorts nicht explizit lit=no getaggt ist?
(ähnlich wie bei max_speed?).

Was meint ihr dazu? Schaut mal in euerer Umgebung.

Wie definierst Du den innerorts?
Und wie würdest Du die Nachtabschaltung berücksichtigen die sich in den 
letzen Jahren deutlich ausgebreitet hat?
Manche Dörfer werden ab 24Uhr (fast) komplett abgeschalten, mancherorts 
jede 2. Laterne...


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] [Openstreetbugs] AST der ... fehlt.

[Garry]

Am 09.10.2012 09:32, schrieb Michael Neumann:

Am 09.10.2012 07:53, schrieb Jimmy_K:

Servus,

ich glaube dies ist bis jetzt noch nirgends üblich. Solange es aber
kein ordentliches, zugelassenes Spurmapping-Modell gibt, finde ich
diese Variante sehr angenehm (hatte ich glaube im Forum vor ein paar
Wochen mal vorgeschlagen)
Der Einsatz von _link für Verbindungsfahrbahnen zwischen Strassen - 
also von der eigenen Abbiegefahrbahn(nicht Spur!)
bis zur Autobahnauffahrt ist schon seit vielen Jahren so in Verwendung. 
Esist durchaus hilfreich wenn man aus den Daten erkennen kann
ob man rechtwinklig abbiegen muss oder auf einer eigenen Fahrbahn mit 
eigener Verkehrsregelung auf eine andere Strasse überführt wird.

Also zumindest im Garmin fuehrt das dazu, dass er diese *_link als
Rampen interpretiert, das ergibt bei Autobahnen und autobahnaehnlichen
Strassen auch Sinn, da sind es naemlich Rampen. Bei normalen Strassen,

Was sind den bei Garmin Rampen?
Wenn ich leo.org trauen darf kann man das englische ramp u.a. auch mit 
Fahrtrasse übersetzen so dass
man den OSM_link durchaus mit ramp gleichsetzen kann. Die 
deutsche Rampe im Sinne einer ansteigenden
/abfallenden Auffahrt/Abfahrt wäre nur ein Teilaspekt bzw. eine 
Beschreibung der Bauausführung, weniger eine routingrelevante Information.



wo man mit *_link Abbiegespuren taggt, gibt das furchtbare Ansagen. Wenn
ich von der A-Strasse auf die B-Strasse abbiege, fahre ich halt nicht
ueber eine Rampe ...

Wenn das generell bei Auf/-Abfahrten von Autobahnen etc. verwendet 
werden sollte würde es auch nicht passen,

da fahre ich auch nicht zwangsläufig über eine Rampe.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] geplante und historische Objekte

[Garry]

Hallo,

Am 12.09.2012 23:09, schrieb Stephan Wolff:


Die weitaus meisten Nutzer wollen sicherlich eine Funktion nutzen und 
nicht am Bau mitwirken. 
Diese weitaus meisten Nutzer haben auch zahlreiche andere 
Informationsquellen um ihre benötigte Information zu bekommen.
Auch für Handwerker dürfte eine klare Unterscheidung zwischen in Bau 
befindlichen und fertigen Objekten wichtig sein.
Der Handwerker hat in erster Linie einen Termin und eine Adresse die er 
finden möchte.Mit einer leeren Acker- oder meinetwegen 
Construction-flächen

kann er nicht viel Anfangen wenn da längst zahlreiche Rohbauten stehen.




Ich würde im Bedarfsfall nie zu einem Krankenhaus oder Bahnhof fahren
nur weil es in einer Karte verzeichnet ist sondern die Karte dazu nutzen
die entsprechende Einrichtung aufzufinden nachdem ich aus
anderen Quellen die Information habe dass ich das dort vorfinde was ich
benötige.


Nicht jede OSM-Nutzung erfolgt vom Internet-PC. Auf Fernreise nutze 
ich die Suchfunktion im Outdoor-GPS. Andere Informationsquellen habe 
ich dort oft nicht.
Das bedeuted aber auch dass Du auf nicht aktuelle Daten zugreifst. Die 
Daten sind schon mindestens so alt wie Dein letzter Download, häufig 
auch schon viel älter - und
schlimmer, Du siehst dort auf Deinem Outodoor-GPS noch nichtmal wann 
der letzte Mapper dort die Daten aktualisiert hat. D.h. Du navigierst im 
Zweifelsfall auf sehr gut aussehenden Daten die aber schon längst 
überholt sind. Ich bevorzuge da mit alterstoleranten Daten zu arbeiten 
die mir sagen Zur Zeit der Erstellung der Daten war hier noch Acker und 
das Objekt nur geplant, aber wenn das jetzt fertig vor Dir steht dann 
ist das ein(e) ... und bist hier richtig ...



Oder fährst Du blindlings zum nächsten Bahnhof ohne Information
ob es dort einen für Dich geeigneten Zughalt gibt?


In Großstädten habe ich es so gemacht. Welche U- oder S-Bahn dort hält 
ist mir egal. Schlimmstenfalls muss ich einmal mehr umsteigen.
In Großstädten hast Du meist alle paar hundert Meter eine Haltestelle 
und bei Bauarbeiten Schienenersatzverkehr oder Hinweise auf 
Ausweichmöglichkeiten, da gibt es ehr

weniger Probleme mit falschen Daten im Taschenhirn vom Fleck zu kommen..

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] geplante und historische Objekte

[Garry]

Am 14.09.2012 00:30, schrieb Karl Eichwalder:


Eben.  Und wenn ich wo wandern will, will ich dort keine autobahnen
sehen, die dort vielleicht in 5 oder 10 jahren gebaut werden (oder auch
nicht).  Geplante oder historische objekte können meinetwegen in die
datenbank, aber nur mit solchen tags, dass die eine verwechslung mit
real-existierenden objekten ausschließen.
Historische Objekte (solche die es nicht mehr gibt) wirst Du dort nie 
mehr antreffen, aber die geplante Autobahn
kann durchaus schon zum Zeitpunkt Deiner Wanderung Deinen Weg 
durchkreuzen.  Oder die Information geben  Geniese diese Wanderung -  
bald wird sie in dieser Form nicht mehr möglich sein.



In Großstädten habe ich es so gemacht. Welche U- oder S-Bahn dort hält
ist mir egal. Schlimmstenfalls muss ich einmal mehr umsteigen.
Für manche OSM-Objekte reicht nicht die Auswertung des Haupttags
sondern man möchte über weitere Tags Unterklassen berücksichtigen.
Das hat aber nichts damit zu tun, dass ich immer zwischen nutzbaren
und geplanten bzw. ehemaligen Einrichtungen unterscheiden möchte.

Genau, das ist ein sehr gutes beispiel.
Hier geht hier beide vom Idealfall aus dass die OSM-Daten aktuell sind. 
An prominenten Orten mag das der Fall sein,

an weniger prominenten - den häufigeren Fällen - aber ehr die Ausnahme.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] geplante und historische Objekte

[Garry]

Am 12.09.2012 11:26, schrieb Martin Koppenhoefer

Korrekter Name und eine Zusatzinformation dahinter in Klammer sollte ein 
gangbarer Kompromiss sein um einerseits nicht die Anwendungen zu stören,
andererseits dem Nutzer wichtige Zusatzinformationen zu geben auf die er sonst 
keinen Zugriff hat.


Aber nicht im name-tag sondern auf Anwendungsseite. In den Name-Tag gehört der 
reine Name und kein Kompromiss.

Idealistisch gesehen hast Du recht. Realistisch gesehen ist es 
verwirrend wenn die Realität nicht mit dem übereinstimmt was die Karte 
hergibt und es keinen Hinweis gibt dass sich die Realität gerade 
verändert hat. OSM bietet zwar die Möglickeit aktuelle zu sein, aber es 
ist nur eine Möglichkeit!


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] geplante und historische Objekte

[Garry]

Am 10.09.2012 12:35, schrieb Stephan Wolff:

Moin!

Am 10.09.2012 10:10, schrieb smart...@gmx-topmail.de:
nein, gerade highway=construction ist ein Merkmal das besonders viele 
Menschen interresiert.


Da hatte ich mich missverständlich ausgedrückt. highway=construction 
ist etabliert und ich nutze es selbst auch. Mir ging es um die übrigen,

häufig falsch ausgewerteten Schreibweisen.

Ich persönlich bevorzuge bei Straßen dabei das Fertigstellungsdatum 
als Name anzugeben wie es auch in gedruckten Karten üblich ist:

highway=construction
construction=primary
name=open 2013
name:when finished=zukünftiger Name


Das name-Tag beschreibt den Namen, nicht einen gewünschten 
Kartentext. In vielen Anwendungen (Straßenverzeichnissen, Routern, 
...) führen solche Pseudonamen zu Fehlern.
Das geplante Eröffnungsdatum kann man in opening_date unterbringen. 
Wenn ein Kartenersteller es nützlich findet, kann er aus name und 
opening_date den Kartentext zusammensetzen.
Korrekter Name und eine Zusatzinformation dahinter in Klammer sollte ein 
gangbarer Kompromiss sein um einerseits nicht die Anwendungen zu stören,
andererseits dem Nutzer wichtige Zusatzinformationen zu geben auf die er 
sonst keinen Zugriff hat.
Hätte auch den Effekt dass bei abgelaufenem Datum ehr eine 
Statusüberprüfung und Korrektur stattfindet.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] geplante und historische Objekte

[Garry]

Am 09.09.2012 12:41, schrieb Stephan Wolff:


Oft werden diese Objekte in der Mapnikkarte dargestellt. Das dürfte
in den meisten Fällen vom betreffenden Mappern erwünscht sein oder
sogar seine Tagauswahl bestimmt haben. Wenn in der Karte nicht erkennbar
ist, ob ein Objekt in Bau oder aufgegeben ist, finde ich es ärgerlich.
In erster Linie möchte ein Anwender ein Objekt auffinden. Ob es aktuell 
in seiner vorgesehenen Funktion benutzt werden kann ist nur ein Teilaspekt.
Dem Handwerker, Lieferanten etc. ist es egal in welchem Zustand das 
Objekt ist, er möchte es schnellstmöglich finden!



Noch unangenehmer ist es, wenn der Router den Nutzer statt zum nächsten
Bahnhof, Krankenhaus, etc. zu einem Baufeld oder einer Ruine führt.
Siehst Du darin ernsthaft ein Problem? Ich würde im Bedarfsfall nie zu 
einem Krankenhaus oder Bahnhof fahren
nur weil es in einer Karte verzeichnet ist sondern die Karte dazu nutzen 
die entsprechende Einrichtung aufzufinden nachdem ich aus
anderen Quellen die Information habe dass ich das dort vorfinde was ich 
benötige. Oder fährst Du blindlings zum nächsten Bahnhof ohne Information
ob es dort einen für Dich geeigneten Zughalt gibt? Oder mit einer 
Unfallverletzung zum nächsten angezeigten Krankenhaus das vielleicht 
nur eine Suchtklinik-

oder Geburtenstation ist?

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Offene Schranken

[Garry]

Am 05.09.2012 23:04, schrieb Tirkon:

Sven Geggus li...@fuchsschwanzdomain.de wrote:


Da das nicht die einzige Schranke solchen Typs ist, könnte man ein Tag
barrier=normally_open_lift_gate nutzen.

-1

Wir mappen genausowenig für kaputte routing engines wie wir für den renderer
mappen!

Ich habe nur deshalb normally_open_lift_gate vorgeschlagen, weil es
genau dasjenige ist, was wir in der Wirklichkeit vorfinden. Du musst
ja der Anwendung wenigstens die Chance geben, über den Zustand
normally open informiert zu sein. Das access Tag regelt im
verbreiteten Gebrauch von OSM den Zugang bei geschlossener Schranke
und nicht bei offener. Denn dann gibt es keine durch die Schranke
verurachte Zugangsbeschränkung. Ist die Schranke also normally
closed, muss der Router sperren und ist deswegen nicht kaputt.
Lediglich sofern ein access angegeben wurde, soll er diesen auch bei
geschlossener Schranke zulassen. Dass die Router und Navis bei dem
Gebrauch von barrier=normally_open_lift_gate ohne weitere Eingriffe
richtig reagieren, ist somit nur ein schöner Nebeneffekt. Ich habe
hierfür korrekt und nicht bewusst falsch gemappt, um eine gewünschte
Reaktion zu erzwingen.



Eine Unterscheidung Ereignisgetriggerte- von 
Berechtigungsgetriggerte- Barriere hätte was...
Schranken an Mautstellen, Parkhäusern müsste man dabei unter 
Ereignisgetriggert (Ereignis = bezahlen) einordnen.


Ereignis:
Tunnelstörung/Unfall, 
Lawinengefahr/Wintersperre,Hochwasser,Nutzungsgebühr entrichtet,


Berechtigung:
Uhrzeit, Fahrzeugkategorie, Personenkategorie (Anlieger, Werkszugehöriger,)

Dabei sollte sich der key deutlich unterscheiden um bei 
Ereignis-Barrieren grundsätzlich von einer Durchfahrtmöglichkeit 
ausgehen zu können soweit

keine anderen, externen Informationen vorliegen.

Garry



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wildbruecke - Gruenbruecke

[Garry]

Am 06.08.2012 10:23, schrieb Volker Schmidt:

Hier sind die drei Gruenbruecken, dich ich jetzt provisorisch als ways
eingetragen habe:
http://www.openstreetmap.org/browse/way/174688679/,
174688678,
174688677
Bin auch mit dem way nicht gluecklich. area waere wohl angebrachter. Tunnel
passt nicht, da es sich wirklich um Brueckenkonstruktionen handelt. Die
Bruecken sind bewaldet und es fuehrt jeweils ein Forstweg drueber.

Eine vierte Gruenbruecke war bereits als normale Bruecke eingetragen:
38227647
  Darueber fuehrt auch eine Radroute, die auf Bing deutlich erkennbar ist.


Du solltest Dir die Mühe machen die Autobahn freizuschneiden, dann kommt 
das auch mit der Grünbrücke raus.
Wo eine Autobahntrasse ist passt landuse=forest nicht, mit Ausnahme der 
Grünbrücken.
Tunnel würde ich als angebracht sehen wenn man beim überqueren nicht 
wahrnimmt dass man über einen Verkehrsweg geführt wird



Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] LKW Mautinformationen

[Garry]

Am 23.07.2012 17:24, schrieb Michael Herbold:

Hallo,

erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback.

Wir haben heute früh schon angefangen, die Strecken entsprechend zu
taggen (siehe http://www.openstreetmap.org/user/synyx/edits).

Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die
Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut
und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy
für den Vorschlag).
Hier sollte man nur im Hinterkopf behalten dass die 12Tonnen Maut kein 
Naturgesetz ist.
Ein Herabstufung auf 7,5Tonnen wurde auch schon diskutiert, eine 
parallele PKW-Maut mit abweichendem
und/oder zeitabhängigem mautpflichtigem Strassennetzt wäre auch 
denkbar(Stichwort Verkehrslenkung).

Die Problematik mit den impliziten Informationen ist uns bewusst.
Prinzipiell haben wir kein Problem damit, dass mautpflichtige Autobahnen
mit toll:N3=yes getaggt werden. Wie Jimmy schrieb, schliesst das eine
das andere nicht aus. Wir haben bislang eben nur die mautfreien Teile
getaggt. Ist es denn überhaupt gewollt, alle anderen Stelle mit yes zu
taggen? Dies würde dazu führen, dass wirklich (fast) jedes Autobahnstück
in Deutschland den Tag erhalten würde.
Anderst wird es schwer zu unterscheiden ob ein Abschnitt nicht 
mautpflichtigt oder nur nicht getaggt ist.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zurueck in die Steinzeit

[Garry]

Am 20.07.2012 07:43, schrieb Manuel Reimer:

Garry GarryD2 at gmx.de writes:

Wenn in einer frühzeitig gut gemappten Stadt wie Karlsruhe wo einige OSM
Profis sitzen schon das Haupstrassennetz an vielen Stellen
zusammenbricht lässt das nicht erwarten dass es im Rest der Welt kaum
Probleme gibt...

Die gibt es. In meiner Region ist der Bot jetzt (endlich) drüber und ich kann
mich um den Wiederaufbau kümmern.
Schon klar dass in Gebieten die grösstenteils von einzelnen Mappern 
erfasst worden sind die zugestimmt haben
kaum Probleme auftreten. Jeder dichter das Gebiet besiedelt ist um so 
mehr Mapper hatten in der Regel ihre Finger im Spiel.
Und wenn da ein Nichtzustimmer fast jede (grössere ) Kreuz mal angefasst 
sowie Strassenkategorien verändert hat


Einige Wälder sind verschwunden (werde ich später gleich großflächig via Bing
neu machen) und eine naheliegende Stadt ist so gut wie komplett verschwunden.
Das war aber abzusehen. Den zuständigen Mapper hatte ich angeschrieben und
keinerlei Antwort erhalten.
Wälder sehe ich da ehr als schmückendes Beiwerk ohne nenneswerter 
funktionaler Relevanz.
Häufig sind die auch noch sehr grob aus Yahoo-Quellen erfasst so dass 
der Schaden sichj in Grenzen hält.
Unlogisch nach fast jedem Way-Segment wechselnde Strassenkategorien sind 
da schon erheblich funktionsstörender.


Gruss
Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Karte für Windkraftanlagen

[Garry]

Am 20.07.2012 08:00, schrieb Bernd Wurst:

Hallo.

Weil das Thema grade so schön aktuell ist:
Kennt jemand eine Karte in der mögliche Windkraft-Standorte berechnet
werden? Ich meine damit erstmal nur die banale Regelung, dass es 700
Meter zur nächsten Bebauung sein muss. Das ließe sich doch mit den
vorhandenen Tools machen, um alle Bebauungen 700 Umkreis einzufärben, oder?
Was willst Du den als Bebauung nehmen? Alle building = yes? Alle 
landuse=residential?
Wie berücksichtigst Du die Topologie? Ohne Höhenmodell fallen viel mehr 
mögliche Standorte raus die in der 3D-Realität

die 700m Abstand locker einhalten.

Gerald


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Karte für Windkraftanlagen

[Garry]

Am 20.07.2012 14:00, schrieb Peter Wendorff:
Falls sich jemand dran versuchen sollte: alle addr:housenumber würde 
ich mitrechnen, da nur dann Adressen an Häusern sind, wenn da auch 
Bebauung ist.


Gerade in den für  Windkraft interessanten Gebieten würde ich noch keine 
allzu hohe Hausnummertaggingquote erwarten.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Karte für Windkraftanlagen

[Garry]

Am 20.07.2012 13:46, schrieb Bernd Wurst:

Hallo.

Am 20.07.2012 13:23, schrieb Garry:

Was willst Du den als Bebauung nehmen? Alle building = yes? Alle
landuse=residential?

Genau die beiden wären mir jetzt auch spontan eingefallen. Für die
Briefkästen gab es ja mal eine Reichweiten-Auswertung mit Kreisen um die
Briefkästen. Wenn man jetzt solche Kreise um jeden Node eines der von
dir genannten Objekte zieht, hat man im Prinzip schon was brauchbares. :)
Dann sollte man noch Einzelgebäude bzw. buildings herausfiltern, sonst 
verhindert jedes kleine Bauwerk, Scheune,

Schutzhütte... einen Windpark im 700m-Umkreis...

Wie berücksichtigst Du die Topologie? Ohne Höhenmodell fallen viel mehr
mögliche Standorte raus die in der 3D-Realität
die 700m Abstand locker einhalten.

Es ist nicht so dass man eine Karte mit den von mir genannten 700 Metern
erstellt und hinten purzeln dann fertige Windkraft-Standorte heraus. Da
erzählst du mir nicht wirklich neues. Aber das ist das Kriterium, das
man am einfachsten neutral und sachlich bewerten kann. Und eines das man
mit OSM-Daten berechnen könnte.

Wer das wirklich verfolgen will, kann das ja noch mit SRTM-Daten
verrechnen (im Umkreis von X Kilometern dürfen maximal Y Prozent der
Fläche höher liegen als der Standort oder sowas) und bekommt dann ein
besseres Ergebnis. Aber das ist eine völlig andere Geschichte.

Hier in der Gegend einigt man sich übrigens gerade auf 800m zu 
Industriebebauung und 1000m Abstand zur

Wohnbebauung einhalten zu wollen.

Gruss
Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zurueck in die Steinzeit

[Garry]

Am 20.07.2012 15:19, schrieb Walter Nordmann:

Joerg Fischer-2 wrote


Wie bitte? Die Router, die Garminkarten, OsmAnd usw, die alle mit ein paar
Tagen Verzögerung diesen Unsinn als Karte installieren? Das stört nicht?


Die machen das doch nicht von selber; da sitzen immer - noch - Menschen
daneben, die entscheiden, dass zum passenden Zeitpunkt die Basisdaten für
ihre Software aktualisiert wird.
Viele Anbieter haben diesen Vorgang erst einmal etwas zurückgestellt - wenn
sie es nicht verpennt haben wie diese jetzt fast bankrotte Firma in Polen.


Super, und das jetzt mitten in der Hauptreisezeit... :-(
Aktuelle Karten sind nicht verfügbar/nutzbar weil sie entweder nicht 
aktualisiert werden oder

unbrauchbar weil der Bot zu viele Lücken reingerissen hat.

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zurueck in die Steinzeit

[Garry]

Am 19.07.2012 13:41, schrieb Sven Geggus:

Zumindest Ways without tags gibt es im OSM Inspector. Standalone Nodes
without tags gibt es anscheinend nicht. Vielleicht kann Jochen das ja
einbauen.




Gibt das keine Probleme mit der Lizenz? Der Verlauf ist ja dann nicht 
mehr zwischen einer Kopie und einer Neuerstellung unterscheidbar?


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zurueck in die Steinzeit

[Garry]

Am 19.07.2012 11:32, schrieb Michael Kugelmann:

Am 19.07.2012 10:35, kommentierte Bernd Wurst:

Von selbst wird es nicht besser. Wenn du nicht mit hilfst, wird es
jemand anders machen müssen. Aber es wird jemand machen. Es wird besser.
Recht bald sogar, würde ich vermuten.

+1

Was soll ich von solchen Weicheiern [1] halten? Als ich Anfang 2007 
angefangen habe war fast ganz Deutschland eine weiße Fläche! Wie hätte 
ich die Zuversicht haben sollen, dass das etwas etwas wird? Und 
trotzdem habe ich angefangen und es ist etwas gutes geworden.
Seit doch mal realitisch bzw. etwas ehrlich: in Deutschland war es uns 
doch fast schon langweilig, weil es (fast) nichts mehr zu tun gab. Wir 
haben doch schon angefangen, Gulideckel zu mappen weil es sonst nicht 
mehr viel gefehlt hatte. Also nicht rumjammern sondern remappen. Hoch 
den Ars## aus dem Sessel (bzw. in den Stuhl wenn via Luftbilder) und 
remappen statt nur faul rumzujammern: das Jammern nerft viele mehr als 
ein paar neu zu erfassende Daten...
Nur ist eine weiße Fläche zu bearbeiten wesentlich motivierender - man 
sieht was man getan hat - als in einer Vollerfassung nach vielen 
kleinen Fehlern zu suchen die
man in der Kartendarstellung kaum sieht, fürs routing aber z.B. 
tödlich sind.


Für den Aufwand den man jetzt hat könnte man OSM auch gleich neu 
aufsetzen und die Erfahrungen vergangener Jahre nutzen um strengere 
Regeln zu definieren die ein konsistenteres Datenmodell schaffen.
Ich betrachte es nach wie vor als eine Art von Nötigung der Umstellung 
zustimmen zu müssen damit die bisher geleistete Arbeit nicht verloren 
geht und dann nenoch ein großes
Arbeitspaket vorgesetzt bekommt um die Daten wieder auf das bisher 
erreichte Niveau zu heben.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zurueck in die Steinzeit

[Garry]

Am 19.07.2012 18:03, schrieb Jimmy_K:

Am 19.07.2012 14:31, schrieb Garry:

Für den Aufwand den man jetzt hat könnte man OSM auch gleich neu
aufsetzen und die Erfahrungen vergangener Jahre nutzen um strengere
Regeln zu definieren die ein konsistenteres Datenmodell schaffen.


Das kann man aber nur erreichen, in dem man die Community weniger
mitreden lässt, was aber gleichzeitig ein Kritikpunkt ist?!


Wenn man beide Optionen parallel laufen lässt kann jeder selbst entscheiden.
Mit dem jetztigen Zustand kann jedenfalls kaum jemand zufrieden sein.
Da hat OSM jahrelang bewiesen dass es entgegen aller externen 
Provezeiungen relativ unempfindlich gegen Vandalismus ist

und dann setzt es sich selber ausser Gefecht..

Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zurueck in die Steinzeit

[Garry]

Am 19.07.2012 14:16, schrieb Sven Geggus:

Garry garr...@gmx.de wrote:


Gibt das keine Probleme mit der Lizenz? Der Verlauf ist ja dann nicht
mehr zwischen einer Kopie und einer Neuerstellung unterscheidbar?

Warum sollte das Probleme geben? Der Redaction Bot hinterläßt Wege ohne Tag
und ungetaggte Nodes ohne Verbindung. Beide wurden mal (als Teil eines
Weges, den ein Nichtzustimmer erstellt hat) eingefügt. Wo ist also das
Problem, wenn man diese nun mit Hilfe der Inspector view findet und neu
erstellt?



Weil es im Ergebnis(!) dann ja (sehr häufig)auch nichts anderes mehr ist 
als die alte OSM-Karte darunterzulegen und abzuzeichen.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zurueck in die Steinzeit

[Garry]

Am 19.07.2012 23:48, schrieb Michael Kugelmann:

Am 19.07.2012 14:31, schrieb Garry:
Nur ist eine weiße Fläche zu bearbeiten wesentlich motivierender - 
man sieht was man getan hat - als in einer Vollerfassung nach 
vielen kleinen Fehlern zu suchen die man in der Kartendarstellung 
kaum sieht, fürs routing aber z.B. tödlich sind.
Bestreite ich nicht. Aber wir haben Tools, welche derartige Fehler 
finden.
Welches Tool zeigt den Beispielsweise an dass an einer Kreuzung die 
Fahrspur zum rechtsabiegen verloren gegangen ist?


Für den Aufwand den man jetzt hat könnte man OSM auch gleich neu 
aufsetzen 
Das halte ich für eine deutliche Übertreibung. Bei mir ist so viel 
nicht kaputt weil _vorher_ sinnvoll remappt wurde [1]! BTW: Basis dazu 
war OSMI.  Oder ich lasse die Daten
Wenn in einer frühzeitig gut gemappten Stadt wie Karlsruhe wo einige OSM 
Profis sitzen schon das Haupstrassennetz an vielen Stellen 
zusammenbricht lässt das nicht erwarten dass es im Rest der Welt kaum 
Probleme gibt...
(von einem kleinen Dorf) bewusst komplett löschen um sie hinterher neu 
zu mappen (weil die alten Daten sowieso veraltet und nicht gut gemappt 
waren, stammen komplett von einem Nicht-Zustimmer).
Ein kleines Dorf sehe ich auch nicht als Problem, da kommt man schon 
irgendwie durch - gibt ja immer noch Papierkarten.
Aber in einer Stadt kann so eine falsch gemappte Kreuzung schon zu 
grösseren Problemen führen.


und die Erfahrungen vergangener Jahre nutzen um strengere Regeln zu 
definieren die ein konsistenteres Datenmodell schaffen.
Ich wäre eigentlich auch ein Freund von strengeren Regeln um die 
Verwendbarkeit der Daten z.B. für Routing zu vereinfachen. Aber ich 
muss anerkennen, dass dies den Grundsätzen von OSM (WIKI-Prinzip) 
widerspricht und deswegen nicht mehrheitsfähig ist. Also beuge ich 
mich der Mehrheit.
Woraus erkennst Du diese Mehrheit? Ich glaube nicht dass ich der 
einzigste bin der es in etwa so sieht: Entweder beugst Du Dich dem 
Lizenzwechsel mit allen
Konsequenzen oder OSM und die ganze Zeit die Du schon reingesteckt hast 
ist für Dich Geschichte...


Gruss
Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

[Garry]

Am 11.07.2012 18:01, schrieb Christian Müller:


Woher weißt du eigentlich bei aneinandergereihten Gebäuden, ob die 
Wand an der Stoßstelle wirklich nur eine Wand ist? In aller Regel 
gibt es diese Wand in der Tat zweimal.


In diesem Fall liegen sie dann aber auch nebeneinander ;-)  Ich weiß, 
dass das (noch) Haarspalterei ist - aber mit der Verfügbarkeit der 
letzten Bing-Bilder sind ja nun mittlerweile auch die Gulli-Deckel 
sichtbar geworden..


Selbst wenn Du auf Ameisengrösse auflösen kannst wirst Du nicht erkennen 
ob z.B. ein Doppelhaus aus zwei aneinandergebauten Einzelhäusern besteht 
oder als Gesamtgebäude mit einer durchgehenden Trennwand gebaut ist. 
Sowas ist häufig nur mit Bauplan aufzulösen.
Die Ausführung der Trennung halte ich jetzt aber nicht gerade für 
OSM-relevant. Wichtige Information ist dass es sich um zwei getrennt 
genutzte Gebäude(teile) mit in der Regel

wohl eigener Hausnummer handelt.

Garry





___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned

[Garry]

Am 14.05.2012 21:35, schrieb Alexander Matheisen:


+1

Der Rechtsstaus dürfte für praktisch keinen Anwender von Bedeutung sein. Und
Das ist für jeden relevant der sich auf dem Gelände aufhält. Bei 
Stillgelegt ist es nach wie vor ein Bahngelände und das 
Eisenbahngesetz greift.
z.B. 
http://www.jusline.at/47._Betreten_hief%C3%BCr_nicht_bestimmter_Stellen_von_Eisenbahnanlagen_EisBG.html


Bei einer entwidmeten Strecke ist es dagegen kein Bahngelände mehr im 
Sinne des Eisenbahngesetz so dass dieses nich mehr greift.




Leute, für die das wichtig ist, würden dafür sowieso nicht OSM benutzen.

Wenn man mit schwammigen Tags diese Unterscheidungsmöglichkeit in OSM 
unterbindet haben sie erst gar keine Möglichkeit OSM dafür zu nutzen.


Garry



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de