Re: [Talk-de] Relation für relationale Struktur

[steffterra]

 werden muss, um zu bestimmen, welche der Möglickeiten die einfachste 
oder nötige Art ist, das abzubilden, was die Regel aussagt. Theoretisch lässt 
sich alles mit Relationen abbilden (fast). Doch sinnvoll ist es nicht immer, 
wie der umgekehrte Fall auch.

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

Re: [Talk-de] Relation für relationale Struktur

[steffterra]

Am 18.07.2010 um 14:02 schrieb Thomas Ineichen:

 Lieber Wikipedia-Benutzer,
 
 wahrscheinlich  hast  Du Dich daran gewöhnt, dass jeder Artikel in der
 Wikipedia  zu  mindestens  einer  Kategorie  gehört.  Sobald  Du einen
 Artikel  ohne  Kategorie erstellst, wird er entweder sofort als Lösch-
 kandidat  markiert oder einer Kategorie zugeordnet. Es gibt Leute, die
 den ganzen Tag nichts anderes tun als Artikeln Kategorien zuzuweisen.
 
 Relationen  in  OSM sind *keine* Kategorien. Sie sind dazu da, um eine
 enge  Verbindung (meistens lokal) zwischen Objekten herzustellen; z.B.
 'dieser  Eingang  führt  zu dieser U-Bahn-Station' oder 'Du darfst von
 dieser  Strasse  nicht  auf  jene  Strasse  abbiegen'. Sie werden auch
 benutzt,  um  zusammengehörige  Strassenabschnitte zu gruppieren [Anm:
 Sagen  wir  nicht  andernorts, Relationen für Strassen seien unnötig?]
 Allerdings  werden  Relationen  nicht  benutzt,  um  lose  Gruppen von
 irgendwie  verbundenen  Objekten  zu  sammeln.  Es gibt keine Relation
 Fusswege  in  Westangola oder Seen in Schottland. Als Wikipedianer
 hast  Du vielleicht das Bedürfnis, für jedes Objekt welches Du anfasst
 eine  passende  Relation  zu  finden  - bitte widerstehe diesem Drang.
 Unsere Datenbank ist eine räumliche Datenbank; dies bedeutet, dass die
 Datenbank  'weiss',  wo  ein  Objekt  liegt.  Wenn Du alle Fusswege in
 Westangola  anzeigen  möchtest,  dann  kannst Du einfach alle Fusswege
 innerhalb  der  Grenzen  von  Westangola  anfordern,  und die Sammlung
 Fusswege  in  Westangola  wird  in  dem Moment automatisch erstellt.
 Jeder,  der  einen  Fussweg in Westangola der Datenbank hinzufügt muss
 nur  sicherstellen, dass der Weg korrekt getagged und am richtigen Ort
 ist  - der Fakt, dass der Weg in Westangola ist, muss nicht zusätzlich
 angegeben werden.
 
 Daher, nochmals: Bitte keine Relation Fusswege in Westangola.
 
 Doch  was ist mit Gruppen wie Geldautomaten der HSBC-Bank? Auch hier
 ist  eine  Relation meistens unnötig: Wenn die Geldautomaten mit einem
 Tag  wie  operator=HSBC  versehen werden, dann kann jeder alle HSBC-
 Geldautomaten  in  der Datenbank abrufen; es wird keine Relation dafür
 benötigt.  (Eine  Relation macht bloss das Editieren komplizierter und
 fehleranfälliger.)   Gruppen-Relationen  machen  nur  sinn,  wenn  die
 Gruppierung  nicht  geographisch  (wie oben beschrieben) oder exklusiv
 (wie  das HSBC-Beispiel; es ist unwahrscheinlich, dass ein Geldautomat
 von zwei verschiedenen Banken betrieben wird) ist.
 
 Ein  gutes  Beispiel  für  eine  sinnvolle  Gruppierung ist die Route-
 Relation,  bei der mehrere Way-Elemente verbunden werden, um eine Rad-
 oder  Wanderstrecke  abzubilden.  Ein  einzelner  Weg kann in mehreren
 Routen  enthalten  sein  und  daher  kann  der  Weg  nicht einfach mit
 route=xxx getagged werden.
 
 
 Vielen Dank für Dein Verständnis,
 
 Diejenigen, welche Relationen erfunden haben
 
 [Dies  ist  nur  eine  Übersetzung  und  nicht  unbedingt meine eigene
 Meinung.]


Danke Thomas, ist drin :-)
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relation für relationale Struktur

[steffterra]

Am 18.07.2010 um 14:42 schrieb steffterra:

  Sie werden auch
 benutzt,  um  zusammengehörige  Strassenabschnitte zu gruppieren [Anm:
 Sagen  wir  nicht  andernorts, Relationen für Strassen seien unnötig?]

Hier habe ich soeben ein Beispiel ergänzt: ', wie z.B. für offiziell 
ausgeschilderte Wanderwege des Alpenvereins. Ich denke, dann ist klar, was 
gemeint ist.

Danke nochmals für die Übersetzung (bist im log erwähnt *g*), 

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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 18.07.2010 um 15:27 schrieb fly:

 Generell halte ich die Diskussion um Newbees und Relationen für fragwürdig.
 1. Existieren immer mehr Relation und man wird damit sehr schnell
 konfrontiert, somit sollte man neuen Mitglieder diese eher gut erklären
 als zu behaupten, es wäre kompliziert.

Ich schrieb ja davon, dass man sowieso Doku lesen muss und sich Hilfe holen 
sollte.

 2. Probleme sehe ich eher bei den Editors als den Mappern. Leider können
 die Editors häufig nicht gut mit Relationen umgehen.(bearbeiten/darstellen)

Auch diese sollten sich erfahrenen Usern anschließen, wenn sie es anhand von 
Doku nicht herausfinden wie es geht. Oder vorerst die Finger von Objekten 
lassen, die Teil einer Relation sind und sich vor einem erneuten Versuch 
weiterbilden.

 Als ich vor ca. 1 Jahr neu dazu kam, gab es leider noch weniger
 Dokumentation. Trotzdem war ich recht schnell mit route-Relationen
 konfrontiert. Schon beim Einfügen einer Abbiegespur mußte ich Relationen
 bearbeiten.
 
 Zu der Zeit existierten zusätzlich noch einige Bugs in JOSM, wodurch ich
 auch eine Relationen beschädigte. Darauf wurde ich von zwei erfahreneren
 Benutzern hingewiesen und wir haben die Fehler gemeinsam behoben.
 
 Diese Probleme haben mir als neues Mitglied sehr geholfen Erfahrungen
 und Verständnis zu gewinnen und zusätzlich in einer Gegend ohne
 user-group erste Kontakte zu lokalen Mappern ermöglicht.
 
 Als Anfänger macht jeder Fehler, aber gerade dadurch kann man auch viel
 lernen.

Kann ich Dir nur zustimmen und ist auch meine persönliche Erfahrung. 

Doch speziell beim Thema Adresse/Hausnummerntagging gibt es einen Unterschied 
zu anderen Relationen:

Liebe Diskussionsteilnehmer :-) 

-  Hausnummern werden dringender als alles andere in OSM benötigt. Es gibt 
immer mehr Anwendungen (u.a. OSM-Router) die unter großem Konkurrenzdruck durch 
das kostenlose Google-Turn-by-Turn-Routing stehen und OSM _noch_ als die 
bessere Alternative ansehen und deshalb nicht die Flinte ins Korn werfen, 
sondern weiter auf OSM bauen. Das Überleben für diese ist nicht leicht. 
Kommerziell wie nichtkommerzielle OSM-Routinganwendungen haben zur Zeit echt zu 
kämpfen.

Bitte helft doch mit, OSM gerade durch seinen Mehrwert gegenüber GoogleCo. 
konkurrenzfähig zu halten/machen und unterstützt das Adress-Tagging wo es geht.
Relationen kann man machen, aber Full-addr:-key-Tagging auch. Letzteres ist für 
Neuuser faktisch die beste und einfachste Möglichkeit, schnell direkt nutzbare 
Ergebnisse zu erzielen. Und diese Möglichkeit sollte man ihnen nicht nehmen, 
indem man ihnen den Einstieg in OSM übers Hausnummern-Taggen durch Relationen 
_unnötig_ erschwert.

Daher rührt mein Engagement für full-addr:-key-Tagging und gegen Relationen 
_bei Neuusern_. Denn auf die sind wir angewiesen und sie werden über die 
Anwendungen auch kommen. So wie beim maxspeed-tag auch: Aus dem Anwender eines 
OSM-Navi zum OSM-Mapper. Das Userpotential gilt es zu nutzen und nicht 
abzuschrecken.

Werbt dafür, dass Neuuser es superleicht haben, Addressen zu taggen, anstatt 
sie gleich zu Anfang mit Relationen zu demotivieren. Gebt ihnen die einfache 
Variante an die Hand!

Wenn die Daten in DE erstmal genauso vorhanden sind , wie Straßen, kann man 
immer noch darüber nachdenken, alle Addr-tags in Reltionen umzutaggen, (für 
die Redunzanreduzierung der db) was für einen Bot nicht allzu schwer sein 
sollte, wenn die Addr-Nodes und Gebäude in korrekter Straßenschreibweise mit 
PLZ, etc. im full-addr:-key-Tagging erfasst wurden. 

- Aber lasst es sie doch erstmal tun um Himmels willen! -

Es gibt kein richtig oder falsch, beides ist möglich und nicht falsch. Darf man 
da nicht das eine Verfahren für Neuuser empfehlen und das andere für erfahrene 
User??? Bitte - besonders im oben dargestellten Kontext!
Überlasst nicht google das Feld sondern erleichtert es Neueinsteigern in OSM 
Hausnummern einzutragen!

steffterra





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

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

Am 18.07.2010 um 16:06 schrieb Tirkon:

 steffterra steffte...@me.com wrote:
 
 [Vieles]
 
 Irgendwie denkst Du an bestimmten Punkten anders als ich. Ich verstehe
 Deine Auffassung in Teilen nicht und umgekehrt. Es scheint momentan
 nicht zu gelingen, diese Punkte auf dem Weg der gesschriebenen
 Kommunikation ausfindig zu machen. Da mir die Formulierung noch
 längerer Texte zu mühsam wird, gebe ich hier auf.

Dennoch war ich immer interessiert an Deiner Meinung. Schade, aber ich verstehe 
Dich und mir geht es ähnlich. Manchmal endet die Diskussionsgrundlage bei der 
Textform, stimmt.
Falls Du dennoch Interesse am weiteren Meinungsaustausch diesbezüglich hast, 
kannst Du mich ja auch gerne per eMail und dann per chat kontaktieren. Ich 
zeichne auch gerne das eine oder andere auf, falls das zum Verständnis beiträgt.

Grüße und danke für den regen Gedankenaustausch,

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

Re: [Talk-de] Behindertenparkplatz

[steffterra]

Am 18.07.2010 um 17:20 schrieb Thomas Ineichen osm.mailingl...@t-i.ch:


Daher: Irgendwelche Einwände gegen

amenity=disabled_parking
capacity=1


Ja. Es ist ja nicht disabled, sondern für Behinderte.

Also was spricht gegen
amenity=parking
capacity:total=15
capacity:handicap=1
capacity:all=10
capacity:women=2
capacity:family=5

(Anmerkung: gegen ein capacity:normal wehre ich mich, weil das  
implizieren würde, dass handicap und family, etc. Nicht normal  
wären ;-)


steffterra (der hier bisher nicht in bestehenden Proposals  
recherchiert hat)

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

Re: [Talk-de] Behindertenparkplatz

[steffterra]

Am 18.07.2010 um 18:23 schrieb Guenther Meyer d@sordidmusic.com:


Am Sonntag 18 Juli 2010, 17:51:01 schrieb steffterra:
Am 18.07.2010 um 17:20 schrieb Thomas Ineichen osm.mailingl...@t-i.ch 
:

Daher: Irgendwelche Einwände gegen

amenity=disabled_parking
capacity=1


Ja. Es ist ja nicht disabled, sondern für Behinderte.

disabled ist aber durchaus mit der gaengigste Begriff fuer  
Behinderte...


Gängig heißt bei welchen Tags (außer parking) noch? Helfe mir bitte  
auf die Sprünge mit Beispielen und Wikilinks. Danke.





Also was spricht gegen
amenity=parking
capacity:total=15
capacity:handicap=1
capacity:all=10
capacity:women=2
capacity:family=5

(Anmerkung: gegen ein capacity:normal wehre ich mich, weil das
implizieren würde, dass handicap und family, etc. Nicht normal
wären ;-)


d.h. dein all ersetzt normal?


Ja, aber all meinte nicht alle Parkplätze, sondern alle dürfen  
hier parken. Denn auch ein Handicap darf natürlich auf einem  
normalen Parkplatz parken.



find ich irgendwie komisch.


Stimme ich Dir zu. Weißt du was besseres? Ich mache unten einen neuen  
Vorschlag.


es reicht doch, die Summe anzugeben und die jeweils vorhandenen  
speziellen

Parkplaetze.


sodass sich die normalen errechnen lassen/müssen? Ok kein Aufwand  
für Anwendungen. Doch zu einer Aufzählung gehören die normalen  
eigentlich dazu. capacity:all ist aber wirklich nicht so gut, da man  
es mit capacity:total verwechseln könnte.


Gut, wie wäre es mit capacity:all_allowed für die normalen. Klingt  
doch gar nicht so schlecht, oder?


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

Re: [Talk-de] Behindertenparkplatz

[steffterra]

Am 18.07.2010 um 18:23 schrieb Guenther Meyer:

 Am Sonntag 18 Juli 2010, 17:51:01 schrieb steffterra:
 Am 18.07.2010 um 17:20 schrieb Thomas Ineichen osm.mailingl...@t-i.ch:
 Daher: Irgendwelche Einwände gegen
 
 amenity=disabled_parking
 capacity=1
 
 Ja. Es ist ja nicht disabled, sondern für Behinderte.
 
 disabled ist aber durchaus mit der gaengigste Begriff fuer Behinderte...

Ok hab ich kapiert. Leo sagt ja das disabled der Körperbehinderte ist. 
Sorry für meine schlechten Englischkenntisse.

 Also was spricht gegen
 amenity=parking
 capacity:total=15
 capacity:handicap=1
 capacity:all=10
 capacity:women=2
 capacity:family=5

Sorry. Das kommt davon, wenn man nicht in den Proposals nachschaut.

Natürlich will ich das Rad nicht neu erfinden und schließe mich erfreut dem 
vorhanden Proposal von LuLu-Ann an:

http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces

Das Proposal könnte noch um passende Symbole für Mapnik/Osmarender oder aus 
existierenden Verkehrsschildern erweitert werden. Besonders gespannt bin ich 
dabei auf capacity:horse ;-) 

Danke frü dieses Proposal Lulu-Ann! :-)

steffterra


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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 18.07.2010 um 16:41 schrieb Tobias Knerr:

 Am 18.07.2010 15:27, schrieb fly:
 Generell halte ich die Diskussion um Newbees und Relationen für fragwürdig.
 1. Existieren immer mehr Relation und man wird damit sehr schnell
 konfrontiert, somit sollte man neuen Mitglieder diese eher gut erklären
 als zu behaupten, es wäre kompliziert.
 
 Ich finde nicht, dass jeder, der in OSM mal eine Hausnummer eintragen
 will, gleich zum Mapping-Profi ausgebildet werden muss. Es sollte m.E.
 durchaus einen Platz in OSM für Leute geben, die gar nicht allzu tief
 eintauchen möchten, sondern nur ein paar Geschäfte und Hausnummern in
 ihrer Umgebung eintragen wollen. Brauchen können wir solche Beiträge
 definitiv.
 
 Für eine solche Zielgruppe stimmt dein Argument, dass man sich früher
 oder später eh mit Relationen beschäftigen muss, eben nicht. Wer nicht
 mehr machen will, als Änderungen nach Art der oben genannten einfachen
 Aufgaben, für den reichen Punkte und Polygone völlig aus.
 
 2. Probleme sehe ich eher bei den Editors als den Mappern. Leider
 können die Editors häufig nicht gut mit Relationen umgehen.
 (bearbeiten/darstellen)
 
 Tags sind eben unschlagbar einfach: Zu bearbeitendes Objekt in einer
 Kartendarstellung anklicken, Eigenschaften in einer Tabelle ändern.
 
 Daran werden auch bessere Editoren im Grundsatz nichts ändern können.

Dann ergänze ich diesen Sachverhalt auch mal im Wiki. Sollte der leichteren 
Orientierung für Neuuser dienlich sein, für welches Verfahren sie sich 
entscheiden, um das taggen von Adressen grunsätzlich zu fördern. (siehe mein 
Plädoyer in meiner vorherigen mail an die Liste)

steffterra


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

Re: [Talk-de] Behindertenparkplatz

[steffterra]

Am 18.07.2010 um 20:16 schrieb Thomas Ineichen:

 Hallo Dietmar,
 ...
 Es  ist  eben  nicht total einfach. Falls man 'amenity=parking' *auch*
 für   nur-Behinderten-Parkplätze   benutzen  möchte,  ändert  man  die
 Bedeutung  des  Tags.  


Warum. Es ist erstmal ein Parkplatz. Punkt. Und für wen er ist, wird im key 
angeben. Wo ist das Problem dieses einheitlichen, verständlichen Schemas?

 Im Gegensatz dazu ist 'capacity:disabled=*' bei
 einem  grossen  Parkplatz  eine  *Erweiterung*  des  Tags. (Das ist so
 ähnlich   wie   bei   der  Diskussion  ob  eine  Fahrschule  auch  als
 'amenity=school' getagged werden soll.)

Auch da sehe ich es genauso. Wo ist das problem, im key anzugeben, welche 
Schule es ist? Grundschule, Gesamtschule, Fahrschule ...

 Bisher  konnte  man  sich  'als normaler Autofahrer' darauf verlassen,
 dass  man bei einem Node mit 'amenity=parking' einen Parkplatz findet.
 Das sollte auch weiterhin so bleiben.

Warum sollte das anders sein? key auswerten und man weiss auch für wen der 
Parkplatz ist.

 Der  'übliche  Spruch'  wird leider von vielen - auch von Dir - falsch
 verstanden:
 http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

Ich weiss, Du meintest nicht mich persönlich. Aber genau das wäre Dein vorgehen 
doch. Nur weil der Renderer derzeit alle Parkplätze mit demselben Icon 
versieht, gibt es keinen Grund, nach einem gesunden Schema zu taggen.
Der Render wird sich darauf einstellen und für jeden key ein anderes Icon 
einbauen, um das Parken transparenter zu machen.

 Mich  juckt  es eben, ob in der Stadt Zürich plötzlich 200 neue P auf-
 blitzen, wenn dort der normale Autofahrer gar nicht parken darf.

Das ist ein Problem des Renderers, nicht des taggens.

 Daher: Irgendwelche Einwände gegen
 
 amenity=disabled_parking
 capacity=1
 
 Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst.
 
 *Falls* man die Bedeutung von 'parking' ändert.

Was sollte sich ändern. Parken ist parken. Und wer parken darf, wird im key 
angeben, udn sogar im gleichen key zusätzlich noch wie viele Parkplätze 
vorhanden sind. Das kann ein einzelner sein, oder gemischt mit anderen keys 
jeweils hunderte.

 Der einzige Grund ist das Rendern in normalen Karten. Wenn Du das nicht
 möchtest, erstell ein entsprechendes Ticket beim Renderer-System.

+1

 Die  Darstellung  auf  Karten und das Routing. Mit anderen Worten: die
 Hauptnutzungen von OSM. Wenn das mal kein Grund ist..

Es hindert aber auch die Renderer und Routing-Software nicht daran, den key 
auszuwerten. (Nebenbei erwähnt vereinfacht das einheitliche Tagging für 
Großparkplätze und Einzelparkplätze den Algorithmus ja sogar, da nciht weitere 
Tags für Einzelparkplätze untertstützt werden müssten)

 Oder besser: erstelle ein Ticket, damit die Rolli-Parkplätze mit extra
 Symbolen versehen werden. Ich habe entsprechende verfügbar, die ein normales
 P-Icon beinhalten mit dem Rolli-Symbol zusätzlich rechts davon.
 
 Eine Karte kann auch *zu* viel Information anzeigen.

dafür gibt es ja das + am rechten Rand guter openlayer-Karten ;-)

steffterra


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

Re: [Talk-de] pastafarian: Fliegendes Spaghettimonster

[steffterra]

Am 19.07.2010 um 00:13 schrieb Claudius:

 Was ist denn daran des Rausschmeissens würdig? Ist doch völlig legitim 
 (mindestens genau so, wie die anderen aufgeführten Religionen) und relevant 
 (ha, ich habs' gesagt) und tut niemandem weh, oder?
 
 Claudius
 
 Am 18.07.2010 23:59, Walter Nordmann:
 
 hi,
 
 bin beim stöbern in UNSEREM OSM-WIKI auf das hier gestoßen:
 
 http://wiki.openstreetmap.org/wiki/Key:denomination (ganz unten)
 http://wiki.openstreetmap.org/wiki/Tag:religion%3Dpastafarian
 u.s.w wo donomination oder religion ein thema ist
 
 nähere sachdienstliche hinweise hier:
 http://de.wikipedia.org/wiki/Fliegendes_Spaghettimonster
 
 werd ich demnächst wohl rausschmeißen

würde ich vorsest mal nicht.

Schaut mal hier: 
http://wiki.openstreetmap.org/w/index.php?title=Key:denominationdiff=401523oldid=398675
 angeblich wurde es tatsächlich getaggt. Nur wo? Vlt. kann dass ja mal jemand 
mit der Wirklichkeit abgleichen und in DE mal bei dem Ort nachsehen, ob das 
wirklich an der Haustüre steht und gleich  mal ein Foto machen fürs Wiki.

Hat mal jemand den Urheber der ursprünglichen Wiki-Einträge angeschrieben und 
nach seinen Beweggründen gefragt? Vlt. werden wir auch nur getestet, wie wir 
damit umgehen.

steffterra (der sonst recht offen ist, was Religionsfreiheit angeht)


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

Re: [Talk-de] pastafarian: Fliegendes Spaghettimonster

[steffterra]

Am 19.07.2010 um 00:22 schrieb steffterra:

 
 Am 19.07.2010 um 00:13 schrieb Claudius:
 
 Was ist denn daran des Rausschmeissens würdig? Ist doch völlig legitim 
 (mindestens genau so, wie die anderen aufgeführten Religionen) und relevant 
 (ha, ich habs' gesagt) und tut niemandem weh, oder?
 
 Claudius
 
 Am 18.07.2010 23:59, Walter Nordmann:
 
 hi,
 
 bin beim stöbern in UNSEREM OSM-WIKI auf das hier gestoßen:
 
 http://wiki.openstreetmap.org/wiki/Key:denomination (ganz unten)
 http://wiki.openstreetmap.org/wiki/Tag:religion%3Dpastafarian
 u.s.w wo donomination oder religion ein thema ist
 
 nähere sachdienstliche hinweise hier:
 http://de.wikipedia.org/wiki/Fliegendes_Spaghettimonster
 
 werd ich demnächst wohl rausschmeißen
 
 würde ich vorsest mal nicht.
 
 Schaut mal hier: 
 http://wiki.openstreetmap.org/w/index.php?title=Key:denominationdiff=401523oldid=398675
  angeblich wurde es tatsächlich getaggt. Nur wo? Vlt. kann dass ja mal jemand 
 mit der Wirklichkeit abgleichen und in DE mal bei dem Ort nachsehen, ob das 
 wirklich an der Haustüre steht und gleich  mal ein Foto machen fürs Wiki.
 
 Hat mal jemand den Urheber der ursprünglichen Wiki-Einträge angeschrieben und 
 nach seinen Beweggründen gefragt? Vlt. werden wir auch nur getestet, wie wir 
 damit umgehen.
 
 steffterra (der sonst recht offen ist, was Religionsfreiheit angeht)


Ergänzung: kann jemand Spanisch? 

http://wiki.openstreetmap.org/wiki/File:2020_stBN_placeofworship_pastafarian.svg
 Eintragender User: http://wiki.openstreetmap.org/wiki/User:Sergionaranja
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Job fuer einen Bot: Hoehenangabe im Namen

[steffterra]

Am 19.07.2010 um 00:24 schrieb Jonas Stein:

 Bei unzaehligen Berghuetten steht die Hoehe im Namen.
 Das hat wohl historische Gruende.

Wenn Du mit historisch gedruckte Karten meinst ...

 http://www.openstreetmap.org/browse/node/477726059
 name = Gehrenalpe (1354m)

nehme an, dass das Taggen für den Rednerer ist, da so die Höhenlöage der Hütte 
wie in Wanderkarten üblich mit angezeigt wird: 
http://b.tile.openstreetmap.org/18/138342/91687.png
Es könnte aber auch sein, dass die Höhenlage tatsächlich Teil des Namens ist, 
wie man es evtl. an der Hütte selbst auch lesen könnte - falls dem häufig so 
ist.

 Hier waere ein umtaggen nach ele=* gut:
 http://wiki.openstreetmap.org/wiki/Key:ele
 
 Wer kennt sich damit aus?

Schreib ihn doch bitter erstmal an, und weise ihn nett darauf hin, dass das so 
nicht gedacht ist. Sicher war es nicht böse gemeint.

Schöne Woche,
steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Stats OSM Routing View 2010-07

[steffterra]

Am 18.07.2010 um 21:50 schrieb Pascal Neis:

 Hi,
 weil doch hin und wieder vereinzelt Anfragen kommen:
 Die neue monatliche Statistik zum Routing View Deutschland
 findet sich unter:
 http://neis-one.org/2010/07/18/stats-osm-routing-view-2010-07/
 
 Wer nur Interesse am Diagramm der Bundesländervergleiche hat:
 http://neis-one.org/wp-content/uploads/2010/07/Stats_OSMI_R_V_201007.png

Erstmal Danke dafür.

Darf ich fragen was da in Hessen passiert ist? Von einem Monat (11.06.10) auf 
den anderen (17.07.10) wurden die Fehler um fast die Hälfte reduziert? Und 
davor (10.05.10) waren sie sogar weniger als am 17.07.10?
Wurde da großflächig gepfuscht und dann kurz darauf alles auf einen Schlag 
wieder Rückgängig gemacht?

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

Re: [Talk-de] Behindertenparkplatz

[steffterra]

Am 19.07.2010 um 00:42 schrieb Thomas Ineichen:

 Guten Tag Guenther Meyer,
 
 Nicht im bisher genutzen Sinne von amenity=parking.
 
 Das mag sein, aber es widerspricht auch nicht der Definition.
 
 Welcher Definition?
 
 Diese  sollten eine gewisse Größe aufweisen, es sollte also nicht für
 jede kleine Möglichkeit ein Auto abzustellen ein Parkplatz eingetragen 
 werden.
 http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking
 
 Bei meinem Problem geht es aber gerade um einzelne Parkplätze.

Ich vermute so langsam, Du meinst: nicht eingezeichnete Plätze an denen man 
parken kann, kann das sein? Wenn Parkplätze nicht als solche irgendwie auf dem 
Asphalt eingezeichnet, oder ausgeschildert sind, dann ist jeder Platz ein 
Parkplatz, sofern er nicht gegen andere StVO-Regeln verstößt, wie z.B. das 
Parken in einer Kurve oder vor einer Kreuzung, da hier Abstände einzuhalten 
sind. Da ist es in der Schweiz sicher nicht so viel anders als in DE.

ABER: Davon sprichst Du ja gar nicht, da obiges keine Parkplätze sind, sondern 
einfach nur Straße, auf der Parken erlaubt ist, wie überall, wo nicht gesondert 
geregelt (zumindest in DE ist es so). In Deiner ursprünglichen Frage ging es 
aber sogar um _einzelne_ Behindertenparkplätze. Doch, dass diese solche in DE 
welche sind, müssen sie so ausgeschildert sein. Natürlich dürfen auch 
Behinderte überall dort parken, wo es nicht gesondert geregelt ist, solange die 
StVO eingehalten wird.
Aber sorry - das ist gar nicht zu taggen, da es einfach Straße ist, da weder so 
ausgeschildert, noch am Asphalt eingezeichnet, also kein extra Parkplatz und 
schon gar nicht extra für Behinderte reserviert. Achtung Ironie Wenn man 
jeden Platz, wo man theoretisch parken dürfte als Parkplatz taggen würde, dann 
sollte man auch horse miteinbeziehen...

 Wenn  ein  Tagging  dazu  führt,  dass  die  Daten auf *allen* anderen
 Renderern  zu  einem neuen, ungewollten Ergebnis führen, dann darf man
 sich  ruhig überlegen, ob man vielleicht nicht doch sein Taggin-Schema
 ändern sollte..
 
 nochmal: das bestehende Schema enthaelt alles Notwendige und ist gut
 dokumentiert. Wenn ein Renderer damit nicht zurechtkommt, ist das erst mal
 sein Problem.
 
 Nein.  Wer möchte, dass sein Schema benutzt wird, der sollte sich auch
 Gedanken  über  die technische Umsetzung machen. Z.B. den Kompliziert-
 heits-Aspekt, den Du nicht zitiert hast.

Was ist daran kompliziert. Kompliziert wird es dann, wenn neben einem einfachen 
Schema, noch weitere Tags _speziell_ für Einzelparkplätze von Dir eingeführt 
werden oder willst Du das gar nicht? (btw, ausser amenity=bicycle_parking 
gibt e derzeit keinen anderen parking-tag und das ist gut so. So muss nur 
dieser eine in ein amenity=parking und capacity:bicycle=yes geändert werden 
und gut ists. Das kann sehr einfach ein bot erledigen, sobald dass Proposal 
angenommen wurde: 
http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces

z.B. capacity:disabled:yes gibts schon jetzt offiziell im wiki: 
http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking  Es ist also längst 
etabliert, also führe bitte nichts neues ein. Das Rad muss nicht neu erfunden 
werden. 

 Hübsches Beispiel, wie man eine Karte unbrauchbar macht:
 http://www.openstreetmap.org/?lat=41.97575lon=2.81843zoom=15layers=B000FTF

Wenn das alles ausgezeichnete Parkplätze sind, ist es doch nicht falsch. Das 
Tagging kann auch nichts dafür, dass alle drei Renderer hier nicht unter 
verschiedenen Parkplatzarten unterscheiden. Dass tatsächlich 
Behindertenparkplätze darunter sind, kann man in JOSM einfach nachschauen. 

Sieht übrigens sehr schön aus in JOSM - lauter Bäume. ;-)

Und äh - wie war nochmal Deine Frage zu Beginn des Threads?

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

Re: [Talk-de] pastafarian: Fliegendes Spaghettimonster

[steffterra]

Am 19.07.2010 um 00:49 schrieb Walter Nordmann:

 Hat mal jemand den Urheber der ursprünglichen Wiki-Einträge angeschrieben
 und nach seinen Beweggründen gefragt? Vlt. werden wir auch nur getestet, wie
 wir damit umgehen.
 steht doch im richtigen wiki alles drin (s.o.) 

Du meinst hier: http://de.wikipedia.org/wiki/Fliegendes_Spaghettimonster
Dann lasst es doch drin ihr lieben. ;-)

steffterra



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

Re: [Talk-de] Adressen mit PostGIS zusammenbasteln

[steffterra]

Am 17.07.2010 um 02:08 schrieb Sven Geggus:

 Ich möchte für eine Karte mit Spezial POI Adressen auch anzeigen wenn
 nur addr:housenumber erfasst wurde.

Das könnte auch für eine OSM-Navigation interessant sein. Denn nicht immer ist 
vollständig getaggt.

 Die Straße rauszufinden ist noch relativ einfach, man sucht einfach
 den nächsten way mit
 highway='residential','living_street','primary','secondary','tertiary','unclassified'

Was machst Du bei Gebäuden / Nodes mit addr:housenumber an Straßenkreuzungen? 
Woher weisst Du, zu welcher Straße deren Adresse gehört. Selbst wenn der 
Eingang getaggt sein sollte, ist das kein zuverlässiger Hinweis, dass dessen 
Seite zur Strtaße zeigt, zu dem die Hausnummer gehört. Das weiss ich aus 
eigenen Erfahrungen beim Hausnummerntaggen.

 Nun möchte ich aber gerne auch PLZ und Hausnummer rausfinden. Hat da
 schon mal jemand was probiert?

Hausnummern? Hast dich verschrieben oder? Aber bei der PLZ, Stadt/Ortschaft und 
Land bin ich auch sehr gespannt, ob das jemand konkret hinbekommt. Vor allem, 
wenn die einen Häuser einer Straße zur einen PLZ gehören und die anderen zu 
einer anderen der gleichen Stadt.

Freue mich auf Ergebnisse,
steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 17.07.2010 um 12:27 schrieb Tilmann Sult:

 Das in die Relation nur eine Straße hereinkommt ist Schwachsinn.

k.a., aber ...

 Ich
 trage auch mehrere Straßen in die Relation ein und zumindest Nominatim
 kommt damit klar (siehe
 http://www.openstreetmap.org/browse/relation/454381).

... Du hast in dieser Relation auch nur eine Straße (Sterndamm), natürlich mit 
allen ways dieser Straße, vlt. meintest Du mehrere ways und nicht mehrere 
Straßen und damit kommt Nominatim natürlich klar, weil es weiss, dass alle 
Hausnummern dieser Relation zum Straßennnamen Sterndamm gehören.

Ich denke es war gemeint, dass man nicht mehrere Straßen im Sinne von 
Straßennamen nicht in eine Relation gehören, weil man sonst nicht weiss welche 
Hausnummer zu welchem Straßennamen gehören. Deshalb dafür eigene Relationen 
erstellen, wenn es denn schon Relationen sein müssen. Denn in dieser Diskussion 
haben wir ja festgestellt, dass das zwar die schönere Datenart ist, aber das 
full-addr:-tagging nach Karlsruher Schema die praktikabelste Lösung für das 
nachfolgende Mappen/Änderungen an der betroffenen Straße ist.

 Womit wieder
 einmal belegt ist, dass nicht alles was im Wiki steht auch so umgesetzt
 wird.

Ob man sich ans Wiki hält oder nicht steht sowieso jedem (technisch, aber nicht 
moralisch) frei. Ob das dann _allgemeinen_ Zuspruch findet, es anders zu 
machen, kann man in Diskussionen wie dieser hier und neuen Proposals 
herausfinden.

 Und die Kontrolle finde ich jetzt auch besser, da man nur gucken muss,
 ob alle Objekte in der Relation enthalten sind und nur noch die in der
 Relation enthaltenen Adressdaten kontrollieren muss.

Und bei Deinem Beispiel sieht man, dass noch lange nicht alles enthalten ist, 
was an POI's und Gebäuden schon (noch ohne Hausnummer) erfasst ist. Ob 
vollständig getaggt ist, kann man aber auch sehen, wenn man die Hausnummern 
durch Mehrfachmarkierung in JOSM anklickt und eben mal schnell vervollständig 
;-) Geht sogar leichter und schneller, als die Hausnummern in die Relation 
aufzunehmen, da in JOSM nur ein Klick entfernt . 

Aber dass das full-addr:-tagging nach Karlsruher Schema fürs Erfassen und vor 
allem spätere Editieren an den Straßen praktikabler ist, wurde ja nun schon 
mehrfach erwähnt und ist der eigentliche Outcome dieser Diskussion.

steffterra


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

Re: [Talk-de] Adressen mit PostGIS zusammenbasteln

[steffterra]

Am 17.07.2010 um 13:10 schrieb Sven Geggus:

 steffterra steffte...@me.com wrote:
 
 Was machst Du bei Gebäuden / Nodes mit addr:housenumber an Straßenkreuzungen?
 
 Im Extremfall die falsche Straße erraten. Funktionierende Glaskugeln sind
 AFAIK noch nicht erfunden worden.

Eben, deshalb halte ich dieses vorgehen für fragwürdig, weil dann jede Straße 
an jeder Einmündung und am Anfang und Ende jeweils mind. 2 potentielle 
50/50-Falsch-Richtig-Zuweisungen aufweist. Das ist IMHO zuviel und ich wäre als 
User not amused, zur falschen Adresse gelotst zu werden. Der nicht 
OSM-affinie-Navi-User würde sagen: Scheiss OSM-Navi, findet an Eckhäusern nur 
ab und zu die richtige Adresse :-(

 Nun möchte ich aber gerne auch PLZ und Hausnummer rausfinden. Hat da
 schon mal jemand was probiert?
 
 Hausnummern?
 
 Gemeint war der Ort. Wenn man die PLZ hat dürfte der aber nicht mehr
 das Problem sein.

Hört sich einfach an, aber wie machst Du es technisch? Eigene Datenbank wie das 
PLZ-Buch der Post  bei der die Straßennamen in PLZ einsortiert sind (gibts das 
überhaupt noch in gedruckter Form - ich befürchte es...)?

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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 17.07.2010 um 14:41 schrieb Tilmann Sult:

 On 07/17/2010 01:32 PM, steffterra wrote:
 
 ... Du hast in dieser Relation auch nur eine Straße (Sterndamm), natürlich 
 mit allen ways dieser Straße, vlt. meintest Du mehrere ways und nicht 
 mehrere Straßen und damit kommt Nominatim natürlich klar, weil es weiss, 
 dass alle Hausnummern dieser Relation zum Straßennnamen Sterndamm gehören.
 
 Ich denke es war gemeint, dass man nicht mehrere Straßen im Sinne von 
 Straßennamen nicht in eine Relation gehören, weil man sonst nicht weiss 
 welche Hausnummer zu welchem Straßennamen gehören. Deshalb dafür eigene 
 Relationen erstellen, wenn es denn schon Relationen sein müssen. Denn in 
 dieser Diskussion haben wir ja festgestellt, dass das zwar die schönere 
 Datenart ist, aber das full-addr:-tagging nach Karlsruher Schema die 
 praktikabelste Lösung für das nachfolgende Mappen/Änderungen an der 
 betroffenen Straße ist.
 
 Also soweit ich die Diskussion verstanden habe, war das Argument bei
 veränderten Tags der Straße (oneway, cycleway, surface etc.) müsse man
 neue Relations für jede Änderung anlegen. Dies stimmt aber nicht,

DAS stimmt in der Tat nicht, aber was gesagt wurde und wiederum stimmt, ist, 
dass wenn man den way selbst ändert, teilt, etc (und das wurde auch so 
kommuniziert), dass man dann als nicht so firmer User dann mit den Relationen 
schneller konfroniert wird. Wenn man nun davon ausgeht, dass aus Deiner 
Argumentations-Sicht heraus idealerweise alle Straßen und Hausnummern in 
Relationen erfasst werden, haben wir an allen Straßen mit Hausnummern genau das 
Problem, das sich entweder keiner mehr traut, die ways (nicht die tags am way) 
zu ändern, oder dass viele street-associated-Realtionen kaputt gemacht werden.
Nur deshalb war das die Hauptargumentation, warum das normale 
full-addr:-tagging nach Karlsruher Schema das _praktikablere Vorgehen ist. 
Außerdem ist OSM noch sehr schlecht mit Hausnummern getaggt und man solle es 
nicht unnötig durch (relativ zum tagging wesentlich komplizierteren) Relationen 
zu erschweren.

Hast Du bestimmt überlesen...

 Aber dass das full-addr:-tagging nach Karlsruher Schema fürs Erfassen und 
 vor allem spätere Editieren an den Straßen praktikabler ist, wurde ja nun 
 schon mehrfach erwähnt und ist der eigentliche Outcome dieser Diskussion.
 
 Finde ich nicht. Wenn zum Beispiel die Straße umbenannt wird, müssten
 erst einmal alle zugehörigen Hausnummern gesucht werden und dann
 umbenannt, während bei der Relation nichts verändert werden müsste,
 solange die Straße einheitlich umbenannt wird.

Das ist ein Argument - aber wie oft werden Straßennamen umbenannt? :-) Und dann 
ist es doch IMHO wichtiger es vor allem Neuusern zu erleichtern, sich fürs 
Hausnummern-tagging zu begeistern, ohne ihn mit Relationen konfrontieren zu 
müssen, was nur einen Bruchteil der Neuuser _nicht_ abschrecken dürfte.

 Oder falls irgendjemand die addr:city und addr:country bei bestimmten
 Hausnummern gelöscht hat, weil er meinte diese seien aus der Geometrie
 ableitbar,

Dafür sollte man das Wiki lesen, und das tut man schon als Neuuser, der nciht 
einfach so über OSM herfällt. Letzterem Nicht-Wiki-Leser bringst Du auch nicht 
Relationen bei ;-)

 Die Pflege der Daten ist damit mit Relations einfacher.

vielleicht für Dich, aber sicher nicht für Neuuser, die einfach nur Hausnummern 
taggen wollen.

 Deswegen nehme
 ich den etwas höheren Erfassungsaufwand auf mich.

wie gesagt, Dir sei das zugestanden, aber die praktikablere Lösung ist wegen 
seiner Einfachheit (vor allem für Neuuser, die man zum Hausnummerntaggenm 
gewinnen möchte) einfach das direkte Eigneschafttagging der addr:-Tags am 
Gebäude oder Node.

steffterra


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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

 btw, die Wiki-Seite wird insgesamt komisch gerendert. Woran kann das liegen? 
 Sie war übrigens auch schon so, als ich sie heute das erste mal sah ;-) Vlt. 
 kann mal jemand drüber schauen und ggf. mitteilen, woran das lag. Denn schon 
 im Editiermodus ist das Rednering der Seite eigenartig ist und auch im 
 weiteren Text das Textrendering von Fettschrift, innerhalb des 
 Editierbereichs nach dem Speichern nicht korrekt angezeigt wird.
 
 http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/De:Hausnummern

Habe den Fehler im Proposal gefunden und behoben. War aus dem Januar 09 ;-) 
Danke dennoch.

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

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

 bestimmte 
Fahrtrichtung vorgeben (z.B. nur rechts abbiegen). Doch sollten sie das 
taggen der durchgezogenen Mittellinie als Eigenschaft am way _nicht ersetzen_, 
da sie nicht für jeden Fall ein vollwertiger Ersatz sind und der Zusatznutzen 
weiterer Verkehrsregeln, die sich aus der durchgezogenen Mittellinie ergeben 
(wie z.B. das Überholverbot) nicht genutzt würde und extra erfasst werden 
müsste.

Alles klar?

Vlt. ist der Sachverhalt deshalb so schwierig zu diskutieren, weil es eben 
nicht einfach ist, alle vor- und Nachteile abzuwägen und sauber zu 
argumentieren, wenn schon verschiedene Relationenarten (Abbiegerelationen  und 
die Zusammenfassung der ways mit durchgezog. Mittellinie in einer Relation) 
verwechselt werden.

Wenn noch Fragen offen sind, werde ich keinem vorwerfen, diese zu stellen.

optimistische Grüße,

steffterra



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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 16.07.2010 um 13:43 schrieb Tobias Knerr:

 Am 15.07.2010 23:12, schrieb Mitja Kleider:
 
 3. Häuser zu einer Relation associatedStreet mit dem Namen der Straße
 hinzufügen - das klingt sinnvoll! Also eine Relation pro Straßennamen
 hinzufügen und dann alle Häuser an der Straße als Mitglieder dieser
 Relation.
 [...]
 Diese Variante wird bisher kaum verwendet. Spricht aber auch grundsätzlich
 etwas dagegen?
 
 Node anklicken/setzen und in einem Preset oder einer Tag-Tabelle etwas
 eintragen schafft so ziemlich jeder. Relation korrekt anlegen nicht ohne
 weiteres.
 
 Gerade Hausnummern eintragen ist aber etwas, wo OSM durchaus die
 Unterstützung der breiten Masse gebrauchen kann. Diese Tätigkeit muss
 man nicht durch Relationseinsatz künstlich der OSM-Elite vorbehalten.
 
 Vor allem hat die Relation ja keinen praktischen Vorteil! Sie ist, je
 nach Software, sogar umständlicher auszuwerten; sie verteilt die
 History-Information einer Adresse auf unterschiedliche Objekte (das
 Haus, die Relation und den Way); sie erhöht gerade bei langen Straßen
 die Wahrscheinlichkeit von Bearbeitungskonflikten; sie vergrößert den
 Unterschied zu anderen Ausprägungen von Adressen (nicht alles basiert
 auf Straßennamen, es gibt z.B. auch Block-bezogene Adressen); ...
 
 Die associatedStreet-Relation ist einer der Fälle, wo man sich und
 anderen mit abstrakten Prinzipien (Redundanzvermeidung), die bei
 näherer Betrachtung in dem jeweiligen Anwendungsfall gar nicht von
 Belang sind, das Leben nur unnötig schwer macht.
 Meine Meinung jedenfalls.

volle Zustimmung + 1000 ;.-)

steffterra


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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 16.07.2010 um 13:44 schrieb Nils Faerber:

 Thomas Ineichen wrote:

 auch finde ich die Suche via Realtionen auch nicht so fürchterlich
 tragisch, wenn man den Straßenrelationen noch ein paar Tags mitgeben
 würde, wie eben bspw. die restlichen Adreßdaten wie Ort/PLZ. Dann ließe
 sich die Suche komplett in den Relationen bewerkstelligen. Für den
 Ortswechsel innerhalb einer Straße würde ich dann schlicht zwei oder
 mehr Relationen anlegen.

Und das sind dann unterm Strich weniger bytes?

 Wenn ja, dann sollte man den Straßennamen nicht in den name= setzen,
 sondern die normalen addr:city addr:postcode addr:street
 verwenden.

Das setzen wir doch voraus. Immerhin geht es darum _Adress_informationen als 
Eigenschaft des Gebäudes zu taggen. Ich verstehe immernoch nicht, welchen 
Vorteil es hat, _Adress_-Informationen in einer Relation zusammenzufassen und 
nciht als Eigenschaft des Gebäudes am Gebäude zu lassen.

Die ganze Datenersparnisdikussion ist mir _in diesem Zusammenhang_ von ihrer 
Relevanz her vollkommen unverständlich, auch wenn sie technisch klar ist. 
Könnte mir mal jemand anhand von sagen wir 1 Mio. Hausnummern ausrechen, 
wieviel Kb effektiv gespart würde? Wir sprechen doch von Text-Zeichen, oder? 
Und dann noch auch bitte nach der Komprimierung... Gerne auch im worst-case mit 
verhältnismäßig wenig Straßen, auf die sich die Hausnummern verteilen würden.

Danke, steffterra

(Danke auch für die Beispiele, wo es schon Verwendung findet)

steffterra


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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 16.07.2010 um 13:55 schrieb Sven Geggus:

 Tobias Knerr o...@tobias-knerr.de wrote:
 
 Vor allem hat die Relation ja keinen praktischen Vorteil! Sie ist, je
 nach Software, sogar umständlicher auszuwerten; sie verteilt die
 History-Information einer Adresse auf unterschiedliche Objekte (das
 Haus, die Relation und den Way); sie erhöht gerade bei langen Straßen
 die Wahrscheinlichkeit von Bearbeitungskonflikten; sie vergrößert den
 Unterschied zu anderen Ausprägungen von Adressen (nicht alles basiert
 auf Straßennamen, es gibt z.B. auch Block-bezogene Adressen); ...
 
 +1

+1

 Die associatedStreet-Relation ist einer der Fälle, wo man sich und
 anderen mit abstrakten Prinzipien (Redundanzvermeidung), die bei
 näherer Betrachtung in dem jeweiligen Anwendungsfall gar nicht von
 Belang sind, das Leben nur unnötig schwer macht.
 Meine Meinung jedenfalls.
 
 Das war übrigens einer der Gründe weshalb wir uns damals beim
 Hausnummernworkshop eher gegen die Relation entschieden haben.

+1

 Der OSM Inspektor berücksichtigt diese jedenfalls auch nicht.

Warum eigentlich nicht? Sind Realrionen im Allgemeinen zu aufwändig? Oder woarn 
liegt es, dass es dazu so wenige Tools gibt - selbst innerhalb JOSM tut man 
sich schwer und benötigt Sponsoren wie Skobbler, um z.B. ein halbwegs gutes 
turn_restriction-Plugin für diese Art Relationen zu entwickeln.

Relationen sind ein wichtiges Instrument, aber in vielen diskussionen hier 
liest man unterm Strich, dass man für die Datenerspartnis gerne  vieles in Kauf 
nimmt - z.b. auch dass Eigenschaften nciht mehr am Objekt getaggt werden, 
sondern über Relationen abgeleitet werden sollen. Es gibt kaum eine 
tag-Diskussion ohne dass jemand die Relationen als Allerheilmittel für am 
liebsten alles hinstellen möchten.

Adressinformationen sind Eigenschaften des Gebäudes, als tag am Gebäude. Dass 
es viele Häuser in Europa gibt, kann man nicht ändern.  

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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 16.07.2010 um 15:01 schrieb Florian Lohoff:

 3. Häuser zu einer Relation associatedStreet mit dem Namen der Straße
 hinzufügen - das klingt sinnvoll! Also eine Relation pro Straßennamen
 hinzufügen und dann alle Häuser an der Straße als Mitglieder dieser
 Relation. Nur leider kennt JOSM diesen Relationstyp nicht, was mich
 etwas verwirrt.
 
 Die associatedStreet relation ist kaputt. Sie ist definiert das sie
 nur EINE Straße beinhalten darf. Das Problem dabei ist das wir
 die Straßen zu zerhaeckseln wegen oneway, maxspeed, width, cycleway etc
 so das nur noch straßenschnipsel ueber bleiben. Danach muss ich fuer
 einen Straßenzug dann irgendwelche 20 Relations anlegen damit jedes Haus
 auch zu der vor ihm liegenden Straße gehoert? Kann irgendwie nicht sein.
 Und was ist wenn ich dann eine Straße zerschneide? Dann sind mit einem mal
 beide Straßenschnipsel in der relation und die relation ist syntaktisch
 kaputt. Wenn ich das also reparieren moechte muss ich jedesmal beim zerteilen
 einer Straße die relation doppeln - die jeweiligen Straßenschnippsel aus
 den relationen entfernen und entsprechend auch die Haeuser.


Das ist für mich fast das wichtigste Argument. Die Handhabbarkeit in der 
Praxis, wie auch schon von anderen hier so gesehen.

Wenn alle Straßen in Orten, in den denen es Hausnummern gibt, in Relationen 
gefasst wären, dann könnten wir OSM für Neuuser dicht machen und wären ständig 
am nachreparieren der Hausnummer-Straßen-Relationen. Weil - selbst wenn man 
nichts mit Hausnummern am Hut hat und auch gar nichts an der Relation ändern 
will - und sei es nur dass sich der Verlauf eines Radweges geändert hat, dann 
ist die Relation futsch und ein Router findet keine einzige Hausnummer dieser 
Relation mehr, wenn der (Neu)User die Relation nicht richtig beachtet hat.

'Wir bauen uns quasi alle Straßen innerorts mit den Relationen zu unt schließen 
sie vor Neuusern aus, die sich nciht an Relationen trauen, oder sind städnig am 
nachbessern und komen gar nciht mehr dazu neues zu taggen. Das wäre nicht nur 
taktisch unklug, das wäre dumm. Außerdem födert es nicht gerade, dass überhaupt 
jemand Hausnummern taggt. Es ist aber immens wichtig, dass diese Flächendeckend 
zumindest in den vorhandenen Orten erfasst werden, um von Geocodern wie Google 
unabhängig zu werden und Nominatim die nötigen Daten zu liefern.

Also nicht nur wegen obigem Argument - Diskussion damit mit dem Fazit/Ergebnis, 
dass Variante 2 (vollständiges addr-tagging nach Karlsruher Schema am Gebäude 
oder Einzelnode, wenn Gebäude nicht eingezeichnet) die für die meisten Fälle 
praktikabelste und damit zu bevorzugende Methode ist. Richtiges Fazit?

Dann gut jetzt, oder ist noch was offen? Bestätigung des Karlsruher Schemas. 
Danke.

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

[Talk-de] Einfahrtverbot durch turn_restriction- Relationen abbilden (war: unechte Einbahnstraße )

[steffterra]

Hi,

Kommt es nicht auf das Schild an, für welche Bereiche es gilt? Das regelt doch 
die StVO. Z.B. Ein Abbiegeverbotsschild gilt nicht erst ab dem Punkt wo es 
steht, man darf auch direkt danach und direkt davor nicht in die Straße 
abbiegen, die es verbietet.
Bei einem Höchstgeschwindigkeitsschild ist es so, dass bei Erreichen des 
Schildes und bis zur nächsten Änderung/Aufhebung diese Höchstgeschwindigkeit 
für der gesamte Way gilt. Bei einem Vorfahrtstraße-Schild ist es ebenso. 
Deshalb sind diese _Eigenschaften_ des way wunderbar auf dem way selbst als Tag 
integrierbar. 

Bei unserem Thema Einfahrverbot ist es aber anders:

Hier schreibt das Schild Nr. 267 
(http://upload.wikimedia.org/wikipedia/commons/e/ee/Zeichen_267.svg) eine Regel 
vor - das Einfahrsverbot - und ändert _nicht_ die Eigenschaft eines ways, wie 
das z.B. im Falle der Geschwindigkeitsbegrenzung der Fall wäre und dann am way 
selbst zu taggen wäre.

Das Einfahrverbot gilt ab dem Schild. Bis zum Schild darf man fahren, sofern 
bis zum Schild eine Straße der gleichen Richtung vorhanden ist. Das Schild 
steht also exakt bei Beginn der Straße. Und wenn es erst weiter hinten gilt, 
dann steht es erst dort oder es gibt ein Zusatzschild dass angibt in 50m und 
dort wird es dann ohne Zusatzschild wiederholt. 

Also. Wieso diskutieren wir hier, wo nach einer Kreuzung die Straße (in die man 
nicht hineinfahren darf) anfängt? Man darf bis zum Schild fahren. Punkt. Wenn 
das Schild nun 3 Meter in einer Straße drin steht, dann kann man das auch mit 
einem node in 3 Meter Abstand abbilden. Dann ist es IMHO legitim, eine 
restriction-Relation von (from) dem way mit den 3 Metern über (via) dem node, 
wo das Schild steht zu dem way dahinter (to) zu erstellen, die als Wert 
no_straight_on enthält. Der Node gibt an - ab wann das Einfahrverbot auf der 
Straße gilt, nämlich für den to-way ab dem node und das ist nunmal ab da, wo 
das Schild steht.

Wenn die Einfahrt schon bei Beginn der Einmündung verboten ist, und nicht erst 
3 Meter dahinter (das Schild steht dann am rechten Fahrbahnrand der sich 
kreuzenden Straße und nicht 3 Meter in der Verbotsstraße), dann ist das 
from an jedem der drei anderen ways der (normalen Kreuzung zweier Straßen), 
das via am Kreuzungspunkt und das to am way, in den man nicht hineinfahren 
darf, mit drei trun_restriction-Relationen abzubilden. Ob der node nun die 
Mitte der Kreuzung darstellt (was geographisch gecodemäßig natürlich so sein 
sollte, der way sollte auch auf der geographischen Mitte der Straße liegen und 
nicht daneben), oder nicht, ist für _diese_ Diskussion unerheblich, da  _eine 
Regel_ für jede Richtung der Kreuzung, aus der man kommt für die to-Straße, 
abgebildet wird und nicht wo das Schild steht, denn das Einfahrverbot _aus_ 
diesen Richtungen gilt für die gesamte to-Straße und die fängt am 
Kreuzungsnode an.

Fazit: 


turn_restriction-Relationen bilden das Einfahrverbot ausreichend ab. Es ist ja 
nichts anderes, als ein Abbiegeverbot in diese Straße, egal aus welcher 
Richtung einer Kreuzung (no_right_turn, no_left_turn, no_straight_on)  man 
kommt und egal, ob es mitten auf einer einzelnen Straße ist (only_steight_on), 
oder wo auch immer. Für alle Richtungen aus der man kommt gibt es Relationen, 
auch für die gerade-Aus-Richtung, die das Einfahrverbot ausreichend abbilden.

Ein kurzes Stück oneway (egal wie kurz oder lang) ist einfach falsches Tagging, 
da hier die _Eigenschaft_ eines way falsch getaggt wird und eine falsche Regel 
abgebildet wird. Den auf oneways, darf man innerhalb des ways nur in einer 
Richtung fahren. Hinter dem Einfahrtverbotsschild darf man aber in jeder 
Richtung fahren. Bei Relationen wird die Eigenschaft von ways nicht verändert 
(was ja auch das Einfahrtverbotsschild nicht macht!), sondern es wird eine 
Verkehrsregel abgebildet, die das Einfahrtverbotsschild beschreibt.

Das Fazit noch weiter heruntergebrochen:
_

Regelabbildung - turn_restriction-Relationen
Eigenschaften eines way ändern - tagging am way

Einbahnstraße = _Eigenschaft_ eines way: hier darf nur in einer Richtung 
gefahren werden - tagging oneway am way.
Einfahrverbot = _Regel_, die für Elemente der Kreuzung gilt, da es auch 
beschreibt, aus (from) welcher Richtung es gilt und in (to) welche Richtung es 
gilt und ab wo (via) es gilt  - turn_restriction-Relationen

Gleichzeitig darf man die ways benutzen, wie sie getaggt sind (Geschwindigkeit, 
oneway, mit Radweg, Parking_lane, etc.), nur wie man sich vom einen way zum 
anderen bewegen soll, ist durch die Regel die dafür gilt festgelegt und durch 
die Relationen abgebildet.


Noch etwas: Wenn das Einfahrverbotsschild am Ende einer echten Einbahnstraße 
steht (am anderen Ende ist das Einbahnstraßenschild) dann ist es nciht nötig 
dieses Einfahrtverbot durch relationen abzubilden, das die _Eigenschaft des 
way_ (oneway=yes) die Regeln impliziert.

Grüße, steffterra
___
Talk-de

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

Am 15.07.2010 um 06:16 schrieb Tirkon:

 steffterra steffte...@me.com wrote:
 
 Am 14.07.2010 um 18:40 schrieb Tirkon:
 
 ... sonst wäre es keine Kreuzung. 
 
 Wenn Du so möchtest, dann ist es eben keine Kreuzung. Ich habe ja auch
 nicht von Kreuzung gesprochen, sondern von drei Straßen, die sich in
 einem Punkt treffen und lasse offen, ob das mit der Zusatzbedingung
 eine Kreuzung ist oder nicht.
 
 Sorry, aber was ist es dann, wenn keine Kreuzung??? 
 
 Das frage Dich selbst. Denn dass das keine Kreuzung wäre, kam von Dir:
 steffterra: ... sonst wäre es keine Kreuzung. 

Ja, denn es war meine Argumentation, dass es in einer Kreuzung/Einmündung  eben 
_keine durchgezogenen Mittellinien gibt_! Verstehst Du. Das hast Du mit Deinen 
Zeichnungen versucht zu widerlegen und dabei kam heraus, dass es sich um 
Sonderfälle _in_ Parkhäusern handelte. ;-). 

 Meinst Du wirklich, dass eine dermaßen gefährliche Kreuzung keine weitere 
 Verkehrsregelung wie z.B. Abbiegegebots/Verbotsschilder hat, die das 
 zusätzlich regeln (und die sowieso über turn_restriction-Relationen 
 abzubilden wären?). Wenn es keine gefährliche Kreuzung sein soll - wieso 
 gibt es dann eine durchgezogene Mittellinie (außer in Parkhäusern habe ich 
 solche Linien noch nicht gesehen und diese ways tagge ich derzeit noch nicht 
 Außerdem gibt es da meist auch noch Pfeilmarkierungen am Boden, die es 
 zusätzlich verdeutlichen ;-) und drittes Argument: zeige mir mal ein 
 Beispiel (google-Maps-link wäre wegen sat-bild gut geeignet), dass mir 
 hilft, dieses Beispiel als nicht-an-den-Haaren-herbeigezogen anzusehen. ;-)
 
 Ich hatte schon beim Schreiben des Postings sinniert, wo ich es
 gesehen habe. Ich wusste nur, dass ich es gesehen habe. Der mich dann
 drauf gebracht hat, warst dann Du.

Gern geschehen. :-)

 Es war tatsächlich im Parkhaus.

Wie gesagt, es gibt keine durchgezogenen Mittellinien in Kreuzungen, damit ist 
Deine Argumentation, dass es über eine Relation abgebildet werden muss (wegen 
der Kreuzungen/Einmündungen/etc. wäre es nötig meintest Du) hinfällig.

 Aber ich verstehe immer weniger, warum Du die durchgezogenen Mittellinien 
 (um bei diesen Beispielen zu bleiben) hier über Relationen abbilden 
 möchtest? 
 Möchte ich ja nicht und hatte ich auch geschrieben: Auch ich würde
 gern auf die Relation verzichten und nur Tags benutzen. 

Würdest - Du meinstes, dass es nicht in jedem Fall ginge. Und ja ich gebe Dir 
Recht im Falle von Kreuzungen _in_ Parkhäusern geht es nicht. Da müssten 
(sofern ein Tagging dort einmal möglich wird) turn_restrictions ausreichen und 
taggen kann man es trotzdem am way zwischen den nodes, die es betrifft. Auch 
kein Problem, oder?

//   /   //
   //   /   //
  //   b   //
 =/   //
 /   //
 -a-P   ||
 \\
 =\   \\
  \\   \   \\
   \\   c   \\
\\   \   \\
 \\   \   \\
 
 gerendert so aussähe:
//   /   //
   //   /   //
  //   b   //
 =/   //
 //
 -a--   ||
 \\
 =\   \\
  \\   \   \\
   \\   c   \\
\\   \   \\
 \\   \   \\
 
 Die ununterbrochene Mittelinie zwischen a und b über den Punkt P
 hinweg fehlt. Jetzt klar?

klar, aber woher weisst Du, dass es so gerendert werden würde? mache die nodes 
so, wie weit die durchgezogene Mittellinie geht und gut. Wenn die durchgezogene 
Mittellinie vorher aufhört, dann mache vorher einen node und wenn sie erst am 
kreuzungsnode aufhört, muss der Rednerer das auch so rendern.

 Die turn_restriction-Relationen sind deshalb ja trotzdem nötig und dann kann 
 man zusätzlich sehr leicht noch die Mitellinie mittaggen - und das geht 
 gerade bei Deinen Beispielen sehr leicht. Erkläre mir mal bitte, wieso man 
 nicht einfach die ways bis zu ihren Nodes entsprechend mit 
 solid_line:middle=yes taggen kann (tag ist noch diskutierbar, siehe mein 
 Eingangsposting) Man könnte natürlich sagen dass from a via Node-aP to 
 P usw. die Regel middle_line=yes haben kann, aber was für einen Nutzen 
 bringt mir das, wenn ich es direkt auf dem way als Eigenschaft des way 
 taggen kann? Wo siehst Du da Probleme, das richtig zu interpretieren? Die 
 Linie ist halt nunmal da durchgezogen, wo es getaggt ist. Fertig.
 Ich hoffe, die obige Zeichnung, welche den Realzustand mit der
 gerenderten Version zeigt, hat die Sache klar gemacht. Du hast mir
 immer noch keinen Weg genannt, mit dem die ununterbrochene Linie
 zwischen a und b im obigen Beispiel auch über den Punkt P hinweg
 korrekt in einer Karte gerendert würde.  

Gerendert würde es vom node bis zum node, auf dem way, auf dem es getaggt 
wird. Dann tagge es doch auf dem way a bis zum node P und auf

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

Am 15.07.2010 um 11:07 schrieb Georg Feddern:

 Dann versuche es doch einmal mit diesem Bild:
 
   //   /   //
  //   /   //
 //   b   //
 =/   //
/   //
 -a-P   ||
\\
 =O   \\
 \\   \   \\
  \\   c   \\
   \\   \   \\
\\   \   \\
 
 
 Strecke c ist bis zum Punkt O mit Mittellinie getaggt und über die Strecke OP 
 ohne Mittellinie an a und b angeschlossen.
 
 Wenn dies nicht funktioniert, dann funktionieren auch Strecken c ohne 
 Mittellinie generell nicht, womit das Konzept eh hinfällig wäre ...

warum sollte man das nicht so taggen können. Entweder man taggt die 
durchgezogene Mittellinie vom node des way c bis zum node O oder bis zu P - wo 
ist das Problem? Klar geht das. Ich dabei davon aus, dass P der gemeinsame 
node von way a, b und c ist. (Die Doppelstriche stellen die in JOSM nicht 
vorhanden Fahrbahnränder dar, welche aber im Renderer natürlich vorhanden sind.)

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

Re: [Talk-de] Vodafone veröffentlicht Navigationssof tware im Quellcode

[steffterra]

Am 15.07.2010 um 18:33 schrieb Philip Gillißen:

 Ein Teil der Software nutzt OpenStreetMap-Daten, jedoch gibt es wohl
 noch Probleme damit.
 
 Hier gibt's weitere Informationen:
 
 http://www.heise.de/newsticker/meldung/Vodafone-gibt-Navigationssoftware-Wayfinder-frei-1039120.html
 
 Vielleicht kann man an den Problemen arbeiten?

Wo gibt es die Beispielkarte?

Danke, steffterra


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

Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?

[steffterra]

Am 15.07.2010 um 23:28 schrieb Patrick Hanft:

 Mitja Kleider wrote:
 
 
 
 Sven Geggus wrote:
 
 3. Häuser zu einer Relation associatedStreet mit dem Namen der Straße
 hinzufügen - das klingt sinnvoll! Also eine Relation pro Straßennamen
 hinzufügen und dann alle Häuser an der Straße als Mitglieder dieser
 Relation. Nur leider kennt JOSM diesen Relationstyp nicht, was mich
 etwas verwirrt.
 
 AFAIK machend as die wenigsten Mapper so.
 
 Was ist also die beste und favorisierte Variante derzeit in OSM.de?
 
 Nicht die Nummer 3.
 
 
 Diese Variante wird bisher kaum verwendet. Spricht aber auch grundsätzlich
 etwas dagegen?
 
 Vermutlich nicht viel mehr als die Wahrscheinlichkeit, dass vermutlich 
 Tools, die diese Daten auswerten zunächst vermutlich eher die Varianten 2 
 und dann vielleicht noch 1 implementieren und weniger die Variante 3. 
 Aber das ist zugegebenermaßen eine Mutmaßung…

Aber eine sehr wahrscheinliche, oder?

Nochmal zusammengefasst:

 1. Straßennamen nicht mit angeben - Algorithmen sollen bei einer Suche
 in der Nähe der Straße suchen. Das ist in wohl 90% der Fälle OK, schlägt
 aber bei Häusern an Straßenecken fehl.

ist aus genanntem Grund schlecht: weiterer Grund: die _Adresseinformation_ 
eines Gebäudes besteht nicht nur aus der Hausnummer.

 2. Straßenname mit als Attribut an das Haus. Finde ich super redundant.
 Dann steht der Straßenname-String (n+1) mal in der OSM Datenbank -
 eigentlich Blödsinn.

nein, wei les zwei verschiedene paar Stiefel sind. Das eine ist die 
Adressinformation des Gebäudes, das andere der Name der Straße als Eigenschaft 
derselben.

 3. Häuser zu einer Relation associatedStreet mit dem Namen der Straße
 hinzufügen - das klingt sinnvoll! Also eine Relation pro Straßennamen
 hinzufügen und dann alle Häuser an der Straße als Mitglieder dieser
 Relation. Nur leider kennt JOSM diesen Relationstyp nicht, was mich
 etwas verwirrt.

Dadurch würden die Adressinformationen in verschiedene Daternarten zerissen - 
in tag und Relationen und müssten erst wieder zusamengeführt werden, ein 
zusätzliches Problem wird geschaffen.

Variante 2. halte ich persönlich für die sinnvollste, weil es sich ja um die 
_Adress-Information_ eines Gebäudes handelt (und damit zum Gebäude gehörig ist) 
und deshalb auch Spezialsituationen automatisch perfekt abgebildet werden. Die 
Redundanz ergibt sich aus der Wirklichkeit: Die Straße hat einen namen (tag an 
der Straße) und das Gebäude hat eine Adresse (vollständiger Adresstag am 
Gebäude). Dass der Straßenname der Adresse logischerweise der gleiche 
Straßenname wie der der Straße ist, ist nur sinnvoll, sind aber streng genommen 
zwei verschiedene Paar Stiefel. 
Nochmal: Im Falle des Gebäudes wird die Adresse des Gebäudes abgebildet - also 
eine Information die zum Gebäude gehört.  Die Zusammengehörigkeit ergibt sich 
aus dem gleichen Namen von Adresse des Gebäudes und Straßenname. Eine Relation 
stellt nur einen( weiteren, zusätzlichen) Bezug zwischen beiden her, bildet 
aber nicht die Adresseinformation des Gebäudes ab.

Weiterer großer Nachteil: Die vollständig abzuleitende Adresse (und man muss 
sie dann ableiten und kann sie nicht mehr direkt ablesen)  eines Gebäudes wird 
in gleich mehrere Datenarten zerissen:  einmal in die am Gebäude getaggte 
Hausnummer und Straßenname in der Relation. Stadtname und Land, Postleitzahl 
muss man sich ebenso woanders her holen, vlt. aus der Relation des 
Postleitzahlengebiets?. Und nochmal: Es geht nicht um die geoagraphische Lage 
eines Gebäudes - es geht um die Adress-Information - diese würde zerissen! 
Deshalb halte ich es für falsch eine Relation als _alleinige_ 
Adresseinformation gelten zu lassen und lehne deshalb Variante 3 ab.

Aber unabhängig davon würde mich interessieren (nicht als Argumentation): 
- Unterstützt _derzeit_ z.B. Nominatim die Adressuche in Relationen?
- Außerdem wäre es natürlich super, wenn auch der OSM-Inspektor um diese 
Variante 3 erweitert würde. 
(http://tools.geofabrik.de/osmi/?view=addresseslon=9.93101lat=49.79438zoom=18opacity=0.77overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads)
- Könntet ihr bitte einen Beispiellink posten, wo es so umgesetzt wurde? Danke.

Vielen Dank, steffterra


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

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

Am 14.07.2010 um 10:09 schrieb Tobias Knerr:

 Am 13.07.2010 21:36, schrieb steffterra:
 
 Am 13.07.2010 um 20:00 schrieb Tobias Knerr:
 
 Am 13.07.2010 18:31, schrieb steffterra:
 - Unterbrechungen der durchgezogenen Mittellinie kann man einfach zwischen 
 zwei Knoten durch das absichtliche Setzen des no-Werts abbilden. 
 - z.B. wenn zwischen diesen beiden Knoten ein way abzweigt, für den die 
 reale durchgezogene Mittellinie tatsächlich unterbrochen wurde
 - der no-Wert  sollte nur zwischen zwei ways genutzt werden, bei denen 
 der yes-Wert gesetzt wurde. Somit weiß man, dass hier absichtlich so 
 getaggt wurde und es nicht um ein Versehen handelt bzw. nur vergessen 
 wurde. Außerdem hilft diese Regelung dabei, dass nicht jemand auf die Idee 
 kommt, alle ways, die keine durchgezogene Mittellinie besitzen, mit dem 
 tag und no-Wert zu taggen ...
 
 Ich bin mir gerade nicht sicher, ob das Einfügen von zwei zusätzlichen
 winzigen Ways vor einer Kreuzung wirklich die bessere Lösung gegenüber
 einer Relation ist. Meine folgenden Anmerkungen insofern unter diesem
 Vorbehalt.
 
 Wie  jetzt - von zwei winzige way einfügen war doch gar nicht die Rede. 
 Setzte einfach je einen zusätzlichen node links und rechts vom node, der zum 
 abzweigenden way führt, der befahren werden darf, und dann noch zwischen 
 diesen beiden nodes entsprechend mit no-Wert taggen. Und schon ist das 
 gewünschte - die Unterbrechung - erreicht.
 
 Du kannst das Stück zwischen den beiden Nodes nur dann mit einem anderen
 Tag versehen als den Rest, wenn du den Way an jedem dieser beiden Nodes
 auftrennst.
 
 Das Auftrennen erzeugt mindestens einen (wenn der ursprüngliche Way
 nicht schon an der Kreuzung aufgetrennt ist), oft eben auch zwei weitere
 Ways.
 
 Oder verstehe ich deinen Vorschlag jetzt falsch?

Ich hatte das einfügen falsch verstanden. Lag vlt. an mir. Natürlich muss man 
einen vorhandenen Weg an den beiden neuen Nodes aufspalten, um den way 
zwischen den neuen nodes dann anders taggen zu können. Wir meinen also das 
gleiche.
Aber bitte aufspalten, nicht auftrennen (um den richtigen JOSM-Menüpunkt zu 
nennen).

Zum Thema: Die Breite einer Straße ist bekannt, und die paar cm rauf oder 
runter machen das Kraut nicht fett. Wenn man es genau machen möchte, nimmt man 
die Straßenbreite des einmündenden weges. Das ist leichter zu taggen als eine 
relation udn für jede Software leichter auszuweerten, da nur einfache Tag 
genutzt werden müssen. Es ist halt nunmal eine Wegeeigenschaft, dass dort eine 
duzrchgezogene Mitellinie vorhanden ist oder eben nicht und erfordert keine 
Relation, die zwei oder mehrere ways und nodes zueinader mit bestimmten Rollen 
in Beziehung setzt, bzw. eben nicht, wenn an der Stelle keine durchgezogene 
Mitellinie ist.

Vlt. habe ich es aber auch nciht richtig verstanden - was möächtest Du wie mit 
welchen Rollen in eine Relation aufnhemen, um die Fahrtrichtung(!)-Trennende 
durchgezogene Mittel(!)linie abzubilden?

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

Re: [Talk-de] unechte Einbahnstraße

[steffterra]

Am 14.07.2010 um 15:08 schrieb fly:

 Am 13.07.2010 22:42, schrieb steffterra:
 
 Am 13.07.2010 um 22:35 schrieb M∡rtin Koppenhoefer:
 
 Am 13. Juli 2010 21:36 schrieb Dimitri Junker o...@dimitri-junker.de:
 Und beim Zerschneiden müßte es nur einem der neuen Wege zugeordnet werden,
 beim Zusammenfügen gibt es ggf. ernste Probleme,... letzteres stimmt
 natürlich auch für die Abbiege-Relations.
 
 was JOSM seit einiger Zeit automatisch richtig macht, soweit ich weiss
 (korrigiert mich, wenn ich irre).
 
 
 Nein, Du irrst nicht. Das automatische Drehen in JOSM funktioniert auch für 
 destination:forward/backward. ;-) bzw. der Vorschlag desselben: 
 http://wiki.openstreetmap.org/w/images/6/6d/JOSM_automatische_merkmalskorrektur.png
 
 Ja, JOSM hat sich in dieser Hinsicht gemausert.
 
 Großen Dank and die EntwicklerInnen.
 
 Leider gibt es allerdings schon seit lange noch einen Problem wenn einer der
 beiden Weg gedreht werden muß. Also Vorsicht.

Welches Problem denn? (vorsichtig sein muss man natürlich immer - gerade bei 
Relationen)

 Ich halte in dieser Situation immernoch eine kleine Weg mit oneway als
 einfachste Lösung, und wenn dieser Weg nur 1-2m lang ist sollte alles gelöst 
 sein.

Das bildet aber nicht die Wirklichkeit ab, sondern damit taggt man, dass ein 
Straßenabschnitt eine Einbahnstraße ist, was aber defakto keine ist. Denn man 
darf auch auf diesem Stück in beiden Richtungen fahren. Keine Einbahnstraße, 
egal in welchem Abschnitt und egal wie lange dieser ist, es ist einfach nicht 
korrekt. Dann kannst Du auch nen bollard setzen, obwohl er nicht da ist. Das 
wäre genauso falsch. 

Dein Vorschlag dient nur indirekt dem Zeck der erreicht werden soll, er dienst 
nicht dem Zweck der Durchschaubarkeit für andere User, noch dient es dem Zweck 
für den der oneway-tag geschaffen wurde. Also in 3 Hinsichten falsch. Ich mag 
Relationen auch nicht, aber hier sind sie die einzig richtig anwendbare 
Methode, das sauber abzubilden, ohne die Wirklichkeit zu verfälschen. Denn wir 
taggen mit den relationen hier ja keine nicht vorhandenen 
Abbiegeverbots-Schilder, sondern die Abbiegeregeln, die sich aus dem einen 
Einfahrverbots-Schild ergeben.

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

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

 to P usw. die Regel middle_line=yes haben 
kann, aber was für einen Nutzen bringt mir das, wenn ich es direkt auf dem way 
als Eigenschaft des way taggen kann? Wo siehst Du da Probleme, das richtig zu 
interpretieren? Die Linie ist halt nunmal da durchgezogen, wo es getaggt ist. 
Fertig.

Falls in der einen Fahrtrichtung nun die Mittellinie durchgezogen und in der 
anderen gestreichelt ist, dann kann man das doch auch taggen: 
solid_line:middle:forward=yes und  solid_line:middle:backward=no (in 
Richtung der Einzeichnung des way bezogen, wie immer bei Verwendung von forward 
und backward)

Bei Relationen könnte man natürlich eine Relation in der umgekehrten Richtung 
für den no-Wert anlegen. Nur ich stelle den grundsätzlichen Nutzen eine 
Relation in Frage, wenn es sich um die eigenschaften eines way handelt und 
nciht um die Abbildung einer Regel oder Sachverhalts, die es zu interpretieren 
gilt. Denn dafür haben wir schon die turn_restriction-Relationen.

Noch ein Nachteil der Relationen: Man müsste alle way-Abschnitte (also alle 
einzelways einer Straße) zu der Relation zusammenfassen, durch die die 
Mitellinie durchgezogen ist, sonst macht es keinen Sinn. Wir haben schon 
Probleme, dass Wanderwege-Relationen, ÖPNV-Realtionen usw. nicht zerstört 
werden. Dann bitte lasst es uns dort unterlassen, so umfangreiche Relationen zu 
erstellen, wo es auch sehr einfach als way-Eigenschaft direkt getaggt werden 
kann. Nicht unönötig verkomplizieren bitte.

(Bei mehreren Fahrstreifen  - und das wird sicher irgendwann kommen - schon 
wegen der zukünfitgen Routinganfoderungen -müsste man zusätzlich auch nochmal 
Relationen für diese erstellen - wo führt das hin?)

Grüße, steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

 nach innen durchnummerieren müsste (1st, 
2nd, 3rd Lane) und dann für diejenige Fahrspur einheitlich immer den linken 
oder die rechte Linie als solid taggen sollte oder nicht.
Also z.B. wenn sich zwischen 2. und 3. lane eine durchgezogene Linie befindet: 
solid_line:2nd_lane=yes (wenn man immer auf der linken Seite des lanes die 
Linie taggt)
Eine durchgezogene Mittellinie würde dann so getaggt werden: 
solid_line:middle=yes (Das könnte ich mir auch als Alternative zu meinem obigen 
Vorschlag vorstellen, s.o.)

Auch könnte man den destination-tag so einsetzen und Fahrspur-Richtungs-Tagging 
ermöglichen:  destination:1st_lane=Bahnhof oder auf der Autobahn _vor_ 
motroway_links: destinatiion:1st_lane=München destination:3rd_lane=Ulm

Aber soweit wollte ich nicht gleich gehen, auch weil hier die Gegenrichtung 
nicht definiert ist. Dazu müsste noch ein :forward und :backward (in Richtung 
der gezeichneten way-Richtung) ergänzend ins Konzept aufgenommen werden udn 
dann wird schon richtig kompliziert.

Wie denkt ihr aber erstmal über den wichtigsten Schritt, die durchgezogene 
Mittellinie über 
- solid_middleline=yes/no
oder, um es für die Zukunft für weitere Fahrspuren offen zu halten: 
- solid_line:middle=yes/no 
abzubilden?

Freue mich aufs Feedback!

Grüße, steffterra





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

Re: [Talk-de] unechte Einbahnstraße

[steffterra]

Am 13.07.2010 um 18:17 schrieb Tobias Knerr:

 Ich finde daher, dass eine Darstellung als Beziehung zwischen Kreuzung
 und Straße, also eine Relation, das geeignetere Mittel zur Modellierung ist.

1. Ich denke auch, dass es keine Eigenschaft des ways ist, sondern des Knotens, 
über den man fahren müsste, was man aber aufgrund des Verbots nicht darf. Also 
muss die Eigenschaft am Knoten festgemacht werden. 
2. Da der Knoten aber (z.B. im Mindest-Falle einer T-Kreuzung) auch Teil eines 
weiteren ways ist, kann es nur über eine Relation abgebildet werden, die 
aussagt, von (from) welchem way über welchen Knoten (via) das Einfahrverbot auf 
welchen Way gilt.

Deshalb bin ich für eine Relation, die natürlich aus jeder Richtung gilt, von 
der man kommen kann, also gilt es als Abbiegeverbot _in_ den way über diesen 
Knoten aus (from) jedem way, und deshalb auch von (from) jedem way aus und für 
jeden way gewtaggt werden muss. Es gilt ja auch von jedem way aus.

Nochmal zu denen, die meinen, dass über turn_restriction-relationen 
(Abbiege-Verbots-/Gebotsschilder abgebildet werden, dann sei ihnen gesagt, dass 
dem mitnichten so ist! Es werden lediglich die _Verkehrsregeln_ (eben die 
Abbiegeverbote= engl.: turn restriction, icht turn_restriction_sign ;-) 
abgebildet, die dieses Abbiege-Verbots-/Gebotsschild aussagt. Und nur deshalb 
werden die Schilder als _Beispiel_ für die Regelung genannt. Man kann jede 
andere Form der Abbiegeeinschränkung oder Einfahrverbot über eine 
turn_restriction-relation abbilden, auch wenn es sich um kein 
Abbiege-Verbots-/Gebotsschild handelt, das das regelt.

Also sind für mich die normalen turn_restrictions für jede Richtung, aus der 
man kommt (way) zu taggen, da genau diese Regeln das Einfahrverbotschild 
aussagt. 
(nochmal zusammenfassend: Ein einfacher access-tag am node geht aus oben 
genannten Gründen ja nicht, da dann auch der andere way betroffen wäre und am 
way hat er nichts verloren, da die Eigenschaft nicht den way, sondern den 
Knoten betrifft, siehe auch oben, deshalb relation nötig)

Wenn gewünscht kann ich das gerne im Wiki auf Relation:restriction 
verdeutlichen und das passende Schild dazu einbauen. Auch wäre es natürlich 
super, wenn jemand das turn_restriction-plugin um die Funktion erweitern 
könnte, dass das Einfahrverbot durch die automatische Erstellung der nötigen 
turn_restrictiopn-Relationen aller beteiligten from-ways, des betroffenen 
Knotens und des to-ways erstellt würde.

Grüße, steffterra



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

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

Am 13.07.2010 um 20:00 schrieb Tobias Knerr:

 Am 13.07.2010 18:31, schrieb steffterra:
 - Unterbrechungen der durchgezogenen Mittellinie kann man einfach zwischen 
 zwei Knoten durch das absichtliche Setzen des no-Werts abbilden. 
 - z.B. wenn zwischen diesen beiden Knoten ein way abzweigt, für den die 
 reale durchgezogene Mittellinie tatsächlich unterbrochen wurde
 - der no-Wert  sollte nur zwischen zwei ways genutzt werden, bei denen 
 der yes-Wert gesetzt wurde. Somit weiß man, dass hier absichtlich so 
 getaggt wurde und es nicht um ein Versehen handelt bzw. nur vergessen wurde. 
 Außerdem hilft diese Regelung dabei, dass nicht jemand auf die Idee kommt, 
 alle ways, die keine durchgezogene Mittellinie besitzen, mit dem tag und 
 no-Wert zu taggen ...
 
 Ich bin mir gerade nicht sicher, ob das Einfügen von zwei zusätzlichen
 winzigen Ways vor einer Kreuzung wirklich die bessere Lösung gegenüber
 einer Relation ist. Meine folgenden Anmerkungen insofern unter diesem
 Vorbehalt.

Wie  jetzt - von zwei winzige way einfügen war doch gar nicht die Rede. 
Setzte einfach je einen zusätzlichen node links und rechts vom node, der zum 
abzweigenden way führt, der befahren werden darf, und dann noch zwischen diesen 
beiden nodes entsprechend mit no-Wert taggen. Und schon ist das gewünschte - 
die Unterbrechung - erreicht.

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

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

Am 13.07.2010 um 21:41 schrieb Tirkon:

 Aber bei einigen Beispielen sehe ich
 keine Möglichkeit mit Tags, die funktionieren würde - auch nicht die
 hier geschilderten Vorgehensweisen: 
 
 Nehmen wir drei Straßen a, b und c an, welche sich in einem Punkt P
 treffen. Alle drei führen eine durchgezogene Mittellinie an die
 Kreuzung heran.

soweit mit tags machbar. entsprechende knoten setzen, bis zu derer die 
durchgezogenen Mittellinien gehen. fertig. Die Kreuzung selbst hat keine 
durchgezogene Mittellinie, sonst wäre es keine Kreuzung. Bedenke, dass ich 
explizit nur von der _Mittel_linie spreche, also von der, die die beiden 
Fahrt_richtungen_ auf einer Straße trennt! Diese Trennung wäre an Kreuzungen 
aber unsinnig, weil man sonst nicht abbiegen dürfte, da man sie ja nicht 
überfahren darf. Was meinst Du also bitte mit Mitellinie?

 Aber nur zwischen a und b ist diese durchgehend.

den Fall zeige mir bitte mit einem google-maps-link (wegen des sat-bildes). 
IMHO gibt es keine Kreuzungen, bei denen durchgezogenen Mittellinien (s.o.) die 
Fahrtrichtugnen von einander trennt. 

 Auf die Lösung, die nur mit Tags funktioniert, bin ich gespannt. Sobald
 ich den Punkt P mit Mittellinie=yes tagge,

??? s.o.

 weiß man nicht, welche
 beiden von drei Straßen beteiligt sind.

welche Straßen beteiltigt sind, also welche eine durchgezogene Mittellinie zur 
Trennung der Fahrbahnrichtungen aufweisen, taggt man einfach auf der Straße die 
diese Eigenschaft hat. Wo ist das Problem?

 Ich sehe da nur eine Relation
 aPb, die hier funktionieren würde.

Was soll denn in der Relation zusamengefasst werden, wenn es genügt den 
betroffenen way-Abschnitt einfach so zu taggen? Dann weiss man, dass zwischen 
den beiden nodes auf dem way eine durchgezogene Mitellinie vorhanden ist. 
Fertig.

 Meine ursprünglich gepostete Lösung
 würde genau diese Basislösung fortspinnen. 

Verstehe nur ich Dich komplett falsch? Auf welcher Keuzung gibt es denn eine 
durchgezogene Mittellinie, die ja auch das Abbiegen über diese verbieten würde. 
Sowas gibts doch nicht, ich lasse mich aber gerne belehren, aber bitte mit 
goolge-maps-Sat-Bild-Beispiel.

Gruß, steffterra

P.S. für den Fall dass nur auf in einer Fahrrichtung die durchgezogene Linie 
gilt, in der anderen Fahrtrichtung, aber nicht (Doppellinie, eine durchgezogen, 
eine unterbrochen, wie normal), kann man entsprechend der way-Richtung mit 
:forward=yes und :backward=no arbeiten.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] unechte Einbahnstraße

[steffterra]

Am 13.07.2010 um 21:07 schrieb M∡rtin Koppenhoefer:

 Am 13. Juli 2010 19:06 schrieb steffterra steffte...@me.com:
 
 Am 13.07.2010 um 18:17 schrieb Tobias Knerr:
 Ich finde daher, dass eine Darstellung als Beziehung zwischen Kreuzung
 und Straße, also eine Relation, das geeignetere Mittel zur Modellierung ist.
 
 
 +1
 
 
 2. Da der Knoten aber (z.B. im Mindest-Falle einer T-Kreuzung) auch Teil 
 eines weiteren ways ist,
 
 
 -1
 
 der entsprechende Knoten ist da, wo das Schild ist, das ist nie die
 Mitte einer Kreuzung. Das sieht vielleicht ein bisschen nach
 Erbsenzählerei aus, aber man darf bis zum Schild durchaus fahren. Auch
 wenn das ganz am Anfang steht, so ist doch noch das Stück von der
 Mitte der Querstraße bis zum Schild nicht betroffen.


+1 ok. ist korrekt udn schön, dass Du es erwähnst. Aber dann machts eben eine 
Relation von dem way vor dem Schild über den Knoten beim Schild zum way hinter 
dem Schild., oder? :-) Dann spart man sich sogar die anderen turn_restrictions 
für die anderen ways.

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

Re: [Talk-de] unechte Einbahnstraße

[steffterra]

Am 13.07.2010 um 22:35 schrieb M∡rtin Koppenhoefer:

 Am 13. Juli 2010 21:36 schrieb Dimitri Junker o...@dimitri-junker.de:
 Und beim Zerschneiden müßte es nur einem der neuen Wege zugeordnet werden,
 beim Zusammenfügen gibt es ggf. ernste Probleme,... letzteres stimmt
 natürlich auch für die Abbiege-Relations.
 
 was JOSM seit einiger Zeit automatisch richtig macht, soweit ich weiss
 (korrigiert mich, wenn ich irre).


Nein, Du irrst nicht. Das automatische Drehen in JOSM funktioniert auch für 
destination:forward/backward. ;-) bzw. der Vorschlag desselben: 
http://wiki.openstreetmap.org/w/images/6/6d/JOSM_automatische_merkmalskorrektur.png

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

Re: [Talk-de] Durchgehende Mittellinie

[steffterra]

Am 14.07.2010 um 00:25 schrieb M∡rtin Koppenhoefer:

 Am 13. Juli 2010 22:35 schrieb steffterra steffte...@me.com:
 soweit mit tags machbar. entsprechende knoten setzen, bis zu derer die 
 durchgezogenen Mittellinien gehen. fertig.
 
 +1
 
 den Fall zeige mir bitte mit einem google-maps-link (wegen des sat-bildes). 
 IMHO gibt es keine Kreuzungen, bei denen durchgezogenen Mittellinien (s.o.) 
 die Fahrtrichtugnen von einander trennt.
 
 aber es gibt sehr viele Stellen, wo man trotzdem nur gerade aus fahren
 darf.

Das habe ich nie bezweifelt. Ich habe nur bezweifelt, dass dies durch eine 
durchgezogene Mittellinie geregelt wird, weil dann der Querverkehr ja auch 
nicht über diese fahren dürfte, richtig?

 z.B. hier auf der Nord-SüdRichtung:
 http://maps.google.de/maps?hl=deq=romie=UTF8hq=hnear=Rom,+Latium,+Italiengl=deei=NeU8TJWCEYf20gT155yQCwved=0CCkQ8gEwAAll=41.825789,12.479066spn=0.000533,0.00151t=kz=20

Das Abbiegeverbot stimmt, aber ich kann keine durchgezogene Mittellinie 
erkennen. Im Gegenteil, es ist eine bauliche Trennung vorhanden, die an den 
Kreuzungsstellen der Fahrbahnen unterbrochen ist, aber keine Mittellinie, schon 
gar keine durchgezogene, um die es in dieser Diskussion geht ;-). Und das 
Abbiegeverbot können wir wunderbar aus beiden Richtungen jeweils mit 
turn_restriction-Relationen abbilden, wo ist das Problem?

Grüße, steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Demo Routingfunktion openstreetmap,org

[steffterra]

Am 02.07.2010 um 20:44 schrieb fx99:

 
 Bicycle (routes) geht bei mir auch über die Autobahn, genauso Moped und Mofa.
 Car und Bicycle sehen sehr gut aus. Foot geht teilweise mitten auf der
 Straße statt parallelem Radweg.

Ist doch noch heavy beta. Ist ja nicht umsonst nur auf der dev-Seite. Also 
warum nicht erstmal abwarten, was noch passiert, und dann nochmal drüber 
schauen, ob das gewünschte funktioniert.
Weiss eigentlich jemand, ob da cloudmade seine Finger mit im Spiel hat, oder ob 
das von denen _völlig_ unabhänig ist? Immerhin ist cloudmade von Steve Coast 
co-gegründet.

Grüße,

steffterra


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

Re: [Talk-de] Skobbler Android auf dem PC emulieren

[steffterra]

Am 30.06.2010 um 02:10 schrieb Tirkon tirko...@yahoo.de:


Offenbar kann man Android emulieren:
http://www.addictivetips.com/windows-tips/download-google-android-emulator/

Ist es damit auch möglich, Skobbler Android auf dem PC laufen zu
lassen? Funktioniert das vielleicht sogar schon bei jemand? Oder ist
das eine Milchmädchenrechnung?


wenn man im Emulator auch GPS-Positionen emulieren kann, dann wäre es  
denkbar. Sonst macht das IMHO keinen Sinn.



So könnte man nachvollziehen, was Skobbler aus dem selbst gemappten
Material macht und Fehler sowohl am OSM Material als auch bei Skobbler
ausfindig machen.


Die GPS-Position sollte man natürlich im laufenden Emulator öfter mal  
ändern dürfen...


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

Re: [Talk-de] Verkehrsinsel Tool?

[steffterra]

Am 26.06.2010 um 12:29 schrieb M∡rtin Koppenhoefer:

 Am 26. Juni 2010 10:33 schrieb Thomas Ineichen osm.mailingl...@t-i.ch:
 Ein  Auftrennen  in  zwei  Einbahnstrassen  ist mMn überflüssig. Setze
 einfache einen Punkt mit
 
 
 m.E. ist es nötig, baulich getrennt ist baulich getrennt, und die
 Situation wird klarer auf der Karte (mehr geometrisches/lage-Detail).


+1 Ist wie am Berliner Platz in Würzburg nach diversen Umbauten der letzten 
Monate. Die Relationen für Buslinien etc. müssen dann tatsächlich aufgedröselt 
werden, viel Arbeit, aber auch mit entsprechendem Gewinn für Darstellung der 
tatsächlichen Geometrie.

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

Re: [Talk-de] Hochauflösende Aufnahmen der Erdkugel

[steffterra]

Am 26.06.2010 um 15:18 schrieb Jan Kolarik:

 Hallo,
 
 http://www.spiegel.de/wissenschaft/weltall/0,1518,703043,00.html
 
 Ich nehme an die Daten werden mangels Veröffentlichung, ausreichend freier 
 Lizenz, bzw. immer noch unzureichender Auflösung für OSM uninteressant 
 sein(?).

Ich kann jetzt keine Quelle angeben, aber ich meine in einem Interview gehört 
zu haben, dass das Zusammenspiel der beiden Radar-Satelliten eine 3D-Auflösung 
von 60 cm hervorbringen _kann_.
Das betrifft aber keine Bilddarstellung sondern das reine Oberflächenprofil. 
Küstenlinien-Veränderungen, Überschwemmungen, tektonische Verschiebungen und 
damit Erdbeebenvorhersage und ähnliches soll damit viel genauer möglich sein. 
Einen Nutzen für OSM kann ich mir nur bzgl. der Höhenlinien vorstellen, da ja 
keine Fotos gemacht werden. Allenfalls eine Darstellung freistehender hoher 
Gebäude könnte man evtl. daraus ableiten.

steffterra


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

Re: [Talk-de] Hochauflösende Aufnahmen der Erdkugel

[steffterra]

Hi,

Auf der Webseite zum Launch ist ein Videofilm, in dem es unter  
anderem heisst, die wissenschaftliche Verwertung der Daten wuerde  
von der DLR uebernommen, und die Daten haetten natuerlich auch  
einen betraechtlichen kommerziellen Nutzen.


Das hängt damit zusammen, dass eine Firma die Finanzierung des zweiten  
Satelliten zu einem nicht unbeträchtlichen Teil mitübernommen hat.  
Dieser Firma wurde deshalb die kommerzielle Nutzung zugesagt, welche  
aber nicht exclusiv ist.
D.h. die Daten werden vom DLR nicht kommerziell und wissenschaftlich  
genutzt und diese Firma darf sie auch weiterverwerten und verkaufen.


Da hoer ich heraus, dass es im allerbesten Fall eine fuer OSM  
immernoch ungenuegende noncommercial-Lizenz geben


Nicht unbedingt (s.o.)

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

Re: [Talk-de] xybot / name tag korrektur

[steffterra]

Hi,

Mit Deiner Differenzierung des Sachverhalts kann ich gut leben.

Eine Zusatzinfo in einer notw ist da hilfreicher als einfach ohne  
Hinweis zu taggen. Der Plausibiliät wegen ist diese dann auch genauso  
dort nötig, wo man den offiziellen Namen am Amt recherchiert hat und  
diesen dann im Name-Tag einträgt, und in der Note den Hinweis auf die  
falsche Schreibweise auf dem Schild unterbringt.


Alternative: Warum nicht einfach verschiedene tags verwenden (Die ja  
auch so wohl schon existieren)?


- name:official: offizieller recherchierter Name
- name:sign: Schreibweise auf dem Schild
- name_local: örtlich gebräuchliche Bezeichnung

Das würde das Problem doch auch ausreichend abbilden und es wäre auch  
von Software leichter nutzbar, als eine Beschreibung in einer note,  
oder?


Grüße,
steffterra


Am 25.06.2010 um 11:01 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.c 
om:


zunächst mal +1 zur Forderung, der xybot solle keine Namen korrigie 
ren.


Das sehe ich natürlich ebenso.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] xybot / name tag korrektur

[steffterra]

Am 25.06.2010 um 14:41 schrieb M∡rtin Koppenhoefer:

 Am 25. Juni 2010 12:45 schrieb Rainer Kluge rklug...@web.de:
 Manche Strassennamen sind so lang, dass sie ausgeschrieben auf kein
 Straßenschild passen. Bei einer Joseph-von-Eichendorff-Straße findet man auf 
 den
 Schildern vor, Stadtplänen, amtlichen Dokumente so ziemlich alle 
 Kombinationen
 von J. | Jos. | Joseph + von | v. + Eichendorff. Was soll man da mappen?

name:sign= J. v. Eichendorff Straße
name:official= Joseph von Eichendorff Straße

 es ist (AFAIK) Konsens, den vollen Namen zu nehmen. Es gibt allerdings
 auch Spezialisten, die z.B. die Straßennamen (od. andere Namen)
 komplett in Großbuchstaben schreiben, wenn das so auf dem Schild
 steht, und die das auch vehement verteidigen / zurückändern.
 
 Teilweise bin ich mir dann selbst auch nicht sicher, s.z.B. hier:
 http://www.openstreetmap.org/browse/node/449208870/history

Wieso? Wenn der Eigenname so geschrieben wird, warum dann nicht? Was steht denn 
im Schaukasten des Kindergartens, auf Aushängen und über der Türe?

Auch hier könnte man name:official=INA.KINDER.GARTEN und 
name:local=internationaler Kindergarten oder einen ähnlich (sinnvolleren?) 
Tag verwenden.

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

Re: [Talk-de] xybot / name tag korrektur

[steffterra]

Hallo liebe Teilnehmer an dieser Diskussion,

Je länger ich hier in talk-de mitlese desto mehr frage ich mich nach  
dem Sinn so mancher Diskussion.


Geht es bei OSM nicht darum, die Wirklichkeit, also das, was man auf  
der (z.B) Strasse geregelt und vorhanden sieht in Tags und Keys  
umzusetzen?


Wieso diskutieren wir hier darüber, ob man einen Strassennamen, der  
auf _allen_ Schildern _einer_ Strasse gleich geschrieben wird, nur als  
Anhaltspunkt für dessen tatsächlichen Namen annehmen darf???


Ja Leute, wo kommen wir denn da hin, wenn wir alles in Frage stellen,  
was mal offiziell so aufgestellt wurde?


Außerdem: selbst wenn der Name anders lauten/geschrieben werden  
müsste: was hilft mir das denn, wenn ich dann mit meiner OSM-Karte die  
Strasse nicht finde, weil er auf dem Schild anders steht als auf der  
Karte.


Sorry, aber das ist nicht mehr nachvollziehbar. Geht mal zwei Schritte  
zurück, schaut Euch mal an, welche Vorschläge und Aussagen ihr hier  
macht, und was die Umsetzung für Konsequenzen hätte.
Bevor ich eine Strasse benenne, kann ich doch nicht erst noch auf die  
Gemeinde ins Sitzungsprotokoll gucken, ob die das Schild richtig  
geschrieben haben...


Nur so nebenbei: wer sagt Euch denn, dass die Circusstrasse nicht nach  
einem Hr. Circus benannt wurde?


Also bitte macht es doch den vielen Neueinsteigern nicht so schwer und  
taggt einfach die Schreibweise, die auf dem Schild steht! Dann ist die  
Wirklichkeit abgebildet und das hilft dann auch bei der Orientierung.



Das Straßenschild alleine reicht allerdings m.E. als Quelle nicht
(bietet aber einen guten Anhaltspunkt, weiter nachzuforschen


Mannomann...

Freundliche Grüsse,

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

Re: [Talk-de] Wiki bzgl. ref auf motorway_link ändern/ergänzen und ref dort ersetzen/entfernen?

[steffterra]

Am 14.06.2010 um 00:49 schrieb Bodo Meissner b...@bodo-m.de:
 Am 14.06.2010 00:05, schrieb M∡rtin Koppenhoefer:
 Am 13. Juni 2010 19:20 schrieb steffterra steffte...@me.com:
 Dass der Weg eine Autobahnauffahrt ist, und wo die hinfuehrt, steht
 schon in den Daten.

 Du meinst es steht in den Daten in dem der motorway_link mit dem  
 motorway einen gemeinsamen knoten hat, oder meinst Du etwas anderes?

 Im Prinzip ja, es ist aber noch mehr: der motorway-link hat ja eine
 Richtung, und es ist nicht irgendein node sondern der letzte Node,  
 der
 gleichzeitig die Autobahn ist, wo er hinführt. Diese Redundanz, di 
 e Du
 vorschlägst, macht für mich an dieser Stelle daher keinen Sinn. ( 
 Bei
 Ausfahrten ist es das selbe in grün).

 Es gibt auch komplexere Konstruktionen, bei denen das nicht mehr so  
 einfach zu verfolgen ist.
 Beispiel: Autobahndreieck Allgäu 
 http://www.openstreetmap.org/?lat=47.687261lon=10.368329zoom=1 
 8
 Von der A7 in nördlicher Richtung zweigt eine Parallelspur ab, die a 
 uch wieder auf die A7 führt. Davon geht dann wieder die Verbindung z 
 ur A980 ab.

Dererlei Beispiele gibt es viele.

 Hier müßte man entlang der Route alle *_link-Stücke verfolgen, bis  
 man auf eine andere Straße (nicht *_link) trifft und ggf. das dortig 
 e ref verwenden.

+1

 Wenn man manuell festgelegte Werte an die *_link-Stücke klebt, erlei 
 chtert das dem Router bzw. dem Routing-Karten-Generator die Arbeit.

Dafür mache ich es aber nicht. Ich nutzte das aber gerne als positiven  
Nebeneffekt. Letztendlich taggt man damit ja auch die Information, die  
auf dem Richtungsschild steht.

Alternativ könnte man natürlich auch in einer Relation die  
beteiligten *._links einer Richtung zusammenfassen. Doch nicht nur die  
Auswertung, auch die Erstellung wäre unverhältnismäßig aufwendiger.  
Außerdem würde das implizieren, dass dann auch bei einem einfachen  
motorway_link statt eines einfachen destination_ref die unnötigerweise  
aufwändigere Relation zu nutzten wäre...

Deshalb bin ich für den destination_ref-key auf allen *._links, die  
zu Autobahnen und allen baulichen Arten von Bundesstrassen führen, da  
der destiination_ref auch dort so ausgeschildert ist.

 Und da scheinbar in vielen Fällen der Mißbrauch des ref-Tags  
 gängige Praxis ist, wäre es sicher sinnvoll, die Information in ein  
 besser geeignetes Tag wie das vorgeschlagenen destination_ref zu ver 
 lagern.

+1, und dass das gängige Praxis ist, zeigt aber auch, dass es  
eigentlich kein Proposal benötigt, ihn umzubenennen. Der Key wird ja  
nicht neu erfunden, nur weil man ihn sinnvoller benennt. Der Bedarf  
ist da, gängige Praxis ist erwiesen, also nur noch umbenennen in die  
sinnvollere Schreibweise.

 Ich denke, es schadet nichts, den vorgeschlagenen Key zu verwenden,  
 auch wenn das möglicherweise redundant ist.
 Da es aber bisher nicht der gängigen Praxis entspricht,

Der ref am _link ist gängige Praxis, also ist es nur eine Frage der  
Umbenennung am _link und keine Proposal-Fragestellung nach dem  
generellen Bedarf. S.o.

 würde ich das zuerst als Proposed_feature eintragen.

Eigentlich eben nicht nötig, s.o.

 Alternative: häufig in der DB verwenden und dann mit Verweis auf die 
  Verbreitung direkt ohne Proposal als Key eintragen.

Der falsche ref am _link ist weit verbreitet, deshalb würde ich das  
mit dem Umbenennen vorhandener _falscher_ ref's an _links ins Wiki  
schreiben (natürlich mit Hinweis auf echte ref's an _links, wenn diese  
tatsächlich so ausgeschildert oder in offiziellen Papieren so  
bezeichnet werden. Siehe dazu aktueller Wikieintrag bei motorway_link).

 Wenn jemand ein Programm schreibt, das die korrekten destination_ref- 
 Werte für alle motorway_link ermitteln kann, ist das vielleicht ein  
 Hinweis, daß man auf destination_ref verzichten kann.

Das geht sicher, ist aber dann eigentlich schon ein Routingprogramm -  
und damit sind wir wieder am Anfang der Diskussion. Dass es aber eine  
(nicht umsonst  auch ausgeschilderte) Information ist, wird dabei  
ignoriert und man reduziert es auf die Router-Diskussion.

Aber was bisher komplett vernachlässigt wurde, ist die Tatsache, dass  
der Key destinatin_ref auch wunderbar an Bundesstrassen eingesetzt  
werden kann, an denen die Richtung zu einer Autobahn ausgeschildert  
ist, so wie es häufig in Städten aber auch im ländlichen Bereich der  
Fall ist.
Da ist gar keine Redundanz gegeben, wenn es nicht getaggt wird und ist  
auch wiederum nicht nur für Router eine sinnvolle Ergänzung.

steffterra 

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

Re: [Talk-de] ORS

[steffterra]

Am 13.06.2010 um 02:40 schrieb Johann H. Addicks addi...@gmx.net:

 provo  Ist bei ORS schon die Luft raus?/provo,

 Hat der Domainumzug dort schon geklappt?

Ist es denn kein Projekt der Uni mehr? Warum musste man umziehen?

 dass Cloudmade lahm ist, wissen wir ja - und die vermarkten sich  
 kommerziell und müssten es eigentlich schon aus eigenem Qualitätsa 
 nspruch besser wissen. Es ist zumindest leichter, als Abbiege-Rela 
 tionen zu berücksichtigen ...

 Cloudmade beherrscht doch seit 2(?) Monaten auch (die mir bekannten)
 Turn-Restrictions.
 Oder gibt's da doch wieder Probleme?

Cloudmade hat die Auswertung von Turn-Restriction-Relationen erst auf  
Druck/Zusammenarbeit (nennt es wie ihr mögt) mit Skobbler eingeführt.  
Davor stand dieses, für gutes Routing essentielle Feature, schon über  
ein Jahr im Support-Ticketsystem.
Erst als Skobbler mit 100.000 Usern im Rücken sich bei cloudemade  
einkaufte (cm verlangt Kohle für ihre API) haben sie dies in Betracht  
gezogen. Umgesetzt wurde es aber erst vor zwei Monaten, weil die  
Userschaft von Skobbler sich über das schlechte Routing beschwert  
hatte...

Anscheinend ist die Auswertung von Relationen für die Routenfindung  
(nicht fürs Navigieren ansich) doch aufwändiger, als man hinlänglich  
meint, und bei großer Userschaft dann serverseitig auch ein  
Kostenfaktor.

Wie hat ORS das denn kostengünstig umgesetzt?

Immerhin scheint dafür das Betreiben einer eigenen db für die  
Relationen nötig zu sein, die sich auch performant in die  
Routenberechnung einfügt und regelmäßige Updates benötigt.

Gibt es andere Lösungswege?

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

Re: [Talk-de] Wiki bzgl. ref auf motorway_link ändern/ergänzen und ref dort ersetzen/entfernen?

[steffterra]

Am 13.06.2010 um 12:41 schrieb M∡rtin Koppenhoefer:

 Am 12. Juni 2010 22:09 schrieb steffterra steffte...@me.com:
 Was denkt ihr?
 
 
 wozu sollte man das angeben? Ergibt sich das nicht aus der Topologie?

Du meinst das:

(Beispiel Autobahnauffahrt zu A 22 Richtung Berlin  Schild 430 
(http://www.sicherestrassen.de/VKZKatalog/Kat430.htm) taggen:
destination=Berlin
destination_ref=A 22

Weil es sowieso auf dem Schild steht, dass es da zur A 22 geht?
Dass es da nach Berlin geht, steht ja auch drauf.

Und wenn es nicht so weit verbreitet wäre, fälschlicherweise ref zu taggen, 
dann ist doch destination_ref - zumal das auf dem Schild steht, doch die 
bessere Wahl, oder? So würde man denen entgegen kommen, die das unbedingt 
getaggt haben wollen und stören tut es sowieso nicht (was hier auch Argument 
gegen das Löschen des falschen ref war ...) 
Dann doch lieber besser taggen, als falsch taggen, oder?

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

Re: [Talk-de] Wiki bzgl. ref auf motorway_link ändern/ergänzen und ref dort ersetzen/entfernen?

[steffterra]

Am 13.06.2010 um 17:36 schrieb M∡rtin Koppenhoefer:

 Am 13. Juni 2010 14:25 schrieb steffterra steffte...@me.com:
 wozu sollte man das angeben? Ergibt sich das nicht aus der Topologie?
 
 Du meinst das:
 
 (Beispiel Autobahnauffahrt zu A 22 Richtung Berlin  Schild 430 
 (http://www.sicherestrassen.de/VKZKatalog/Kat430.htm) taggen:
 destination=Berlin
 destination_ref=A 22
 
 Weil es sowieso auf dem Schild steht, dass es da zur A 22 geht?
 Dass es da nach Berlin geht, steht ja auch drauf.
 
 Und wenn es nicht so weit verbreitet wäre, fälschlicherweise ref zu 
 taggen, dann ist doch destination_ref - zumal das auf dem Schild steht, doch 
 die bessere Wahl, oder? ...
 
 
 Dass der Weg eine Autobahnauffahrt ist, und wo die hinfuehrt, steht
 schon in den Daten.

Du meinst es steht in den Daten in dem der motorway_link mit dem motorway 
einen gemeinsamen knoten hat, oder meinst Du etwas anderes?

 Was Du taggen willst ist das Schild,

Nein. Ein Schild wird über eine Relation besser abgebildet. Das Schild dient 
lediglich als Informationsquelle.


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

Re: [Talk-de] ORS

[steffterra]

Am 12.06.2010 um 19:46 schrieb Ulf Lamping:

 Am 12.06.2010 19:26, schrieb Johann H. Addicks:
 Am 12.06.2010 14:48, schrieb Martin Simon:
 
 Ein anderes Beispiel, wo ORS zur Zeit Mist baut ist barrier=bollard
 an nodes - wenn ich mich recht erinnere, hat das früher mal
 funktioniert... yournavigation.org hingegen beachtet das tag korrekt.
 
 Naja, man muss derzeit (auch für den Cloudmade-Router und damit eben
 auch für das Iphone-Dings) eben statt einem Bollard die Straße
 auftrennen und stattdessen ein kurzes Stück (1m) Rad-/Fussweg als
 Verbindung setzen.
 
 ... und mit dieser Vorgehensweise bessert sich der Router dann nie.
 
 Sowas nennt man Mappen für den Router - keine sonderlich gute Idee.

Das ist nicht nur keine gute Idee, das ist ehrlich gesagt Blödsinn vom Feinsten.
Erstens entspricht es nicht der Realität und zweitens ist es viel effizienter 
den Router intelligenter zu machen.
provo Ist bei ORS schon die Luft raus?/provo, dass Cloudmade lahm ist, 
wissen wir ja - und die vermarkten sich kommerziell und müssten es eigentlich 
schon aus eigenem Qualitätsanspruch besser wissen. Es ist zumindest leichter, 
als Abbiege-Relationen zu berücksichtigen ... 

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

Re: [Talk-de] Wiki bzgl. ref auf motorway_link ändern/ergänzen und ref dort ersetzen/entfernen?

[steffterra]

Hallo talk-de 

Da ja jetzt kein weiteres Feedback mehr kam, das dem zuletzt gesagten entgegen 
spräche, habe ich nun die highway_link-Seiten für de und en entsprechend dem 
Ergebnis hier in der Liste im Wiki angepasst.

Beim Erweitern der destination-Seite 
http://wiki.openstreetmap.org/wiki/DE:Key:destination und der Recherche für die 
Richtungsschilder ist mir nun aber eine Lösung für den wegfallenenden ref-Tag 
am hioghway_link aufgefallen.

Genauso, wie auf dem Richtungsschild der Name der Stadt steht, zu dem die 
darauf folgende Autobahn führt, steht da häufig auch der ref der darauf 
folgenden Autobahn.
Man könne also analog zum destination-key folgendes am highway_link (Beispiel 
Autobahnauffahrt zu A 22 Richtung Berlin  Schild 430 
(http://www.sicherestrassen.de/VKZKatalog/Kat430.htm) taggen:
destination=Berlin
destination_ref=A 22

destination_ref deshalb, weil es die Richtung zum ref angibt (in Richtung A 22)
destination weil es die Richtung der Auffahrt angibt (in Richtung Berlin)

Auch wenn wir mittlerweile festgestellt haben, dass der ref-Tag der darauf 
folgenden Autobahn am highway_link nur dann getaggt werden solle, wenn ein 
Schild oder eine andere Quelle dies auch sagt, so haben wir mit destinaion_ref 
dann einen Tag gefunden, der die Richtung zur A 22 angibt und eben nicht 
fälschlicherweise die A 22 am _link angibt.

Was denkt ihr über destination_ref - besonders, wenn man dieses Schild gesehen 
hat: http://wiki.openstreetmap.org/wiki/File:Zeichen_430.svg
Ich denke, den könnten wir ja schon aufgrudn der allgemeinen (falschen) 
Akzeptanz von ref am motorway_link auch ohne proposal ins wiki einführen, 
oder?
Was denkt ihr?

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

Re: [Talk-de] motorway_link mit ref taggen oder etwa nich t??? (war: Re: Trennzeichen bei Aufzählungen i m Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen))

[steffterra]

Am 09.06.2010 um 09:24 schrieb Martin Simon grenzde...@gmail.com:

 Am 8. Juni 2010 19:49 schrieb steffterra steffte...@me.com:

 Hier mußt du differenzieren zwischen dem Verkehrsraum Autobahn
 (alles zwischen den blauen Beginn und Ende-Schildchen, was nicht
 Rastplatz, Dienstzufahrt etc. ist) und der Autobahn $Nummer.

 Es würde ja niemand sagen, dass man die Autobahn am Kreuz verlasse 
 n hat und dann auf die andere
 Autobahn aufgefahren ist, sondern man würde eher sagen, dass man v 
 on der einen auf die andere
 Autobahn gefahren ist.

 Ich verlasse am Kreuz den Raum Autobahn nicht, jedoch _verlasse_ ich
 die konkrete Autobahn A 3, fahre über die Verbindungsrampe und dann
 _auf_ die Autobahn A 666.

 Ergo: der motorway_link ist zumindest im Falle von Autobahnkruezen/ 
 Dreiecken eben schon Teil der Autobahn und deshalb korrekt mit  
 ref zu taggen. Warum brechen sich dann hier einige einen Zacken  
 aus der Krone, normale Auffahrten ebenso zu taggen?

 Noch viel schöner: er gehört in allen Fällen zum Raum Autobahn,
 sonst würden wir ihn nicht mit motorway_link taggen. ;-)

 Eine andere Frage ist, ob er _tatsächlich_ eine ref hat. Das wäre e 
 in
 Grund, diese auch zu taggen - ein _angenommener_ Vorteil bei
 routing-Anweisungen ist jedpch _kein_ Grund hierfür.

Nein, natürlich ist das kein Grund, genauso wenig wie spezielle für  
eine renderingsoftware zu taggen ;-)
Habe ich in früheren Mails auch mehrfach immer wieder betonen müsen.

 Und wnen nicht mit ref, gibts ja den Vorschlag mit leadingt_ref,  
 zu dem ich mir etwas Resonanz wünschte (sowohl positive als auch n 
 egative, wenn gut begründet, oder besserer Vorschlag). Wenn dann g 
 enug Feedback dazu da ist, bin ich gerne bereit mich dafür einzuse 
 tzen und ein Proposal dazu zu schreiben.

 Das ist mir zumindest lieber, als tatsächliches vorhandensein einer
 ref und die ref der Zielautobahn in einem tag zu vermischen - auch
 wenn ich es für ziemlich überflüssig halte - stören würde es mich
 nicht großartig.

Ich persönlich brauche das ref auf dem Link auch nicht, ich konnte mir  
nur vorstellen, dass dieser nicht unpraktisch ist und deshalb _direkt_  
und einfach nutzbar fürs Routing.
Er war ja schon vor mir dort...
Außerdem möchte ich nochmal klar stellen, dass nicht ich den ref am  
link aufs Tapet gebracht habe, sondern den destination-key, der sehr  
wohl allgemeinen Nutzen hat.

Das mit dem ref am link entstand aus der Diskussion mit den  
Leerzeichen bei Aufzählung derselben an links, die wohl meist dort  
anzutreffen sind (wohl fälschlicherweise, weil ref ja grundsätzlich  
in Frage steht am link)

 Ja, das meine ich und nein, die Geräte sind in der Lage, beim Abbieg 
 en
 auf eine unbenannte Straße, die _zu_ einer benannten führt, den Nam 
 en
 letzterer anzuzeigen (Meldung: rechts halten _nach_ A 666 statt
 _auf_ A 666).

Und dank destination-Key können sie nun auch dazu sagen Richtung  
Kassel (nicht A 666, ich weiß), denn das kann man nicht aus der  
fertigen Route auslesen.


 Du aber mutest jedem potentiellen OSM basierenden Navi zu, den  
 Rechenaufwand (z.B. direkt auf einem mobilen Endgerät) zu betreibe 
 n. Warum?

 Kannst du beziffern, worin der Aufwand für das Gerät liegt? (Hinwei 
 s:
 zu diesem Zeitpunkt liegt bereits eine geordnete Liste aller zu
 befahrenen Routenteile im Speicher...)

Im Schritt davor. Wenn die Routenbeschreibung (also die geordnete  
Liste) fertig ist, sollte die Information in der Tat schon da sein.

Aber wie auch immer, wir taggen/Mappen ja nicht für Router ;-)

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

[Talk-de] Wiki bzgl. ref auf motorway_link ändern/ergänzen und ref dort ersetzen/entfernen? (war: Re: motorway_link mit ref taggen oder etwa nicht???)

[steffterra]

Am 09.06.2010 um 11:08 schrieb M∡rtin Koppenhoefer:

 Am 9. Juni 2010 09:24 schrieb Martin Simon grenzde...@gmail.com:
 Am 8. Juni 2010 19:49 schrieb steffterra steffte...@me.com:
 Ach ja, passend dazu (nicht direkt auf Deine mail, aber zur bisherigen 
 Diskussion, siehe Betreff,
  passend: ) Wenn man von einer Autobahn über ein Autobahnkreuz/Dreieck auf 
 eine andere Autobahn
 kommt, würdest Du das Kreuz mit seinen motorway_links auch zu der Autobahn 
 zählen oder?
 
 Hier mußt du differenzieren zwischen dem Verkehrsraum Autobahn
 (alles zwischen den blauen Beginn und Ende-Schildchen, was nicht
 Rastplatz, Dienstzufahrt etc. ist) und der Autobahn $Nummer.
 
 
 +1. Sobald ich auf der Abfahrt bin, ist die ref nicht mehr dieselbe
 (sondern es gilt die Ref der Ausfahrt/Einfahrt/Überfahrt).

Aber zählt dann auf der Abfahrt wirklich der ref der darauffolgenden 
(Bundes-)Straße? Nach aktuellem Stand der Diskussion hier ist das ebensowenig 
der Fall, wie man den ref der Autobahn am link einsetzen soll, auf die der link 
führt.

 Diese ganze
 Diskussion ist wohl nur entstanden, weil im WIki dazu was stand, was
 sich mit der Taggingpraxis soweit mir bekannt nicht deckt. Hat das
 zwischenzeitlich jemand angepasst?

Im Wiki stand in der letzten Version vor der Einführung des destination-tag ins 
wiki folgendes:
Die Verbindungen zwischen zwei Autobahnen sollten gewöhnlich mit dem ref 
derjenigen Autobahn markiert werden, zu der sie führen.

Ich habe den Satz dann nach Einführung des destination-keys ins Wiki nur noch 
um diesen erweitert.: 
Die Verbindungen zwischen zwei Autobahnen sollten gewöhnlich mit dem ref=* und 
destination=* derjenigen Autobahn markiert werden, zu der sie führen und in 
dessen Richtung (Stadtname) sie führen.

Die allgemeine Praxis (zumindest wie ich sie vorgefunden habe und auch hier 
indirekt bestätigt wurde) ist, dass diese im wiki für Autobahnkreuze 
beschriebene Vorgehensweise auf andere highway_links ausgelegt wurde:
a) Autobahn_abfahrten_ findet man mit dem ref der folgenden Bundesstraße.
b) Autobahn_auffahrten findet man mit dem ref der folgenden Autobahn.

Dass man nun eine Unterscheidung zwischen einem highway_link im Verkehrsraum 
Autobahn und einem highway_link außerhalb des Verkehrsraums Autobahn  
(normale Abfahrt auf Bundesstraße) macht, geht weder aus der Wiki-Seite für 
ref, noch aus der wiki-Seite für motorway noch aus der für motorway_link 
hervor. (Das gleiche analog dazu für trunk_link und secondary_link).

Woher soll nun der gemeine Mapper wissen, dass der ref der Autobahn nichts auf 
der Auffahrt zu suchen hat?

Als Konsens aus der bisherigen Diskussion schließe ich nun folgendes:

1. der key/tag ref soll nur angewendet werden auf:
a) motorway, trunk, secondary, etc., wo auch real vorhanden (sprich 
ausgeschildert)
b) auf *_link nur, wenn Teil eines Autobahnkreuzes oder -Dreiecks.
c) im Umkehrschluss zu b) - auf *_link nicht, wenn reine Abfahrt oder reine 
Auffahrt von/zu einem motorway, trunk, secondary, etc.

2. da der key/tag ref auf c) recht häufig anzutreffen ist, sollte er dort 
konsequenterweise entfernt werden.

Daraus ergeben sich folgende Möglichkeiten, die ich zur Zeit sehe:

a) Das wiki sollte bezüglich 1. a) bis c) auf den entsprechenden Seiten 
entsprechend geändert und ergänzt werden. (kann ich gerne übernehmen, sofern 
inhaltlich so wie oben beschrieben abgesegnet, mit Quellenangabe zu dieser 
Diskussion)
b) Man kann sich überlegen, durch einen robot die tags zu entfernen. Der robot 
muss natürlich berücksichtigen, dass er bei Verbindungen von 
motorway-motorway_link
c) Man kann sich überlegen, den tkey/ag durch einen anderen (per robot oder/und 
nur durch Eintrag ins Wiki) zu ersetzen, der hier zumindest nicht dementiert 
wurde:  leadingto_ref. wobei man hier diksutieren könnte, ob das dann auch 
für Autobahnkreuze ok wäre, oder restriktiv eben nicht, da nicht ausserhalb des 
Raums Autobahn Die Defintionen für den Raum Autobahn müssen dann natürlich 
auch ins Wiki.

Jetzt warte ich aber erstmal Euer Feedback ab. (von der Anwendung eines robots 
habe ich z.b. keine Ahnung und falls überhaupt sinnvoll/gewünscht sollte es 
dann sowieso jemand machen, der dann auch weiss, was er tut ;-)

Grüße, steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wiki bzgl. ref auf motorway_link ändern/ergänzen und ref dort ersetzen/entfernen? (war: Re: motorway_link mit ref taggen oder etwa nicht???)

[steffterra]

Am 09.06.2010 um 21:57 schrieb M∡rtin Koppenhoefer:

 Am 9. Juni 2010 16:35 schrieb steffterra steffte...@me.com:
 Aber zählt dann auf der Abfahrt wirklich der ref der darauffolgenden 
 (Bundes-)Straße? Nach aktuellem Stand der Diskussion hier ist das 
 ebensowenig der Fall, wie man den ref der Autobahn am link einsetzen soll, 
 auf die der link führt.
 
 
 ich verstehe nicht, was das bringen soll, und finde es im Gegenteil
 schädlich. Der ref ist der der Straße die man taggt, nichts anderes.
 Ist doch extrem simpel. Wenn es keinen gibt, macht man eben keinen
 ref-tag hin. (Wobei ich nicht blindlings die tags entfernen würde, nur
 weil ich auf Anhieb kein entspr. Schild vor Ort gefunden habe).

Da mal (als Nichtkenner des Autobahnabschnitts, der diese motorway_links 
enthält) die Informationsquelle für den ref-key nicht kennt (kann Schild sein, 
oder Info aus einer Autobahnverwaltungsdatei, etc.), kann man auch nichts 
dagegen tun und jeder, der sowas getaggt hat, muss sich die Frage stellen, ob 
es Gültigkeit hat, da die Informationsquelle klar einen ref rechtfertigt, 
oder eben nicht. Z.b. weil es nach der Behauptung (siehe Vorredner) im Wiki 
getaggt wurde?

Wenn das den Sachverhalt trifft, wird das wiki mit diesen Informationen 
angepasst und das wars. Dann muss halt jeder selbst schauen, der so getaggt 
hat, ob es zutrifft oder nicht.

 Dass man nun eine Unterscheidung zwischen einem highway_link im Verkehrsraum 
 Autobahn und einem highway_link außerhalb des Verkehrsraums Autobahn  
 (normale Abfahrt auf Bundesstraße) macht, geht weder aus der Wiki-Seite für 
 ref, noch aus der wiki-Seite für motorway noch aus der für motorway_link 
 hervor. (Das gleiche analog dazu für trunk_link und secondary_link).
 
 
 würde ich auch nicht machen, diese Unterscheidung. Als ref. ist
 jeweils nur derjenige der Straße die man taggt sinnvoll, anders machen
 wir es an keiner Stelle mit keinem Tag.

also dann ist auch das klar, dass jeder motorway_link zutrifft auf obigen 
Sachverhalt.

 1. der key/tag ref soll nur angewendet werden auf:
 a) motorway, trunk, secondary, etc., wo auch real vorhanden (sprich 
 ausgeschildert)
 real vorhanden ist m.E. nicht gleichbedeutend mit ausgeschildert,
 wobei ausgeschildert die Sache natürlich erleichtert.

s.o. andere Informationsquellen als z.B. ein km-Schild.

 b) auf *_link nur, wenn Teil eines Autobahnkreuzes oder -Dreiecks.
 gut, da könnte es evtl. Stellen geben, wo es Sinn macht, da würde ich
 dann allerdings auch den Ref. vor Ort erwarten (Kilometermarken oder
 so was).

dito: s.o. andere Informationsquellen als z.B. ein km-Schild.

 2. da der key/tag ref auf c) recht häufig anzutreffen ist, sollte er dort 
 konsequenterweise entfernt werden.
 würde ich tun, ja. Sonst verwirrt das nur noch mehr.

aber auch hier s.o. derjenige der es getaggt hat, muss es auch entfernen, denn 
nur der weiß, was seine Informationsquelle war.

 Daraus ergeben sich folgende Möglichkeiten, die ich zur Zeit sehe:
 a) Das wiki sollte bezüglich 1. a) bis c) auf den entsprechenden Seiten 
 entsprechend geändert und ergänzt werden
 
 +1

Wenn alle offenen Fragen (s.o.) geklärt sind, kann ich das gerne 
zusammenfassend zu diesem Thread hier machen.

 b) Man kann sich überlegen, durch einen robot die tags zu entfernen. Der 
 robot muss natürlich berücksichtigen, dass er bei Verbindungen von 
 motorway-motorway_link
 -1, wozu? Und woher soll der bot wissen, welcher ref richtig ist?

o.k. verstandenb. s.o.: jeder der es getaggt hat, muss selbst überlegen, wo 
seine Information herstammt.

 c) Man kann sich überlegen, den tkey/ag durch einen anderen (per robot 
 oder/und nur durch Eintrag ins Wiki) zu ersetzen, der hier zumindest nicht 
 dementiert wurde
 -1, halte ich für überflüssig: wenn das ein Bot kann, kann es der
 Router auch. Am Ende haben wir überall leading_to=Rome ;-)

alles klar. verstanden.

 Gruß Martin

Danke für die klärenden konkreten Worte :-)
Auf weiterführende Klärung (s.o.) hoffend,

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

Re: [Talk-de] motorway_link mit ref taggen oder etwa nicht??? (war: Re: Trennzeichen bei Aufzähl ungen im Wert eines Tags (war: motorway und motorway _link um destination-tag ergänzen))

[steffterra]

Am 07.06.2010 um 07:36 schrieb Martin Simon:

 Am 5. Juni 2010 02:18 schrieb steffterra steffte...@me.com:
 
 Der ref hat einen Bezug, wie sein Name schon sagt. Und der ist der 
 logischste: der wohin er mich
 hinführt. Und zwar nicht nur die Auffahrt führt mich auf die Autobahn, 
 sondern auch die Abfahrt führt mich
 auch auf die Landstraße. Deshalb konsequent für letzteres auch den ref der 
 Landstraße setzen. Oder
 man macht es anders herum genauso konsequent: immer den ref dahin setzen, wo 
 die Straße
 herkommt - doch wo führt uns das hin? (kleines Wortspiel).
 
 Meine Güte, es wurde doch bereits (er/ge)klärt, daß ref=* _nicht_ der
 Wörterbuch-Übersetzung (deiner Wahl) von reference entspricht,
 sondern einfach nur die Kurzbezeichnung angibt, unter der diese Route
 wenn du so willst *referenziert* wird.

Hallo Martin,

Meine Güte, der Thread ist auch schon weiter fortgeschritten - falls Du das 
nicht verfolgen konntest. Kann ja passieren.

Dort wurde auch schon ein Vorschlag für einen neuen, für den motorway_link 
evtl. besser passenden, ref-key gemacht:
leadingto_ref. Weitere Vorschläge sind bisher nicht eingetroffen - Nun vlt. 
jetzt?

Ach ja, passend dazu (nicht direkt auf Deine mail, aber zur bisherigen 
Diskussion, siehe Betreff,  passend: ) Wenn man von einer Autobahn über ein 
Autobahnkreuz/Dreieck auf eine andere Autobahn kommt, würdest Du das Kreuz mit 
seinen motorway_links auch zu der Autobahn zählen oder? Es würde ja niemand 
sagen, dass man die Autobahn am Kreuz verlassen hat und dann auf die andere 
Autobahn aufgefahren ist, sondern man würde eher sagen, dass man von der einen 
auf die andere Autobahn gefahren ist.
Ergo: der motorway_link ist zumindest im Falle von Autobahnkruezen/Dreiecken 
eben schon Teil der Autobahn und deshalb korrekt mit ref zu taggen. Warum 
brechen sich dann hier einige einen Zacken aus der Krone, normale Auffahrten 
ebenso zu taggen?
Und wnen nicht mit ref, gibts ja den Vorschlag mit leadingt_ref, zu dem ich 
mir etwas Resonanz wünschte (sowohl positive als auch negative, wenn gut 
begründet, oder besserer Vorschlag). Wenn dann genug Feedback dazu da ist, bin 
ich gerne bereit mich dafür einzusetzen und ein Proposal dazu zu schreiben.

 Im übrigen ist es kein Problem für einen Router, bei einem
 Abbiegehinweis einfach den Namen des _nächsten_ Stückchens Straße zu
 nennen, das einen solchen hat (in diesem Falle eine ref).
 Frag mal die Firma Garmin, beispielsweise.

Die Firma Garmin nutzt bekanntermaßen NavTeq und nicht OSM - und das sicher aus 
gutem Grund. Leider hatte ich noch nicht die Gelegenheit, einen Blick in die 
NavTeq-Daten zu werfen (was aus Lizenzgründen auch nicht kostenlos möglich sein 
wird ;-) Ich bin mir aber sehr sicher, dass sie den Rechenaufwand für die 
Routen-Ansagen-Generierung möglichst gering halten möchten und schon deshalb 
soviel Informationen wie möglich bereithalten. Die werden sicher keine 
Interpretationen machen, wenn sie genauso gut dafür auch die Information selbst 
vorhalten können. Und das gleiche sollten wir auch tun.

Und das was Du wahrscheinlich eigentlich meinst ist die Generierung von 
Ansagen, die in n Metern vorher genannt werden. Diese sog. Ankündigungen werden 
aber aus dem Abbiegepunkt von der Bundesstraße auf die Autobahnauffahrt 
generiert und dann die entsprechende Strecke davor festgelegt, zu der die 
Ankündigung mit n Metern angesagt wird. 
Ich kann mir nicht vorstellen, dass in NavTeq nur die Autobahn enthalten ist, 
aber in den Daten zur Auffahrt nichts steht und das Nüvi das selbst herleiten 
muss. Das wäre absurd, da das unnötigen Rechenaufwand bedeutet. Denn einmal 
eingepflegt und die Daten stehen direkt zur Ansagen-Generierung zur Verfügung.

Du aber mutest jedem potentiellen OSM basierenden Navi zu, den Rechenaufwand 
(z.B. direkt auf einem mobilen Endgerät) zu betreiben. Warum?

 Wieso sollte eine Autobahn zwei verschiedene ref-Tags haben? Die A 3 kann 
 nicht auch auf der A 7 sein. Ausnahme: motorway_links am Kreuz A 3-A 7 -  
 aber das sind auch keine Autobahnen ;-)
 
 Die Antwort ist 42.
 
 http://www.openstreetmap.org/browse/way/4241623
 
 Lass dich von der 23 nicht beirren. Das hat seine Richtigkeit.

Das mit der 42 und der 23 musst Du mir bei Gelegenheit mal erklären, bitte 
;-)
Aber danke für den Hinweis, sicher gibt es besondere Autobahnstrecken, die sich 
bei Überschneidungen wie in Deinem Beispiel ein Stück Autobahn teilen. 
Aus der Diskussion, wie das dann im Syntax mit Leerzeichen oder ohne zu machen 
ist, habe ich mich bereits zurückgezogen. Mir ist es schlichtweg wurscht (Sorry 
Bernd, keine Anspielung).

Grüße, steffterra


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

Re: [Talk-de] BAB mit no horse, bike etc.

[steffterra]

Hi,
und wieso trägt man diese tags dann nicht in der description von  
motorway und motorway_link unter implies ein? Dann fühlt man (ich  
wars nicht ;-) sich nicht mehr genötigt, das auf die AB zu mappen.  
Wäre das eine Lösung?

steffterra



Am 06.06.2010 um 12:02 schrieb aighes h.scholl...@googlemail.com:


 Die Tags sind ja nicht fehlerhaft. Sie sind lediglich für einen deut 
 schen
 bzw. für eine deutsche Karte überflüssig. Die Tags würde ich also  
 drin
 lassen. Stören tun sie ja nicht.

 Viele Grüße,
 aighes
 -- 
 View this message in context: 
 http://gis.638310.n2.nabble.com/BAB-mit-no-horse-bike-etc-tp5144924p5145058.html
 Sent from the Germany mailing list archive at Nabble.com.

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

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

Re: [Talk-de] BAB mit no horse, bike etc.

[steffterra]

Am 06.06.2010 um 14:07 schrieb aighes h.scholl...@googlemail.com:


 Hallo,
 das wurde doch schon gesagt. OSM ist ein internationales Projekt.  
 Wenn man
 für highway=motorway bicycle=no annimmt, müssten bspw. in den USA al 
 le
 Motorways mit bicycle=yes getaggt werden. Die minimale Geschwindigkeit
 unterscheidet sich auch von Land zu Land.

Naja, die Wikiseiten sind nie allgemein gültig, wie auch. Deshalb  
könnte doch auch für jedes Land in eine Tabelle eingetragen werden,  
die das entsprechende landesspezifisch aussagt. Dann gibt's halt eine  
Implies-Tabelle, die das leistet. Wo ist das Problem?

Der von Dir angesprochene Fall, dass sich jemand erst gar nicht diese  
Doku anschaut, hat sowieso verloren. Man muss sich schon etwas mit der  
Materie beschäftigen, wenn man von derselben profitieren möchte.

Letztendlich etscheidet das Gesetz im jeweiligen Land.

Doch selbst wenn jemand aus Versehen bycicle=yes hier in .de auf der A  
7 mappen würde, muss das eine Software ignorieren können, die fürs  
Fahrradrouting in .de gedacht ist.

Ich habe diese Tags immer so verstanden, dass man damit Ausnahmen und  
geregelte Abweichungen mappt und nicht den gesetzlichen Normalzustand.
Nun, das habe ich anscheinend falsch verstanden. Dann vergesst aber  
bitte nicht motorcar=yes und hgv=yes zu mappen...

Ob wir als Mapper damit jedoch Anwendungen helfen, sei dahingestellt.

Fakt ist, dass sich Software nie alleine auf die OSM-Daten verlassen  
kann, so wie der gesunde Menschenverstand auch nicht.

Also mappt doch alles, was sowieso im jeweiligen Land verboten ist,  
als verboten- dann muss die Software halt den ganzen unwichtigen Müll  
herausfiltern beim parsen der Daten. Was soll's. Darauf lässt man sich  
als Entwickler sowieso ein, alles andere wäre blauäugig.

 hinzu kommt, dass implizierte Tags immer schlecht sind. Als  
 Auswerter der
 Daten weiß man nie, ob es absichtlich weggelassen wurde, da ja impli 
 ziert

Doch - wenn man die Gesetze des jeweiligen Landes anwendet, ist man  
auf der sicheren Seite (ohne die Ausnahmen, denn dafür wären  
Zusatztags nach meinem Verständnis da).

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

Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert ei nes Tags (war: motorway und motorway_link um destinat ion-tag ergänzen )

[steffterra]

Am 06.06.2010 um 14:16 schrieb Guenther Meyer d@sordidmusic.com:

 Am Freitag 04 Juni 2010, 08:19:26 schrieb Schorschi:
 Leerzeichen zu entfernen ist technisch kein Problem, eine Anwendung
 sollte das sicherheitshalber schon koennen.
 Aber da die Leerzeichen keinerlei Vorteil bieten, laesst man sie  
 besser
 gleich weg.

 äh, soll ich jetzt sagen: typisch Computer-Freak?

 nein, Entwickler.

 Ich hatte es doch geschrieben: Lesbarkeit ... damit  
 Benutzerfreundlichkeit
 DAS Argument schlechthin, wenn man etwas lesen muss.

 Ich wage zu behaupten, dass die Daten in den meisten Faellen von  
 Software
 gelesen und verarbeitet werden.
 Und ich zumindest kann sowas durchaus auch ohne Leerzeichen lesen.

Software, die sich auf OSM-Daten verlässt, muss sich sowieso immer auf  
beide Fälle einstellen, zumindest, solange man sich keine teuren  
Lizenzen antun möchte.

Wer also einfach, ressourcensparend und effektiv Rouingsoftware bauen  
möchte, muss halt in die Tasche greifen. Schade, dass _hier_ OSM nie  
konkurrenzfähig wird, aber das liegt in der Natur der Sache und andere  
Regeln würden Innovationen in OSM im Keim ersticken.

Damit muss man aber leben, wenn man nicht zu Navteq oder Teleatlas  
verkümmern möchte.

--Somit gebe ich für meinen Teil die Diskussion über das  
Leerzeichen  nach dem Semikolon auf und halte mich in diesem Punkt  
auch nicht ans Wiki, da genau dieser Punkt immer wieder hin und her  
geändert werden wird.

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

Re: [Talk-de] BAB mit no horse, bike etc.

[steffterra]

 Warum die ganze Aufregung?

Weil diskutiert wird z.B. bycicle=no, foot=no, etc. doch bitte drin zu  
lassen. Warum um Himmels Willen? ... kann man ein paar Posts vorher  
nachlesen. Ich las es sogar als Aufforderung es so zu mappen - bei auf  
deutschen (!) motorways ...

Gruß, steffterra

 offensichtlich hat da jemand bei der JOSM-Bedienung nicht aufgepaßt. 
  Ich
 hatte bei der Änderung der alten A4 auf  Kraftfahrstraße an einer St 
 elle
 sogar *boat=no*. Ich glaube der Bug ist aber jetzt behoben.



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

Re: [Talk-de] BAB mit no horse, bike etc.

[steffterra]

[1] Auch wenn ich sie für überflüssig halte: solange sie nicht
falsch sind, bleiben die drin



Ich bin mir sehr sicher, dass genau dieses Thema schonmal  
ausführlichst durchgekaut und sogar international festgelegt wurde?


Klassischer Fall von RTFM :-)

Im Wiki steht auf der acess-Seite:
Auf dieser Seite sind Möglichkeiten dokumentiert, mit denen  
Zugangbeschränkungen zu Wegen, Straßen oder sonstigen Objekten  
angegeben werden können, die von den Standard-Access-Restrictions  
abweichen.


Auf der englischsprachigen Seite, die hier (http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions 
) verlinkt ist, kann man dann sehr schön sehen, welche tags  
standardmäßig für einen motorway in Deutschland gelten und eben aus  
genau diesem Grund nicht mehr extra zu mappen sind.


Das unterstreicht schon der erste Satz auf dieser Seite:

Limited access is documented in: Key:access.
Also nur das, was über das hinausgeht (die Ausnahmen eben) müssen  
extra getagged werden. Und wie, steht auf der access-Seite.
Jedoch nicht die default-Tags, wie sie auf dieser Seite für sehr sehr  
viele Länder stehen.


BTW, bicycle ist auch in USA no auf einem motorway, nicht jedoch auf  
einem trunk, auf dem auch Pferde und Fußgänger anscheinend erlaubt  
sind.


Liege ich nun daneben, oder wurden diese Wiki-Seiten für die Katz'  
angelegt?


stefterra

(offtopic P.S. Ich hoffe nicht, dass die unterschiedlichen  
Schriftgrössen auch bei Euch so ankommen, ansonsten entschuldige ich  
mich hiermit dafür.)





Am 06.06.2010 um 19:22 schrieb Florian Gross usenet-spam-genausoguel...@grossing.de 
:



Jan Tappenbeck glaubte zu wissen:

Am 06.06.2010 10:26, schrieb Chris66:

Am 06.06.2010 10:20, schrieb Jan Tappenbeck:

auf der Strecke Hamburg - Berlin (z.B. [1] ) habe ich gesehe das  
jemand

no horse, no bike und no foot definiert hat.

Das ist ja mehr als überflüssig - stehen lassen oder wegneh 
men??


Wie ist Eure Meinung ?


Hier in meiner Gegend pappt auch snowmobile=no, minspeed=60
etc. dran also alles eigentlich überflüssig.

Aber da es nicht weiter stört lösche ich die Tags
nur, wenn ich sowieso an der Autobahn am basteln bin.


sicher mappen wir nicht für die renderer - aber alle möglichen
tag-kombis kann man immer nur schwer filtern und deshalb dachte ich  
an

schrott weg damit !


Bitte nicht. Die Tags sind nicht falsch, also drinlassen.[1]

Du löscht tags, weil sie dir das Suchen etwas erschweren?
Das ist jetzt nicht dein Ernst, oder?

Dem nächsten sind dann Stolpersteine im Weg - ach egal, einfach
löschen und gut ist?

flo
--

Für unverlangt ausgeführte Dienstleistungen? Pah!

Wir Koennen auch Straffen verhaengen, fuer Subjektbeschaedigung!
Wenn Du schon dabei bist: könntest Du bitte mal meinen Hintern str 
affen?

:-)  Dachte Du hast ne Freundin?
  [Martin Leidig und Herbert Steinboeck in  
suse-talk]



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


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

Re: [Talk-de] ref =/ Referenz? und andere philosph . Fragen (war: Re: Trennzeichen bei Aufzählunge n im Wert eines Tags)

[steffterra]

Am 05.06.2010 um 08:51 schrieb Frederik Ramm:

 Im Englischen ist eine reference number 
 eine Nummer, unter der man etwas aufsuchen oder nachschlagen kann,

Das mag ja sein, aber ref steht für reference in jedem Wörterbuch (ich möchte 
jetzt nicht die gefühlten 15 gleichbedeutenden deutschen Synonyme von leo.org 
aufzählen, die das weiter untermauern, was reference übersetzt heisst) und 
nicht für reference number, wie man im wiki nachlesen kann (grüner Kasten) 
Sorry, aber wie soll man das wissen, dass reference number gemeint ist, wenn 
reference im Wiki steht udn sich das mehr als eindeutig übersetzen lässt. (Wenn 
es nur slang ist, dann ist es schade, dass das noch niemand richtig gestellt 
hat.)

 aber wie gesagt, es ist sowieso fahrlaessig, solche Behauptungen allein aus 
 der (vermuteten) Bedeutung des Worts, das als key eingesetzt wird, 
 abzuleiten.

und wer sagt, dass Du nicht nur vermutest? ;-)

 Und was spricht gegen die Nutzung von OSM als Router?
 
 Nichts natuerlich. Aber man sollte Daten nicht falsch eintragen, nur 
 damit ein (schlecht programmierter?) Router bessere Arbeit machen kann. 

das ist richtig.

 Und meines Erachtens ist es falsch, ein ref=A5 an etwas zu haengen, was 
 nicht die A5 ist.

Das hat sich aber in .de so eingebürgert - lange vor unserer Diskussion :-) 
Vlt. auch weil es eben keine deutsche Wiki-Seite dazu gibt, die es so erklärt 
hat wie Du.

 Fuer dieses Stuck Strasse fuehrt auf etwas, das A5 heisst wuerde ich 
 in der Tat ein eigenes Tag erfinden.

Gut, das packen wir dann auf die deutsche wiki-Seite. Nennen wir ihn 
referring? Dann ist die Wortbedeutung einleuchtend: bezugnehmend, denn 
referenz (Bezug) ist ja schon besetzt.

 (Gibts uebrigens auch im 
 innerstaedtischen Gebrauch manchmal - Strassenschilder mit Amselweg, 
 Zugang zu Drosselweg oder so.)


Und wie wird das gemappt?

Danke für die Hinweise,

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

Re: [Talk-de] ref =/ Referenz? und andere philosph. F ragen (war: Re: Trennzeichen bei Aufzählungen im We rt eines Tags)

[steffterra]

Am 05.06.2010 um 13:05 schrieb Frederik Ramm frede...@remote.org:

 Hallo,

 steffterra wrote:
 Fuer dieses Stuck Strasse fuehrt auf etwas, das A5 heisst wuerde
 ich in der Tat ein eigenes Tag erfinden.

 Gut, das packen wir dann auf die deutsche wiki-Seite. Nennen wir ihn
 referring? Dann ist die Wortbedeutung einleuchtend: bezugnehmend,
 denn referenz (Bezug) ist ja schon besetzt.

 Das ist hetzt sicher nicht ernst gemeint, oder? Da waeren ja staendige
 Verwechslungen vorprogrammiert.

Nein, war _nicht_ ernst gemeint.

 Ausserdem waere das zu schwach, denn es
 handelt sich ja nicht um irgendeine beliebige Bezugnahme, sondern um  
 ein
 Ziel - leading_to oder sowas waere m.E. angebrachter.

Dann schon eher leadingto_ref als neuen ref-key. Das wäre mir sogar  
ein proposal (mit anschließender Übersetzung der ref-Wikiseite) wert,  
wenn sich hier mehr Anhänger dafür gewinnen ließen.

Was sagt Ihr? Weitere Vorschläge?

 Andererseits kann ein halbwegs intelligenter Router das auch selber
 rausfinden, dass man, wenn man die Auffahrt rauffaehrt, auf etwas  
 kommt,
 das A5 heisst. Deswegen kriegen meine Auffahrten auch kein ref ;-)

Das mag für einfache Auffahrten gelten. Es gibt aber häufig baulich  
sehr kompliziert gestaltete Auffahrten, wo das mit einem  
softwareseitigen Verfolgen des ways (wohin er führt), nicht getan ist,  
da es zuviele Möglichkeiten gibt.

Aber vielleicht finden sich ja ein paar Unterstützer für meinen  
obigen Vorschlag, leadingto_ref einzuführen...?

Andere Vorschläge?


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

Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um d estination-tag ergänzen )

[steffterra]

Am 04.06.2010 um 13:25 schrieb Bernd Wurst:

 Dir ist klar, dass wir hier nur von Tags reden, die mehrere Werte beim selben 
 Key haben? Das kommt nicht alle Tage vor und das läuft dem normalen Mapper 
 auch nicht jeden Tag übern Weg. 

Kann ich nur unterstützen. Im konkreten Fall ging es bei ref und bei 
destination ausschließlich um sehr kurze ways, auf denen im Gegenverkehr 
Auffahrt und Abfahrt einer  Autobahn auf dem _selben_ way befinden, oder kurze 
Strecken an Autobahnkreuzen, die für die Abfahrt in mehrere Richtungen gelten 
und sich dann gleich wieder in die Zielrichtungen aufteilen. Das ist zwar recht 
Häufig an Autobahnen und ersteres auch an Bundes- und Kraftfahrstraßen-Auf - 
und Abfahrten, aber in der Häufigkeit auch nur dort und ziehen sich nicht 
durchs gesamte Land.

Ich sehe da auch keine Probleme bei der Lesbarkeit: Wo ist der _nennenswerte_ 
vorteil von ref=A 7;A 3 gegenüber ref=A 7; A 3? mehr als zwei kommen da eh 
nicht ins Tag, da es sehr weniger Autobahnkreuze gibt, an denen mehr als zwei 
Autobahnen kreuzen ;-)
Das gleiche für den destinatin-Tag im Falle einer gemeinsamen Auf- und Abfahrt 
auf motorway_link: destination=Würzburg:Dettelbach gegenüber 
destination=Würzburg; Dettelbach. Wenn ich eine lange Wortkette hätte, bei 
denen sich 5-10 Städtename aufreihen würden  Warum diskutieren wir 
überhaupt darüber. Solche Auffahrten gibt es nämlich nicht ;-)

Im Falle der beiden ways für jede Fahrrichtung von Autobahnen sind 
Autobahnbezeichnung und Europastraßenbezeichnung sowieso getrennt (z.B. ref=A 
7, int_ref= E 45) und ohne den ref-Tag würde der Renderer auch keine A 7 auf 
den way rendern. Also warum alle Auf- und Abfahrten möglichst in einzelne 
Relationen packen? Verstehe ich nicht. Für die Autobahn/Europastraße 
selbstverständlich schon.

Schönes Wo-Ende, steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)

[steffterra]

Am 04.06.2010 um 13:32 schrieb Frederik Ramm:

 Hallo,
 
 steffterra wrote:
 Keine Ahnung, vlt. ist auch das Komma mit Leerzeichen ungewöhnlich und man 
 sollte auch beim ref eher Semikolon und kein Leerzeichen verwenden? 
 Weiss da jemand mehr darüber, was bei anderen Tags üblich ist?
 
 Wenn es irgend geht, sollten mehrere Werte in einem Tag vermieden 
 werden.

Zustimmung.

 Ich weiss, dass es nicht immer geht,

ja. Z.b. wenn ein way sich eine Auf- und eine Abfahrt im Gegenverkehr teilt und 
sich erst beim Anschluss jeweils aufteilt. - nur so als Beispiel.

 aber eine Aufazehlung mit 
 Trennzeichen ist immer die zweitbeste Loesung. Im Falle von ref wuerde 
 ich z.B. Relationen benutzen

Also jede einzelne Auffahrt und jede Abfahrt als Relation erfassen? Was für 
Vorteile bietet das gegenüber dem kurzen, schnellen einfachen mapping von 
ref=A 7;A 3 und von destination=Würzburg;Frankfurt?

 und am Way selbst nur eine, oder sogar gar 
 keine, der Strassenbezeichnungen setzen.

O.k. man soll nicht für die Renderer und andere Software mappen. Aber derzeit 
wird imho zumindest in Mapnik die Darstellung der Autobahn-Nummer durch den 
ref-Tag erzeugt, oder? 
Wohl auch dem Vorteil nach, dass wenn man sich da alleine auf (evtl. kaputte) 
Relationen verlassen würde, das Rendering u.U. auch mal durchlöchtert wäre.

Darf ich mal eine Grundsatzfrage stellen? Ich lese ja erst seit kurzem mit. 
aber ich bemerke immer wieder zwei Lager: die einen, die am liebsten _alles_ in 
Relationen packen würden und die Verfechter der Meinung, das kurze prägnante 
neue Zusatztags viele Vorteile bieten. Was sind denn die großen Vorteile von 
Relationen für _alles_?

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

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 04.06.2010 um 13:47 schrieb Thomas Ineichen:

 Hallo steffterra,
 
 Am Thu, 03 Jun 2010 00:50:30 +0200 schrieb steffterra:
 das habe ich bisher auch, bis ich die Wikieinträge (die mittlerweile Dank 
 Eurer Unterstützung wieder online sind!) geschrieben habe.
 Der ref-Tag gibt vor, dass man ref=A 7, E 22 taggen soll - also Komma und 
 Leerzeichen. Ich habe das jetzt für den destination-tag übernommen, dass es 
 einheitlich ist. Ich werde meine mappings dahingehend auch ändern. Oder mag 
 da jemand nen Robot drüber laufen lassen? ;-) Wäre super!

Nun hat sich ja herausgestellt, dass das mit Semikolon ohne Leerzeichen (wenn 
auch wohl umstritten), das allgemein übliche ist und ich habe es im Wiki 
entsprechend angepasst und für destination sowieso.
Außerdem war das Beispiel schlecht, da natürlich int_ref für E 22 zu verwenden 
ist. Mein Fehler.

 Nur, weil's sonst noch niemand gesagt hat (und die Diskussion abgedriftet
 ist):
 
 Für das E-Netz wird häufig der Key int_ref=* verwendet. Du könntest 'A 7'
 und 'E 22' also auf zwei verschiedene Keys aufteilen.

Danke. s.o.

Falls nun jemand meint, das wäre auch für den destination-key wichtig: Nope. 
Weil es keine grünen Autobahn-Auffahrtschilder gibt, auf denen der Städtename 
des nächsten Europastraßen-Fernziels steht ;-) Und falls irgendwo auf der Welt 
dennoch beides in äquivalenter Weise vorhanden wäre, kann man auch 
int_destination als key für deren Auffahrten einführen, oder?

 (Längerfristig gehören diese refs natürlich sowieso in eine Relation.)

(habe ich schon unter anderem subject gefragt, bitte nicht unter diesem auch 
nochmal antworten)


Grüße, steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um d estination-tag ergänzen )

[steffterra]

Am 04.06.2010 um 19:42 schrieb steffterra:

 Das gleiche für den destinatin-Tag im Falle einer gemeinsamen Auf- und 
 Abfahrt auf motorway_link: destination=Würzburg:Dettelbach gegenüber 
 destination=Würzburg; Dettelbach. 

Ich muss mich selbst korrigieren. Natürlich werden im Falle einer gemeinsamen 
Auf- und Abfahrt auch eigene keys verwendet: In Richtung des eingezeichneten 
way: destination:forward=Würzburg und in der Gegenrichtung 
destination:backward=Dettelbach
Also stellt sich hier die Frage der Lesbarkeit erst gar nicht...

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

Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)

[steffterra]

Am 04.06.2010 um 20:42 schrieb Frederik Ramm:

 steffterra wrote:
 Also jede einzelne Auffahrt und jede Abfahrt als Relation erfassen?
 
 Ich habe die Auffahrt-Problematik nicht praesent; falls Du gerade
 vorschlaegst, ein ref=A3 an eine Auffahrt zu setzen, die auf die A3
 fuehrt, so wuerde ich dem widersprechen - ref=A3 soll m.E. nur an
 Strassenstuecke, die Teil der Autobahn sind.

Dem muss ich nun widersprechen - und nicht nur weil genau das etablierte Praxis 
ist ;-) Laut einem sehr alten Wikieintrag für motorway_link gilt folgendes (und 
ist imho auch weit verbreitet etabliert und steht wohl auch deshalb im wiki):
Die Verbindungen zwischen zwei Autobahnen sollten gewöhnlich mit dem ref=* 
derjenigen Autobahn markiert werden, zu der sie führen (Ich habe diesen Satz 
nun um den destination-key erweitert)
Dem entsprechend sagt mir die Logik, dass ich nicht nur die Auffahrt mit dem 
ref der Autobahn mappe zu der sie führt, sondern ebenso die Abfahrt mit dem ref 
der Bundesstraße (oder was auch immer folgt) zu dem sie führt, mappe. 

Du begeründest es mit:
 ref=A3 soll m.E. nur an Strassenstuecke, die Teil der Autobahn sind.

Der Kausalität nach gehört  imho die Auffahrt zur Autobahn und die Abfahrt zur 
Bundesstraße zu der sie führt. Demensprechend ref-Autobahn an Auffahrt 
ref-Bundesstraße an die Abfahrt. Diese Logik ist imho sehr klar  und kann so 
auch an komplizierten AB-Kreuzen/Anschlussstellen durch reine Logik konsequent 
umgesetzt werden. Diese Art die motoway_links, trunk_links und secondary_links 
(etc.) zu mappen bringt absolute _direkt nutzbare_ Vorteile für Routingsoftware 
gegenüber dem Nichtmappen, ebenso wie der destination-key.

 Daher ist es auch ein
 leichtes, die alle in eine Relation A3 zu packen. Die Auffahrt braucht
 m.E. keine Relation. Das destination=A;B laesst sich auch nicht gut
 durch eine Relation ersetzen,

Dann sind wir ja einer Meinung :-)

 aber in diesem Fall ist das ja eh weniger 
 ein computerlesbares Tag sondern nur ein abgeschriebenes Verkehrsschild.

Es geht _nicht_ darum, Schilder zu taggen. Dafür gibt es die 
Schilder-Relationen. Das Ablesen des Schildes ist nur als Informationsquelle 
für den destination-key gedacht. 

Dieser wiederum kann leicht von Software wie z.b. routern ausgelesen und direkt 
für sehr natürliche Anweisungen genutzt werden, weil der Fahrer die gleiche 
Anweisung dann auf dem Schild zu lesen bekommt - Diese gleiche 
Orientierungs-Basis erleichtert jede Navigation. (Negativ-Beispiel: ''Viele 
Navis, nennen die Namen der Staats- und Stadt-Straßen, wie z.B. St 2245, wenn 
sie eine Routenanweisung geben. Das ist Quatsch, weil das nicht der 
Orientierung dienlich ist, da das dass auf keinem Straßenschild steht. Hilft 
dem Fahrer also nicht wirklich. )
Der ref- und der destination-key jedoch schon, weil er eben vom Auffahrtsschild 
abgelesen wurde und sich auch auf anderen Hinweisschildern für die Autobahn 
wieder findet. Das gleiche gilt für Abfahrten: Auf der AB findet man dort den 
Hinweis auf die Bundesstraße und den Zielort zu dem sie führt. Perfekt im 
destination und ref-Tag der Abfahrt untergebracht! (siehe obige Argumentation!)

 Darf ich mal eine Grundsatzfrage stellen? Ich lese ja erst seit
 kurzem mit. aber ich bemerke immer wieder zwei Lager: die einen, die
 am liebsten _alles_ in Relationen packen würden und die Verfechter
 der Meinung, das kurze prägnante neue Zusatztags viele Vorteile
 bieten. Was sind denn die großen Vorteile von Relationen für _alles_?
 
 Relationen fuer alles ist Quatsch. Relationen sollten da benutzt 
 werden, wo mehrere Objekte zusammengehoeren und/oder wo ein Tag alleine 
 nicht ausreicht. Also z.B. wenn Du an ein Haus architect=Friedensreich 
 Hundertwasser dranschreibst als Tag ist das voellig ok, eine Relation 
 dafuer waere ueberfluessig (Leute machen das manchmal, weil sie auf 
 einfache Weise alle Haeuser von Hundertwasser aus der Datenbank laden 
 wollen, das geht mit einer Relation gut, aber ich halte das fuer einen 
 Missbrauch).

Wenn man nun alle motorway_links mit Relationen zusammen fassen würde - was 
würde das für einen Vorteil bringen? Welchen direkten Nutzen habe ich derzeit 
davon?

 Sobald Du aber anfangen musst, mit einem Semikolon zu 
 operieren, weil ein Stueck Strasse sowohl zum Wanderweg A als auch zum 
 Wanderweg B gehoert, ist eine Relation fuer beide Wanderwege sinnvoll.

Für einen Wanderweg, Radroute, Mottarroute, etc. sicher. Aber doch nciht für 
die kurzen Wege einer Autobahnauffahrt die maximal (im gemeinsamen Teil, weil 
nicht baulich getrennt) mehrere 100m beträgt...

 Oftmals - aber nicht immer - funktioniert die folgende Faustregel: Mappe 
 ich eine wesentliche Eigenschaft eines Objekts, kommt das in ein Tag. 
 Mappe ich hingegen etwas, wo das Objekt nur eine Rolle spielt, dann 
 ist eine Relation besser. Wenn die Stadtverwaltung sich heute 
 entscheidet, dass der Stadtrundgang kuenftig durch die A-Strasse und 
 nicht mehr durch die B-Strasse fuehren soll, dann aendert sich

[Talk-de] ref =/ Referenz? und andere philosph . Fragen (war: Re: Trennzeichen bei Aufzählunge n im Wert eines Tags)

[steffterra]

Am 05.06.2010 um 00:54 schrieb Thomas Ineichen:

 Hallo steffterra,
 
 am Freitag, 4. Juni 2010 um 21:41 schrieb steffterra:
 
 Am 04.06.2010 um 20:42 schrieb Frederik Ramm:
 Ich habe die Auffahrt-Problematik nicht praesent; falls Du gerade
 vorschlaegst, ein ref=A3 an eine Auffahrt zu setzen, die auf die A3
 fuehrt, so wuerde ich dem widersprechen - ref=A3 soll m.E. nur an
 Strassenstuecke, die Teil der Autobahn sind.
 
 Dem muss ich nun widersprechen - und nicht nur weil genau das
 etablierte Praxis ist ;-) Laut einem sehr alten Wikieintrag für
 motorway_link gilt folgendes (und ist imho auch weit verbreitet
 etabliert und steht wohl auch deshalb im wiki):
 Die Verbindungen zwischen zwei Autobahnen sollten gewöhnlich mit
 dem ref=* derjenigen Autobahn markiert werden, zu der sie führen
 
 Ich  glaube, das hat sich vor allem durchgesetzt, weil dann der Router
 so  schön  sagen  kann  fahren Sie rechts auf die A3. Was *wirklich*
 alles  zur A3 gehört, darüber lässt sich lange philosophieren. 

Nunja ref ist laut wiki die Abkürzung für reference das heisst einfach 
übersetzt Referenz oder Bezug

Und wenn ich dem highway_link den ref= A 3 gebe, dann sage ich damit aus, dass 
dieser Link zur A 3 einen Bezug hat, nämlich den der Auffahrt (was wiederum 
der highway_link aussagt)
Man könnte eher umgekehrt argumentieren und sagen, die Autobahn selbst darf 
nicht ref tragen,  da sie nicht nur einen Bezug zu dieser hat, sondern sie es 
selbst ist ;-)
Wo ist das Problem?

 (Ich habe diesen Satz nun um den destination-key erweitert)
 
 *Nur*  ein  destination=*  bzw. ein destination_ref=* an die motorway_
 links wäre meiner Meinung nach am besten, aber etablierte Systeme kann
 und darf man nicht einfach so umstellen.

Naja, vielleicht entwickelt sich das ja dann daraus. Wäre ja nicht so schlecht. 
Ich mache da jetzt aber kein proposal draus ;-)

 werden. Diese Art die motoway_links, trunk_links und secondary_links
 (etc.) zu mappen bringt absolute _direkt nutzbare_ Vorteile für
 Routingsoftware gegenüber dem Nichtmappen, ebenso wie der destination-key.
 
 Das  Nützliche  ist  eben  nicht immer richtig, und das Richtige nicht
 immer nützlich.. ;)

Nicht immer, aber ist es in diesem Fall falsch, obwohl seit langem etabliert? 
Da sind wir natürlich bei Grundsatz-philosophischen Fragen zu OSM angekommen. 
Dabei dreht sich doch immer alles darum, was falsch und richtig ist und wer es 
festlegen darf.
Ich bin immer noch der Meinung, dass alles, was sich breit etabliert hat, auch 
einen Nutzen hat  - und schon deshalb nicht falsch sein kann, da ja bewährt.

Und was spricht gegen die Nutzung von OSM als Router? Wofür machen wir die 
Karte überhaupt? Richtig - zur Orientierung auf Papier oder Computerbasis. Zur 
Orientierung trägt der ref-und destination-tag allemal bei ;-)

Es wird immer wieder darüber gesprochen, dass man nicht für Router oder andere 
Software oder auch Renderer _speziell_ taggen soll, weil das Datenmüll 
produziert, weil die Renderer und Router von heute das vlt. brauchen können, 
die von morgen schon nicht mehr und dann liegt er rum der Datenmüll, der sonst 
keinen Nutzen hat. (wer weiss wie lange noch Osmrender-tags genutzt werden ... 
und dann nur rumiegen)
Im Falle von allgemeinen Tags und Keys die einen Zustand oder eine Eigenschaft 
einer Straße beschreiben, besteht diese Festlegung auf ein propiertäres System 
nicht. Der Informationsgehalt bleibt - egal von wem oder was er heute oder in 
Zukunft ausgelesen/ausgewertet wird.

 Wenn  man  den  ref  auch  benutzt  um  anzugeben, auf welchen ref die
 Strasse hinführt, dann Verwässert man die Bedeutung des ref-Keys..

nein, denn ref heisst Referenz . siehe oben. Unglücklich gewählte 
Wortbedeutung? Hätte man etwas anderes nehmen sollen als ref?

 Der Übergang zum Missbrauch ist sehr fliessend. Sobald es sich um mehr
 als  eine  (1) gemeinsame Eigenschaft handelt (z.B. Autobahn und in
 der  Schweiz),  gibt  bisher  kein  anderes  OSM-Werkzeug, welches so
 schnell und einfach ein Ergebnis liefert wie die Relation.

Dieses Ergebnis jedoch schnell verfügbar zu machen ist aber auch heute noch mit 
Mehraufwand verbunden, den der tag nicht benötigt. Aber für diese besonders 
zusammenhängenden Informationen (weswegen man sie in eine solche Relation 
packt) nimmt man den Mehraufwand gerne in Form von Rechenkraft und Zeitaufwand 
in Kauf. doch für einfache Informationen, die schnell verfügbar sein sollen 
steht das derzeit noch in keinem Verhältnis.

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

[Talk-de] motorway_link mit ref taggen oder etwa nicht??? (war: Re: Trennzeichen bei Aufzäh lungen im Wert eines Tags (war: motorway und motorwa y_link um destination-tag ergänzen))

[steffterra]

 
 Glueck sagen, dass die Leute, die vor 5 Jahren mit OSM angefangen haben, 
 nicht vorrangig diese Frage gestellt haben ;-)

Ich denke sehr wohl, dass sie sich diese Frage gestellt haben, als sie ihre 
erste Prioritätenliste erstellt haben. Aber da kann man Steve ja mal fragen ;-)
Deine Aussage impliziert, dass sie wild drauf losgetaggt haben, egal, ob sie 
dafür schon damals einen direkten Nutzen gesehen haben. Das denke ich nicht. 
Ich denke, sie haben sich sehr wohl die Frage gestellt: wie fangen wir am 
besten an, dass man das _später auch mal_ nutzen kann... Und diese Frage 
sollte man sich auch stellen, wenn man darüber nachdenkt, dass man diese blauen 
Schilder an den Autobahnauffahrten später auch mal nutzen können sollte - und 
welch Freude - es geht heute schon! :-)

schöne Tage,
 steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)

[steffterra]

Am 03.06.2010 um 09:43 schrieb Chris66:

 Am 03.06.2010 00:50, schrieb steffterra:
 
 Der ref-Tag gibt vor, dass man ref=A 7, E 22 taggen soll - also Komma und 
 Leerzeichen. 
 
 Oha, ich dachte es sei Usus (und habe es bisher immer so in den Daten
 gesehen), bei mehreren Values pro Tag das Semikolon zu benutzen.

Keine Ahnung, vlt. ist auch das Komma mit Leerzeichen ungewöhnlich und man 
sollte auch beim ref eher Semikolon und kein Leerzeichen verwenden? 
Weiss da jemand mehr darüber, was bei anderen Tags üblich ist?

Danke im voraus, 
steffterra
 
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 03.06.2010 um 08:44 schrieb Bernd Wurst:

 Am Mittwoch 02 Juni 2010, 20:39:55 schrieb steffterra:
 Das Fernziel ist jedoch nur eines dieser junctions
 
 Noch nichtmal das.
 
 Fernziele sind meistens Städte gewisser Größe, die mehrere Autobahnabfahrten 
 haben (oder gleich per Kreuz mit einer Bundesstraße/lokalen Autobahn 
 angebunden sind).
 Es gibt z.B. meines Wissens keine Autobahnabfahrten Hamburg oder 
 Stuttgart.

glaube ich auch. Hast Recht. Dennoch werden diese Fernziele als Städtenamen auf 
den Auffahrten genannt. die Abfahrten sind dann meist genauer bezeichnet, schon 
weil es an diesen Fernzielen meist mehrere Abfahrten gibt (xy Nord, xy Süd, mit 
Namens-Zusatz der nä. Ortschaft in der Nähe der Abfahrt, etc.)

Kennt ihr eine Liste/Datenbank, in der die Auffahrten mit ihren 
Fernziel-Städtenamen (Zeichen Nr. 430, und für AB-Kreuze Nr.448) gesammelt sind?

Danke,

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

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 03.06.2010 um 20:50 schrieb Bernd Wurst:

 Hallo.
 
 Am Donnerstag 03 Juni 2010, 19:48:40 schrieb steffterra:
 Kennt ihr eine Liste/Datenbank, in der die Auffahrten mit ihren
 Fernziel-Städtenamen (Zeichen Nr. 430, und für AB-Kreuze Nr.448) gesammelt
 sind?
 
 Es ist nicht exakt das was du suchst, aber die Fotos auf 
 http://www.autobahn-bilder.de/
 sind dafür gut geeignet.

Das ist ja der Hammer - da hat sich ja jemand wirklich Arbeit gemacht (die 
postproduction war sicher sehr aufwendig)

Danke dafür,

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

Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um d estination-tag ergänzen )

[steffterra]

Am 03.06.2010 um 20:57 schrieb Gerry Light:

 Am 03.06.2010 20:33, schrieb Bernd Wurst:
  Ich würde ganz stark dazu raten,
 überall Semikolon zu benutzen, das
 
  ist vergleichsweise sehr weit verbreitet.
 
 
 +1
 
 nicht nur verbreitet, sondern auch dokumentiert, siehe z.B. auch 
 http://wiki.openstreetmap.org/wiki/Faq#What_shall_I_do_for_roads_that_have_multiple_values_for_a_tag.3F

Habs geändert für motorway und motorway_link  und natürlich auch für 
destination richtig mit Semikolon ohne Leerzeichen eingetragen. Des weiteren 
habe ich mir erlaubt die engl. Seite für ref auf den Fall der mehrfachen 
Values etwas anzupassen. (Daher stammt auch Dein link, wie ich vermute)  Passt 
doch so, oder? :-)

Grüße,

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

[Talk-de] Re: motorway und motorway_link um de stination-tag ergänzen

[steffterra]

Am 02.06.2010 um 10:28 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.c 
om


 selbst im August 2009 (OSMDoc) gab es den Tag schon 448 mal, und
 nochmal ca. 200 mal mit destination1, 2, etc.

In welchem Kontext wird denn destination1, destination2, etc. genutzt?  
Als Fernziel, dann näheres Ziel? So wie auf der Autobahn  
ausgeschildert das oberste das Fernziel und dann darunter (meist auch  
kleiner geschrieben) das nähere? Macht das Sinn, das so zu nutzen?  
gibt's dazu ein ProposL ;-) das das näher erklärt? Ggf. macht es ja  
Sinn, das dann ins Wiki zu übernehmen.

Halte ich pers. halte es aber für überflüssig, diese Angabe in  
Abstufungen, denn die näheren Ziele könnten auch durch die Software  
(z.B Navi) auch über den highway_junction-Node abgefragt werden, der  
an jeder Abfahrt getaggt sein sollte.

Das Fernziel ist jedoch nur eines dieser junctions und deshalb  
sinnvoll extra über den destination-tag genannt zu werden (und  
natürlich auch weil der natürlicher Orientierung des Fahrers  
zugrundeliegend dieses Fernziel immer an den Auffahrtschildern, bei  
Unfallangaben und im Verkehrsfunk genannt wird).

steffterra

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

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 02.06.2010 um 21:41 schrieb Chris66:

 Am 02.06.2010 20:39, schrieb steffterra:
 
 In welchem Kontext wird denn destination1, destination2, etc. genutzt?  
 Als Fernziel, dann näheres Ziel? 
 
 Vermutlich soll es das bedeuten, ich persönlich habe allerdings mit der
 Semikolonschreibweise gemappt (destination=Hamburg;Bremen)

das habe ich bisher auch, bis ich die Wikieinträge (die mittlerweile Dank Eurer 
Unterstützung wieder online sind!) geschrieben habe.
Der ref-Tag gibt vor, dass man ref=A 7, E 22 taggen soll - also Komma und 
Leerzeichen. Ich habe das jetzt für den destination-tag übernommen, dass es 
einheitlich ist. Ich werde meine mappings dahingehend auch ändern. Oder mag da 
jemand nen Robot drüber laufen lassen? ;-) Wäre super!

Grüße und Danke an alle,

steffterra

P.S. ich habe die destination-Wikieinträge in .de und .en mittlerweile um die 
Sonderfälle ergänzt für den gemeinsamen way und den Fall der gemeinsamen Auf- 
und Abfahrt und für letzteres :backward und :forward genutzt. 
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 02.06.2010 um 23:37 schrieb Carsten Gerlach:

 Naabend,
 
 Am Mittwoch 02. Juni 2010 20:39:55 schrieb steffterra:
 In welchem Kontext wird denn destination1, destination2, etc. genutzt?
 
 Jetzt fällt mir wieder ein, daß Mirko Küster mal erwähnt hat, mit diesem Tag 
 Wegweiser an Radwegen zu versehen, also an Knoten mit information=guidepost.

Ist ja auch nicht verkehrt und im sinngemäß das gleiche wie an der Autobahn - 
nur auf einem anderen way-typ eben. Aber er nutzt es am node anstatt am 
gesamten way?

Die einzigen Bedenken die ich dabei habe ist, dass dadurch n-fache 
destination-tags produziert werden. Mein Vorschlag wäre hier eher das mit einem 
angehängten :1 zu machen. also z.B:
destination:1= , destination:2=, usw.

nur so ne Idee ...

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

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 01.06.2010 um 11:30 schrieb M∡rtin Koppenhoefer:

 Am 1. Juni 2010 10:11 schrieb Chris66 chris66...@gmx.de:
 Am 01.06.2010 02:24, schrieb steffterra:
 Ist hiermit für motorway, motorway_link und trunk geschehen. Der 
 destination-Tag ansich wird diese Tage im Wiki ausführlich erklärend 
 ergänzt.
 
 Meine Einträge im deutschen und englischen OSM-Wiki wurden wieder gelöscht 
 (Norwegischer User Gnonthgol) mit der Begründung no tag.
 Wie gehe ich vor, dass das nicht nochmal passiert? Muss der tag 
 destination erst irgendwie allgemein akzeptiert werden?
 Du musst erst eine Proposed Feature Page im Wiki anlegen.
 http://wiki.openstreetmap.org/wiki/Proposed_Features
 
 
 alternativ kann man einen Tag direkt im Wiki hinzufügen

das hatte ich ja versucht. Die Einträge wurden aber wieder gelöscht: 

z.b. diese hier für DE:Tag:highway=motorway_link:
http://wiki.openstreetmap.org/w/index.php?title=DE:Tag:highway%3Dmotorway_linkcurid=26543diff=481049oldid=480948
die anderen:
http://wiki.openstreetmap.org/w/index.php?title=DE:Tag:highway%3Dtrunkcurid=9150diff=481050oldid=480943
http://wiki.openstreetmap.org/w/index.php?title=DE:Tag:highway%3Dmotorwaycurid=26541diff=481048oldid=481010
http://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dtrunkcurid=9149diff=481047oldid=481017

Übersicht über alle Änderungen: 

 wenn er gut
 etabliert ist, also bereits oft im Planetfile vorkommt. Das wäre bei
 einem Tag wie hier mind. ein paar hundert mal.

mittlerweile wurde auch eine nähere Begründung in der Diskussion zum tag 
destination begonnen: 
http://wiki.openstreetmap.org/wiki/User_talk:Steffterra#Key:destination

so long,

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

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 01.06.2010 um 19:35 schrieb Carsten Gerlach:

 Also laut Tagwatch von gestern kommt der Tag in Europa 3992 mal und in Asien  
 3 mal vor. Das sollte doch als ausreichend etabliert gelten.

Hast du mal bitte einen link - ich kam nicht auf diese Zahl. Kann man das 
Suchergebnis nach tag-Kombinationen filtern, sodass z.B. nur motorway_links 
rauskommen, etc.?

 @ Steffterra: Schreib den Wiki-Löscher an und weise ihn auf das Vorhandensein 
 hin. Falls ihm keine weitere Begründung einfällt, als no tag, dann möge er 
 doch deinen Eintrag bestehen lassen. :-)


Danke für die Tips und Infos. Habe ihn jetzt angeschrieben. Mal sehen wie er 
reagiert.

steffterra


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

[Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Hallo liebe talk-de-comunity

ich bin relativ neu bei OSM (1 Jahr), und lese talk-de regelmäßig seit ca. 8 
Wochen. Nun möchte ich einen Vorschlag machen, der das Autobahnrouting und 
damit die Nutzung von OSM-Navi's wesentlich natürlicher gestalten könnte.

Wenn z.b. neben ref=A 7 noch der Tag destination=Kassel auf dem way vom 
motorway_link (nur Auffahrt) zusätzlich gesetzt werden würde, könnte ein 
Routing-Programm diesen Tag sehr leicht auswerten.
Stellenweise habe ich schon gesehen dass ref=A 7 Kassel getaggt wurde, was 
ich aber nicht für sinnvoll halte. Zustätzlich kann man sich noch überlegen, 
den Autobahn-way in entsprechender Richtung ebenfalls mit dem destination-tag 
auszustatten.

Vorteile: 
- Sofortige Information über die Richtung einer Auffahrt oder eine 
Autobhanabschnitts. Durch einfaches und schnelles Auslesen des Tags wäre es 
Routern/Navis sofort möglich zu bestimmen, in welche Richtung man unterwegs 
ist. Also z.b. in Richtung Kassel. Woher soll der Router sonst wissen, wohin 
dieser Autobahnabschnitt führt? Stadt-Polygone-auswerten und schauen, ob diese 
Autobahn diese durchkreuzt ist ungleich aufwendiger, als einfach den 
destination-Tag auszulesen.

- Einfachere Generierung von Auffahrts-Anweisungen an motorway_links:  Eine 
Abbiegeanweisung auf die A 7 Richtung Kassel ist mit diesem Tag deutlich 
schneller und weniger rechenintensiv zu erzeugen, als den Stadt-Polygon (s.o.) 
auszuwerten. Unnatürliche Anweisungen ohne Richtungsangabe jetzt abbiegen auf 
A 7  würden der Vergangenheit angehören.

Nachteile:
- sehe ich derzeit keine, da es sich um ein einfaches Tag handelt, das nicht 
kompliziert ist. 
- Das Wiki wäre auf 
- http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dmotorway
- http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dmotorway_link
- http://wiki.openstreetmap.org/wiki/Autobahn
relativ einfach zu ergänzen.

Vorgehensweise: 

- an Auffahrten: als destination (also Richtung) sollte der Name der Stadt 
eingetragen werden, die auf dem blauen Auffahrtsschild steht

Beispiel:

highway=motorway_link
ref=A 1; E 22
destination=Lübeck
maxspeed=60
etc...

- auf der AB selbst: als destination sollte der Name der Stadt eingetragen 
werden, der zuoberst des blauen Autobahnschildes steht.

Beispiel:

highway=motorway
name=Lübeck - Stuhr
destionaion=Lübeck
lanes=4
maxspeed=100
etc...

Anmerkungen/Bedenken:

- Abfahrten benötigen keinen destination-tag, da hier ja schon durch 
motorway_junction:name=xyz der Name der Stadt enthalten ist, zu dem die Abfahrt 
gehört.
- der name-Tag des motorway ist nicht aussagekräftig bezüglich der Richtung, 
in der dieser way führt. Z.B. A 7 Ulm-Kassel IMHO ändert sich der Name nicht 
in A 7 Kassel-Ulm, wenn man die Gegenrichtung taggt - oder habe ich das im 
wiki übersehen? Der motorway_link wäre dennoch sinnvoll mit destination zu 
taggen.
- Richtigerweise werden jetzt manche sagen, dass man nicht für Anwendungen 
taggen soll. Das ist auch meine Meinung. Doch durch diesen Vorschlag würden 
keine gültigen OSM-Tagging-Regeln verbogen werden, um es routern einfacher zu 
machen. sondern der Informationsgehalt würde verbessert werden, der nicht nur 
Routern zugute kommen würde.

Freue mich über zahlreiches Feedback,

steffterra

http://developer.roadee.net
http://map.roadee.net/routino/router.html




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

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 31.05.2010 um 13:25 schrieb Chris66:

 Am 31.05.2010 13:18, schrieb steffterra:
 
 ich bin relativ neu bei OSM (1 Jahr), und lese talk-de regelmäßig seit ca. 8 
 Wochen. Nun möchte ich einen Vorschlag machen, der das Autobahnrouting und 
 damit die Nutzung von OSM-Navi's wesentlich natürlicher gestalten könnte.
 
 +1
 einige Autobahnkreuze sind schon so getaggt.

das stimmt. Doch wäre es doch gut, wenn das auch Einzug in die Wiki-Seiten 
hielte, oder? An wen wende ich mich da am besten? Liest hier jemand mit, der da 
Erfahrungen gemacht hat?

 Dann gibt's da noch ein relationsbasierten Vorschlag zum Mapping von
 Wegweisern, den ich aber für zu kompliziert halte. ;-)

Relationen sind wichtig, um Zusammenhänge verstreuter oder aneinander gefügte 
unterschiedliche ways und nodes thematisch zu verbinden. Dafür sind sie super. 
Der destination-tag ist jedoch einfach zu realisieren und tut imho keinem weh 
und kann viel einfacher ausgewertet werden, als eine (für diesen Zweck) 
umständliche Relation.
Also warum nicht ins wiki eintragen?

Grüße steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 31.05.2010 um 15:03 schrieb steffterra:

 einige Autobahnkreuze sind schon so getaggt.
 
 das stimmt. Doch wäre es doch gut, wenn das auch Einzug in die Wiki-Seiten 
 hielte, oder? An wen wende ich mich da am besten? Liest hier jemand mit, der 
 da Erfahrungen gemacht hat?


Ist hiermit für motorway, motorway_link und trunk geschehen. Der 
destination-Tag ansich wird diese Tage im Wiki ausführlich erklärend ergänzt.

Grüße, steffterra

http://developer.roadee.net
http://map.roadee.net/routino/router.html

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

Re: [Talk-de] motorway und motorway_link um desti nation-tag ergänzen

[steffterra]

Am 31.05.2010 um 20:15 schrieb steffterra:

 
 Am 31.05.2010 um 15:03 schrieb steffterra:
 
 einige Autobahnkreuze sind schon so getaggt.
 
 das stimmt. Doch wäre es doch gut, wenn das auch Einzug in die Wiki-Seiten 
 hielte, oder? An wen wende ich mich da am besten? Liest hier jemand mit, der 
 da Erfahrungen gemacht hat?
 
 
 Ist hiermit für motorway, motorway_link und trunk geschehen. Der 
 destination-Tag ansich wird diese Tage im Wiki ausführlich erklärend ergänzt.

Meine Einträge im deutschen und englischen OSM-Wiki wurden wieder gelöscht 
(Norwegischer User Gnonthgol) mit der Begründung no tag.

Wie gehe ich vor, dass das nicht nochmal passiert? Muss der tag destination 
erst irgendwie allgemein akzeptiert werden? Laut wiki ist nicht immer eine 
Abstimmung notwendig um einen tag zu benutzen, aber um ihn ins Wiki zu bringen 
bedeutet es wohl etwas mehr Aufwand.

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