[Talk-de] Kandidatur für den OSMF-Vorstand

[Tobias Knerr]

Hallo zusammen,

morgen beginnen die diesjährigen Vorstandswahlen¹ der OSM Foundation,
und wie einige von euch schon wissen, habe mich entschieden, noch einmal
anzutreten.

Ich bin ja jetzt seit zwei Jahren Vorstandsmitglied. Nicht alle Ideen,
die ich bei meiner letzten Wahl hatte, waren im Vorstand mehrheitsfähig,
aber einiges konnte ich doch umsetzen – etwa die Mehrheit der Punkte,
die ich in meinem damaligen Wahlprogramm² aufgeführt hatte.

Nichtsdestotrotz ist das eigentlich eine Daueraufgabe. Manche Probleme
sind wir angegangen, dafür kommen neue Herausforderungen auf uns zu, z.B.:

* Die zunehmende Firmenpräsenz in den Working Groups der OSMF.
* Die Risiken, wenn Arbeit in der Foundation zunehmend durch bezahlte
Kräfte erledigt wird.
* Der wachsende Anteil bezahlten und organisierten Mappings an den
Beiträgen zu OSM, und die Nutzung von Werkzeugen wie RapiD.
* Die immer noch unzureichende Durchsetzung unserer Standards für
Namensnennung, gerade bei prominenten Datennutzern wie Facebook.

Dafür zu sorgen, dass die Interessen der freiwilligen Mapper bei den
Veränderungen in OSM nicht unter die Räder kommen, wird also weiter ein
Schwerpunkt für mich sein. Allerdings will ich mich nicht darauf
beschränken. Mir liegt auch am Herzen, den Innovationsstau bei der
zentralen Infrastruktur von OSM zu lösen: Dass etwa die API seit über
einem Jahrzehnt keine großen Updates mehr erlebt hat, die OSM-Hauptseite
nur einen Bruchteil der Möglichkeiten von OSM zeigt, die Leute von Forum
und Mailingliste in proprietäre soziale Netzwerke abwandern oder dass
wir lange gewünschten Website-Features in den letzten Jahren kaum einen
Schritt näher gekommen sind. Da die OSMF diese Dienste betreibt, sollten
wir auch dafür sorgen, dass sie mit dem Rest des OSM-Universums Schritt
halten.

Die offizielle Sammlung³ der Antworten und Positionen aller Kandidaten
wurde inzwischen veröffentlicht, meine findet ihr hier:
https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos/Tobias_Knerr

Dort äußere ich mich sehr viel ausführlicher (auf Englisch, aber es
überlebt eine automatische Übersetzung einigermaßen heil :)). Ich stehe
euch aber auch hier auf der Liste gern Rede und Antwort!

Viele Grüße,
Tobias


PS: Ich möchte euch bei dieser Gelegenheit die zusammen mit den Wahlen
stattfindenden Abstimmungen über eine Ausweitung der Beitragsbefreiung
für aktive Mapper auf die normale Mitgliedschaft sowie die beiden
Vorschläge zum Schutz vor Übernahmeversuchen (Mindestvoraussetzungen für
die Mitgliedschaft, Verbot von durch den Arbeitgeber gesteuerter
Stimmabgabe) ans Herz legen. Die letzten beiden sind zwar noch keine
konkreten Änderungen, sondern nur eine Aufforderung an den Vorstand,
entsprechende Vorschläge zu erarbeiten, aber ein klares Ergebnis würde
dennoch ein wichtiges Signal senden.


¹ https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board
²
https://wiki.openstreetmap.org/wiki/User:De:Tordanik/2018_OSMF_board_elections_manifesto
³
https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos

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

Re: [Talk-de] Massenweise Entfernung von oneway=no

[Tobias Knerr]

On 22.05.20 15:15, Volker Schmidt wrote:
> Ich persoenlich setze routinemaessig oneway=no um anzuzeigen, dass ich
> geprueft habe, dass die Strasse keine Einbahnstrasse ist. In Verbindung mit
> dem Aenderungsdatum ist das nuetzlich in Gegenden, wo Strassenrichtungen
> haeufig von den Behoerden geaendert werden.

Meiner Meinung nach geht die Idee, Default-Werte explizit zu setzen, zu
Lasten der Übersichtlichkeit. Die logische Konsequenz wären ja
maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no
access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. Und
wie mappe ich z.B., dass zwischen zwei Straßen keine Abbiegebeschränkung
besteht – lege ich dann jeweils eine Relation mit restriction=allowed
an? Wie mappe ich, dass an einer Stelle kein Gebäude steht, in einem
Gebäude kein weiterer Laden mehr ist, auf dem Gehsteig kein weiterer
Abfalleimer steht, ...?

Vielleicht etwas übertrieben, aber worauf ich hinaus will: Die
Abwesenheit von einem Objekt oder Attribut sollte normalerweise nicht
erfasst werden – nur in Ausnahmefällen dort, wo sie überraschend ist
(weil es kürzlich anders war, die Luftbilder veraltet sind, es bei den
Straßen drumherum anders ist, ...) . Wenn in deiner Gegend bestimmte
Arten von Straßen oft "umgedreht" werden, kann das durchaus so ein Fall
sein.

Aber auch dann wäre evtl. etwas nach Art von last_check:oneway=
besser, denn das funktioniert öfter als nur bei der ersten Überprüfung
und es beeinträchtigt als klar erkennbares Qualitätssicherungs-Tag die
Übersicht weniger.

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

[Talk-de] Dienste für virtuelle OSM-Stammtische

[Tobias Knerr]

Viele OSM-Stammtische finden derzeit wegen der Corona-Pandemie nicht
statt. Es gibt aber Alternativen! Einige Gruppen haben schon erste
virtuelle Treffen erfolgreich durchgeführt.

Wer noch auf der Suche nach geeigneten Diensten dafür ist, findet hier
ein paar von uns getestete Vorschläge:

* BigBlueButton: Der OSMF-Vorstand benutzt seit April eine gemietete
Instanz der freien Videochat-Software BigBlueButton für
Vorstandstreffen. Diese steht auch der OSM-Community zur Verfügung. Um
sie zu nutzen, muss einer der Teilnehmer des Treffens sich unter
https://osmvideo.cloud68.co/user/signup registrieren. Nach der Anmeldung
findet man dann einen Link zu seinem eigenen "Home Room", den man mit
anderen Nutzern teilen kann.

http://imagico.de/files/bbb1.png

* Jitsi: Die derzeit wohl bekannteste freie Lösung für Videochats. Es
gibt eine ganze Reihe frei nutzbarer Jitsi-Server im Netz, eine Liste
findet sich unter https://pads.ccc.de/ep/pad/view/jitsiliste/latest.  Um
ein Jitsi-Treffen zu starten, wählt man dafür einen eindeutigen Namen
und teilt diesen mit allen Teilnehmern.

http://imagico.de/files/jitsi1.png

* Mumble: Wer auf das Video-Bild verzichten kann oder möchte findet mit
Mumble eine deutlich schmalbandigere Lösung, die aber im Gegensatz zu
den übrigen Möglichkeiten die Installation einer eigenen Software
erfordert.  Wer schon mal bei einem FOSSGIS- oder OSMF-Vorstandstreffen
zugehört hat, kennt dies bereits.  Eine Anleitung findet sich unter
http://podcast.openstreetmap.de/mitmachen/.  Der FOSSGIS-Mumble-Server
kann von allen in der OSM-Community verwendet werden, daneben gibt es
als Ausweich-Möglichkeit auch noch einen Mumble-Server von HOT:
https://wiki.osm.org/Mumble

Egal für welche technische Lösung ihr euch entscheidet - am Anfang mag
dies erst einmal ungewohnt erscheinen.  Aber ausprobieren lohnt sich!
Viele, die jetzt in Zeiten der Corona-Pandemie zum ersten Mal virtuelle
Treffen ausprobiert haben sind positiv überrascht, wie kommunikativ so
was sein kann.  Also: keine Scheu beim ausprobieren und teilt Eure
Erfahrungen in der OSM-Community.

(Danke an Christoph für die Hilfe beim Testen und Texten!)

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

Re: [Talk-de] Datenqualität open data NRW und OSM

[Tobias Knerr]

On 06.03.20 12:42, Florian Lohoff wrote:
> On Fri, Mar 06, 2020 at 11:30:53AM +0100, Otto Dassau wrote:
>> * Könnten/Dürften die Daten NRW genutzt werden, um die OSM Daten
>>   flächendeckend z.B. für NRW zu optimieren? 
> 
> Am Ende nein. Gucken darfst du, aber übernehmen nicht.

Vor ein paar Tagen wurde im Forum die Neuigkeit verbreitet, dass die
"Geobasisdaten NRW" jetzt unter der Datenlizenz Deutschland Zero stehen,
die meines Wissens mit OSM kompatibel ist:
https://forum.openstreetmap.org/viewtopic.php?pid=779174#p779174

Ich bin mir jetzt nicht sicher, ob da die hier diskutierten Daten auch
darunter fallen?

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

Re: [Talk-de] Entfernen des "WikiProject"-Präfixes

[Tobias Knerr]

On 18.08.19 18:44, dcapillae wrote:
> I would like to change the name of the wiki pages related to the Germany
> mapping project to remove the "Wikiproject" prefix according to the
> pages name conventions [1].

Sure, I'd be happy to see the pages renamed. Thanks for all the time you
spend on wiki maintenance!

Für die deutschsprachigen Mitleser: Daniel möchte gern die Seite
"WikiProject Germany" nach "Germany" verschieben, wie er es schon bei
diversen anderen Ländern gemacht hat.

Aus meiner Sicht ist das sinnvoll, da Wikiseiten zu Städten,
Bundesländern etc. schon heute nur den jeweiligen Namen als Seitentitel
haben und die Begrifflichkeit "WikiProject" ein Relikt aus Urzeiten ist,
die heute den durchschnittlichen Leser eher verwirren dürfte.

Bestehende Links werden weiterhin funktionieren, da Weiterleitungen
eingerichtet werden. Daniel verspricht, darauf zu achten, dass alles
weiterhin korrekt funktioniert.

> I could make the necessary changes, and also add the "Country" template
> [9] to the Germany project page, although this change is optional.

I probably wouldn't add the "Country" template. It promises more than
the current page can keep. The page is quite stale at this point, so a
visitor isn't going to find "national events, ongoing projects" or
things like that, unfortunately.

Hier geht es darum, ob die Vorlage https://wiki.osm.org/Template:Country
auf der Wikiseite eingebaut werden soll.

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

Re: [Talk-de] Besorgt über den iD-Editor

[Tobias Knerr]

On 29.03.19 15:32, Frederik Ramm wrote:
> Zugleich
> äussern sich die Entwickler gern auch mal geringschätzend über das Wiki
> oder Tagging-Diskussionen und nehmen sich eben das Privileg heraus, neue
> Features einfach einzubauen, die sie gut finden

Das scheint die herrschende Einstellung zu sein, ja. Zitat Bryan Housel
frisch von letzter Woche: "I basically just disregard everything on the
tagging mailing list and the OSM wiki."

https://github.com/openstreetmap/iD/issues/5835#issuecomment-477696136

Das ist natürlich nicht die erste entsprechende Äußerung und der Link
wirft auch sonst kein schönes Licht auf die iD-Entwicklung: Bryan äußert
sich negativ über die Community, vertritt kontroverse Taggingansichten,
die er via iD durchsetzen will, und sperrt beim Aufkommen von Kritik die
Github-Diskussion für Nichtentwickler. Letztlich geht es auch hier
wieder nur um eine Kleinigkeit, aber das Gesamtbild aus diversen solchen
Vorfällen macht auch mir inzwischen Sorgen.

Dass das alles mittelfristig ein Problem fürs Projekt werden kann, ist
aus meiner Sicht ziemlich offensichtlich. Bei der Frage nach Lösungen
würde ich mich im Großen und Ganzen Michael anschließen. Die wesentliche
Hürde für eine (über die Kritik an Einzelentscheidungen und eventuelle
Eskalation via Abstimmungen und DWG hinausgehende) Reaktion ist m.E. das
Fehlen plausibler Alternativen. Wenn sich jemand fände, der eine auf
Community-Konsens zurechtgestutzte Version der Tagging-Vorlagen von iD
pflegt, sähe das schon ganz anders aus.

Viele Grüße,
Tobias

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

Re: [Talk-de] Fwd: Adressmapping auf Building-Relationen oder Outline

[Tobias Knerr]

On 10.03.19 19:20, Tom Pfeifer wrote:
> Eigenschaften, die das ganze Gebäude betreffen, sollten daher auf dem
> Gebäudeumring liegen, der auch ohne 3D-Mapping da wäre. Also auch die
> Adresse.

Ja, solche Relationen werten normalerweise nur 3D-Renderer aus. Die
Informationen, die auch andere Anwendungen brauchen, sind daher am
Umriss besser aufgehoben.

Als "belastbare Doku" würde ich "Simple 3D Buildings" heranziehen, den
Taggingstandard fürs 3D-Mapping: "Building attributes (e.g., address,
name, overall height, operator, etc.) must be tagged on the building
outline."¹

In diesem Beispiel ist die Relation übrigens auch für 3D eigentlich
nicht notwendig: Sämtliche Gebäudeteile liegen innerhalb des Umrisses
und es gibt keine Überlappungen/Mehrdeutigkeiten mit anderen Gebäuden.

Tobias

¹ https://wiki.osm.org/Simple_3D_buildings#Building_outlines

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

Re: [Talk-de] Experimentelles Öffnungszeiten-Webtool

[Tobias Knerr]

On 19.02.19 09:24, Stefan Keller wrote:
> Fernziel ist u.a., den Tag "opening_hours:url" zu verwenden, um den
> dort verlinkten Webinhalt in opening_hours zu wandeln.

Finde ich eine spannende Vision, denn so könnten Änderungen bei den
Öffnungszeiten viel schneller entdeckt werden. Für OSM ist zumindest in
Europa die größte Herausforderung ja zunehmend das Aktualisieren (statt
Ersterfassen) von Daten.

> Feedback willkommen - hier oder als Issue im Repository!

Meine einfachen bis mittelschwierigen Tests haben beide
Implementierungen anstandslos geschluckt!

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

[Talk-de] Kandidatur für den OSMF-Vorstand

[Tobias Knerr]

Hallo zusammen,

ich habe dieses Wochenende erfahren, dass Peda (Peter Barth) aus dem
Vorstand der OSMF ausscheiden und nicht erneut kandidieren wird. Peda
hat aus meiner Sicht einiges erreicht, was das reibungslose
Funktionieren unseres Projekts, die Transparenz der Arbeit des Boards
(z.B. durch öffentliche Vorstandssitzungen und die Veröffentlichung von
Abstimmungsergebnissen), das Bekenntnis zu freier Software und offenen
Kommunikationsplattformen und nicht zuletzt die Vertretung der
Interessen von ehrenamtlichen Mappern angeht. Ich glaube, dass Peda auch
deshalb wertvoll für die Community war, weil er derzeit als einziges
Boardmitglied keiner Firma oder humanitären Organisation mit
geschäftlichen Interessen an OSM angehört. Für seine gute Arbeit möchte
ich ihm hiermit herzlich danken!

Da es mir wichtig ist, dass diese gute Arbeit auch in den kommenden
Jahren fortgeführt werden kann, werde ich mich für den Vorstand der OSMF
zur Wahl stellen. Ich bin in der OSMF seit 2009 Mitglied und auch in
einigen OSMF-Arbeitsgruppen gelegentlich aktiv. Vor allem aber bin ich
seit langem als Mapper und inzwischen auch als Hobby-Entwickler in der
OSM-Community zu Gange. Auch aus dem Forum oder Wiki dürften mich einige
von euch schon kennen.

Ausführlichere Infos liefere ich später noch nach, auch über die
offiziellen Kanäle: Es soll auch dieses Mal wieder Wahlprogramme sowie
die Möglichkeit zum Einreichen von Fragen an die Kandidaten geben. Da
die Vorstandswahl im deutschen Forum dank der fleißigen
Mitgliederwerbung von Nakaner aber bereits Gesprächsthema ist, wollte
ich den sprichwörtlichen Hut schon einmal in den Ring werfen. Und
natürlich dürft ihr mich auch jetzt schon mit Vorschlägen, Kritik und
Fragen löchern!

Viele Grüße,
Tobias

( Crossposting von https://forum.osm.org/viewtopic.php?id=64360 )

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

Re: [Talk-de] Relation für Gebäude

[Tobias Knerr]

Am 18.09.2018, 16:21, schrieb Benedikt Bastin:
> Gibt es abseits des Zugehörigkeitsproblems noch weitere Sachen, die gegen 
> eine solche Relation sprechen?

Im Allgemeinen tendiert der Konsens in der Community dahin, Relationen
nur dort zu verwenden, wo sie notwendig sind.

Aus diesem Grund ist auch in Simple Indoor Tagging anders als bei dem
von dir verlinkten älteren Indoor-Proposal vorgesehen, dass der
Gebäudeumriss + level-Tags an den enthaltenen Elementen für die
Zuordnung zum Gebäude ausreichen soll.

Einen sehr ähnlich gelagerten Fall gibt es übrigens bei
3D-Gebäudemapping: Auch dort ist die Nutzung von Relationen zur
Zuordnung von Gebäudeteilen zum Gesamtgebäude in den allermeisten Fällen
optional¹ und unüblich – die weit überwiegende Mehrheit der 3D-Gebäude
verzichtet darauf.

Wenn du dennoch eine Relation verwenden willst, dann ist die
building-Relation die gängigste Wahl. Ich würde aber wie gesagt eher
davon abraten. Auch eine geringere Fehleranfälligkeit von Relationen
halte ich in der Praxis nämlich nicht für gegeben: Es ist einfach zu
schnell passiert, dass ein Mapper z.B. ein neues Objekt ergänzt, es aber
nicht zur Relation hinzufügt.


¹ Ausnahme ist die Klärung von Zuordnungsproblemen bei überlappenden
Gebäudeumrissen

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

[Talk-de] building:levels, Altbau/Neubau

[Tobias Knerr]

On 22.07.2018 17:00, Frederik Ramm wrote:> wenn man building:levels
erfasst - das ist ja doch ein bisschen
> einfacher als eine echte Höhenmessung - macht es ja einen ziemlichen
> Unterschied, ob man es mit einem Altbau-Stadthaus mit 3,50m hohen
> Stockwerken zu tun hat oder mit einem Neubau mit nur 2,40. Sollte man
> das irgendwie mit erfassen?

Ich stimme zu, dass es einen Unterschied macht. Schöne Tagging-Lösungen
kenne ich allerdings nicht. Wenn man das erfassen will, bleibt einem
derzeit nur, das Ergebnis der Überschlagsrechnung als height-Tag am
Gebäude zu hinterlegen.

Im Prinzip könnte ein Renderer natürlich abhängig von
building:architecture, start_date oder ähnlichen Schlüsseln
unterschiedliche Default-Stockwerkhöhen annehmen. Allerdings weiß ich
bisher von keinem 3D-Renderer, der das tut.

> Ausserdem haben Gebäude in der Stadt oft so ein "Hochpaterre" (?), wo
> das Erdgeschoss nicht auf Straßenniveau ist, sondern einen halben Meter
> drüber. building:levels=3.5?

Das ist ein häufiger genanntes Problem, für das es meines Wissens
ebenfalls noch keine Lösung gibt – Interesse hätte ich und würde das
z.B. auch in OSM2World gerne einbauen.

Nicht ganzzahlige building:levels-Werte sind leider nicht gut
auszuwerten, weil man nicht weiß, _wo_ am Gebäude das halbe Stockwerk
ist. Das ist für die reine Höhenschätzung kein Problem, wohl aber wenn
man z.B. Fensterreihen einzeichnen oder Indoor-Mapping ins Gebäudemodell
einpassen will.

Theoretisch gäbe es sogar eine Lösung unter Verwendung von bestehenden
Tags, nämlich Simple Indoor Tagging: Man kann eine Fläche fürs
Erdgeschoss einzeichnen (indoor=level + level=0) und mit min_height=0.5
taggen. Aber eigentlich sollte ein so häufiger Fall einfacher abzubilden
sein, vor allem ohne den Pflegeaufwand von zusätzlicher Geometrie...

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

Re: [Talk-de] routing.openstreetmap.de

[Tobias Knerr]

On 31.12.2017 10:25, Volker Schmidt wrote:
> Die drei im vorliegenden Fall vorhandenen einschraenkenden
> tags beziehen sich ausschliesslich auf motorisierte Fahrzeuge; daher sollte
> der Router Fussgaenger, Radfahrer und Reiter durchlassen.

Der Schlüssel access bezieht sich keineswegs nur auf motorisierte
Fahrzeuge, und der Way ist als access=agricultural getaggt. Richtig wäre
vermutlich motor_vehicle=agricultural.

Dass zusätzlich zum access-Tag auch noch Einschränkungen getaggt sind,
die sich nicht auf Fußgänger beziehen – nämlich motorcar=no und
motorcycle=no – ändert daran nichts.

Und um auch noch eine weitere Quelle der Verwirrung auszuschließen: Es
gibt "agricultural" auch als Schlüssel, wo es dann keine Nutzungsart,
sondern einen Fahrzeugtyp bezeichnet und Fußgänger daher nicht betrifft.
Das spielt für diese Diskussion aber keine Rolle, da hier der Wert
agricultural genutzt wurde, nicht der Schlüssel agricultural.

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

[Talk-de] Nutzung von building:part durch Mentz GmbH

[Tobias Knerr]

Hallo zusammen,

mir ist aufgefallen, dass Mentz beim Bahnhofsmapping eine inkompatible
Interpretation des Schlüssels building:part gewählt hat. Dieser kommt
bei Mentz für Indoor-Elemente wie Aufzüge, die nicht unbedingt einen
Einfluss auf die äußere Form eines Gebäudes haben, oder auch für
Tunnel[1] zum Einsatz. Auch Stockwerke werden in der Mentz-eigenen
Dokumentation[2] als Einsatzmöglichkeit erwähnt.

Das widerspricht allerdings klar der etablierten Bedeutung dieses
Schlüssels, der ja aus Simple 3D Buildings stammt. Um den bestehenden
Standard nicht zu gefährden, sollte hier ein anderes Tagging gefunden
werden. Daher würde ich hoffen, dass Mentz bereit ist, eine andere
Lösung zu wählen und ihre eingetragenen Daten entsprechend zu korrigieren.

Ich hatte das bereits vor zwei Wochen im Wiki angesprochen, aber keine
Reaktion erhalten:
http://wiki.openstreetmap.org/wiki/Talk:MENTZ_GmbH/Modellierungsvorschl%C3%A4ge_Indoor#Problematische_Nutzung_von_building:part

Gruß,
Tobias

[1] Beispiel: http://www.openstreetmap.org/relation/7103998
[2] http://wiki.osm.org/DE:MENTZ_GmbH/Modellierungsvorschläge_Indoor



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

[Talk-de] OSM-Events auf der FOSSGIS 2017

[Tobias Knerr]

Hallo zusammen,

lang ist's ja nicht mehr hin bis zur FOSSGIS in Passau. Daher zunächst 
mal die Erinnerung: Denkt daran, euch unter 
http://fossgis-konferenz.de/2017/anmeldung/ anzumelden!


Wie ihr vielleicht schon gehört habt, wird es auf der FOSSGIS dieses 
Jahr zwei OSM-spezifische Events geben, die auch unabhängig vom Rest der 
Konferenz besucht werden können: Am Nachmittag des dritten 
Konferenztages richten wir eine Mappingparty aus, bei der gemeinsam die 
Daten in der Passauer Altstadt verbessert werden. Der Tag darauf steht 
dann als "OSM-Samstag" komplett im Zeichen von OSM – das Programm wird 
im Stil einer Unkonferenz von euch selbst gestaltet.


Damit wir diese OSM-Events besser planen können, wäre es schön, wenn ihr 
euch bei Interesse vorher auf den entsprechenden Wikiseiten eintragt:


http://wiki.osm.org/FOSSGIS_2017/Mappingparty
http://wiki.osm.org/FOSSGIS_2017/OSM-Samstag

Viele Grüße,
Tobias

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

Re: [Talk-de] Bitte HEUTE Vorträge einreichen für die FOSSGIS-Konferenz

[Tobias Knerr]

Zur Erinnerung: *Heute* endet die Vortragseinreichung für die 
FOSSGIS-Konferenz 2017 in Passau. Verlängern können wir die Frist 
diesmal leider nicht, also reicht schnell noch eure Ideen ein!


https://www.fossgis-konferenz.de/2017/callforpapers/

Falls euch die Zeit nicht mehr ganz reicht, stellt heute zumindest die 
Basisinfos ein. Am Abstract dürft ihr dann noch die nächsten Tage feilen.


Wer schon eingereicht hat: Danke für den Beitrag, das Programmkommittee 
wird sich nach Einreichungsschluss an die Arbeit machen und das Programm 
zusammenstellen. Wir haben nach dem aktuellen Stand schon viele 
interessante Vortragseinreichungen. :) Nichtsdestotrotz würden wir uns 
noch über weitere Vorträge aus dem OSM-Umfeld freuen!


Gruß,
Tobias

On 01.01.2017 21:09, Peter Barth wrote:

Hallo,

und da wir jetzt ein neues Jahr haben bumpe ich den Thread nochmal und
erinnere daran, dass bis zum 6. Januar keine ganze Woche mehr ist. Also
bitte nutzt eure restliche vorlesungsfreie Zeit/Ferien/Urlaub/... noch
euch ein gutes Thema zu überlegen und einzureichen. Wir haben zwar die
Einstelligkeit der Einreichungen bereits überschritten, wollen aber noch
viel mehr ;-)

Außerdem könnt ihr euch gerne schon heute für den OSM-Samstag im Wiki
eintragen: https://wiki.openstreetmap.org/wiki/FOSSGIS_2017/OSM-Events
Das erleichtert uns dann die Planung bzgl. Räumlichkeiten und
Verpflegung. Der OSM-Sonntag in Salzburg war wirklich genial; ich kann
euch nur empfehlen auch den OSM-Samstag in diesem Jahr nicht zu
verpassen!

Bei Fragen einfach hier oder direkt an mich oder an das Programmkomitee.
Ich freue mich über eure Einreichungen,
Peda


Frederik Ramm schrieb:


Hallo,

   vielleicht erinnert ihr Euch an Peters Aufruf hier:

https://lists.openstreetmap.org/pipermail/talk-de/2016-November/113629.html

Es geht um die FOSSGIS-Konferenz, die im März in Passau stattfindet. Die
Vortragseinreichung läuft bis zum 6. Januar. Das hört sich lang an, aber
wenn man alle vor uns liegenden Feier-, Fest- und Reisetage abzieht, ist
das bei den meisten noch so etwa eine Woche ;)

Es wäre echt super, wenn sich aus unseren Reihen noch ein paar
Vortragende finden würden. Ich weiss nicht, ob ich das ausplaudern darf,
also sag ich es mal ganz vage: Bislang ist eine hohe einstellige Zahl
von Vorträgen eingereicht worden ;) Das reicht noch nicht *ganz* für
eine schöne Konferenz in Passau. Also - wer hat noch nicht, wer will
nochmal, ich weiss, dass unter uns viele sind, die etwas interessantes
zu OSM erzählen können, sei es aus Anwender-, Programmierer-, oder
Mappersicht.

Bitte lasst die Frist nicht verstreichen - wenn ihr eine gute Idee für
einen Vortrag habt, die aber noch etwas ausformulieren wollt, wäre den
Veranstaltern auch sehr geholfen, wenn ihr jetzt noch vor Weihnachten
eine Einreichung macht und Euch dann später nochmal einloggt und am Text
feilt (das geht im Interface problemlos) - besser als die Sache vor sich
herzuschieben und dann kommt ihr nicht mehr dazu ;)

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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





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

Re: [Talk-de] Lizenz für Programme und Code

[Tobias Knerr]

Am 01.03.2016 10:59, schrieb Markus:
> Was verwendest Du? wieso?

Meine bevorzugte Lizenz, gerade für kleinere Sachen, ist die CC0. Ich
bin generell ein Fan der "ganz freien" Lizenzen, weil ich möchte, dass
möglichst viele andere Entwickler meine Software als Grundlage nutzen
können und sich keinen großen Gedanken über rechtliche Fragen machen müssen.

Eine Ausnahme ist hier OSM2World, dort verwende ich die LGPL.

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

Re: [Talk-de] Treppen und Handläufe

[Tobias Knerr]

Am 15.12.2015 21:53, schrieb Thorsten Alge:
> kennt Ihr noch andere OSM-basierte Dienste als
> http://openls.geog.uni-heidelberg.de/wheelchair-test/ , welche die Tags
> highway=steps und handrail[:left|:right]=yes auswerten?

OSM2World wertet diese Tags aus. Allerdings sind die Handläufe zu klein,
als dass sie in der auf Zoom 18 limitierten Onlinekarte sichtbar wären.
Daher bemerkt man sie derzeit nur offline.

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

Re: [Talk-de] Problem mit Bahnhofsmapping von MentzDV

[Tobias Knerr]

Hallo Roland,

danke für deine Reaktion. Ich finde allerdings, du machst es dir da zu
leicht. Mit Weiterpflegen (aka Hinterherputzen) am Passauer Bahnhof ist
das Grundproblem nicht gelöst. Viele Fehler bei eurem Mapping sind
systematisch, und treten eben nicht nur in Passau auf.

Zumindest die folgenden Punkte sind wahrscheinlich Systemprobleme:
* Pseudo-Fußwege auf den Bahnsteigen
* Verwendung von level außerhalb von Gebäuden
* Mappen Bahnsteig-Verkaufsautomaten als "Kiosk"
* Getrenntmapping von Gehsteigen, wo 0 bauliche Trennung existiert
* Mapping von Bahnsteigdächern als Gebäude

Ich wünsche mir, dass ihr:
* diese Fehler bei allen bearbeiteten Bahnhöfen korrigiert
* diese Fehler in Zukunft nicht mehr macht.

Ansonsten kann ich in eurem Mapping keinen Gewinn für OSM sehen.

Dann noch im Detail zu deinen einzelnen Punkten:

Am 31.08.2015 10:56, schrieb Roland Olbricht:
> Wer sich über den jetzigen Zustand echauffiert, sollte allerdings auch
> mal einen Blick auf den Zustand vorher geworfen haben:

Sicher, der Zustand vorher war nicht perfekt. Es hätte für uns einfach
wenig Sinn ergeben, den Bahnhof detaillierter zu erfassen, da er seit
langem komplett umgebaut wird. Z.B. ist die Fußgängerunterführung schon
heute nicht mehr dort, wo sie war (und wo ihr schön detailliert den
alten Zustand eingezeichnet habt).

>> * Dann gibt es zig neue Bushaltestellen entlang der Straße.
[...]
> Die ganze Batterie mit wenigen Metern Abstand ist aber verdächtig.

Das ist insbesondere deshalb problematisch, weil die einzelnen Halte in
keiner Weise unter den gemeinsamen Namen der Haltestelle gruppiert sind.

> Generell gibt es für Fußwege die beiden Modelle, den Fußweg separat zu
> mappen oder den Fußweg über Attribute im Weg zu beschreiben, und beide
> stehen gleichberechtigt nebeneinander.

Das ist zugegeben eine laufende Diskussion, aber es gibt seit langem das
Kriterium der baulichen Trennung. Eine solche ist in dem Fall nicht
gegeben. Es besteht auch keine nennenswerte Komplexität, die eigene
Geometrie erfordern würde. Was vorliegt, ist einfach ein Gehsteig am
Straßenrand:
http://regiowiki.pnp.de/index.php/Datei:Bushaltestelle_Hauptbahnhof.JPG

Euer Mapping stellt die Situation übrigens ziemlich falsch dar:
* Der Gehsteig südlich von Weg 7718378 geht ganz bis rechts bis zur
Kreuzung, er endet nicht plötzlich.
* Es gibt auch an der Nordseite einen Gehsteig.

> Der obige Fall ist da durchaus ein gutes Beispiel: Weg 7718378 ist
> vorher getaggt gewesen als für Fußgänger verboten.

Geschenkt. Ist aber leicht zu korrigieren und kaum ein Grund zum
Komplettumbau.

> Selbst wenn man jetzt nur
> das "access"-Recht für Fußgänger umgesetzt hätte, wäre überhaupt nicht
> klar, wo da die Fahrradfahrer durchmüssen: [...]
> Das kann man in einem komplexen
> Lane-Tagging umsetzen, das 80% aller Mapper dann erst einmal
> interpretieren müssten

Du meinst das Lane-Tagging über Tags am Way? Das sich im Alltag längst
etabliert und gegenüber Ways-für-Spuren durchgesetzt hat? Ja, genau
dieses Schema solltet ihr verwenden.

Es gibt dort übrigens weder Busspuren noch Busbuchten noch überhaupt
markierte Spuren. D.h. die Straße mit sidewalk=both reicht völlig.

>> * Gleiches auf den Bahnsteigen (http://osm.org/way/367435362). Imho
>> gehören da keine Fußwege hin. Ein Router sollte schon selbst erkennen
>> können, dass die ganze Bahnsteiglänge für's Einsteigen gedacht ist.
> 
> Das Modell stammt gar nicht von uns, sondern hat sich schon seit langer
> Zeit etabliert

Ich verfolge durchaus selber die Tagging-Diskussionen im Projekt, und
kann von daher mit ziemlicher Sicherheit sagen: Nein, das ist nicht
"etabliert". Und außerhalb von Mailinglisten habe ich es bisher
ausschließlich an von euch gemappten Bahnsteigen gesehen.

> man mappt die Blindenleitstreifen als Fußwege.

Ich glaube das lasse ich mal für sich stehen.

> Generell: Wie wollen wir sonst mit vertikalen Strukturen umgehen? Für
> einen Laien dürfte eine Gliederung in Ebenen der intuitivste Zugang
> sein,

Wie wäre layer für outdoor, level für Indoor...?

> Für die Betreuung unserer Hiwis nehme ich folgende Erkenntnisse mit:
[...]
> Bitte ergänzt die Liste, falls ich etwas vergessen habe.

- Insbesondere die zuoberst genannten nicht Passau-spezifischen Fehler
bei den bisher bearbeiteten Bahnhöfen beheben und in Zukunft nicht mehr
machen.

Danke fürs Zuhören und viele Grüße,
Tobias

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

Re: [Talk-de] OSM Wiki-Übersetzung Griechisch?

[Tobias Knerr]

Am 15.07.2015 23:16, schrieb rza31:
> Hallo,
> bei https://wiki.openstreetmap.org/wiki/Wiki_Translation ist unter
> "Andere Sprachen" Griechisch nicht aufgeführt. Sollte man dies nicht
> ergänzen?

Ein roter Link für Griechisch (Ελληνικά) ist dort doch vorhanden? Oder
meinst du, dass jemand eine Übersetzung ins Griechische erstellen soll?


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

Re: [Talk-de] waterway=riverbank

[Tobias Knerr]

Am 29.05.2015 06:25, schrieb Markus:
> Das würde ein weltweites Tagging-Schema zerstören...
> 
> Wer weiss Genaueres?

Das geht auf ein erfolgreiches Proposal von 2011 zurück:
http://wiki.openstreetmap.org/wiki/Proposed_features/Water_details

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

Re: [Talk-de] unpraktisches Nominatim-Ergebnis

[Tobias Knerr]

Am 02.05.2015 21:43, schrieb Christian H. Bruhn:
> Ich habe gestern auf openstreetmap.org nach "Wildpark Eekholt"
> gesucht. Da gab es mehrere Suchergebnisse. Das erste war
> http://www.openstreetmap.org/node/2414231380 , welches ein
> Straßenschild ist. So eine braune Tafel, welche an Autobahnen auf
> touristische Ziele hinweist.

Es ist ja auch fraglich, ob "Wildpark Eekholt" wirklich der Name des
Schildes ist. Ich würde da ja eher zu inscription (Beschriftung) tendieren.

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

Re: [Talk-de] Taginfo-Challenge

[Tobias Knerr]

On 14.03.2015 13:59, Andreas Goss wrote:
> Da ich letztes mal noch keine Antwort bekommen hatte, wie sieht es mit
> case sensitive key aus?
> 
> Spielt das für die Datenbank eine Rolle, also sollten alle key klein
> sein? Oder ist es egal, dann wäre es gut wenn Taginfo das da einfach
> ignoriert.

Die Konvention ist schon, dass Keys klein sind, siehe z.B. hier:
http://wiki.osm.org/Any_tags_you_like#Syntactic_conventions_for_new_tags

Viele Programme behandeln sie auch case sensitive, also ist es imo
sinnvoll, Großschreibungen von Keys zu korrigieren.

Die Ausnahme ist natürlich dort, wo sich in Einzelfällen etwas anderes
etabliert hat. Beispielsweise ist die Schreibweise TODO statt todo
heutzutage zwar nicht mehr populär, aber doch noch existent.


___
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

[Tobias Knerr]

Am 18.02.2015 12:09, schrieb Alexander Lehner:
> ... wenngleich auch etwas kritisch:

... und nicht ganz richtig: "anonyme Korrekturen oder Hinweise
akzeptiert OpenStreetMap nicht".

Trotzdem sehr schön, dass uns das neue Routing-Feature ordentlich
Aufmerksamkeit bringt. Sind schon etliche Artikel aufgetaucht:

http://wiki.openstreetmap.org/wiki/OpenStreetMap_in_the_media

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

Re: [Talk-de] Update of german Aral petrol stations

[Tobias Knerr]

Am 12.02.2015 14:41, schrieb Sven Geggus:
> Wie bitte? Wenn es dieses Problem wirklich gäbe, dann hätten es alle Daten,
> die derzeit in der Datenbank sind ebenfalls, denn auch bei diesen Daten ist
> eine Re-Lizensierung nicht möglich.

Bei allen von Hand eingetragenen Daten hat der Urheber (= der Mapper)
die Contributor Terms akzeptiert. In denen steht drin, dass die Daten,
eine erfolgreiche Abstimmung vorausgesetzt, auch unter einer anderen
freien Lizenz veröffentlicht werden dürfen.

Bei Importen besteht das Problem, dass der eintragende Mapper nicht der
Urheber ist, und wir daher auch nicht automatisch die Zustimmung des
Urhebers zur Veröffentlichung unter anderen freien Lizenzen haben. Das
lässt sich lösen, indem der Urheber die Daten generell für die
Verwendung bei OSM (ohne Einschränkung auf eine bestimmte Lizenz) zulässt.

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

Re: [Talk-de] Update of german Aral petrol stations

[Tobias Knerr]

Am 11.02.2015 18:28, schrieb Michael Reichert:
> Ich persönlich denke, dass die ODbL als Lizenz für eine Import nicht
> ausreichend ist. Was passiert, wenn sich die Zweidrittelmehrheit der
> aktiven Mapper nach Artikel 3 der Contributor Terms für eine neue Lizenz
> entscheidet?
> http://www.osmfoundation.org/wiki/License/Contributor_Terms

+1

Auch ich bin der Ansicht, dass Daten nur dann importiert werden sollten,
wenn sie uns nach einem Lizenzwechsel noch erhalten bleiben. Das ist bei
Daten, deren Verwendung nur unter ODbL erlaubt ist, nicht der Fall.

Vielleicht lässt sich ja eine Lösung finden, die generell die Nutzung
für OSM (unabhängig von der Lizenz) erlaubt.

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

Re: [Talk-de] mehrere Häuser mit gemeinsamen Dach

[Tobias Knerr]

Am 03.02.2015 23:49, schrieb Holger Jeromin:
>> Jetzt habe ich doch noch roof:shape=side_hipped [1] entdeckt. Scheint
>> für einfachere Fälle zu funktionieren.
>
> Oder eine Linie als  roof:ridge quer rüber eintragen.

Es müssten 3 Linien mit gemeinsamen Knoten mit den Gebäuderändern sein.
Gemeinsame Firstlinien für mehrere Gebäude sind meines Wissens nirgends
definiert. Übrigens ist auch side_hipped keine standardisierte Dachform
(wobei man argumentieren könnte, dass entweder ein neuer roof:shape-Wert
oder ein Subtag für das normale hipped für so etwas sinnvoll wäre).

Viele Grüße,
Tobias

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

Re: [Talk-de] cycleway=track bei Bordstein Trennung

[Tobias Knerr]

Am 16.12.2014 13:05, schrieb Wolfgang Hinsch:
> Damit der Renderer erkennen kann, dass die extra-Fußwege an die Straße 
> gehören 
> und er sich somit die (für den Maßstab) passendere Variante aussuchen kann, 
> sollten es eine street-Relation geben, in der alle Linien, die zur gleichen 
> Straße gehören, erfasst sind. Das erleichtert auch die Zuordung von 
> Straßennamen etc. zu separaten Wegen.

Es erleichtert das Problem mit den Straßennamen. Aber das Kernproblem,
das ein Renderer-Autor hat, ist doch die Zuordnung eines Fußweges zu
einem ganz bestimmten Way, nicht einer Gruppe von Ways. Es kann ja sein,
dass manche Teile einer Straße einen Fußweg haben, andere vielleicht
zwei oder gar keinen.

Gruß,
Tobias

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur

[Tobias Knerr]

Am 07.12.2014 19:19, schrieb Martin Vonwald:
>> * Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut
>> werden? Wenn ja, wie?
> 
> Parkspuren theoretisch ja, auch wenn ich kein Freund davon bin. Gehsteige
> würde ich nein sagen, da es ja keine "Spuren" für irgendwas sind. Bei
> Gehsteigen würde ich bei dem bewährten Konzept mit den sidewalk-Tags (inkl.
> Sub-Tags und ohne separate Wege) bleiben.

Momentan haben wir Tags für die normalen lanes, für die cycleways, für
die parking:lanes, und für die sidewalks. Das Problem, das ich lösen
will: Wie kann ich angeben, in welcher Ordnung die sich zueinander
befinden?

Ich kann mir da zwei Lösungen vorstellen:
* Alles in die *:lanes=* mit integrieren
* Zusätzlich zu den genannten Tags noch eine Liste taggen, die die
Reihenfolge der genannten Elemente angibt

Und ich versuche gerade, etwas nachzufühlen, was wohl besser ankommt.

>> * Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es
>> nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf
>> die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur
>> mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das
>> anders?
> 
> Jeder der mit xxx:lanes-Tags arbeitet, sollte sich vorstellen, dass er nur
> die eine Spur sieht und gedanklich alle andere ausblenden und alle
> xxx:lanes-Tags zu xxx reduzieren. In deinem Beispiel bleibt dann ein "Weg"
> übrig, welcher nur für Radfahrer zulässig ist. Welche Breite würdest du
> annehmen für einen Weg, welcher nur für Radfahrer erlaubt ist?

Ich würde normal gar nicht auf die access-Tags sehen, wenn ich die
Breite eines Weges bestimme, sondern nur auf den highway-Wert und width.
Das funktioniert auch bei normalen Wegen gut genug, aber bei den Spuren
lande ich so eben auch bei Radspuren bei der Standardbreite normaler Spuren.

Das will ich jetzt nicht zum prinzipiellen Problem aufbauschen, nur
fände ich es gut, wenn man das klarstellen könnte.

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur

[Tobias Knerr]

Am 05.12.2014 18:56, schrieb fly:
> Am 05.12.2014 um 16:10 schrieb Tobias Knerr:
>> * Im Sinne unserer damaligen Diskussion, ob left/right nicht besser wäre
>> als forward/backward: Wie mappe ich Radwege, die in beide Richtungen
>> nutzbar sind?
> 
> Entweder als separaten Weg und bicycle=use_sidepath oder mit einer
> Kombination aus left/right + forward/backward.

Ich denke hier natürlich konkret an den Fall, dass ich diesen Radweg in
die *:lanes=* mit einbauen will. Wie habe ich mir diese Kombination
vorzustellen? Es muss ja weiterhin bicycle:lanes:forward/backward
verwendet werden, oder?

> Analog zu cycleway:lanes*=* kann ich mir auch sidewalk:lanes*=* und
> parking:lane:lanes*=* vorstellen
> 
> Mein Problem ist hier nur der Umgang mit Barrieren álà kerb oder auch
> unterbrochene fence_type=railing

Falls das konsensfähig ist, wäre es natürlich eine schöne Möglichkeit.

Das Problem der Interaktion mit explizit eingetragenen Barrieren gibt es
ja ohnehin auch beim klassischen sidewalk- und parking:lane-Tagging. Und
bei separaten Ways hat man ganz andere, viel größere Probleme...

>> * Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es
>> nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf
>> die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur
>> mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das anders?
> 
> Für die Breite gibt es width:lanes*=*

Das weiß ich. Es geht mir um die Default-Breite, denn wer will schon bei
einem stinknormalen Radweg die Breite taggen?

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur

[Tobias Knerr]

Am 05.12.2014 13:19, schrieb Martin Vonwald:
> Vom Prinzip her ist bicycle:lanes=...|designated|... und
> cycleway:lanes=|lane| identisch. Welche Variante besser ist, kann
> ich sagen. Ich tendiere eher zu bicycle:lanes, da es konsistent mit der
> Angabe anderer access-Beschränkungen wäre, z.B. bus:lanes.

Ich sehe hier einige Probleme:
* Im Sinne unserer damaligen Diskussion, ob left/right nicht besser wäre
als forward/backward: Wie mappe ich Radwege, die in beide Richtungen
nutzbar sind?
* Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut
werden? Wenn ja, wie?
* Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es
nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf
die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur
mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das anders?

Gruß,
Tobias

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

Re: [Talk-de] Gemeinsamer Account

[Tobias Knerr]

Am 29.11.2014 16:47, schrieb Michael Kugelmann:
> Somit existierten zwei unabhängige Systeme (API und Wiki) mit
> unterschiedlichen (sich vielleicht auch widersprechenden Accounts) =>
> zusammenführung "nicht möglich" (bzw. zu schwierig). Die Diskussion
> hatten wir bereits vor 5 Jahren  oder so.   :-(

"Zu schwierig" finde ich es nicht. Allerdings ist es jetzt natürlich
schwieriger als wenn wir es schon vor 5 Jahren gemacht hätten. Und
umgekehrt ist es jetzt deutlich leichter als wenn wir noch 5 Jahre warten.

Meine Vorstellung wäre, die geschätzten >99% unproblematischen Accounts
automatisch zu koppeln, genau so alle zukünftigen. Die wenigen, wo der
Wikiaccount einer anderen Person gehört als der gleichnamige
OSM-Account, ließen sich mit einigen einfachen Regeln abarbeiten oder
schlimmstenfalls als Einzelfälle behandeln.

Das ist keineswegs ein Ding der Unmöglichkeit. Bei Wikipedia hat die
Vereinheitlichung der Accounts ("Single Unified Login") auch geklappt.

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

Re: [Talk-de] Thomas Krenn Open Source Förderung für OSM2World

[Tobias Knerr]

Am 21.08.2014 18:47, schrieb Christoph Hormann:
> Glückwunsch!
> 
> Ist das Preisgeld nur für die Anschaffung der Hardware oder ist damit 
> auch über einen längeren Zeitraum der Betrieb sichergestellt?

Danke für die Glückwünsche. :)

Abgedeckt ist vom Preisgeld nur die Hardware. Um den Betrieb müssen wir
uns selber kümmern. Wir sind allerdings zuversichtlich, dass wir da eine
Lösung finden.

> Für weltweite Anwendung ist der aktuelle Darstellungsstil vermutlich 
> etwas zu mitteleuropäisch geprägt.

Ja, letztlich braucht man regional unterschiedliche Stile. Aber die
nötige Hardwarebasis ist schon mal ein erster Schritt, und ich denke,
dass mit entsprechendem Tagging auch jetzt schon einiges möglich ist.

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

[Talk-de] Thomas Krenn Open Source Förderung für OSM2World

[Tobias Knerr]

Hallo,

wir haben uns mit OSM2World¹ in diesem Jahr erstmals für die
OpenSource-Förderung von Thomas Krenn beworben. Die Gewinner wurden von
einer Jury bestimmt. Gestern haben wir das Ergebnis erfahren: Wir haben
den ersten Platz erzielt und erhalten Server-Hardware im Wert von 2500€.

https://www.thomas-krenn.com/de/tkmag/tk-insights/ausgezeichnete-und-geehrt-thomas-krenn-honoriert-fuenf-open-source-projekte/

Wir planen, den Server einzusetzen, um die OSM2World-Slippymap² weltweit
anbieten zu können und längerfristig auch WebGL-Darstellung zu ermöglichen.

Die feierliche Preisverleihung findet voraussichtlich im September statt.

Viele Grüße
Tobias

¹ http://osm2world.org/
² http://maps.osm2world.org/

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

Re: [Talk-de] Adressdaten in POI nodes

[Tobias Knerr]

Am 13.08.2014 11:52, schrieb Tom Pfeifer:
> Städte haben viel unterirdische Infrastruktur. Der Imbiss im U-Bahnhof hat
> keine Beziehung zu dem Gebäude und insbesondere der Addresse im Haus
> obendrüber.

Das sind aber dann eben auch die einzigen Fälle, in denen eine Relation
in Frage kommt.

Bei eindeutigen Situationen sollte man davon ausgehen, dass POI
innerhalb eines Gebäudeumrisses sich auch in der Realität in diesem
Gebäude befinden.

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

Re: [Talk-de] Veggiekarte.de

[Tobias Knerr]

Am 11.08.2014 14:43, schrieb André Riedel:
> Gibt es eigentlich eine Unterscheidung zwischen "Viele
> vegetarische/vegane Gerichte" und "Salat+EinOderZweiAndereGerichte" ?

Da kommt es jetzt darauf an, wie man die Definition liest. Es heißt ja
für yes: "full options available (i.e. several proper meals not just
side salads in restaurants or a baked potato in a pub ...)"

Insofern könnte man durchaus argumentieren, dass
"Salat+EinOderZweiAndereGerichte" nicht für yes reicht.

Zufriedenstellend ist das nicht, denn dann geht der wichtige Unterschied
zwischen überhaupt keinen Optionen und wenig Optionen verloren. Aber
wenn man ein minimales Angebot und ein sehr reichhaltiges beide mit yes
versieht, dann ist das auch nicht ideal.

Eigentlich bräuchte man einen zusätzlichen "limited"-Wert zwischen no
und yes.

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

Re: [Talk-de] Sichelförmige Treppe

[Tobias Knerr]

Am 21.07.2014 15:33, schrieb Martin Koppenhoefer:
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area#Area-steps.2C_steps_which_are_wide_and.2For_irregular

In deinem Proposal finde ich noch keinen Hinweis darauf, wie ein solches
Mapping ausgewertet werden soll. Kannst du kurz die Vorgehensweise bei
der Berechnung der Stufen beschreiben, wenn die Area-Relation und
step_count bekannt sind?

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

Re: [Talk-de] Vorschlag neuer Geometrie (relationen)-Typ: node-relation

[Tobias Knerr]

Am 09.07.2014 19:48, schrieb Martin Koppenhoefer:
> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Node
> 
> Es geht darum, mehrere Node-Objekte am selben Ort mappen zu können, eine
> Situation, die z.B. bei Verkehrsschildern öfters auftaucht, für die es aber
> sicherlich noch hundert andere Anwendungsfälle gibt.

Ich halte eine solche Relation für nicht sinnvoll, denn in einer
Geodatenbank wird "ist an derselben Stelle" über die Koordinaten
ausgedrückt.

Dein Beispiel mit den Verkehrsschildern ist zudem nicht sinnvoll, da –
wie bereits von anderen erwähnt – hier schon eine dokumentierte Lösung
existiert: Semikolons. Da ist die Nutzung einer Relation keineswegs
bequemer.

Das ebenfalls genannte Beispiel, dass ein Objekt an einem Baum (oder
einem Mast, einer Mauer, ...) befestigt ist, deckt deine Relation
hingegen gar nicht zufriedenstellend ab – dafür bräuchte man eher eine
"befestigt an"-Relation mit entsprechender Semantik. Diese wäre dann
aber auch nicht auf Nodes beschränkt.

Gruß,
Tobias

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

Re: [Talk-de] Grillfleisch-Automat

[Tobias Knerr]

Am 30.06.2014 11:24, schrieb Andreas Goss:
> Ist halt die Frage wie man vending=food definiert.

Zumindest mal als verzehrfertiges Essen. Schon allein deshalb, weil das
vermutlich 99% oder mehr aller vending=food ausmachen wird.

> Andererseits hat es eben den Vorteil, dass ich nicht für jedes
> Nahrungsmittel einen neuen vending=tag brauche, dann müsste ich halt nur
> jedes mal vending=food; food:snacks=yes setzten, wenn ich diesen
> typischen Automaten am Bahnhof meine.

Ich sehe keinen Vorteil darin, wenn ich zwar keinen neuen vending-Wert,
dafür einen neuen food:*-Schlüssel brauche. Und wenn ich dann auch noch
für alle Nahrungsmittel-bezogenen Automaten zwei Zusatztags statt einen
brauche, steht unter dem Strich ein Nachteil.

Mehrere Klassen zusammenzufassen ist auf jeden Fall dann sinnlos, wenn
man ohne genauere Information ohnehin keine brauchbare Auswertung machen
kann. Und das wäre hier der Fall: Weder den hungrigen Reisenden, noch
den Grillfan kann man dann zu einem vending=food ohne weitere Infos
schicken.

Gruß,
Tobias

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

Re: [Talk-de] Markierungen auf Sportplätzen

[Tobias Knerr]

Am 05.06.2014 16:09, schrieb Florian Schäfer:
> Außerdem gibt es auch noch Spielfelder mit Markierungen für mehrere
> Sportarten (siehe Bsp. [1]).
> Wie wäre es z.B. mit field_marking=soccer und in dem Beispiel dann
> field_marking=soccer;volleyball;basketball

Das fände ich eine gute Lösung. Für einfache Fälle yes/no, ansonsten
eine semikolon-separierte Liste der Sportarten (Werte von sport=*), für
die Markierungen vorhanden sind.

Gruß,
Tobias

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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Tobias Knerr]

Am 29.05.2014 13:59, schrieb Bernhard Weiskopf:
> Wie trägt man zeitlich beschränkte Öffnungszeiten für Tore ein?

Das hier ist korrekt:

> acess:conditional = yes @ (Mo-Sa 07:00-20:30; PH off)

Das auch (eben mit dem Unterschied, dass es nur für Fußgänger gilt):

> foot:conditional = yes @ (Mo-Sa 07:00-20:30; PH off)

Das hier nicht, aber als access:foot:conditional = * wäre es korrekt:

> access:conditional:foot = yes @ (Mo-Sa 07:00-20:30; PH off)

Bei allen Varianten könnte es noch helfen, den Standard-Zustand
anzugeben, wenn keine der bedingten Regeln gelten. Das ginge z.B. mit
access = no.

Gruß
Tobias

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

Re: [Talk-de] Gelöschte Daten finden [was: 3D-Mapping]

[Tobias Knerr]

Am 08.05.2014 23:44, schrieb Ralf GESELLENSETTER:
> Wäre ja mal interessant, wie das F4MAP & Co. rendern.

So: http://up.picr.de/18219052uf.jpg

(Bild aus dem Forum)

> BTW: Gibt es inzwischen 3D-Darstellungen, die ohne 3D-Graphik
> (OpenGL usw.) auskommen? Müsste ja echt nicht dynamisch sein...

http://osmbuildings.org zeichnet 3D-Gebäude mit einer 2D-Grafik-API. Hat
natürlich entsprechende Einschränkungen, sieht aber trotzdem sehr schick
aus.

Und wenn es dir nur darum geht, dass der Nutzer kein OpenGL ausführen
muss, dann gibts natürlich noch http://maps.osm2world.org/

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

Re: [Talk-de] 3D-Mapping

[Tobias Knerr]

Am 07.05.2014 18:58, schrieb tumsi:
>
>> Aber natürlich hat es ein humorloser User schon alles gelöscht. Ja,
>> gelöscht, nicht etwa durch sauberes 3D-Tagging ersetzt. Es kann
>> schließlich nicht schnell genug gehen.
>>
>> Hätte doch wirklich keinem geschadet, das noch ein paar Tage stehen zu
>> lassen. :/
> 
> Echt? Ich konnte das gerade alles abrufen. Oder gab es einen Revert?
> (kann man einen Revert eigentlich irgendwie erkennen?)

Wie ich mittlerweile gemerkt habe, stehen 2 Gebäude noch, wenn du das
meinst.

Die anderen wurden in diesem Changeset, sowie anderen Changesets des
Users mit dem gleichen Kommentar, abgerissen:
http://www.openstreetmap.org/way/280009469

Siehe das Bild von Alex in diesem Thread für ein Rendering der
kompletten Gebäudegruppe. Wen es interessiert, ich habe mir da vorher
noch die Gebäude via JOSM geladen.

Gruß,
Tobias

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

Re: [Talk-de] 3D-Mapping

[Tobias Knerr]

Am 07.05.2014 16:37, schrieb Christoph Hormann:
>
>> http://www.openstreetmap.org/#map=18/40.02307/32.92564
> 
> Wow, das ist so gut, dass es fast schon schade ist, wenn das gelöscht 
> wird...

Geht mir auch so, das ist schon irgendwie beeindruckend.

Aber natürlich hat es ein humorloser User schon alles gelöscht. Ja,
gelöscht, nicht etwa durch sauberes 3D-Tagging ersetzt. Es kann
schließlich nicht schnell genug gehen.

Hätte doch wirklich keinem geschadet, das noch ein paar Tage stehen zu
lassen. :/

Gruß,
Tobias

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

Re: [Talk-de] Announce: Mapnik-de: Schöneres Rendering von Sportplätzen

[Tobias Knerr]

Am 07.04.2014 12:14, schrieb Sven Geggus:
> chris66  wrote:
>> Manchmal werden ja z.B. mehrere nebeneinanderliegende Tennisplätze
>> als ein Feld getaggt.
> 
> Dann muss man das halt abteilen. Das Josm Plugin zum Abteilen von Gebäuden
> kann man hierfür wunderschön missbrauchen :)

Das heißt, wir sind uns einig, dass ein leisure=pitch immer nur genau 1
Feld umfassen soll?


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

Re: [Talk-de] "Flächenmapping" so korrekt? Wie korrigieren?

[Tobias Knerr]

Am 04.04.2014 18:53, schrieb Martin Koppenhoefer:
> Ich finde es prinzipiell nicht schlimm, wenn sowas als area gemappt wird,
> vor allem wenn zusätzlich noch die Straßenmittellinie als highway gemappt
> ist.

Die Kombination Mittellinie + Fläche ist m.E. nur akzeptabel, wenn die
Fläche als area:highway getaggt ist - also das Gegenstück zum
Riverbank-Modell. Nur dann ist brauchbares Routing und Rendering
sichergestellt.

Die einzige Situation, wo eine highway-Linie über eine highway-Fläche
korrektes Mapping ist, sind sichtbar abgesetzte Wege, die einen Platz
queren.

> Wenn Du Dir das Wiki ansiehst, steht da:
> "In the case you want to map a complete area for example a market place or
> plaza create a closed area with the ways and attach the
> area
> =yes tag to it."
> 
> da steht m.E., dass man es sich aussuchen kann, und nicht wie im Deutschen,
> dass man nur größere Plätze so mappen darf.

Auch dort steht aber nicht, dass man Straßen als Flächen mappen darf.
Wie man an den Beispielen (Marktplatz, Plaza) erkennen kann, bezieht
sich der Abschnitt speziell auf Plätze.

Gruß,
Tobias

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

Re: [Talk-de] "Flächenmapping" so korrekt? Wie korrigieren?

[Tobias Knerr]

Am 04.04.2014 17:12, schrieb Martin Koppenhoefer:
> "Ein größerer Platz kann auch als Fläche gemappt werden" würde ich ändern
> in "sollte als Fläche" gemappt werden, weil ein größerer Platz von einer
> Linie ziemlich schlecht repräsentiert wird (m.E. selbst ein kleinerer
> Platz, von daher ggf. auch das "größerer" weglassen, ist sowieso unscharf
> und Sinn macht es auch nicht wirklich, wenn es ein "Platz" ist, ist eine
> Fläche m.E. immer besser (wegen der Form), auch wenn er nur "klein" ist).

Meinetwegen kann man dort gerne "Plätze sollten als Fläche gemappt
werden" schreiben.

Das hat aber nicht wirklich etwas mit meiner Aussage zu tun, dass man
nur Plätze als highway=pedestrian + area=yes taggen sollte. Oder willst
du dem auch widersprechen?

Gruß,
Tobias

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

Re: [Talk-de] "Flächenmapping" so korrekt? Wie korrigieren?

[Tobias Knerr]

Am 04.04.2014 10:30, schrieb Georg Feddern:
> Am 03.04.2014 09:47, schrieb Manuel Reimer:
>> Ist "highway=pedestrian" auf die Fläche überhaupt korrekt?
> 
> Gemäß (text)googlen ist es eine Fußgängerzone - und die darf bei OSM
> auch als Fläche getaggt werden.

Plätze in Fußgängerzonen dürfen als Fläche getaggt werden, nicht jede
Fußgängerzone. Oder als Zitat aus dem Wiki:

"Eine Fußgängerzone kann als einfacher Weg gezeichnet werden, wenn es
sich eher um eine straßenähnliche Form handelt. [...] Ein größerer Platz
kann auch als Fläche kartografiert werden."

Gruß,
Tobias

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Tobias Knerr]

Am 03.04.2014 20:16, schrieb Falk Zscheile:
> Und was machst du, wenn auf der Straße gleichzeitig noch eine
> Geschwindigkeitsbegrenzung und ein Halteverbot stehen.

Der Wert von traffic_sign kann ausdrücklich eine Semikolon-getrennte
Liste von Schildern und Schildergruppen enthalten.

Gruß,
Tobias

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

Re: [Talk-de] "Flächenmapping" so korrekt? Wie korrigieren?

[Tobias Knerr]

Am 03.04.2014 10:01, schrieb Manuel Reimer:
> bei uns hat vor einigen Tagen jemand eine Straße in eine Fläche umgewandelt:
> 
> http://www.openstreetmap.org/way/270733792
> 
> Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten.
> 
> Ist "highway=pedestrian" auf die Fläche überhaupt korrekt?

Nein, hier überwiegt klar der lineare Charakter. Das ist kein Platz.

Du solltest m.E. die Linien mit den ursprünglichen Tags wieder
herstellen und die neue Fläche zu area:highway=pedestrian umtaggen.

Gruß,
Tobias

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

Re: [Talk-de] ReMAPTCHA Demo BETA 0.2 online!

[Tobias Knerr]

Am 29.03.2014 09:50, schrieb Stefan Keller:
> Während ein CAPTCHA für Menschen einfach sein soll, soll es für
> Computer schwierig sein. Zeichenbasierte CAPTCHAs haben zig Millionen
> Möglichkeiten! Ein CAPTCHA, das mit "nur" 500 Proben (d.h. 2 Dächer à 24
> Formen) geknackt ist, gilt als unsicher.

IMO könnte man da genauso vorgehen wie bei deinen momentanen ReMAPTCHAs:
Man greift auf die bewährten verformten Wörter zurück.

Grundkonzept: Ein (einfach geformtes) Haus mit dem OSM-Umriss über einem
Luftbild. Daneben dann eine Handvoll Bildchen für typische Dachformen
inkl. "sonstiges", und jeweils ein zugeordnetes, zufälliges Wort. Der
User soll das Wort neben der richtigen Dachform abschreiben.

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

Re: [Talk-de] Noch eine Wappenkarte

[Tobias Knerr]

Am 29.03.2014 15:05, schrieb Kolossos:
> Hallo, das Berliner Hackweekend hatte ich mal genutzt die Idee der
> Wappenkarte auf Wikidata-Basis aufzugreifen und in meine
> Koordinatenextraktion der Wikipedia zu integrieren:
> http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=de&uselang=de&zoom=6&lat=50.08584&lon=6.63143&coats=yes

Eine interessante Weiterführung des Konzepts.

Beim Spielen mit der Karte sind mir zwei Dinge aufgefallen:
* Hier und da tauchen Logos von Fußballklubs auf. Ist das gewollt oder
nur eine Folge der fehlenden "instance of"-Daten?
* Manche Wappen haben keinen transparenten Hintergrund. Gibt es da auf
Wikipedia/Commons Regeln bzgl. der Transparenz, sprich: Kann ich da
einfach das Wappen bearbeiten? Oder bekomme ich da Ärger?

Gruß,
Tobias

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

Re: [Talk-de] ReMAPTCHA Demo BETA 0.2 online!

[Tobias Knerr]

Am 28.03.2014 22:49, schrieb Alexander Heinlein:
> Momentan ist die Frage der vorhandenen Verbindung zwischen zwei
> Wegen mit "ja" oder "nein" zu beantworten. Bei Dachformen hingegen gibt es
> momentan 25 definierte Werte, Tendenz steigend (siehe [1]). Einige sind auf
> den ersten Blick auch nicht von anderen zu unterscheiden. Das kann nicht
> wirklich funktionieren, leider.
> 
> [1]: https://wiki.openstreetmap.org/wiki/OSM-4D/Roof_table

Ich halte schon die Zahl von 25 für übertrieben. Die 4D "Roof table"
spaltet sehr feingranular auf. Manche davon kommen auf Dächern mit
annähernd rechteckiger Grundform (auf diese könnte man sich bei der
Auswahl der Captchas ja beschränken) praktisch gar nicht vor.

Es hat schon seinen Grund, warum Simple 3D Buildings derzeit das
vorherrschende Taggingschema ist und nicht das von dir verlinkte Schema:
Ein kleiner Katalog deckt schon einen Großteil der einfachen Fälle ab.
Ein "Sonstige"-Wert unter den zur Auswahl stehenden Dachformen würde dem
Rest m.E. ausreichend Rechnung tragen.


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

Re: [Talk-de] 3D: Wie Gebäude am Hang taggen?

[Tobias Knerr]

Am 17.03.2014 16:50, schrieb Martin Koppenhoefer:
> ja, und bei mehreren Eingängen sollte jeder davon auf Bodenhöhe sein,
> ausser man trägt auch das Podest oder die Treppe ein, über die der Zugang
> erfolgt, dann sollte diese auf Bodenhöhe anfangen. Und bei mehreren Häusern
> nebeneinander sollte jeweils der Eingang auf Bodenhöhe sein (bzw. der
> Anfang der Zugangstreppe). Ist nicht komplett trivial, wäre aber sicher
> spannend, wenn das mal jemand versuchen würde. Meistens haben wir aber auch
> keine absoluten Höhen für die Häuser an sich, wenn man nun aber doch für
> einzelne Punkte mal eine Höhe hat, verbiegt man dann auch das Modell
> passend?

Ich habe in OSM2World schon versucht, ein SRTM-Gelände mithilfe solcher
Informationen aus OSM zu verfeinern. Leider war es doch schwieriger als
gedacht und funktioniert noch nicht befriedigend. Ich habe die Hoffnung
aber nicht aufgegeben! ;)

Wen meine Experimente diesbezüglich interessieren, der kann sich das
Video von meinem letztjährigen FOSSGIS-Vortrag ansehen.

Und der Vollständigkeit halber: Rein SRTM-basierte Geländeformen kann
man mit OSM2World auch heute schon haben, allerdings geht das nur in der
Offlineanwendung und ist noch nicht sehr benutzerfreundlich.

Gruß,
Tobias

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

Re: [Talk-de] 3D: Wie Gebäude am Hang taggen?

[Tobias Knerr]

Hallo,

Am 17.03.2014 09:02, schrieb Manuel Reimer:
> in einem konkreten Fall sehe ich beim Betrachten von vorne: Ein Stockwerk,
> ein Dachgeschoss, ein Kellergeschoss.
> 
> Nun laufe ich einen Fußweg neben dem Gebäude nach unten und betrachte das
> Gebäude von der anderen Seite.
> 
> Jetzt sieht die Situation anders aus. Aus dem Kellergeschoss ist ein
> ebenerdiges Geschoss geworden. Also zwei Stockwerke, ein Dachgeschoss, kein
> Kellergeschoss.

dazu gibt es einen "Standard", auf der wir uns in der 3D-Entwicklerrunde
geeinigt haben: Zu den building:levels zählen alle Geschosse, die von
irgendeiner Seite aus oberirdisch sind - also in deinem Beispiel auch
das "Kellergeschoss".

Dass das Gebäude dann auch richtig erscheint, hängt bisher
ausschließlich von der Qualität der Geländedaten ab, die der Renderer
verwendet. Für die Zukunft ist es aber hilfreich, weitere Angaben zu
machen, die einen Rückschluss auf den Geländeverlauf entlang der
Hauswand erlauben, z.B. level-Tags an den Eingängen.

Gruß,
Tobias

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

Re: [Talk-de] 3D-Tagging: Mehrfarbige Fassaden

[Tobias Knerr]

Am 12.03.2014 22:14, schrieb Ralf GESELLENSETTER:
> Am 11.03.2014 09:44, schrieb Lars Schimmer:
>> Hmm. Ich habs immer so gemacht, das ich den Gesamtumriss des Gebäudes
>> mit building=* getaggt habe, dazu jeden einzelnen Teil mit
>> building:part, hinzu aber noch eine building Relation mit allen
>> building:part und building=*. Das brauchen manche Renderer.
> 
> Hallo, danke für deine Ausführungen. Hört sich irgendwie doppelt
> gemoppelt (redundant) an - ich hatte es so verstanden, dass gemeinsame
> Punkte bereits die Zugehörigkeit signalisieren.

Die Relation ist nur in sehr wenigen Fällen (übereinander gebaute
Gebäude) wirklich notwendig. Die Gebäudeteile lassen sich auch auf Basis
der umgebenden building-Fläche zusammensuchen, was OSM2World
beispielsweise tut.

Manche Anwendungen verlassen sich aber auch bei einfachen Fällen auf
Relationen. Damit bin ich wegen der weiteren Verkomplizierung des
ohnehin recht komplexen 3D-Mappings eher unglücklich.

> Unklar ist für mich hier, ob dann etwa gewünscht ist, dass
> Balkone und überhängende Dächer (die evtl. als building:part
> in 3D gerendert werden sollen) von der Building-Fläche
> eingeschlossen werden sollten (ich dachte eher nicht).

Die Diskussion kam in letzter Zeit immer mal wieder auf und die
Meinungen sind nicht ganz einheitlich. Meine Auffassung ist, dass
Dachüberstände nicht zur Building-Fläche gehören sollen, weil das einige
merkwürdige Effekte hätte, z.B. könnten dann Eingänge nicht mehr in den
Rand der Gebäudefläche gesetzt werden.

Das Mapping von Balkonen ist beim 3D-Mapping insgesamt noch ungeklärt.

> P.S.: Es scheint nichts dagegen zu sprechen, bei
> vertikaler Unterteilung der Fassadenfarbe einen
> way mit 2 Knoten als building:part an eine Hauswand
> zu setzen und dort die entsprechenden Farben anzugeben,
> wenn ich die entsprechenden Wikiseiten richtig
> interpretiere?

building:part sind per Definition Flächen, keine offenen Ways.

Meines Wissens ist Kendzi3D der einzige Renderer, der die Angabe der
Farbe an einzelnen Wänden unterstützt, und er nutzt dazu Ways, die
ausschließlich mit der Farbe getagt sind. Ich schätze, über die Frage
wird noch einmal diskutiert werden, wenn andere Renderer das Thema
aufgreifen.

Gruß,
Tobias

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

Re: [Talk-de] Natural Wood = Forest Landuse

[Tobias Knerr]

Am 01.03.2014 15:45, schrieb Martin Koppenhoefer:
> Für mich wäre es besser, "natural=forest" für einen Wald zu definieren, und
> "natural=wood" (od. ggf. woodland) für "Woodland" (gibt leider im Deutschen
> kein richtiges Wort dafür), beides jeweils im Sinne eines Gebiets, das
> physisch auch andere Arten von Oberfläche / Bewuchs / Nutzung enthalten
> könnte, während landuse=forest für die effektiv baumbestandenen Teile in
> Benutzung bliebe.

Vorschläge für komplett neue Tags lassen sich sicher nicht kurzfristig
umsetzen. Mit dem Ursprungsvorschlag könnten wir hingegen auf einfache
Weise eine Verbesserung des Taggingschemas erreichen, so dass endlich
auch wieder Laien wissen, was sie mit einem Haufen Bäume anfangen
sollen. Das finde ich gut und das sollte m.E. auch unser Hauptfokus sein
- nicht so sehr das Lösen aller waldbezogenen Probleme.

Gruß,
Tobias

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Tobias Knerr]

Am 05.02.2014 18:01, schrieb Martin Raifer:
> Gute Text-to-Speech Software sollte aber mit diesen Abkürzungen locker
> umgehen können. Und wenn nicht, dann bedarf es für die jeweilige
> Anwendung schlicht eines Post-Processing Schritts, der die Abkürzungen
> entsprechend expandiert.

Wie schon mehrmals in dieser Diskussion erwähnt wurde, sind
ausgeschriebene Namen einfacher (und vor allem eindeutiger) zu verkürzen
als umgekehrt. Daher genügt der volle Name, um beide Bedürfnisse
abzudecken. Wenn man nur den abgekürzten Namen hat, ist die Herleitung
der ausgeschriebenen Variante schwerer, in manchen Fällen sogar
praktisch unmöglich.

> Wieso es dem Mapper schwer machen wegen möglicherweise schlechter
> Anwendungs-Software?

Wir diskutieren hier über zwei Alternativen, die beide gleich leicht für
den Mapper sind - man muss sich eben nur auf eine festlegen.

Und noch einmal: Es geht nicht um nur "schlechte" Anwendungs-Software,
sondern um jegliche Anwendungssoftware, denn das automatische
Ausschreiben ist eben nicht so "schlicht" wie du behauptest

> Oder im OSM-Slang: „Wir mappen nicht für das
> Text-to-Speech Programm!“

Der Spruch mit dem "Wir mappen nicht für ..." bezieht sich nicht auf die
Berücksichtigung von Anwender-Interessen beim Festlegen von
Taggingregeln, sondern ausschließlich auf das bewusste Ignorieren von
Tag-Definitionen beim Mapping.

Gruß,
Tobias

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Tobias Knerr]

Am 05.02.2014 13:42, schrieb Martin Raifer:
> Wieso schreiben wir in OSM Straßennamen nicht wie ihn praktisch Jeder in
> Texten schreiben würde?

Weil der Eintrag in der Datenbank nicht nur dazu dient, dass der Name
hingeschrieben werden kann, sondern - um nur ein Beispiel zu nennen -
auch dafür, dass man ihn aussprechen kann (Text-to-Speech).

Du hast recht, dass es Abkürzungskonventionen bei Geschriebenem gibt,
aber das ist lediglich ein Argument dafür, dass z.B. Mapnik diese
Namensbestandteile immer abkürzt. Die Datenbank an sich muss aber
allgemeiner verwendbar sein.

Gruß,
Tobias

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Tobias Knerr]

Am 05.02.2014 11:10, schrieb Falk Zscheile:
> Aus Sicht von jemanden der "on the ground"
> mappt gibt es die schon. Darum dreht sich ja der Thread mittlerweile.

Ich finde, die "on the ground"-Regel wird in dieser Diskussion arg
überstrapaziert. Nach meinem Verständnis sagt diese Konvention, dass die
Situation "on the ground" als Quelle dienen soll. Darauf wendet man dann
die Taggingregeln an: Beispielsweise, dass "Anlieger frei" mit dem Wert
destination gemappt wird, obwohl das nicht wortwörtlich auf dem Schild
steht. Und eben, dass Abkürzungen ausgeschrieben werden, obwohl das
nicht wortwörtlich auf dem Schild steht.

Daher sehe ich keinen Widerspruch zwischen der "on the ground"-Regel und
der "Ausschreiben"-Regel. Der entsteht nur dann, wenn man vergisst, dass
es zwischen der Quelle (d.h. bevorzugt der Realität) und den Tags immer
einen Übersetzungsschritt gibt.

Gruß,
Tobias

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

Re: [Talk-de] Stolperstein-Relationen entsorgen?

[Tobias Knerr]

Am 04.02.2014 20:58, schrieb malenki:
> Wie verhält es sich dann mit den bereits zuvor von anderen Usern
> (teilweise "massenhaft") genutzten
> wikipedia=de:Liste von Stolpersteinen in xyz?

Das ist nun aus meiner Sicht wirklich ein Grenzfall, den ich noch
akzeptabel finde. Zwar sind Listenartikel sowie Artikel mit nur einem
Absatz für das konkrete Objekt immer etwas unschön, weil sie z.B. das
Interlanguage-System aushebeln, aber sie werden meinem Eindruck nach
auch bei anderen Objekten wie z.B. denkmalgeschützten Gebäuden als
Wikipedialink akzeptiert. Für die Verlinkung eines Listenartikels
spricht vor allem, dass das individuelle Objekt dort ja doch
beschrieben, abgebildet, mit Artikeln zu der jeweiligen Person verknüpft
etc. wird. Wenn technisch möglich würde ich in so einem Fall einen
Wikipedia-Link mit Anker (#) nutzen.

Solange es sich nicht um mechanische Edits handelt, hat der Nutzer, der
sie einträgt, aber ohnehin viel mehr Entscheidungsspielraum.

Gruß,
Tobias

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

Re: [Talk-de] Stolperstein-Relationen entsorgen?

[Tobias Knerr]

Am 04.02.2014 18:15, schrieb Martin Koppenhoefer:
> naja, ist ein bisschen ein Randfall. In vielen Fällen von Objekten, die wir
> in OSM mappen (z.B. Fluss, Kirche, See, Haus, Straße, Autobahn,  ...) ist
> es sicher nicht sinnvoll oder gewünscht, auf einen allgemeinen Artikel zu
> linken. Andererseits finde ich hier den Verweis auf Wikipedia durchaus
> interessant und sinnvoll, weil es eben nicht nur ein generischer
> "Sammelartikel"  (z.B. "Kunstwerk", "Skulptur") ist, sondern sich der
> Wikipedia-Artikel auf ein individuelles Kunstwerk bezieht (Stolperstein),
> welches halt als Besonderheit hat, dass es räumlich dezentral verteilt ist
> und sich dynamisch vergrößernd (wachsend) verhält.

Ich sehe es nicht als Randfall, sondern als eindeutig falsch. Der
wikipedia-Schlüssel ist genau dann anzuwenden, wenn der verlinkte
Artikel über dieses konkrete Objekt ist. Der Artikel "Stolpersteine" ist
aber kein Artikel über den Stolperstein für Max Mustermann in der
Beispielstraße.

Zur Betrachtung als ein einziges "dezentrales" Kunstwerk: Auf dieser
Grundlage wäre auch die Begründung für die Relationslöschung falsch
gewesen. Die Einstufung als Sammelrelation ergibt nur dann Sinn, wenn
wir die Stolpersteine als eine Gruppe von Kunstwerken betrachten, nicht
als ein einziges großes Objekt.

Aufgrund der unpassenden Verwendung des Wikipedia-Tags möchte ich darum
bitten, das massenhafte Setzen von Wikipedia-Links rückgängig zu machen.
Für diesen Aspekt des Massenedits gab es keinen vorherigen Konsens.

Gruß,
Tobias

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Tobias Knerr]

Danke für die Zahlen, aber inhaltlich überzeugt mich das nicht. ;)

Am 03.02.2014 17:44, schrieb Martin Raifer:
> Es ist doch immer einer der zentralen Doktrinen von OSM gewesen, dass es
> dem Mapper möglichst einfach gemacht werden soll, während es OK wäre,
> den Auswertern etwas mehr Arbeit aufzubürden.

Durch eine Abkürzung wird dem Mapper nichts einfacher gemacht. Denn
"alles ausschreiben" ist eine extrem einfache Regel - viel einfacher als
"manches wird ausgeschrieben, manches nicht".

> Es geht ja nicht darum,
> alle möglichen exotischen Abkürzungen (oder wirklich unauflösbare
> Abkürzungen von Vornamen) pauschal zu erlauben, sondern eben nur
> diejenigen, die im ganz normalen Sprachgebrauch üblich sind.

Es gibt aber auch (mit vertretbarem Aufwand) unauflösbare Abkürzungen im
normalen Sprachgebrauch.

Gruß,
Tobias

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

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

[Tobias Knerr]

Am 01.02.2014 14:57, schrieb Florian Lohoff:
> Ich halte Share-Alike bei Kartendaten immer noch genauso aussichtslos. 
> Ich weiss nicht was wir zu beschützen haben. Den Lizenzwechsel zu ODbL
> halte ich nach wie für für falsch. Das wird uns alle noch in den hintern
> beissen. Ich denke PD wäre langfristig das beste gewesen.

+1

Ich verstehe noch den Wunsch nach Namensnennung, aber die Pflicht zur
Veröffentlichung abgeleiteter Datenbanken hat uns bisher unter dem
Strich überhaupt nichts gebracht - außer dass kaum einer mehr unsere
Lizenz versteht.

Tobias

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

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

[Tobias Knerr]

Am 01.02.2014 16:21, schrieb Caronna:
> Am 01.02.2014 14:57, schrieb Florian Lohoff:
>> Ich weiss nicht was wir zu beschützen haben. Den Lizenzwechsel zu ODbL
>> halte ich nach wie für für falsch. Das wird uns alle noch in den hintern
>> beissen. Ich denke PD wäre langfristig das beste gewesen.
>>
> problematisch: PD wäre für Deutschland nicht möglich

Dann ersetze gedanklich "PD" durch "CC0" oder "Rechtliche Regelung zur
größtmöglichen Freigabe von Rechten im Rahmen der geltenden
Gesetzgebung". Ich gehe davon aus, dass das ohnehin gemeint war.

Gruß,
Tobias

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

Re: [Talk-de] Deutsche Ortsnamen in Osteuropa

[Tobias Knerr]

Am 24.01.2014 21:36, schrieb Martin Koppenhoefer:
> finde ich gut, alle Namen die es in Sprachen und Dialekten gibt für einen 
> Ort, dort auch einzutragen.
> 
> old_name ist in erster Linie für ehemalige Namen, wenn es einen neuen Namen 
> gibt in dieser Sprache.

Nein, old_name ist für Namen, die bei den Sprechern dieser Sprache nicht
mehr gebräuchlich sind. Ob sie heute stattdessen einen neuen Namen in
ihrer Sprache oder einen aus einer anderen Sprache verwenden, ist für
die Einstufung als old_name egal.

Tobias


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

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

[Tobias Knerr]

Am 13.01.2014 12:29, schrieb Ronnie Soak:
> Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und
> ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer
> das vernünftig unterstützt.
> 
> Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer
> plötzlich ausschlaggebend für
> die Auslegung bestehender Taggingpraxis?

Wir reden nicht von einem einzelnen Renderer, sondern von einer
software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach
dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller
Stockwerke, um es mal so auszudrücken.

Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch
in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern
u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig
verzerrtes Bild vom Gebäude.

Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine
wichtige Rolle bei der Etablierung solcher Definitionen spielt.
Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die
vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird.

Gruß,
Tobias

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

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

[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.

> 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.
Der Rest ist Kommunikation vor Ort plus Anwendungen, die sich daran
halten (und wo falsch gemapptes hässlich aussieht).

Tobias

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

Re: [Talk-de] Copyright/Attributierung innerhalb einer Karte

[Tobias Knerr]

Am 29.11.2013 10:13, schrieb marian:
> Wie wichtig ist es, dass die Attributierung tatsächlich innerhalb der Karte 
> auftaucht?

Zunächst einmal ist festzustellen: Diese strenge Platzierungsvorschrift
findet sich auf der Copyright-Seite noch gar nicht so lange. Vor einem
Jahr war davon noch nichts zu lesen:
http://web.archive.org/web/20120930071333/http://www.openstreetmap.org/copyright

Ich halte diese Anforderung für eine unnötige Einschränkung sinnvoller
Gestaltungsmöglichkeiten. Es gibt nun einmal unterschiedliche
Situationen - bei einer mobilen App ist sehr wenig Platz, bei einem
Mashup gibt es u.U. sehr viel mehr als nur eine Quelle. Originellere
Designs als das klassische Kartenrechteck haben überhaupt keine "Ecken",
und bei einem 3D-Spiel will man nicht dauerhaft Text in der
Bildschirmecke einblenden. Diese Situationen erfordern eben jeweils
geeignete Lösungen für die Attribution.

Meine Auffassung: OSM soll mindestens genauso prominent wie andere
verwendete Quellen genannt und nicht absichtlich versteckt werden. Den
Rest überlassen wir dem gesunden Menschenverstand des Designers.

Gruß,
Tobias

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

Re: [Talk-de] path am Strand fuer den Router ...

[Tobias Knerr]

Am 06.11.2013 16:41, schrieb Martin Koppenhoefer:
> mindestens die outer eines highway-Multipolygons als einfachen graph zu
> interpretieren sollte einfach sein, und würde diesen bug schon quasi lösen
> (bisher ist da dann einfach ein Loch im Graph).

Das würde ich als absolute Mindestanforderung ansehen, aber auch für den
kürzesten Weg über eine Fläche mit Hindernissen gibt es fertige
Algorithmen. Müsste man nur in den entsprechenden Programmen auch umsetzen.

Ok, "nur" - ich weiß dass beim Entwickeln man nie genug Zeit für alles
hat. Aber wie man an diesem Thread merkt, verführt das Fehlen dieses für
Navis jenseits des Autos essentiellen Features so manchen Mapper
zunehmend zu schmutzigen Hacks.

Tobias

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

Re: [Talk-de] path am Strand fuer den Router ...

[Tobias Knerr]

Am 04.11.2013 20:16, schrieb Frederik Ramm:
> Die Routing-Engine muss nun also nicht einfach nur
> Wege quer ueber den Platz produzieren (das waere ja leicht einzubauen),
> sondern sie muss alle flaechen- und linienfoermigen Objekte, die sich
> ebenfalls auf dem Platz befinden, auf ihre Hindernis-Eigenschaft hin
> untersuchen.

Wenn wirklich ein Routing-Entwickler sich von unangebrachtem
Perfektionismus dazu verleiten lässt, dieses dringende Thema weiter
schleifen zu lassen, ist das eine arge Fehleinschätzung. Lieber ab und
an mal zufällig eine komische Route durchs Denkmal erwischen statt
*immer* eine komische Route produzieren, oder?

Zumal es ja derselbe Algorithmus ist, egal ob ich nur MP-inners oder
auch sonstige Hindernisse berücksichtige. Die Arbeit wäre insofern nicht
vergeblich, auch wenn man erst mal den einfacheren Weg wählt und erst
später Detailprobleme angeht.

Also nein, diese Ausrede lasse ich nicht gelten. ;)

Gruß,
Tobias

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

Re: [Talk-de] Fahrradwege taggen, "Lübecker Methode"

[Tobias Knerr]

Am 29.10.2013 11:04, schrieb rainerU:
> - Das Schema macht Redundanz zum Prinzip. Wenn cycleway:right und 
> cycleway:left
>  vorhanden sind, braucht es nicht noch cycleway=both. Redundanz schadet 
> nichts,
> aber man sollte sie nicht obligatorisch machen. Das riecht förmlich nach 
> Taggen
> für eine Anwendung.

Dieser Punkt wäre immerhin vergleichbar mit sidewalk. Dort wird mit
sidewalk=left/right/both zuerst das Vorhandensein eines Gehsteigs
angezeigt und mit sidewalk:left/right:* werden Details zum jeweiligen
Gehsteig angegeben.

Eventuell kommt die "Inspiration" von dort?

> Letztlich bleibt als klarer und gravierender Verstoß gegen die bisherige 
> Praxis
> das Umdefinieren des Attributs cycleway.

Das will ich allerdings nicht bestreiten.

Gruß,
Tobias

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

Re: [Talk-de] Account löschen

[Tobias Knerr]

Am 19.10.2013 12:34, schrieb hike39:
> Kann mir einer von Euch einen Tipp geben?

http://wiki.openstreetmap.org/wiki/FAQ#How_can_I_close_my_account.3F

Kurz gesagt: Mail an den Support senden. Natürlich kann es gut sein,
dass einer der anderen Vorschläge dem User schon reicht.


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

Re: [Talk-de] Abgesprochener Import?

[Tobias Knerr]

Am 15.10.2013 13:29, schrieb Walter Nordmann:
> ok, aber eines solle klar sein: Egal ob technisch gesehen "Gute Daten" oder
> "Schlechte Daten" - es sind "Illegale Daten" und die müssen raus.
> OSM kann die Lizenzanforderungen des Spenders nie und nimmer erfüllen.

Wobei es in ähnlich gelagerten Fällen durch ein Gespräch mit dem Spender
oft gelungen ist, das Problem mit der Namensnennung bei OSM klar zu
machen und eine Sondergenehmigung oder Klarstellung zu bekommen.

Natürlich muss so etwas vor dem Import geschehen und auch die in diesem
Thread genannten Taggingfragen sollten vor dem Import geklärt werden.

Gruß,
Tobias

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

Re: [Talk-de] Normale Straße ?=mit =?utf-8?Q?area=yes

[Tobias Knerr]

Am 03.10.2013 14:22, schrieb Jörg Frings-Fürst:
> 
> Am Donnerstag, den 03.10.2013, 13:32 +0200 schrieb Leo Koppelkamm:
>> Was haltet ihr davon? Kommt mir z.b. bei 
>> http://www.openstreetmap.org/browse/way/206802933 ziemlich überflüssig vor.
>> Beim Tempelhofes Feld macht das ja noch Sinn, aber hier kann ich mir 
>> keinerlei Vorteile, auch nicht fürs Routing denken.
> [...]
> 
> ich sehe dort keinen Fehler. Die Straße ist als Way und als Area
> eingetragen. 

Dagegen ist erst einmal nichts zu sagen und das Tagging mit
area:highway=residential + surface=asphalt wäre für sich genommen auch
korrekt.

Leider wurden zusätzlich noch highway=residential + area=yes gesetzt,
die aber nicht die Fläche einer Straße, sondern einen Platz
kennzeichnen. Und das ist dann eben doch ein Fehler, diese beiden Tags
sollten entfernt werden.

Gruß,
Tobias

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

Re: [Talk-de] Ankündigung: Popup-Layer auf osm.org aufgefrischt

[Tobias Knerr]

Am 28.08.2013 21:54, schrieb Roland Olbricht:
> Nun, das ganze Feature ist "Mapper-orientert". Wir können keine Karte bieten, 
> in der alles angezeigt wird, was sinnvoll gemappt werden kann, weil dafür 
> keine bekannte Gestaltung mehr existiert. Das ist, wo ich eigentlich hin 
> möchte: Ein Mapper soll Rückmeldung bekommen, dass sein Objekt nicht nur als 
> XML angekommen ist, sondern eine semantische Interpretation besitzt.

Ok, das macht es für mich etwas klarer, wo du hinwillst. Generell sehe
ich osm.org eben nicht als Mapper-Werkzeugkasten, sondern als etwas, das
man z.B. auch einem neugierigen Laien zeigen können soll.

Am liebsten wäre mir dafür eine Lösung wie die "nebenan" von Peda, siehe
seine Grobskizze: http://osm.won2.de/temp/skizze.png

Fast gesamte Blase zeigt semantisch interpretierte Informationen für nur
ein Objekt, das meinte ich mit "Einzelobjekt-Ansicht". Was ich vor
seinem Vorschlag noch nicht auf dem Plan hatte ist das sehr elegante
Konzept mit den Reitern. Das wäre eine Antwort darauf, wie man mit
mehreren Objekten im Anfrage-Radius umgeht, und erspart eine getrennte
Listenansicht. Durch Sortierung nach Abstand vom Klick würde man
außerdem dafür sorgen, dass präzise Eingaben direkt beim richtigen
Objekt landen.

>> * Regionen/Grenzen wie "Nordrhein-Westfalen" weglassen, denn dafür gibt
>> es schon das "Wo bin ich?"-Feature - und sie blähen die Liste auf
> 
> Die verstopfen in der Tat das Popup. Andererseits habe ich das "Wo bin ich?"-
> Feature wiederholt nicht gefunden. "Show my location" schickt mich an meine 
> Adresse, ohne sie mir zu nennen.

Das Feature ist unter der Suchbox hinter dem erklärenden Text. Das was
du beschreibst ist ein zusätzliches Features für angemeldete Nutzer, die
einen Heimat-Standort eingetragen haben.

> Allgemeiner bräuchten wir also Mechanismen, um
> * für bestimmte Objektklassen Zoombegrenzungen vorzugeben
> * für bestimmte Objektklassen (Boundaries) Oberbegriffe einzuführen, unter 
> denen alle Objekte zusammengefasst werden

Insbesondere die Zoombegrenzungen wären sehr hilfreich für die
Übersicht, ja.

Viele Grüße,
Tobias

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

Re: [Talk-de] Ankündigung: Popup-Layer auf osm.org aufgefrischt

[Tobias Knerr]

Hallo Roland,

Am 26.08.2013 19:36, schrieb Roland Olbricht:
> Per Beispiel:
> http://overpass.apis.dev.openstreetmap.org/#map=15/50.9429/6.9541

ich muss mal etwas grundsätzlicheres loswerden. Technisch finde ich
deine Entwicklung zwar eine gute Basis und nicht zuletzt zeigt der
Anwendungsfall, wie vielseitig einsetzbar die Overpass API ist.

Nur: Mit der Benutzerschnittstelle habe ich etwas Bauchschmerzen, weil
es in eine ganz andere Richtung geht, als ich es bei der Ursprungsidee
"POI anklicken" erwartet hätte.

Bei dir ist das ziemlich analytisch umgesetzt: Man bekommt viele
Einträge in einer Liste präsentiert und kann sich die Rohdaten anschauen
- eher versteckt sogar auch eine halbwegs "übersetzte" Form.
In einer benutzerorientierten Web-Karte würde ich in einem Pop-Up aber
ansprechend gestaltete Informationen über (idealerweise) genau ein
Objekt erwarten.

Konkret wären meine Vorschläge:

* Regionen/Grenzen wie "Nordrhein-Westfalen" weglassen, denn dafür gibt
es schon das "Wo bin ich?"-Feature - und sie blähen die Liste auf

* falls praktikabel zoomstufen-abhängig arbeiten: kleine Gedenktafeln
etc. waren vom Benutzer in deiner Beispielansicht sicher nicht gemeint

* Einzelobjekt-Ansicht bieten statt nur den aufklappbaren Listeneintrag

* in der Liste "[details][tags]" weglassen und ersetzen durch einen Link
zur osm.org-Details-Seite in der o.g. Einzelobjekt-Ansicht

Sorry dafür, dass ich etwas vom Kernthema abgewichen bin, aber diese
grundsätzlichen Überlegungen haben sich mir beim erneuten Ausprobieren
aufgedrängt. Vielleicht bin ich aber auch der einzige, der das so sieht?

Gruß,
Tobias

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

Re: [Talk-de] Autokennzeichen

[Tobias Knerr]

Am 09.08.2013 09:38, schrieb Andreas Labres:
> On 09.08.13 01:00, Tobias Knerr wrote:
>> Ich hätte noch eine spontane Alternativ-Idee: Man könnte auf die
>> Erfassung in OSM verzichten und stattdessen (via wikipedia-Tag) die
>> Information von Wikidata holen.
> 
> Ich denke, es wäre ein leichtes, ein Script zu schreiben, das per Overpass die
> Kreis-Relationen durchiteriert, sich den Kennzeichen-Code aus der Wikipedia 
> holt
> und in OSM den license_plate_code Tag ergänzt (wenn er nicht schon da ist).

Bei einem Import hat man ab diesem Zeitpunkt aber doch wieder eine
Doppelerfassung mit zwei Datensätzen, die parallel gepflegt werden
müssten. (Eine langfristige Synchronisation hat noch kein mir bekannter
Import hinbekommen.)

Da fände ich eine Zusammenführung nach Bedarf auf Auswerterseite sinnvoll.

Gruß,
Tobias

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

Re: [Talk-de] Autokennzeichen

[Tobias Knerr]

Am 08.08.2013 22:00, schrieb Sarah Hoffmann:
> Ich habe gesehen, dass einige Kreis-Relationen schon einen Tag
> license_plate_code erhalten haben, aber lange noch nicht
> alle. Wäre das etwas, was man vielleicht offiziell machen könnte,
> oder gibt es vielleicht schon andere Vorschläge zum Mapping von
> Autokennzeichen, die ich übersehen habe?

Ich hätte noch eine spontane Alternativ-Idee: Man könnte auf die
Erfassung in OSM verzichten und stattdessen (via wikipedia-Tag) die
Information von Wikidata holen. Wenn ich mich nicht irre, bezieht
Nominatim bereits Wikipedia-Informationen ein?

Für die Kennzeichen wird dort afaik diese Property verwendet:
http://www.wikidata.org/wiki/Property:P395?uselang=de

Ein Problem: Die Daten sind bei Weitem noch nicht komplett. Da
allerdings die Daten für Wikipedia-Infoboxen in Zukunft aus Wikidata
kommen sollen und Autokennzeichen in den Infoboxen auftauchen, dürfte
die Community dort Interesse an einer Vervollständigung haben. Sie auch
in OSM einzutragen liefe also auf längere Sicht zwangsläufig auf eine
vermeidbare Doppelerfassung hinaus.

Gruß,
Tobias

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

Re: [Talk-de] Änderung von accepted Proposals

[Tobias Knerr]

Ich bin auch der Meinung, dass an Proposals keine inhaltlichen
Veränderungen mehr durchgeführt werden sollten, wenn sie abgeschlossen
sind. Idealerweise würden gleich danach alle Infos auf (von der
Proposal-Seite aus verlinkten) reguläre Dokumentationsseiten kopiert.

Am 04.08.2013 09:54, schrieb Wilhelm Spickermann:
> Doch, einige. Es geht um das Public Transport Proposal
> http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport

Da ist die Dokumentation schon lange nicht ideal. Es wäre an der Zeit,
alle Informationen aus dem Proposal in normale Dokumentationsseiten
einzuarbeiten (und diese dabei vielleicht gleich etwas übersichtlicher
zu machen).

Es wurde auch schon mal kurz ein Anlauf zum Archivieren des Proposals
gestartet, um solche Verwechslungen zwischen aktuellem Tagging und der
damaligen Abstimmung zu vermeiden:
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Public_Transport#Archiving_of_this_page

Nur war auch da wieder das Problem, dass nicht alle Infos von der
verlinkten "Public transport"-Seite aus verfügbar sind. Und anscheinend
hatte keiner richtig Lust, das zu ändern.

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

Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?

[Tobias Knerr]

Am 28.07.2013 15:56, schrieb Kai Krueger:
> Daten im planet file sind anonym. Das heist grundsaetzlich werden keine uid
> Daten an die Elemente im Planet angehaengt. Fuer einzelne Elemente ueber die
> API und die browse pages bleibt diese Information allerdings erhalten. Die
> Seite http://www.openstreetmap.org/user/xyzabc/edits waere dann nur noch
> fuer user mit "modaratoren privileg" einsichtbar, wobei man die Option hat
> diese fuer alle oeffentlich zu machen wenn man das will

Ich habe schon etliche lokale Probleme u.a. mithilfe der Changesetliste
und ein paar freundlichen Worten schnell gelöst. Vor ein paar Tagen z.B.
einen User, der OSM für ein Werkzeug zum Basteln eigener
Urlaubs-Routenkarten gehalten hatte und mich dann um Rücknahme seiner
Änderungen bat. Das konnte ich dank Changeset-Liste sofort erledigen,
ganz ohne irgendwelche ohnehin überlastete "Moderatoren" (und die
Verzögerung durch die Delegation hätte womöglich den Revert noch erschwert).

Die Information hilft mir dank created_by zudem, einen Neuling mit einer
technischen Frage im Forum oder auf Help nicht mit Anleitungen zu
verwirren, die für einen ganz anderen Editor als den von ihm verwendeten
geschrieben sind. Und auch beim Lizenzwechsel konnte ich mehrere Nutzer
durch solche Daten und Auswertungen wie die von Pascal erkennen und
kontaktieren.

Nicht zuletzt begrüße ich es sehr, dass ich die Möglichkeit habe, bei
Konflikten um vermeintliche Vandalen etc. mir selbst ein Bild zu machen,
statt z.B. der DWG blind vertrauen zu müssen. Wie soll ich sonst wissen
ob sie gute Arbeit machen und mein Vertrauen weiterhin verdienen?

Meine Meinung daher: Ein Verstecken dieser Daten vor der OSM-Community
wäre absolut nicht akzeptabel.

Gruß,
Tobias

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

Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?

[Tobias Knerr]

Am 25.07.2013 19:10, schrieb Dirk Sohler:
> Ja, es ist richtig, dass SÄMTLICHE DATEN,
> inklusive User-Metadaten komplett und vollumfänglich in der Datenbank
> liegen, und von jedermann für alle Zwecke ausgelesen werden (können).

Es werden keineswegs sämtliche Daten, die in der Datenbank liegen,
veröffentlicht. Klassische Benutzerdaten (wie die Mailadresse) und
beispielsweise auch bestimmte als privat eingestellte GPS-Track-Infos
sind in den Extrakten nicht enthalten.

Neben Tracks sind die wichtigsten öffentlichen Datensätze:

* die Geodaten
* die Revisionsgeschichte dieser Geodaten

Bei beidem besteht ein Nutzerbezug nur insofern, als vermerkt wird,
welcher Benutzer (ID und Username) eine Bearbeitung durchgeführt hat.

Und bei beidem ist eine freie Veröffentlichung wichtig. Die Geodaten
sind unser Produkt, da ist das wohl klar. Aber die Revisionsgeschichte
muss ebenfalls öffentlich sein, da die (dezentral programmierten)
Auswertungen dieser Information unsere Grundlage für eine
funktionierende Zusammenarbeit sind. Zudem würde das Geheimhalten dieser
Daten Abspaltungen behindern - Stichwort "Right to Fork".

Ich hätte nichts dagegen, wenn _Auswerter_ eine Opt-Out-Möglichkeit
bieten, und denke, dass das dem Konflikt einiges an Schärfe nehmen
könnte. Aber ich sehe keine Möglichkeit, die genannten Datensätze an
sich geheim zu halten, ohne an den Grundlagen unseres Projekts zu rütteln.

Gruß,
Tobias

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

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

[Tobias Knerr]

Hallo,

da habt ihr euch ja einiges vorgenommen. Leider stoßt ihr bei einigen
Sachen in Bereiche vor, wo sich die OSM-Community noch nicht wirklich
einig ist.

Ich bin mir nicht sicher, wie man da am besten zu einer Klärung kommt.
Aber versuchen wir es erst mal mit ein paar konkreten Hinweisen auf
dieser Liste:

Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:
> Objekt: Rolltreppe (Type: way)
[...]
>  Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Escalator

Es gibt ein alternatives Proposal, das im Gegensatz zu dem von euch
verwendeten "approved" ist. Es beseitigt auch ein paar Probleme bei der
Angabe der Richtung, die fürs Routing ja evtl. auch relevant ist:
http://wiki.osm.org/Proposed_features/Escalators_and_Moving_Walkways

> Objekt: Tunnel (Type: Fläche)
> 
>  - area = yes
[...]
> - building = yes (es handelt sich um ein Indoor-Elment und soll in der
> Karte angezeigt werden)

Einen Tunnel als "building = yes" zu kennzeichnen halte ich für sehr
ungewöhnlich und sicher keine etablierte Praxis.

Ich würde eher zu area:highway = footway für diese Fläche raten (unter
Annahme, dass der bestehende Way für den Tunnel als highway = footway
erfasst ist). Der Schlüssel area:highway ist zwar bisher nur ein
Vorschlag, aber das hat vor allem damit zu tun, dass Flächenerfassung
von Straßen und Wegen bei uns generell noch in den Kinderschuhen steckt.

Gruß,
Tobias

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

Re: [Talk-de] Sinn und Unsinn von Fehlermeldungen (auf osm.org)

[Tobias Knerr]

Am 21.07.2013 15:42, schrieb Dirk Sohler:
> Fehlermeldungen sollten beim Bearbeiten aufpoppen, sobald sie in einer
> Region vorhanden sind. Aktuell sind sie in JOSM allerdigns nicht mal
> auswählbar, und daher dort gar nicht ersichtlich – Man muss also immer
> zwischen mehreren Programmen hin-und-her-springen (oder gibt es eine
> Option, die ich übersehen habe).

Dieses Plugin wurde heute vorgestellt:
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Notes

Es ist allerdings noch als Beta-Version gedacht, daher vor dem Einsatz
bitte auch die Wikiseite (speziell "JOSM versions and authentication")
durchlesen.

Gruß,
Tobias

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

Re: [Talk-de] Project of the Week und Gamification

[Tobias Knerr]

Am 13.07.2013 23:59, schrieb Dirk Sohler:
> Es ist nämlich was anderes, ob jemand die Daten nimmt, und für sich
> selbst aufbereitet, oder ob er auf zusammengeführte und bereits
> aufbereitete Daten zugreifen kann.

Ja, es ist in der Tat etwas anderes:
Eines davon ist transparent, schafft ein weitgehendes Gleichgewicht der
Möglichkeiten zwischen der allgemeinen Öffentlichkeit einerseits und den
Besitzern ausgefeilter Datenanalyse-Techniken und leistungsfähiger
Hardware andererseits - und lässt den Betroffenen selbst beurteilen, was
man über ihn erfahren kann.
Das andere gibt ausgerechnet denjenigen einen Wissensvorsprung, bei
denen das potentiell richtig gefährlich ist, und lässt Betroffene und
die Öffentlichkeit im Dunkeln.

Das war jetzt vielleicht ein bisschen weit ausgeholt, aber ähnliche
Überlegungen gelten auch konkret für OSM:

Frederik beispielsweise, auf dessen Mail du ja geantwortet hast, hätte
sicher das Wissen, um solche User-Analysen selbst durchzuführen, und
könnte sie dann vielleicht im Rahmen seiner DWG-Tätigkeit bei der
Vandalismus-Bekämpfung nutzen. Aber ohne öffentliche Tools wie Pascals
Auswertungen oder einfach nur die Changeset-Liste auf osm.org könnten
wir anderen seine Entscheidungen nicht mehr beurteilen. Das passt in
meinen Augen gar nicht zu einem Projekt, das Hierarchien vermeiden will.

Ich sehe natürlich kein Problem darin, wenn du bei einem Ranking oder
Badge-Sammelspielchen nicht mitmachst. Aber ich fände es sehr
problematisch, wenn man deinen Maßstab konsequent auf alle
nutzerbezogenen Auswertungen der OSM-Daten anwenden müsste. Denn so
etwas läuft auf eine Spaltung in zwei Klassen hinaus: Privilegierte mit
Zugriff auf detaillierte Informationen - und den großen Rest.

Gruß,
Tobias

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

Re: [Talk-de] Project of the Week und Gamification

[Tobias Knerr]

Am 12.07.2013 12:02, schrieb Pascal Neis:
> Optimal wäre natürlich wenn man alle OSM-Accounts (Main-OSM,
> Wiki-OSM, OSM-Forum, OSM-Help, usw.) eines Mitgliedes miteinander
> verknüpfen und diese dann bei den Badges berücksichtigen könnte.
> Mir ist allerdings keine Lösung bekannt wie dies möglich wäre.
> Manche haben einen anderen Wiki-Account/Login als OSM Account
> und/oder Help/Forum.

Forum und Help nutzen in der Regel den normalen OSM-Account eines
Nutzers. Es mag zwar trotzdem Leute geben, die da getrennte Accounts
haben, aber das muss man m.E. für eine erste Umsetzung ebensowenig
abdecken wie Mapper, die schlicht mehrerere OSM-Accounts haben.

> Worüber ich schonmal nachgedacht habe wäre
> eine Art Wiki-Template o.ä. wo man auf seiner OSM-Userseite
> seine unterschiedlichen Accounts angeben könnte, dies könnte
> dann von *Außen* abgefragt und für weitere Dinge verwendet
> werden, klar was ich meine?

Es gibt ein Template zur Verknüpfung von Wiki-Account und OSM-Account:
http://wiki.openstreetmap.org/wiki/Template:User_username

Außerdem existieren gleich zwei zur Verknüpfung mit dem SVN-Account:
http://wiki.openstreetmap.org/wiki/Template:User_SVN
http://wiki.openstreetmap.org/wiki/Template:Svnuser

Gruß,
Tobias

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

Re: [Talk-de] Bauliche Trennung

[Tobias Knerr]

Am 07.07.2013 16:07, schrieb Wolfgang Hinsch:
> Am Sonntag, den 07.07.2013, 15:51 +0200 schrieb Tobias Knerr:
>> change:lanes und divider lassen sich nicht direkt vergleichen. Die
>> konkrete Art der Trennung kann man nämlich nur mit divider abbilden, da
>> ist change:lanes mit seinen nur vier möglichen Wertepaaren fürs
>> Überfahren - beidseitig, nur von links, nur von rechts, gar nicht - kein
>> vollständiger Ersatz.
> 
> Wenn du eine zusätzliche Möglichkeit kennst (überfliegen, überklettern,
> drunter durchtauchen ;-) ), kann man die ja noch einbauen.

Es geht mir eher um die Information, wie die Trennung denn jetzt
physikalisch umgesetzt ist. Der Trenner an sich und die daraus
abgeleiteten Verkehrsvorschriften sind eben zwei Paar Schuhe, analog zum
Unterschied zwischen barrier=bollard und dem daran angebrachten
access=no + foot=yes + ...

> Der Unterschied besteht wohl darin, dass change:lanes direkt sagt, was
> du darfst und was nicht, während man bei divider, so wie du es
> definierst, erst mal die jeweiligen Landesgesetze zu Rate ziehen muss.

Umgekehrt sagt einem divider direkt, wie es aussieht, während man bei
change:lanes die Landesgesetze kennen muss - und bei unterschiedlichen
möglichen Ausführungen auch dann noch raten muss.

Daher ist change:lanes für routing-nahe Anwendungen wie den
intelligenten Spurassistenten nützlich und divider für die grafische
Darstellung. Insofern würde ich kein entweder-oder daraus machen.

> Es gibt aber noch die Möglichkeit, mit barrier=* das jeweilige Hindernis
> einzutragen. Außerdem highway=traffic_island.

Also barrier halte ich für ungeeignet für Trenner innerhalb einer als
Einzelway dargestellten Straße - für eine Leitplanke zwischen zwei Ways
z.B. aber sicher nicht verkehrt.

traffic_island ist natürlich sinnvoll, aber eher etwas punktuelles. Und
mit dem highway-Schlüssel kenne ich das eigentlich gar nicht...?

> Eigenartigerweise gibt es noch nichts für Sperrflächen.

Ja, ist noch eine Lücke.

Tobias

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

Re: [Talk-de] Bauliche Trennung

[Tobias Knerr]

Am 07.07.2013 06:47, schrieb Wolfgang Hinsch:
> divider knapp 300 Einträge seit 12/2007
> change:lanes knapp 5000 Einträge seit 11/2012

change:lanes und divider lassen sich nicht direkt vergleichen. Die
konkrete Art der Trennung kann man nämlich nur mit divider abbilden, da
ist change:lanes mit seinen nur vier möglichen Wertepaaren fürs
Überfahren - beidseitig, nur von links, nur von rechts, gar nicht - kein
vollständiger Ersatz.

Allenfalls könnte man change:lanes als überflüssig betrachten, wenn man
annimmt, dass die Anwendung die Bedeutung von "doppelt durchgezogene
Linie" und allen anderen Trennern in dem jeweiligen Land kennt und die
derzeit in change:lanes enthaltene Information daraus ableiten kann.
Umgekehrt gilt das aber nicht.

Gruß,
Tobias

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

Re: [Talk-de] Bauliche Trennung

[Tobias Knerr]

Am 06.07.2013 15:46, schrieb Martin Koppenhoefer:
> Bisher ist glaube ich die vorherrschende Meinung, dass
> alles ausser Fahrbahnmarkierungen oder explizit überfahrbaren
> Grenzelementen (aus Kunststoff) als baulich getrennt gilt, also z.B. ein
> Grünstreifen oder ein Bordstein.

Also ich sehe derzeit nur eine bauliche Trennung ab einer gewissen
Breite (oder evtl. Höhe) als solche an. Trennungen im Zentimeterbereich
wie die von dir genannten Kunststoffelemente, aber auch Bordsteine,
zähle ich nicht dazu.

Den Bordstein als nicht als bauliche Trennung zu behandeln hat auch
deshalb eine gewisse Logik, weil er insbesondere für diejenigen
Verkehrsteilnehmer, deren Bereich damit in erster Linie abgetrennt wird
- nämlich Fußgänger - kein nennenswertes Hindernis ist. Insofern ist er
durchaus auch "explizit überfahrbar" (oder vielleicht "übergehbar").

Warum schreibe ich oben "derzeit"? Weil wir momentan noch kaum Erfahrung
mit der Nutzung von Spurinformationen in Anwendungen haben und die
Frage, was am besten in der Praxis funktioniert, nicht unberücksichtigt
bleiben sollte. Dafür ist es in dieser Diskussion aber noch zu früh.

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

Re: [Talk-de] Karte einbinden im OSM Wiki

[Tobias Knerr]

Am 05.07.2013 19:58, schrieb Gertrud Simson:
> Hat jemand eine andere Idee, wie man eine Karte mit Markern mit Links in
> einer OSM Wiki Seite einbindet?

Die Schwierigkeit sind die Marker. Die erste Wahl zum Einbinden von
Karten im Wiki wäre nämlich diese Vorlage, die aber keine Marker
unterstützt: http://wiki.openstreetmap.org/wiki/Template:Slippymap

Hintergrund dafür ist, dass Marker bei der auf dem OSM-Wikiserver
installierten SlippyMap-Erweiterung einfach nicht verfügbar sind:
http://www.mediawiki.org/wiki/Extension:SlippyMap

Es gibt zu dieser Erweiterung eine umfangreichere Alternative, die
Marker erlauben würde. Sie ist auf dem OSM-Wikiserver allerdings nicht
installiert: http://www.mediawiki.org/wiki/Extension:Maps

So, wie der OSM-Wikiserver momentan konfiguriert ist, lässt sich dein
Vorhaben also soweit ich sehe nicht in einer Wikiseite eingebettet umsetzen.

Gruß,
Tobias

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

Re: [Talk-de] Spurassistent / lanes / turn

[Tobias Knerr]

Am 05.07.2013 16:22, schrieb Florian Lohoff:
> Eine Frage die mir gekommen ist: Was ist mit
> beschleunigungs/verzoegerungsstreifen auf der Autobahn. Lanes = n+1
> und dann turn=through|through|slight_right ?

Ja. Für einen reinen Beschleunigungsstreifen würde ich allerdings
merge_to_left verwenden.

Am 05.07.2013 16:42, schrieb Eckhart Wörner:
> Am Freitag, 5. Juli 2013, 16:22:32 schrieb Florian Lohoff:
>> Ich habe da fuer mich mal ein "Best common practice" fuer das
>> Autobahnzeugs gemacht - d.h. motorway_link am begin des
>> Verzögerungsstreifens beginnend parallel fuehren etc.
>> Mit dem lanes/turn ist das dann allerdings hinfaellig denke ich.
> 
> Es ist eigentlich mehrheitlich Konsens, dass Verzögerungs- und 
> Beschleunigungsstreifen *nicht* als eigene Wege erfasst werden sollen.
> 
> http://wiki.openstreetmap.org/wiki/Autobahn#Allgemeine_Hinweise_f.C3.BCr_Autobahnen

Er hat selber erkannt, dass das frühe Aufsplitten jetzt nicht mehr
wirklich sinnvoll ist. Da braucht man jetzt keine Diskussion anfangen,
was *vor* der Verfügbarkeit von Spurtagging die sinnvollste Lösung war.

Gruß,
Tobias

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

Re: [Talk-de] Wie Adressen richtig richtig mappen?

[Tobias Knerr]

Am 26.06.2013 02:05, schrieb fly:
> On 26.06.2013 01:42, Tirkon wrote:
>> Die große Mehrheit der Mapper wird sie überhaupt nicht kennen.
> 
> Woran das wohl wieder einmal liegt ? Fehlende Relationsunterstützung der
> Editor-Software ?

Prinzipielle Eigenschaften des Konzepts "Relation", die es schwer
machen, einfach nutzbare Bedienoberflächen zum Bearbeiten von Relationen
anzubieten.

> Ich verwende ausschließlich Relationen, nicht nur weil es viele solcher
> Ausnahmen gibt, sonder auch weil sortierte Relationen eine gute
> Übersicht über noch fehlende Hausnummern bzw. seltsame Nummerierungen
> bietet.

Nun, wie häufig die Ausnahmen sind wäre natürlich interessant. Bei einer
Komplettangabe aller Werte, inkl. Postleitzahl und Ort, sollten sie sich
aber doch auch tag-basiert bewältigen lassen.

Kann ich den zweiten Teil so verstehen, dass du associatedStreet wegen
eines fehlenden Features (tabellarische Ansicht der aktuellen Auswahl
mit sortierbaren Spalten für die Werte) in den Editoren nutzt?

Gruß,
Tobias

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

Re: [Talk-de] Offizielle Definitionen der Linienfarben - KVV

[Tobias Knerr]

Am 05.06.2013 00:09, schrieb Stefan Keller:
> Bei OSM gibt es keine "offiziellen" Farben.

Es geht um das Eintragen derjenigen Farbe, die der Betreiber einer Linie
offiziell vergibt und selbst z.B. auf Nummerntafeln an den Wagen,
Anzeigetafeln an Haltestellen oder in Netzplänen verwendet.

> Siehe Diskussion "CMYK und RGB Farben - Standardisierung in OSM" hier.

Wie auch dort geht dein Kommentar wegen des zugrundeliegenden
Missverständnisses am Thema vorbei.

Diese Farbangabe ist etwas, das bereits existiert und in OSM lediglich
eingetragen würde - nichts das erst durch den OSM-Renderer bestimmt wird.

Gruß,
Tobias

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

Re: [Talk-de] Spendenkampagne 2013 der OSMF für neue Hardware

[Tobias Knerr]

Am 03.06.2013 23:22, schrieb Peter Barth:
> da fällt mir grad ein, dass ich von 2 Leuten gefragt wurde, wo man denn
> flattrn könnte. Ich hab nichts gefunden, auch keine Diskussion dazu. 

Es gibt sogar schon ein Flattr-Profil für OSM:
https://flattr.com/profile/openstreetmap

Leider ist es weder auf der schreibgeschützten Donation-Wikiseite
verlinkt, noch auf osm.org (obwohl das wohl sogar für den
Flattr-Nichtnutzer unsichtbar möglich wäre).

Eventuell sollten wir das mal auf talk ansprechen. Oder ist es anderswo
besser aufgehoben?

Gruß,
Tobias

PS: Wäre schön, wenn jemand mit entsprechenden Rechten die ebenfalls
schreibgeschützte deutsche Donation-Wikiseite noch um die Option Bitcoin
ergänzen könnte. Das fehlt in der Übersetzung bislang:

http://wiki.openstreetmap.org/wiki/DE:Donations

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

Re: [Talk-de] Alleen und Baumreihen

[Tobias Knerr]

Am 24.05.2013 15:04, schrieb RalfGesellensetter:
> Eine solche Allee zeigt auch das Bild zum Tag "natural=tree_row" [2], 
> das demnach dem Tag der Straße zugefügt werden soll:
> "... should be part of the tree row way"

Der von dir teilweise zitierte Absatz lautet:

"If individual trees in a tree row are mapped, the tree nodes should be
part of the tree row way. Usually, however, it's not necessary to map
the individual trees in a tree row."

oder in der deutschen Übersetzung:

"wenn einzelne Bäume in einer Baumreihe als Punkte eingetragen werden,
sollten die Punkte Bestandteil des Baumreihen-Ways sein. Normalerweise
ist es aber nicht nötig, die einzelnen Bäume einer Baumreihe einzutragen."

Der Absatz hat also nichts mit der Beziehung zwischen Straße und
Baumreihe zu tun. Dass das Allee-Bild ausgerechnet neben diesem Absatz
steht, hat keine tiefere Bedeutung - rechts war nur einfach wegen der
dicken Infobox kein Platz mehr.

Die Baumreihen sollten auf jeden Fall dort eingetragen werden, wo sie
wirklich sind (wieder aus der deutschen Übersetzung: "Der Weg startet am
Stamm des ersten Baums in der Reihe und endet am letzten, wobei der Weg
durch die Stämme der Bäume verläuft."), also niemals am selben Way wie
die Straße.

> Ich habe auch schon Baumreihen gesehen, die als Wald (landuse=forest)
> getagt waren, das sieht auf der Karte gut aus, ist aber eigentlich doch
> falsch, oder?

Es hat zumindest in der Praxis das Problem, dass man nichts über die
charakteristische Anordnung der Bäume weiß. In einem Wald hat man ja
normalerweise eine eher chaotische Verteilung der Bäume.

Viele Grüße,
Tobias

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

Re: [Talk-de] 3D-Mapping-Plugins oder Online-Editoren?

[Tobias Knerr]

Am 17.05.2013 22:23, schrieb Peter Wendorff:
> Ich plädiere an dieser Stelle dann erneut dafür, das als externes
> 3D-Modell-Repository abzulegen.

Es fehlt bislang an einem geeigneten Service. Der Vorstoß an der Uni
Heidelberg in diese Richtung weist m.E. schwer wiegende Mängel auf, die
seit langem nicht behoben werden. Andere Ansätze wie O3DM sind nicht
über die Konzeptphase hinaus.

Es gibt auch weitere Nachteile und ungelöste Probleme (siehe weiter
unten), dennoch würde ich ein funktionierendes 3D-Repository aber
begrüßen und mich auch um Support in OSM2World bemühen.

> In OSM codierte 3D-Modelle sind praktisch nicht mehr bearbeitbar durch
> jene, die nicht mindestens einen solchen 3D-fähigen Editor verwenden.
> 
> Ein Haus verschieben? welche der hundert Elemente muss ich da jetzt
> anpacken?

Ein einfaches 3D-Gebäude ist erst nach Anklicken von einem normalen
Gebäudeumriss zu unterscheiden, da es lediglich einige zusätzliche Tags
hat. Ich vermute, du denkst hier vor allem an die (zahlenmäßig viel
selteneren) komplexeren Beispiele wie z.B. bestimmte Kirchen.

Bei einfachen Fällen halte ich ein 3D-Repository nämlich für fehl am
Platz, denn der Aufwand für ein richtiges 3D-Modell wäre deutlich größer
als der für die zusätzlichen Tags. Bei komplexen Konstrukten sieht das
freilich anders aus.

> Ein 3D-Repository, das mit den OSM-Objekten verknüpft wird, würde
> darüber hinaus erlauben:
> - Texturen (bei Bedarf)
> - Wiederverwendbarkeit für baugleiche Reihenhäuser/Bungalows etc,
> - Entlastung der OSm-Datenbank
> - Datenformat, das echt für 3D geeignet ist.

Es würde allerdings folgende Probleme aufwerfen:

- Verknüpfung mit der Umgebung in OSM:
  wie z.B. Tür im 1. Stock mit der in OSM gemappten Treppe verbinden?
- Synchronisation mit OSM:
  wird der OSM-Way geändert, passt das Gebäudemodell nicht mehr
- Erlernen einer zweiten Software:
  es fehlt an einem laientauglichen freien Modelling-Tool
- Lizenzierung:
  nötig wäre ein rechtliches Konstrukt, um von OSM abgeleitete Daten
außerhalb der OSM-Datenbank so zu lizenzieren, dass mit OSM kompatibel
bleiben, auch nach einem Lizenzwechsel.

Zusätzlich gibt es beim Arbeiten im Modeller weitere konzeptionelle
Nachteile gegenüber parametrischen Modellen. Dazu gehören
Performance-Nachteile insbesondere dann, wenn jedes Gebäude eigene
Texturen erhält. Außerdem ist man bei der Art der Ausgabe manchmal sogar
weniger flexibel, denn ein parametrisch beschriebenes Gebäude kann z.B.
durch eine Konfigurationsänderung von einer realistischen Darstellung zu
einem Cartoon-Look umgeschaltet werden. In einem Modell-Repository wären
hier wohl verschiedene Modelle nötig.

Gruß,
Tobias

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

Re: [Talk-de] 3D-Mapping-Plugins oder Online-Editoren?

[Tobias Knerr]

Am 17.05.2013 19:22, schrieb André Reichelt:
> Daher stelle ich mir die Frage, ob es in diese Richtungen bereits
> Bemühungen gibt, beispielsweise innerhalb von JOSM eine Art 3D-Editor zu
> integrieren, der den Mapper mit Vorlagen und einer Live-Vorschau
> unterstützt.

Es gibt das Plugin "Kendzi3D", das eine Live-Vorschau innerhalb von JOSM
bietet. Außerdem existieren vom selben Entwickler auch Presets für die
Simple 3D Buildings, die Formulare für diese gängigen 3D-Tags bieten -
inklusive nette Features wie ein Dropdown-Menü mit Dachform-Skizzen.

Prinzipiell ließe sich auch OSM2World mit mäßigem Aufwand in ein
JOSM-Plugin verpacken, aber das habe ich bisher nicht gemacht, weil
Kenzi3D ja zumindest für Gebäude einen vergleichbaren Feature-Umfang bietet.

> Folgende Features wären mir dabei besonders wichtig:
>  - Gebäude bestehend aus mehreren Teilen effektiv bearbeiten können
>  - Farbinformationen möglichst direkt und automatisch aus Luftbildern
>ableiten

Für diese beiden Features gibt es meines Wissens noch nichts. Den Rest
leisten die genannten Angebote.

Gruß,
Tobias

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

Re: [Talk-de] building=yes vs. building=residential

[Tobias Knerr]

Am 16.05.2013 13:42, schrieb Falk Zscheile:
> Am 16. Mai 2013 13:31 schrieb Martin Koppenhoefer :
>> Die deutschen Seiten sind leider öfters mal keine Übersetzungen sondern
>> widersprechen gelegentlich der englischen Definition, z.T. indem sie sie
>> erweitern oder verkürzen.
>>
> 
> Wie soll es sonst auch Entwicklung geben?

Indem auch Erkenntnisse aus der deutschen Community in die
englischsprachigen Seiten einfließen? Natürlich nach entsprechendem
Austausch mit dem Rest des Projekts.

> Es kann nicht sein, dass eine
> (noch so dürftige) Definition im englischen Wiki dass Maß aller Dinge ist.
> Es gibt unterschiedlich große Communitys in den einzelnen Ländern.
> Entsprechend unterschiedlich schnell entwickelt sich das Taggingschema.

Es IST aber so, dass eine noch so dürftige Definition im englischen Wiki
das Maß aller Dinge ist.

Oder meinst du, ich lese die russische Dokumentation, bevor ich ein
neues Rendering-Feature programmiere? Das ist eine sehr aktive Community
dort, aber wenn sie es nicht schaffen, ihre Ideen mit dem Rest des
Projekts, werden sie größtenteils unter den Tisch fallen. Dasselbe gilt
für die polnische, japanische, französische und eben die deutsche Community.

Wir sind ein internationales Projekt. Unsere Datenbank, die Editoren,
Suchmaschinen, Rendering- und Routingprogramme werden zum allergrößten
Teil weltweit verwendet und wir haben auch nicht die Ressourcen, das
alles zweihundertmal zu schreiben. Von daher sind die
nationalen/regionalen Anpassungen an unserer Technik zwangsläufig
oberflächlich und verhältnismäßig klein.

> Es macht wenig Sinn etwas zur Norm zu erklären, wo sich die Community nicht
> so dynamisch entwickelt wie in Dt.

Du scheinst dem Missverständnis zu unterliegen, die englischsprachigen
Seiten seien nur dazu da, das Tagging in englischsprachigen Ländern zu
beschreiben.

Dem ist mitnichten so. Die englischsprachigen Seiten dienen der
Koordination der gesamten weltweiten OpenStreetMap-Community.

Gruß,
Tobias

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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

[Tobias Knerr]

Am 16.05.2013 12:01, schrieb Simon Poole:
> Der Vorteil von *:left und *:right im Tagnamen ist, dass es von den
> jetzigen Editoren schon unterstützt würde (Renderer müssten natürlich
> nachziehen). Jeder Tag mit solcher Semantik im Tagwert braucht einfach
> wieder ein Sonderbehandlung. 

Also zumindest bei JOSM wird beim Umdrehen aus irgendwas=forward ein
irgendwas=backward, und aus irgendwas=left ein irgendwas=right.

Das ist auch nötig, denn es gibt bereits solche Fälle, zB für Gehsteige
sidewalk = left/right/both
oder für Rolltreppen:
conveying = forward/backward/reversible

> Deine Beispiele lassen widersprüchliche
> Werte dann auch noch zu (cliff:lower_side=left, cliff:upper_side=left).

Nein, da es keinen Schlüssel cliff:upper_side geben soll.

> Ich würde deshalb wenn schon dann eher etwas in der Art wie
> cliff=lower:left verwenden (auch dies würde aber von den Editoren
> Unterstützung verlangen).

Das wäre aber wieder was neues, wohingegen left/right/forward/backward
als Werte bereits in Gebrauch sind, siehe oben.

Tobias

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

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

[Tobias Knerr]

Am 16.05.2013 09:56, schrieb Simon Poole:
> Beispiel Tagging:  
> 
> natural=cliff
> cliff:left=up
> (cliff:right=down)

Meiner Meinung nach sollte bei so etwas left/right in den Wert. Also
cliff:lower_side = left/right
city_wall:inside = left/right
oder auch
flow = forward/backward/(alternating)

Die Seiten- bzw. Richtungsangaben in den Schlüssel zu nehmen macht genau
dann Sinn, wenn man beides gleichzeitig verwenden können soll (etwa bei
zwei Gehsteigen links und rechts, die unterschiedliche surface-Werte
bekommen). Das ist hier aber nicht gewollt - bestenfalls ist es
redundant wie dein Tag in Klammern, eventuell sogar widersprüchlich.

Gruß,
Tobias

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

Re: [Talk-de] Housenumber in "addr:housename"

[Tobias Knerr]

Am 15.05.2013 17:15, schrieb Florian Lohoff:
> On Wed, May 15, 2013 at 04:08:12PM +0200, Ruben Kelevra wrote:
>> Hallo zusammen,
>>
>> ich würde gern eine Diskussion darüber starten ob man nicht per Bot
>> den Tag addr:housename=x in addr:housenumber=x umbenennen kann wenn
>> der Value eine Nummer ist.

Ich wäre dafür - und für eine deutlich zurückhaltendere Platzierung von
"housename" in den Editorpresets.

> Dagegen - Ich habe das zwar auch schon beobachtet - aber die paar
> dinger kann man manuell eben korrigieren ...

Das sind tausende Fälle, nicht "ein paar Dinger".

Tobias

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