Re: [Talk-de] TEDi - Stores richtiger Name

[Alexander Heinlein]

Hallo,

es gibt auch noch weitere Schreibweisen, bspw. T€Di, T€DI und T€di (siehe
https://taginfo.openstreetmap.org/search?q=name%3DT%E2%82%ACdi). Die sind
auch schon auf https://wiki.openstreetmap.org/wiki/WikiProject_Germany/Shops
vermerkt. Bei dieser Wiki-Seite geht es aber anscheinend nicht um das
Verwenden von einheitlichen Namen sondern darum, dass die anderen Tags
(shop=* etc.) möglichst einheitliche Werte haben sollen.

Grüße
Alex

> Gesendet: Donnerstag, 09. Juni 2016 um 13:12 Uhr
> Von: "DC Viennablog" 
> An: "talk-de@openstreetmap.org" 
> Betreff: [Talk-de] TEDi - Stores richtiger Name
>
> Hallo allerseits,
> ich habe vor kurzem ein Geschäft der Linie "TEDi" in die OSM eingetragen. Da 
> laut LOGO, Website und eben auch vor Ort TEDi am Geschäft steht, heißt die 
> Geschäftslinie wohl so. Nach einer Overpass-turbo suche ergaben sich jedoch 
> etwa 80 "TEDi" und 210 "Tedi". Dennoch dachte ich, dass (da der Name ein 
> Akronym ist, das „TEDi“ geschrieben gehört) TEDi richtig ist, und besserte 
> das (ohne zu wissen, das sowas ein mechanischer Edit ist) österreich- und 
> deutschlandweit aus. Da aber nun (wohl insofern richtiger weise) der Edit von 
> Tedi auf TEDi wieder revertiert wurde, frage ich halt hier jetzt auch nach: 
> Wie soll jetzt das Geschäft gemappt werden?
> 
> Ich persönlich kann es nicht ausstehen, wenn man ein Datenbanksystem hat (und 
> die OSM ist nicht anderes) und da sind ein und das selbe Ding (hier Filialen 
> von TEDi) in verschiedenen Schreibweisen und mit oft unterschiedlichen shop 
> Tags drinnen… Die Filialen scheinen alle ident zu sein. Also alles 
> variety-stores mit dem Namen TEDi...
> 
> Im Sinne der Einheitlichkeit wäre hier die Findung einer Namenkonvention 
> (gerne auch in der OSM-WIKI dokumentiert) wünschenswert.
> 
> Gibt es vielleicht einen Fall zum Exempel bezüglich Firmenschreibweisen?
> 
> Hoffe hier weis wer Rat!
> 
> Mit freundlichen Grüßen
> RobinD. (emergency99)
> ___
> 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] tunnel überlagert Buildings auf osm.org

[Alexander Heinlein]

 Von: nebulon42 nebulo...@yandex.com
 
 Möglicherweise ist das aber das gewünschte Verhalten, da sonst z.B. 
 Hausdurchfahrten nicht sichtbar wären.

Für Hausdurchfahrten gibt es aber extra tunnel=building_passage.

Teilweise sieht die Karte mit dem aktuellen Rendering echt kurios aus,
beispielsweise hier: 
http://www.openstreetmap.org/way/4639799#map=18/51.04115/13.73353
http://www.openstreetmap.org/way/4715664#map=18/51.04115/13.73353

Die beiden Tunnel werden über die Gebäude gerendert, aber unterhalb von
Plätzen (die ja genau genommen lediglich andere Straßen sind). Das ist
ziemlich unschön und meiner Meinung nach inkonsistent.

Grüße
Alex

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

Re: [Talk-de] OSRM Routing Problem

[Alexander Heinlein]

Hallo Bernhard,

kurios, scheint tatsächlich ein Bug in OSRM zu sein. Eigentlich sollte OSRM
Abbiegebeschränkungen können. Die Abbiegebeschränkungen passen auch alle und
oneway-Tags sind auch keine falsch gesetzt. Mit MapQuest funktioniert es und
mit GraphHopper übrigens ebenfalls:
http://graphhopper.com/maps/?point=Viernheimer%20Kreuz%2C%2068519%2C%20Deutschlandpoint=Kamenzer%20Stra%C3%9Fe%201%2C%20Mannheim

Grüße
Alex

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

Re: [Talk-de] OSRM Routing Problem

[Alexander Heinlein]

On Sun, May 03, 2015 at 09:13:24PM +0200, Alexander Heinlein wrote:
 Mit MapQuest funktioniert es und mit GraphHopper übrigens ebenfalls:
 http://graphhopper.com/maps/?point=Viernheimer%20Kreuz%2C%2068519%2C%20Deutschlandpoint=Kamenzer%20Stra%C3%9Fe%201%2C%20Mannheim

OK, der Vergleich mit GraphHopper ist schlecht, da es momentan gar keine
Abbiegebeschränkungen kann. OSRM jedoch unterstützt die einfache Variante
(way-node-way), kann jedoch noch keine ways als via. Aber die werden in
diesem Fall ja auch gar nicht verwendet.

Falls du bei GitHub angemeldet bist, kannst du hier für OSRM einen Bugreport
erstellen: https://github.com/Project-OSRM/osrm-backend/issues/new

Grüße
Alex

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

Re: [Talk-de] information=guidepost auf eine kreuzungsnode

[Alexander Heinlein]

 Gesendet: Montag, 23. März 2015 um 08:26 Uhr
 Betreff: Re: [Talk-de] information=guidepost auf eine kreuzungsnode

 On Sun, Mar 22, 2015 at 06:57:22PM +0100, Alexander Heinlein wrote:
   
Leider macht beispielsweise das JOSM-Preset genau das. Klickt man dort 
zwei
mal auf cycling, dann landet ein bicycle=no am Wegweiser. Das ist ja 
bei allen
Preset-Checkboxen so üblich, führt in diesem Fall aber zu 
Routing-Problemen.
   
   JOSM can mittlerweile das no auch unterdrücken. Kannst ja nach einem
   enchancement fragen.
  
  Ist aber leider auch nur eine halbe Lösung. Wenn man bicycle=no unterdrückt,
  dann ist nicht mehr ersichtlich, ob der Wegweiser keine Fahrradrouten
  enthält oder ob es bisher nur niemand eingetragen hat. Nicht vorhandene
  Beschilderungen für Fahrradrouten können dann einfach nicht mehr
  gekennzeichnet werden.
 
 guidepost:bicycle=yes?
 
 Ja diese namespace geschichten sind nicht formal definiert bei OSM aber
 sie werden an allen ecken und enden verwendet.

Namespaces finde ich generell immer die bessere Lösung. Es ist eindeutig
worauf sie sich beziehen und Kollisionen sind ausgeschlossen.

Grüße
Alex

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

Re: [Talk-de] information=guidepost auf eine kreuzungsnode

[Alexander Heinlein]

On Fri, Mar 20, 2015 at 04:23:06PM +0100, fly wrote:
  Solange man nicht bicycle=no für Wanderwegweiser (hiking=yes) mappt, ist
  das kein Problem.
 
  Leider macht beispielsweise das JOSM-Preset genau das. Klickt man dort zwei
  mal auf cycling, dann landet ein bicycle=no am Wegweiser. Das ist ja bei 
  allen
  Preset-Checkboxen so üblich, führt in diesem Fall aber zu 
  Routing-Problemen.
 
 JOSM can mittlerweile das no auch unterdrücken. Kannst ja nach einem
 enchancement fragen.

Ist aber leider auch nur eine halbe Lösung. Wenn man bicycle=no unterdrückt,
dann ist nicht mehr ersichtlich, ob der Wegweiser keine Fahrradrouten
enthält oder ob es bisher nur niemand eingetragen hat. Nicht vorhandene
Beschilderungen für Fahrradrouten können dann einfach nicht mehr
gekennzeichnet werden.

Grüße
Alex

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

Re: [Talk-de] information=guidepost auf eine kreuzungsnode

[Alexander Heinlein]

 Gesendet: Freitag, 20. März 2015 um 10:01 Uhr
 Von: chris66 chris66...@gmx.de
 An: talk-de@openstreetmap.org
 Betreff: Re: [Talk-de] information=guidepost auf eine kreuzungsnode

 Am 19.03.2015 um 22:08 schrieb Kurt Waldhans:
 
  Generell aber noch: ich habe noch keinen Router gefunden, der von einer
  Informations--Tafel gestoppt wurde. 
 
 Solange man nicht bicycle=no für Wanderwegweiser (hiking=yes) mappt, ist
 das kein Problem.

Leider macht beispielsweise das JOSM-Preset genau das. Klickt man dort zwei
mal auf cycling, dann landet ein bicycle=no am Wegweiser. Das ist ja bei allen
Preset-Checkboxen so üblich, führt in diesem Fall aber zu Routing-Problemen.

bicycle ist hier einfach ungünstig gewählt, idealerweise sollte man es durch
ein anderes Tag ersetzen. Leider ist so ein ersetzen bei OSM sowohl in der
Datenbank als auch bei Editoren und Auswertern nicht so einfach möglich :\ Und
dass ein bicycle=no an einem information=guidepost von Routern eine
Spezialbehandlung bekommt, kann auch schlecht verlangt werden.

Grüße
Alex

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

Re: [Talk-de] Adressenkonvertierung

[Alexander Heinlein]

Nominatim[1] kann das doch super. Solange du dich an die usage policy[2]
hälst, also insbesondere nicht mehr als eine Anfrage pro Sekunde stellst,
dürfte das kein Problem sein. Bei 100 Anfragen wärst du also in knapp 2
Minuten fertig. Alternativ nutzt du die Nominatim-Instanz von MapQuest[3],
die hat nicht ganz so harte Beschränkungen.

Grüße
Alex

  [1]: http://wiki.openstreetmap.org/wiki/Nominatim_usage_policy
  [2]: http://wiki.openstreetmap.org/wiki/Nominatim_usage_policy
  [3]: http://developer.mapquest.com/web/products/open/nominatim


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

[Talk-de] YAPIS (Yet Another Point of Interest Submitter)

[Alexander Heinlein]

Hallo,

ich bin gerade durch ein paar Bearbeitungen in meiner Gegend auf YAPIS (Yet
Another Point of Interest Submitter)[1] aufmerksam geworden. Darüber scheint
man recht einfach POIs in OSM anlegen zu können, wenn man bereits über einen
OSM-Account verfügt.

Leider scheint YAPIS bereits vorhandene POIs nicht zu berücksichtigen, so
dass regelmäßig doppelte Einträge erstellt werden. Ein paar Beispiele:

- http://www.openstreetmap.org/node/3030635133 obwohl bereits hier
  vorhanden: http://www.openstreetmap.org/node/1255815777
- http://www.openstreetmap.org/node/3030600551 obwohl bereits hier
  vorhanden: http://www.openstreetmap.org/node/683103854

(In den beiden Fällen ist der Nutzer ein Bekannter von mir, habe ihn bereits
dazu angeschrieben und ihn gebeten, über seine Bearbeitungen zu schauen und
doppelte Einträge zu korrigieren)

Kennt jemand YAPIS näher oder ist dort bereits registriert? Habe auf der
Seite leider keine Kontaktmöglichkeit gefunden, ohne mich selber
registrieren zu müssen. Dieses Problem sollte jedenfalls behoben werden,
damit die Datenbank nicht unnötig mit doppelten Daten zugemüllt wird.


Grüße
Alex


[1]: http://yapis.geoclub.de


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

Re: [Talk-de] YAPIS (Yet Another Point of Interest Submitter)

[Alexander Heinlein]

Hallo Dietmar,

On Fri, Aug 22, 2014 at 07:14:59PM +0200, Dietmar Seifert wrote:
  Kennt jemand YAPIS näher oder ist dort bereits registriert? Habe auf der
  Seite leider keine Kontaktmöglichkeit gefunden, ohne mich selber
 soweit ich weiß, ist der User moenk im OSM-Forum [1] der Betreiber von
 Yapis, Du könntest also ggfs. dort Kontakt aufnehmen.

Danke, ich habe moenk mal direkt angeschrieben.

Grüße
Alex

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

Re: [Talk-de] Rad-Wander-Skate-Routen

[Alexander Heinlein]

On Mon, Jun 02, 2014 at 02:10:49PM +0200, fly wrote:
 Am 25.05.2014 21:08, schrieb Sven Geggus:
  fly lowfligh...@googlemail.com wrote:
  
  Super, ich begegne immer wieder Situationen, wo das Semikolon die
  naheliegenste und einfachste Lösung ist und wundere mich immer warum
  sich dagegen so gesträubt wird.
  
  Lies mal den Blogpost von Jochen. Das Problem ist, dass es eben nicht
  immer so eindeutig ist was damit gemeint ist.
  
  http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html
 
 Die habe ich jetzt wiederholt gelesen und lese dort nur ein Problem mit
 der Definition.
 
 Josm wurde verbessert (ein Erfolg der letzten Diskussion), der Import
 war nicht nur in dieser Hinsicht grauenhaft und hätte nie so statt
 finden dürfen und die cadastre-Source geht auch mit Komma.
 
 Meine Punkte in der Hinsicht lauten dann eher:
 * Einigung auf ein Trennzeichen und Vermeidung dieses Zeichen bei
 anderen Bedeutungen (zB source)
 * Klare Definition bei Verwendung von Listen bzw. Verwendung eines
 eigenen Zeichen ala turn:lanes
 * Ausschluss bei Tags
 
 Diese Definitionen können alle diskutiert und dann im Wiki festgehalten
 werden. Einfach über das Problem hinweggehen und so tun als ob es nicht
 existiere verhindert Software-Unterstützung und wir werden dieses Thema
 in geraumen Abständen immer wieder diskutieren.

+1

Ich sehe auch kein Problem in der Nutzung von Semikolons, solange deren
Verwendung klar definiert ist und sie nicht für obskure Tagging-Schemata
missbraucht werden. Der Blog-Post prangert eigentlich auch nur die falsche
Verwendung und die fehlende Unterstützung in Anwendungen an. Zwei Probleme,
die behoben werden können und die auch mit alternativen Lösungen auftreten
würden.


Alex

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

Re: [Talk-de] Voting zu use_sidepath läuft

[Alexander Heinlein]

On Sat, May 10, 2014 at 08:30:36AM +0200, Christoph (TheFive@OSM) wrote:
 Was spricht dagegen, unsere Daten in einer abgeleiteten Version fürs Routing 
 zur Verfügung zu stellen. Citylimit, Radwegbenutzung, detaillierte 
 Abbiegevorschriften, alles
 was Router glücklich macht, könnte in diesen Daten drin sein. Skobbler 
 rechnet die Basisdaten auch routing tauglich um, bevor sie das in das Handy 
 schicken.
 Heraus käme z.B. eine modifizierte Overpass, die entsprechend maschinell 
 gesetzte Tags verbreitet. Und wenn wir feststellen, das es für die Router 
 besser ist, die Maxheight von einer Brücke an bestimmte Strassen zu vererben, 
 um das LKW Routing zu verbessern, kann das da auch gemacht werden.

Vieles:
 - Das weltweite vorverarbeiten dieser Daten ist entsprechend
   ressourcenintensiv (Rechenpower, Speicherplatz, Traffic)
 - Man kann diese Routingdaten vermutlich nicht tagesaktuell anbieten
 - Jemand müsste so einen komplexen Algorithmus überhaupt erst mal
   implementieren und ständig pflegen
 - Sowohl der allgemeine Mapper als auch die Entwickler von Endanwendungen
   haben dadurch keine direkte Möglichkeit mehr, Routingfehler zu
   korrigieren, die aufrgrund von Bugs in dieser Vorverarbeitung entstanden
   sind. Es entsteht eine Zwischenschicht, die untransparent ist und das
   Debugging unglaublich erschwert.
 - Router, die zusätzlich zur Berechnung der Strecke auch eine Karte
   anzeigen wollen, müssen sich zusätzlich zu diesen vorverarbeiteten Daten
   auch den Planet besorgen. Im schlimmsten Fall passt auch dann die Routen-
   darstellung mit der restlichen Kartendarstellung nicht mehr überein, weil
   beide Datensätze nicht auf dem gleichen Stand sind.

Klar hat es auch Vorteile einen zentralen Algorithmus zu haben, den nicht
jeder Router neu implementieren muss. Den sollte man aber besser als eine
Bibliothek bereitstellen, und nicht als vorverarbeitenden Datensatz.


 Ich dachte das implitize 50 wäre maxspeed =citylimit
 Ich mappe innerorts die 50 nur bei Schildern mit 50.

maxspeed=citylimit gibt es nicht. Du meinst anscheinend maxspeed=50 und
source:maxspeed=DE:urban. Auch da wird das implizite maxspeed explizit
getaggt. Oder dachtest du an maxspeed=DE:urban? Das gibt es nur 219 mal und
ist laut Wiki nur in Rumänien verbreitet (da natürlich nicht mit DE :)),
sollte daher nicht verwendet werden.


Alex

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

Re: [Talk-de] Voting zu use_sidepath läuft

[Alexander Heinlein]

On Fri, May 09, 2014 at 10:23:08PM +0200, Christoph (TheFive@OSM) wrote:
 Am 09.05.2014 um 21:31 schrieb Masi Master masi-mas...@gmx.de:
  Die blauen Radweg-Schilder geben normale Beschränkungen wieder und gelten 
  für Radweg UND Fahrbahn, also sollte auch beides getaggt werden. Hat 
  erstmal nix mit dem Routing zu tun.
  
  bicycle=designated ist zu schwammig formuliert. In Deutschland, aber vor 
  allem weltweit.
  
  Das Andere ist, dass das Bevorzugen von bicycle=designated-Radwegen nicht 
  funktioniert. Der Radweg kann länger als die Fahrbahn sein und wird teils 
  deswegen nicht bevorzugt. Oder es wird nur auf Radwegen geroutet. Außerdem 
  funktioniert kürzeste Route (nach StVO) nicht, bei unterschiedlicher 
  Gewichtung.
  
 
 Sorry, das sind Implementierungsdetails für mich. Bevorzugung ist eine 
 Möglichkeit ein Benutzungsbebot abzubilden. Schon sprachlich (ohne 
 Implementierungsdetails) merkt man, das ein gebot und eine Bevorzugung andere 
 Schwerpunkte haben, das also nicht klappen kann.
 
 Für mich ist das sich aus einem gemappten Schild abgeleitete Benutzungsverbot 
 auf einer Parallelstrasse nicht on the ground, sondern in the law, gehört 
 daher nicht in OSM.

Ich denke nicht dass man von einem Router erwarten kann sämtliche
Sonderregeln aller Länder dieser Welt zu kennen. Das implizite maxspeed=50
innerorts taggen wir doch auch explizit. Daher finde ich die Idee mit
use_sidepath gut. Es macht komplizierte Heuristiken in Routern, die sowieso
nie immer das richtige Ergebnis liefern können, unnötig und ist für Mapper
on the ground auch ziemlich einfach überprüfbar.

Alex

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

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

[Alexander Heinlein]

On Sat, Apr 05, 2014 at 12:24:20PM +0200, Stefan Keller wrote:
 Danke für euren Input! Wir haben das ReMAPTCHA [1] leicht aktualisiert.

Aber die aktualisierte Version ist noch nicht online, oder? Sieht für mich
aus wie die alte, oder übersehe ich etwas?

Grüße
Alex


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

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

[Alexander Heinlein]

On Fri, Apr 04, 2014 at 06:40:30PM +0200, fly wrote:
 Und wieso highway=pedestrian ?
 
 Ich verwende eher highway=path foot=designated
 oder
 highway=service (+ entsprechenden access tags)
 
 Achtung, ein Platz muss noch lange nicht eine Fußgängerzone sein.

Aufpassen, highway=pedestrian ist nicht ausschließlich für Fußgängerzonen.

Deutsche Definition:
 Für Wikipedia Fußgängerzone und größere Flächen mit hartem Untergrund die
 vor allem für Fußgänger gedacht sind, meist im städtischen Gebiet.

Englische Definition:
 For town centres and civic areas, where wide expanses of hard surface are
 provided for pedestrians to walk (often between shops).

Also alles, was hauptsächlich für Fußgänger gedacht ist, befestigt ist und
breiter als ein üblicher Fußweg ist.


Grüße
Alex

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

Re: [Talk-de] AFD nutzt Openstreetmap ohne Attribution in Wahlwerbeflyer in Bremen

[Alexander Heinlein]

On Thu, Apr 03, 2014 at 04:34:19PM +0200, malenki wrote:
 On  02.04.2014 01:53, Dirk-Lüder Kreie wrote:
 
  Ich hab hier grad einen Wahlflyer der AfD hier in Bremen in der Hand
  und beim Wegwerfen fiel mir eine Karte darin auf, und siehe da, es
  ist ein Ausschnitt der Bremer OSM-Karte drin, aber ohne den
  notwendigen Hinweis auf die Quelle.
 
 Ein Beweisfoto vorm Wegwerfen wäre nicht die schlechteste Idee gewesen…

Naja, schaut sich doch eh keiner an ;)

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

Re: [Talk-de] Meinungsbild noexit

[Alexander Heinlein]

On Mon, Mar 31, 2014 at 03:04:46PM +0200, Martin Koppenhoefer wrote:
 Am 31. März 2014 14:54 schrieb fly lowfligh...@googlemail.com:
 
  Bei entrance=* bin ich mir halt unsicher was nun wichtiger ist: main -
  noexit ?
 
 m.e. main, noexit ist streng genommen keine Eigenschaft des Eingangs
 sondern des Ausgangs, logischer wäre es, zusätzlich für Ausgänge einen
 Schlüssel exit zu definieren, so kann man problemlos entrance=main,
 exit=no taggen (oder z.B. exit=emergency, ...)

+1

Ein Eingang kann sowohl der Haupteingang sein, als auch bei regulärem
Betrieb nicht als Ausgang genutzt werden dürfen, als auch im Notfall
Notausgang sein. Und ich sehe keinen Grund warum man nicht all diese
Eigenschaften gleichzeitig angeben können sollte.


Grüße
Alex

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

Re: [Talk-de] Meinungsbild noexit

[Alexander Heinlein]

On Sun, Mar 30, 2014 at 02:32:09PM +0200, Martin Koppenhoefer wrote:
 benutze ich praktisch nie, den Sinn sehe ich vorwiegend in den
 Kommunikation mit anderen Mappern (und Qualityassurance tools) um zu
 bestätigen, dass ein Weg wirklich nicht weitergeht / verbunden ist. Ich
 mappe in solchen Fällen aber lieber das tatsächliche Hindernis (Mauer,
 Stützwand, Leitplanke, Zaun, Grünstreifen, Graben, etc.) bzw. den Footway,
 der für Fußgänger die Stellen verbindet.

Stellt das die gängigen QA-Tools (keep right!, OSMI, ...) denn zufrieden?   
Klar, man sollte nicht für die QA-Tools mappen, aber irgendwie muss man ja
für alle verständlich kennzeichnen, dass ein Weg tatsächlich zuende ist bzw.
keine Verbindung zu einem wenige Meter entfernten anderen Weg existiert.
Selbst wenn der Weg auf  eine Mauer/Zaun/Hecke etc. trifft, kann sich dort
immer noch ein Tor oder ähnliches befinden. noexit=yes hingegen am Endknoten
sagt hier geht es definitiv nicht weiter. Daher finde ich durchaus
sinnvoll, es ab und zu zu setzen. Natürlich nur am Endknoten und nur, wenn
es für _alle_ nicht weitergeht.

Grüße
Alex

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

Re: [Talk-de] Oeffnungszeiten

[Alexander Heinlein]

Hallo Steffen,

On Sat, Mar 29, 2014 at 06:15:45AM +0100, Steffen Wolf wrote:
 Jetzt fiel mir allerdings ein Fall auf, bei dem der Sinn der Eintragung
 strittig war. Es sah in etwa so aus:
  Mo-Fr 18:00-24:00; Fr,Sa 00:00-01:00
 
 Wenn man das nach der Wiki-Definition liest, dann ist am Freitag nur
 eine Stunde lang geoeffnet. Gemeint waren aber die sieben Stunden. Der
 Fall wurde mit allen Beteiligten zur Zufriedenheit geklaert.
 
  http://wiki.openstreetmap.org/wiki/Key:opening_hours
 | Exceptions to a range of days, first the range then the exception
 | (e.g.,  Mo-Sa 10:00-20:00; Tu off) or
 | (e.g.,  Mo-Sa 10:00-20:00; Tu 10:00-14:00)
 | (this means these are not additions, for example Mo-Fr 08:00-12:30; We
 | 14:00-17:00 means that on Wednesdays, the shop is only opened in the
 | afternoons and not additionally)

So habe ich das bisher nie interpretiert, aber du scheinst recht zu haben.
https://wiki.openstreetmap.org/wiki/Key:opening_hours:specification stimmt
dir dabei auch zu:
 The result of evaluating a rule_sequence is the result of the last rule,
 which is applicable to the particular day. Meaning that if multiple rules
 match a specific date then the last rule will overwrite all previous ones.

Das ist für mich insbesondere deswegen überraschend, weil der
OpeningHoursEditor in JOSM es falsch macht und
 We,Th 08:00-12:30; Mo 08:00-12:30,13:00-17:00
genauso interpretiert wie
 We,Th 08:00-12:30; Mo 08:00-12:30,13:00-17:00

Ich frage mich, wieviele andere Editoren/Interpreten das noch falsch machen.
Diese Regel ist auch nicht gerade auf den ersten Blick ersichtlich.


Grüße
Alex

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

Re: [Talk-de] Oeffnungszeiten

[Alexander Heinlein]

On Sat, Mar 29, 2014 at 10:03:33AM +0100, Alexander Heinlein wrote:
 Das ist für mich insbesondere deswegen überraschend, weil der
 OpeningHoursEditor in JOSM es falsch macht und
  We,Th 08:00-12:30; Mo 08:00-12:30,13:00-17:00
 genauso interpretiert wie
  We,Th 08:00-12:30; Mo 08:00-12:30,13:00-17:00

Quatsch, ich meine natürlich
 Mo,We,Th 08:00-12:30; Mo 13:00-17:00
und
 We,Th 08:00-12:30; Mo 08:00-12:30,13:00-17:00

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

Re: [Talk-de] Oeffnungszeiten

[Alexander Heinlein]

On Sat, Mar 29, 2014 at 10:32:26AM +0100, Steffen wrote:
   http://wiki.openstreetmap.org/wiki/Key:opening_hours
 | Exceptions to a range of days, first the range then the exception
 | (e.g.,  Mo-Sa 10:00-20:00; Tu off) or
 | (e.g.,  Mo-Sa 10:00-20:00; Tu 10:00-14:00)
 | (this means these are not additions, for example Mo-Fr 08:00-12:30; We
 | 14:00-17:00 means that on Wednesdays, the shop is only opened in the
 | afternoons and not additionally)
 
 Das heißt also, wenn sich die Zeiten 'überschneiden', dann gilt für den
 angebenden Tag der Eintrag als Ausnahme.
 
 Mo-Sa 10:00-20:00; Tu off
 
 Und wenn sich die Zeiten *nicht* 'überschneiden', dann gilt für den
 angebenden Tag der Eintrag als Zusatz.
 
 Mo-Fr 08:00-12:30; We 14:00-17:00

Nein. Es spielt keine Rolle, ob sie sich überschneiden oder nicht. Für ein
Datum zählt immer nur der letzte Eintrag. Das heißt, Mittwochs wäre nur
Nachmittags (also von 14:00-17:00 auf) und _nicht_, wie die restlichen
Wochentage, von 08:00-12:30.

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

Re: [Talk-de] Oeffnungszeiten

[Alexander Heinlein]

On Sat, Mar 29, 2014 at 10:59:48AM +0100, Steffen wrote:
 Nein. Es spielt keine Rolle, ob sie sich überschneiden oder nicht. Für ein
 Datum zählt immer nur der letzte Eintrag. Das heißt, Mittwochs wäre nur
 Nachmittags (also von 14:00-17:00 auf) und _nicht_, wie die restlichen
 Wochentage, von 08:00-12:30.
 
 
 okay, verstehe. Bei mir macht es der OpeningHoursEditor (V 30325) aber dann
 richtig.
 
 Wenn am Mittwoch nur nachmittags offen ist:
 
 Mo-Fr 08:00-12:30; We 14:00-17:00
 
 Wenn am Mittwoch *auch* nachmittags offen ist:
 
 Mo-Fr 08:00-12:30; We 08:00-12:30,14:00-17:00

Stimmt, das erkennt er richtig. Aber das hier nicht:

 Mo-We 08:00-12:30; We 14:00-17:00

(Mo-We statt Mo-Fr)

Da scheint noch ein Bug drin zu sein.


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

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

[Alexander Heinlein]

On Fri, Mar 28, 2014 at 10:32:32PM +0100, Stefan Keller wrote:
  Gut vorstellen könnte ich mir zum Beispiel Erkennung der
  Dachform von Häusern für das 3D-Mapping.
 
 Die Dachform wäre das Was ist hier das Unknown Word. Wo ist das Control
 Word für den Turing Test?
 
 Meinst du, dass zwei Gebäude dargestellt werden und zwei Dachformen gefragt
 werden (wobei die Dachform des einen bekannt ist)? Ich bin nicht sicher ob
 man dazu genügende passende Daten findet.

Das Problem ist darüber hinaus auch die Vielzahl an unterschiedlichen
Dachformen. 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

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

Re: [Talk-de] einfacher Router

[alexander . heinlein]

Tolle Sache! Sicher auch sehr nützlich zum Experimentieren oder als
Ausgangsbasis für etwas größeres.

Falls du einen Account bei GitHub oder ähnlichem hast, wäre es sinnvoll, das
Script auch dort zu veröffentlichen. Dann kannst du selber auch besser
nachvollziehen, was andere daraus machen.

Leider kann man das Script derzeit nicht über den Link
http://www.yamyam-fisch.de/OpenStreetMap/projekte/simpleRouter/router.py
herunterladen, da der Webserver mit einem 403 Forbidden antwortet.

Grüße
Alex

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

Re: [Talk-de] einfacher Router

[Alexander Heinlein]

On Tue, Mar 25, 2014 at 07:24:03PM +0100, Tobias wrote:
 das ist komisch irgendwie scheint mein hoster Probleme mit der
 Dateiendung zu haben.

Ich vermute, das ist nur eine Sicherheitsvorkehrung. Normalerweise liegen
Scripte auf einem Webserver eher selten zum Download bereit, sondern sollen
in der Regel ausgeführt werden. Sind sie stattdessen downloadbar,
beispielsweise aufgrund einer Fehlkonfiguration, so könnte man im
schlechtesten Fall brisante Daten aus ihnen auslesen. Vielleicht kannst du
dieses Verhalten bei dir für bestimmte Verzeichnisse umkonfigurieren.

Grüße
Alex

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

Re: [Talk-de] Access-Tags

[Alexander Heinlein]

Hallo,

On Thu, Feb 27, 2014 at 12:17:33PM +0100, Peter Wendorff wrote:
 Abgesehen davon ist ein Kernproblem der default-Frage nicht geklärt: Wie
 erkenne ich als Mapper (!), ob ich bei einer bestimmten Straße nochmal
 nachgucken sollte, was gilt, oder ob die default-Werte gelten?
 
 Dass Routingsoftware die Default-Werte annimmt ist ja schön und gut -
 aber wie unterscheidet man zwischen default und fehlend? Das ist nämlich
 leider nicht möglich.

Richtig. Die Erkennung, ob nicht gesetzte Werte fehlen oder nicht benötigt
werden da die Standardwerte ausreichen, ist momentan nicht möglich. Das
wird auch immer das Problem von Standardwerten bleiben. Wobei ich damit
nicht sagen möchte, dass Standardwerte generell schlecht sind. Denn gerade
im Fall von den Zugangsbeschränkungen stimmen die Standardwerte oft mit der
Realität überein.

Man kann alle zutreffenden Standardwerte natürlich zusätzlich explizit
eintragen, dann ist hinterher klar dass diese auch tatsächlich geprüft
wurden. Aber Wege grundsätzlich mit zig access-Tags zu versehen ist auch
ziemlich unschön.

Der Vorteil des Nicht-Eintragens von Standardwerten ist auch der, dass sich
diese aufgrund von neuen Gesetzen auch mal ändern können. Diese Änderung
wird aber nur dann automatisch übernommen (=sobald die Daten-Konsumenten
ihre Programme entsprechend angepasst haben), wenn Standardwerte nicht
nochmal explizit gesetzt wurden. Denn ansonsten muss jeder einzelne Weg
wieder per Hand aktualisiert und eigentlich auch nochmal vor Ort überprüft
werden.

Die einzige Lösung, die ich hier sehe, wäre ein zusätzliches Tag. Dieses
wird genau dann gesetzt, wenn die Standardwerte gelten, also kein
zusätzliches Schild am Weg ist. Das lässt einerseits nachvollziehen, dass
die Zugangsbeschränkungen geprüft wurden, und führt andererseits auch zu
einer automatischen Aktualisierung, falls sich diese Standardwerte durch
eine Gesetzesänderung ändern.

Grüße
Alex

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

Re: [Talk-de] Planetarium

[Alexander Heinlein]

Gute Frage, dem Zeiss-Planetarium in Jena fehlt auch noch ein derartiges
Tag: http://www.openstreetmap.org/way/197459833

Grüße
Alex

On Sat, Feb 22, 2014 at 12:24:49PM +0100, Johannes wrote:
 Hallöchen, wie taggt man ein Planetarium? Wollte mir eigentlich alle in
 meiner Umgebung raussuchen mit der Overpass-API anzeigen, aber gibt es
 da was einheitliches?
 
 Gruß Johannes
 
 ___
 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] [OT] Etrex 30: Sekundengenaue Uhrzeit abfotografieren?

[Alexander Heinlein]

Hallo,

On Mon, Dec 30, 2013 at 12:41:36AM +0100, Andreas Tille wrote:
  Das Loggen auf die Speicherkarte kann man im Hauptmenü unter
  Einstellungen/Tracks/Automatisch archivieren aktivieren, allerdings
  wird wohl nicht parallel in den internen Speicher und auf die
  Speicherkarte geloggt, sondern die Datei auf der Speicherkarte wird
  nur angelegt, wenn die Bedingung bei Automatisch archivieren
  erfüllt ist.
 
 Das habe ich jetzt mal auf täglich gesetzt.  Wäre aber lästig, wenn
 ich so immer bis zum nächsten Tag warten müßte.  Ich habe meine Tracks
 immer per SD Kartenleser kopiert und das Kabel eigentlich nie dabei
 gehabt ...

Das Archivieren kann man auch manuell anstoßen:
Track Manager - Aktueller Track - Track speichern

Dennoch etwas lästig.


Grüße
Alex

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

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

[Alexander Heinlein]

Hi,

On Mon, Nov 04, 2013 at 06:57:46PM +0100, Florian Lohoff wrote:
 ist das eigentlich Konsenz das am Strand zusätzlich ein path angelegt
 wird um das zu einem Hiking network hinzuzufügen?

 [...]
 
 Der Weg existiert ja defakto nicht.

Genau aus dem Grund halte ich das auch für nicht korrekt. Eigentlich mappen
wir nur das, was vor Ort wirklich existiert (abgesehen von so Meta-Zeug wie
Grenzen). Wenn dort trotzdem ein offizieller Wanderweg entlang führt ohne
einem vor Ort ersichtlichen Pfad, dann sollte man diesen meiner Meinung nach
lediglich als Weg (sprich way) eintragen, aber keinen highway-Tag setzen.

Grüße
Alex

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

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

[Alexander Heinlein]

Hi,

On Mon, Nov 04, 2013 at 08:03:13PM +0100, Peter Wendorff wrote:
  On Mon, Nov 04, 2013 at 06:57:46PM +0100, Florian Lohoff wrote:
  ist das eigentlich Konsenz das am Strand zusätzlich ein path angelegt
  wird um das zu einem Hiking network hinzuzufügen?
 
  [...]
 
  Der Weg existiert ja defakto nicht.
  
  Genau aus dem Grund halte ich das auch für nicht korrekt. Eigentlich mappen
  wir nur das, was vor Ort wirklich existiert (abgesehen von so Meta-Zeug wie
  Grenzen). Wenn dort trotzdem ein offizieller Wanderweg entlang führt ohne
  einem vor Ort ersichtlichen Pfad, dann sollte man diesen meiner Meinung nach
  lediglich als Weg (sprich way) eintragen, aber keinen highway-Tag setzen.
 -1
 ein way ohne Tags ist nichts, und lässt sich damit auch nicht als Pfad
 erkennen, das könnte genausogut eine versehentlich nicht getaggte Buhne
 oder sonstwas sein.
 
 Entweder nix eintragen und den Router über die Strand-Fläche routen
 lassen, oder korrekt als Weg eintragen. Wenn der ausgeschildert ist, ist
 es ein Weg, wenn er nicht sichtbar ist, haben wir auch dafür
 entsprechende Tags. Wenn einfach eine Route am Strand entlang führt,
 würde ich Tags auf die beach-Fläche setzen.

Ich schrieb ja auch gar nicht, dass der Weg gar keine Tags haben soll.
Darüber hinaus wird er im Fall von Wanderwegen zusätzlich auch noch Teil der
jeweiligen Relation sein.

Ein Routing über die Fläche und das Hinzufügen der Fläche zur Wanderrelation
ist natürlich auch eine Alternative, die aber ebenso ihre Vor- und Nachteile
besitzt.

Vielleicht bräuchte man auch einfach ein zusätzliches Tag zum Kennzeichnen,
dass dies kein echter Weg ist, sondern er lediglich dem Routing dient. Das
ist zwar ein kleines bisschen Tagging für die Router, aber löst vielleicht
ein paar Probleme.

Grüße
Alex

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

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

[Alexander Heinlein]

On Sun, Nov 03, 2013 at 11:14:39PM +0100, Garry wrote:
 Am 03.11.2013 20:10, schrieb Martin Koppenhoefer:
 
 mit traffic_sign=city_limit neben der Straße kann man innerorts / außerorts 
 darstellen, wenn alle Schilder getaggt sind, kann man die innerorts Inseln 
 bilden.
 
 Dafür gibt es zu viele Sonderfälle(so häufig, dass man sie schon
 gar nicht mehr Sonderfall nennen kann) als dass man dafür sinnvoll
 Inseln bilden könnte.
 Dass residentials meist innerorts liegen ist ehr selbstredend und
 kann in den meisten Fällen bei mehr oder weniger geschlossener
 Bebauung vorausgesetzt werden.
 Bei Strassen mit Verbindungscharakter sieht das anderst aus.

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

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

Grüße
Alex

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

Re: [Talk-de] Routing-Hinweise taggen

[Alexander Heinlein]

Hallo Andreas,

On Fri, Nov 01, 2013 at 02:12:23PM +0100, Andreas Neumann wrote:
 Osmand macht auch nicht
 wirklich einen Fehler, da die Zubringer vermutlich kürzer sind, als die
 Strecke über die Autobahn.

Die Strecke ist vielleicht kürzer, aber sicher nicht die Zeit. Jede Auf- und
Abffahrt benötigt zusätzliche Zeit, genauso wie jede zusätzliche Kreuzung
und jeder Abbiegevorgang Zeit benötigt. Wenn Osmand diese zusätzliche Zeit
nicht berücksichtigt, dann ist das meiner Meinung nach durchaus ein
Fehler, der verbessert werden muss. Dass es sich um Zubringer handelt, ist
ja bereits durch die Tags ersichtlich. Osmand muss sie auch als solche
behandeln und nicht als reguläre Straßen.

Grüße
Alex

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

Re: [Talk-de] Routing-Hinweise taggen

[Alexander Heinlein]

Hallo,

On Fri, Nov 01, 2013 at 03:01:01PM +0100, Thorsten Nau wrote:
 ich denke mal, dass das Problem darin besteht, dass die Auf- und
 Abfahrten (trunk_link) mit motorway=yes getagged sind. Für die
 Straße an sich, ist das sicherlich korrekt. Aber die Auf- und
 Abfahrten sollten aus meiner Sicht kein motorway=yes bekommen.

motorroad=yes meinst du sicher :)
Ob an die Zubringer das motorroad üblicherweise gesetzt wird oder nicht,
weiß ich nicht. Eigentlich wird damit aber auch nur etwas über die
Zugangsbeschränkungen gesagt und sollte einen Router bei der Suche nach dem
schnellsten/kürzesten Weg nicht weiter beeinflussen. Darüber hinaus ist ja
noch trunk_link gesetzt und damit offensichtlich, dass es sich um einen
Zubringer handelt.

Meiner Meinung nach ist das ein Fehler von Osmand. Die Straße daneben, die
vielleicht fünf Meter länger ist, aber weder ein Link, noch (im Fall von
Saalfeld) drei(!) zusätzliche Abbiegemanöver benötigt (Abfahren, Straße
kreuzen, Auffahren), _muss_ bevorzugt werden.

Grüße
Alex

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

Re: [Talk-de] JOSM.jnlp - HowTo

[Alexander Heinlein]

Hallo Markus,

On Wed, Oct 30, 2013 at 07:16:42PM +0100, Markus wrote:
 Nicht verstanden habe ich, was der Vorteil ist, wenn bei .jnlp bei
 jedem Programmstart das Programm neu heruntergeladen wird.

Der Vorteil ist, dass lokal nichts installiert werden muss. Das Programm
bleibt im Browser-Cache und wird idealerweise auch nur dann erneut
heruntergeladen, wenn es eine neue Version gibt.

Siehe dazu auch https://de.wikipedia.org/wiki/Java_Web_Start


Grüße
Alex

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

Re: [Talk-de] Amtliche Daten

[Alexander Heinlein]

On Tue, Oct 29, 2013 at 05:29:30PM +0100, Dirk Sohler wrote:
 Robert S. schrieb:
  Was vor Ort steht, kommt in name=* und was in der Liste steht
  könnte man in official_name=* oder auch alt_name=* packen (wenn
  es von der Lizenz passt).
 
 warum nicht name:offical?

Weil:
  - official_name über 34.000 mal benutzt wurde 
(http://taginfo.openstreetmap.org/keys/official_name)
  - name:official 6 mal benutzt wurde 
(http://taginfo.openstreetmap.org/keys/name%3Aofficial)

Prinzipiell finde ich Namespaces auch besser, aber das lässt sich nun nicht
mehr ändern.

Grüße
Alex

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

Re: [Talk-de] ID solved

[Alexander Heinlein]

On Fri, Oct 04, 2013 at 11:40:34AM +0200, Wolfgang Hinsch wrote:
 Genau um den Eintrag geht es. Er steht bei mir auf de-DE,en-US,en
 
 ...
 
 Jetzt habe ich es verstanden.
 
 Über dem Eintrag steht: Preferred Languages, 
 korrekt übersetzt mit Bevorzugte Sprachen
 
 Aus dem Plural habe ich geschlossen, dass man hier eine Rangfolge
 festlegen soll: Wenn die Spache 1 vorhanden ist - anzeigen, dann
 Sprache 2 etc bis zur Fallback - Sprache, die wohl in jedem Fall
 Englisch ist.

Das hast du denke ich auch richtig verstanden. Ich hab dort angegeben:
de-DE,de,en-US,en
Und hier ist iD auch auf deutsch. Anscheinend liegt es bei dir am fehlenden
de, das de-DE scheint an der Stelle ignoriert bzw. nicht abgefragt zu
werden. Ob das letztendlich ein Fehler oder aber konform ist, weiß ich
nicht.

Alex

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

Re: [Talk-de] Bevorzugte Sprachen

[Alexander Heinlein]

On Fri, Oct 04, 2013 at 11:59:50AM +0200, Wolfgang Hinsch wrote:
 Am Freitag, den 04.10.2013, 11:53 +0200 schrieb Alexander Heinlein:
  On Fri, Oct 04, 2013 at 11:40:34AM +0200, Wolfgang Hinsch wrote:
   Genau um den Eintrag geht es. Er steht bei mir auf de-DE,en-US,en
   
   ...
   
   Jetzt habe ich es verstanden.
   
   Über dem Eintrag steht: Preferred Languages, 
   korrekt übersetzt mit Bevorzugte Sprachen
   
   Aus dem Plural habe ich geschlossen, dass man hier eine Rangfolge
   festlegen soll: Wenn die Spache 1 vorhanden ist - anzeigen, dann
   Sprache 2 etc bis zur Fallback - Sprache, die wohl in jedem Fall
   Englisch ist.
  
  Das hast du denke ich auch richtig verstanden. Ich hab dort angegeben:
  de-DE,de,en-US,en
  Und hier ist iD auch auf deutsch. Anscheinend liegt es bei dir am fehlenden
  de, das de-DE scheint an der Stelle ignoriert bzw. nicht abgefragt zu
  werden. Ob das letztendlich ein Fehler oder aber konform ist, weiß ich
  nicht.
 
 Das ist interessant. Bei mir habe ich es geändert auf de-DE und den
 Rest gelöscht. Damit schaltet alles auf Deutsch um.
 
 Irgendwie habe ich das Gefühl, dass hier ein Bug im Spiel ist.

Wenn ein einzelnes de-DE funktioniert, aber ein am Anfang der Liste
stehendes nicht, dann klingt das sehr nach einem Bug.

Kann ich hier übrigens reproduzieren. de-DE führt zu einer deutschen
Übersetzung der Website, de ebenfalls, de-DE,de,en-US,en auch, aber
de-DE,en-US,en nicht.

Ich vermute das müsste hier berichtet werden:
http://github.com/openstreetmap/openstreetmap-website/issues
Möchtest du das tun? Ansonsten trag ich es dort ein.

Alex

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

Re: [Talk-de] Bevorzugte Sprachen

[Alexander Heinlein]

On Fri, Oct 04, 2013 at 01:10:23PM +0200, Wolfgang Hinsch wrote:
  Ich vermute das müsste hier berichtet werden:
  http://github.com/openstreetmap/openstreetmap-website/issues
  Möchtest du das tun? Ansonsten trag ich es dort ein.
  
 
 Ich habe bei Github (noch) keinen account, wenn du da schon angemeldet
 bis, wäre das insofern einfacher.

Alles klar, hab das Problem gemeldet:
https://github.com/openstreetmap/openstreetmap-website/issues/505

Alex

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

Re: [Talk-de] Bevorzugte Sprachen

[Alexander Heinlein]

On Fri, Oct 04, 2013 at 03:01:49PM +0200, Alexander Heinlein wrote:
 On Fri, Oct 04, 2013 at 01:10:23PM +0200, Wolfgang Hinsch wrote:
   Ich vermute das müsste hier berichtet werden:
   http://github.com/openstreetmap/openstreetmap-website/issues
   Möchtest du das tun? Ansonsten trag ich es dort ein.
   
  
  Ich habe bei Github (noch) keinen account, wenn du da schon angemeldet
  bis, wäre das insofern einfacher.
 
 Alles klar, hab das Problem gemeldet:
 https://github.com/openstreetmap/openstreetmap-website/issues/505

Also laut der Erklärung von tyrasd ist das (zumindest teilweise) so gewollt.
Das de-DE in de-DE,en-US,en scheint keinen Treffer zu produzieren, da
die Übersetzung nur für de vorhanden ist, aber nicht für speziellere
Varianten (auch wenn das in diesem Fall wohl auf die gleiche Übersetzung
hinauslaufen würde). Daher werden die anderen Einträge in der Liste
abgearbeitet und schließlich en genommen, für das es eine Übersetzung
gibt.

Ein einzelnes de-DE hingegen führt zu keinem Treffer, daher wird die
Sprache genommen, die dein Browser sendet. Und das ist wohl de. Also ist
es wohl das Beste, dort de einzutragen statt de-DE, oder beides.

Warum nun bei dir die Seite deutsch und der Editor englisch ist, kann ich
mir nicht erklären und hier auch nicht nachstellen.

Alex

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

Re: [Talk-de] Bevorzugte Sprachen

[Alexander Heinlein]

On Fri, Oct 04, 2013 at 04:52:05PM +0200, Andreas Labres wrote:
 Der Punkt ist, dass eine Accept-Language Angabe
 
de-de, en-us, en
 
 an sich buggy ist (nicht dem entspricht, was Du erwartest), weil Du damit 
 sagst:
 Ich verstehe nur Deutsches Deutsch (nicht aber anderes Deutsch), Ami-Englisch
 und Englisch. (und n.b. alles gleich gut, d.h. nix wird bevorzugt). Wenn Dir
 jetzt eine Website nur de oder en anbieten kann, matcht das nur mit dem 
 en
 von Dir.
 
 Sinnvoll ist eine mehrfache en oder de Angabe eigentlich auch nur, wenn man 
 dann
 beiden auch einen Quality-Wert gibt (z.B. ich bevorzuge en-us, verstehe aber
 auch andere en, also z.B: en-us;q=0.8, en;q=0.6 oder so).
 
 Und wenn man eigenlich sagen will: ich bevorzuge Deutsch, verstehe aber auch
 Englisch, sollte man de, en;q=0.8 oder so sagen.

Ja, das ist richtig. Laut RFC gibt es da keine Bevorzugung, außer man gibt
eine Qualität mit an. Was natürlich auf der Seite der Benutzereinstellungen
überhaupt nicht ersichtlich ist. Und das per Hand dort einzutippen ist
leider auch alles andere als benutzerfreundlich und ziemlich fehleranfällig.

Alex

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

Re: [Talk-de] Normale Straße mit area=yes

[Alexander Heinlein]

Wie bereits richtig gesagt ist das area:highway vollkommen in Ordnung, wird
nur leider momentan noch nicht gerendert. Das highway-Tag hingegen muss da
entfernt werden, denn der Weg darf nicht zum Routing benutzt werden, und das
area=yes gehört demnach danach auch nicht mehr gesetzt.

Ich habe übrigens vor kurzem ein Ticket zum Rendern von area:highway
angelegt:
http://github.com/gravitystorm/openstreetmap-carto/issues/180
Falls jemand in der Lage ist das mit voran zu treiben, wäre das super. Dann
gäbe es auch keinen Grund mehr, in solchen Fällen Tags zu missbrauchen, und
die Karte würde etwas hübscher aussehen.

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