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

2014-06-02 Diskussionsfäden fly
Am 25.05.2014 21:08, schrieb Sven Geggus:
 fly lowfligh...@googlemail.com wrote:
 
 Super, ich begegne immer wieder Situationen, wo das Semikolon die
 naheliegenste und einfachste Lösung ist und wundere mich immer warum
 sich dagegen so gesträubt wird.
 
 Lies mal den Blogpost von Jochen. Das Problem ist, dass es eben nicht
 immer so eindeutig ist was damit gemeint ist.
 
 http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html

Die habe ich jetzt wiederholt gelesen und lese dort nur ein Problem mit
der Definition.

Josm wurde verbessert (ein Erfolg der letzten Diskussion), der Import
war nicht nur in dieser Hinsicht grauenhaft und hätte nie so statt
finden dürfen und die cadastre-Source geht auch mit Komma.

Meine Punkte in der Hinsicht lauten dann eher:
* Einigung auf ein Trennzeichen und Vermeidung dieses Zeichen bei
anderen Bedeutungen (zB source)
* Klare Definition bei Verwendung von Listen bzw. Verwendung eines
eigenen Zeichen ala turn:lanes
* Ausschluss bei Tags

Diese Definitionen können alle diskutiert und dann im Wiki festgehalten
werden. Einfach über das Problem hinweggehen und so tun als ob es nicht
existiere verhindert Software-Unterstützung und wir werden dieses Thema
in geraumen Abständen immer wieder diskutieren.

Ciao fly

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


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

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

+1

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


Alex

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


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

2014-05-25 Diskussionsfäden rainerU

Guten Morgen,

Ich sehe das auch so, dass ein Tagging-Schema möglichst einfach und auch 
vom Durchschnittsmapper handhabbar sein soll.


Mein Vorschlag würde es erst mal ermöglichen, den im UP aufgeworfenen 
Fall mit einer einzigen Relation und ohne Semikolon-Attribute zu 
erfassen. Das ist eine große Vereinfachung gegenüber dem hier auch schon 
gebrachten Vorschlag, mehrerer Relationen anzulegen. Die Praxis zeigt, 
dass viele Mapper mit Wegen, die zu mehreren Relationen gehören 
überfordert sind. Und wenn der Verlauf für die verschiedenen 
Nutzungsarten nicht deckungsgleich ist, kommt man um eine komplexe 
Lösung nicht herum, zumindest kann ich hier bislang keinen einfachen 
Ansatz erkennen. Oder man lebt mit der bei den Voies Vertes/Vias Verdes 
derzeit praktizierten Lösung: bicycle-Route und access-Tags für die 
anderen Nutzungsarten an den Wegen.


Grüße
Rainer

Am 25.05.2014 01:25, schrieb Henning Scholland:


Hallo,

in der IT-Theorie magst du recht haben, dass dies eine saubere
Variante ist, die Redundanz verhindert. OSM ist aber deutlich mehr als
IT-Theorie. Menschen müssen die Routen warten können. Menschen müssen
entscheiden können, was zu tun ist, wenn sie den Weg bearbeiten
wollen. All das wird komplexer. Der typische Mapper hat keine Lust
sich ewig einzulesen, bis er seine Info richtig in OSM platzieren
kann. Entweder er versteht es gleich oder er lässt es. Relationen sind
da ohnehin schon etwas abstrakt. Komplexe Relationskonstrukte blicken
teilweise erfahrene Mapper nicht. Das Problem siehst du beim
ÖPNV-Schema. Es hat einen Grund, warum sich nur sehr wenige damit
befassen.

Die Auswertung wird auch komplexer. Einen Vorteil neben der Redundanz
sehe ich nicht und da würde ich die einfachere Datenstruktur in jedem
Fall bevorzugen. Denn das braucht es, um es vielen zu ermöglichen
daran mitzuwirken und das macht OSM letztlich aus.

Henning

Am 24.05.2014 12:30, schrieb rainerU:

Wenn man die Situation über mehrere Relationen lösen will, und
wahrscheinlich ist das der einzige Weg mit den heute verfügbaren
Mitteln, dann sollte man Redundanz vermeiden und Abschnitte mit
einheitlicher Nutzung auch nur einmal erfassen. Das könnte dann
z.B. so aussehen:

Pro einheitlich genutztem Abschnitt eine Relation mit

route=multi_usage nutzungsart=[yes|no] mit
nutzungsart=bicycle|hiking|inline_skates...

und eine Super-Relation ebenfalls vom Typ multi_usage

Grüße Rainer





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


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

2014-05-25 Diskussionsfäden Martin Koppenhoefer


 Am 25/mag/2014 um 08:06 schrieb rainerU ra...@sfr.fr:
 
 Oder man lebt mit der bei den Voies Vertes/Vias Verdes derzeit praktizierten 
 Lösung: bicycle-Route und access-Tags für die anderen Nutzungsarten an den 
 Wegen.


Das ist keine Lösung für das beschriebene Problem sondern sind schlicht noch 
unvollständige Daten, d.h. es fehlen da noch die Wanderrouten.

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


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

2014-05-25 Diskussionsfäden rainerU

Am 25.05.2014 12:38, schrieb Martin Koppenhoefer:




Am 25/mag/2014 um 08:06 schrieb rainerU ra...@sfr.fr:

Oder man lebt mit der bei den Voies Vertes/Vias Verdes derzeit praktizierten 
Lösung: bicycle-Route und access-Tags für die anderen Nutzungsarten an den 
Wegen.



Das ist keine Lösung für das beschriebene Problem sondern sind schlicht noch 
unvollständige Daten, d.h. es fehlen da noch die Wanderrouten.


...und die Skaterrouten und die Reiterrouten. Das kann doch nicht die 
Lösung für eine kombinierte Wander-, Radwander-, Skating- und 
Reiter-Route sein. Mehr Redundanz geht kaum.




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


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

2014-05-25 Diskussionsfäden Sven Geggus
fly lowfligh...@googlemail.com wrote:

 Super, ich begegne immer wieder Situationen, wo das Semikolon die
 naheliegenste und einfachste Lösung ist und wundere mich immer warum
 sich dagegen so gesträubt wird.

Lies mal den Blogpost von Jochen. Das Problem ist, dass es eben nicht
immer so eindeutig ist was damit gemeint ist.

http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html

Sven

-- 
All bugs added by David S. Miller da...@redhat.com
Linux Kernel boot message from /usr/src/linux/net/8021q/vlan.c

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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


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

2014-05-24 Diskussionsfäden Thorsten Nau
Der Semikolon-Ansatz könnte darüber hinaus noch einen weiteren Nachteil 
haben: Die Reihenfolge der Einträge... Rein theoretisch kann das Feld 
mindestens sieben Stellen bzw. Ausprägungen haben:


- Wanderroute
- Fahrradroute
- Inline-Skating-Route
- Nordic-Walking-Route
- Langlauf-Route
- MTB-Route
- Reitroute
- 

Weitere Ausprägungen sind natürlich möglich. Entweder legt man für jede 
einzelne Position fest, an welcher Position sich welche 
Fortbewegungsart befindet (ähnlich dem Key osmc:symbol), oder man 
wählt einen ganz anderen Ansatz (wenn man nicht für jede einzelne 
Fortbewegungsart eine eigene Relation möchte):


Denkbar hierfür wäre bspw. folgendes Tagging-Schema (analog bspw. dem 
ÖPNV-Schema):


type = route
route = hiking, foot oder dergleichen (je nach Hauptnutzungsart, oder 
auch eine neue Ausprägung, die besagt, dass es sich hier um eine 
ausgeschilderte Wegroute handelt)

network = *
ref = *
name = *
symbol = *
... und die anderen notwendigen Tags.

Hinzu könnten dann noch folgende Tags kommen, die aussagen, für welche 
Fortbewegungsart der ausgewiesene Weg noch genutzt werden kann - bspw.:


hiking=yes
biking=yes
skating=yes
nordic=yes
mtb=no
riding=no


Hierdurch könnte dann z.B. explizit unterschieden werden, ob eine Route 
für Reiter oder MTB möglich bzw. zugelassen ist (wenn die Route über 
Wege führt, die explizit für Reiter / MTB / etc. durch entsprechende 
Zeichen gesperrt sind). Weiterer Vorteil wäre, dass hier noch eine 
zusätzliche Möglichkeit geschaffen werden könnte, um z.B. zu 
kennzeichnen, ob eine ausgeschilderte Route für Rollstuhlfahrer, 
Kinderwagen, etc. befahrbar ist. Bei entsprechendem Interesse, müsste 
das natürlich noch entsprechend ausgearbeitet werden.



VG,
Thorsten



Am 23.05.2014 23:50, schrieb NopMap:

Thorsten Nau wrote

ich würde je Fortbewegungsart eine separate route-Relation erstellen.

+1

Eine dedizierte Relation pro Route ist IMHO die einzig vernünftige Lösung,
auch wenn die Routen für verschiedene Modi zufällig auf dem gleichen
physikalischen Weg liegen.

Wie schon weiter oben geschrieben muß bei der kleinsten Abweichung in der
Wegführung sowieso eine eigene Relation geschaffen werden. Ich halte es für
so extrem selten daß mehrere Routen in allen Details exakt die gleiche
Wegstrecke haben, so daß der Gewinn für einer Sonderregelung für solche
Fälle praktisch gleich Null ist. Der Schaden durch Verwirrung und Relationen
die von den meisten Auswertern nicht ausgewertet werden können ist dagegen
groß.

Der Semikolon-Ansatz löst das Problem nicht mal ansatzweise. An einer
Route-Relation hängen meist noch zahlreiche weitere Werte.
- Es gibt keine Möglichkeit auszudrücken wenn ein Tag nur für eine, aber
nicht alle der Semikolon-Werte gültig sein soll.
- Auch für manche Zusatztags wie network, ref, state, description gibt es
Werte die für jeden Semikolon-Wert anders sein können. Es gibt keine
Möglichkeit das eindeutig auszudrücken, noch mehr Semikolons sind keine
Lösung weil dann immer noch offen ist, welcher Wert zur welchem anderen Wert
gehört. Eine Reihenfolge ist nicht definiert. Dazu kann sich noch die Anzahl
der Werte unterscheiden, z.B. es gibt eine network Einteilung nur für
Wandern und Radeln, aber nicht für's Skaten.

bye, Nop



--
View this message in context: 
http://gis.19327.n5.nabble.com/Rad-Wander-Skate-Routen-tp5807026p5807123.html
Sent from the Germany mailing list archive at Nabble.com.

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



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


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

2014-05-24 Diskussionsfäden Sarah Hoffmann
On Fri, May 23, 2014 at 02:50:47PM -0700, NopMap wrote:
 Thorsten Nau wrote
  ich würde je Fortbewegungsart eine separate route-Relation erstellen. 
 
 +1
 
 Eine dedizierte Relation pro Route ist IMHO die einzig vernünftige Lösung,
 auch wenn die Routen für verschiedene Modi zufällig auf dem gleichen
 physikalischen Weg liegen.

Es geht hier nicht um überlappende Routen, die gehören selbstverständlich
in verschiedene Relationen. Es geht um eine Route, die von Anfang an
für verschieden Modi konzipiert und auch ausgewiesen ist. In Europa
findet man sowas relativ selten, aber in Amerika sind solche
Multi-Use-Routen weiter verbreitet, besonders wohl auf ehemaligen
Bahnstrecken. Die Relation zu duplizieren bildet sowas meiner
Meinung nach ungenügend ab.

Sarah

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


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

2014-05-24 Diskussionsfäden rainerU

Am 23.05.2014 08:15, schrieb Henning Scholland:
 Die Semikolon-Variante finde ich auch nur bedingt gut. Es bleibt ja
 letztlich nicht bei dem einen Semikolon. Bei network tritt das gleiche
 auf. Zumal man den Ansatz komplett vergessen kann, wenn sich die Wege
 unterscheiden. Mal muss der Radfahrer auf die Straße, mal darf der
 Reiter nicht über die Brücke.

Bei den Vias Verdes in Spanien und den Voies Vertes in Frankreich ist 
das der Normalfall. Beide sind grundsätzlich für Fußgänger, Radfahrer, 
Skater und Reiter bestimmt, aber nicht alle Abschnitte sind für jede 
Nutzergruppe freigegeben bzw. verlaufen unterschiedlich für die 
Nutzergruppen. Die meisten dieser Routen sind derzeit als bicycle 
getaggt und die zugrundeliegenden Wege mit access-Tags versehen.


Wenn man die Situation über mehrere Relationen lösen will, und 
wahrscheinlich ist das der einzige Weg mit den heute verfügbaren 
Mitteln, dann sollte man Redundanz vermeiden und Abschnitte mit 
einheitlicher Nutzung auch nur einmal erfassen. Das könnte dann z.B. so 
aussehen:


Pro einheitlich genutztem Abschnitt eine Relation mit

route=multi_usage
nutzungsart=[yes|no] mit nutzungsart=bicycle|hiking|inline_skates...

und eine Super-Relation ebenfalls vom Typ multi_usage

Grüße
Rainer


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


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

2014-05-24 Diskussionsfäden Volker Schmidt
Auch hier in Italien haben wir sehr haeufig percorsi ciclopedonali die
komplett identisch sind fuer beide Verkehrsmittel. Meistens sind auch
Radwege ciclopedonali. Reine Radwege sind sehr selten. Hinzu kommen in
den Bergen sehr viele Wander+MTB Routen.
Was mich auf ein anderes Thema bringt: Radrouten sollten noch mit Radtypen
gekennzeichnet werden: Rennrad - Touringrad - MTB und da taucht dann
daselbe Problem der kombinierten Nutzbarkeit auf.
Rennradstrecken sind meistens auch mit dem Touringrad befahrbar,
MTB-Strecken selten. Ich habe als Nutzer beim Planen von Touring-Radrouten
haeufiger Probleme mit reinen MTB -Routen gehabt, die nicht als solche zu
erkennen sind.

Volker


2014-05-24 12:30 GMT+02:00 rainerU ra...@sfr.fr:

 Am 23.05.2014 08:15, schrieb Henning Scholland:

  Die Semikolon-Variante finde ich auch nur bedingt gut. Es bleibt ja
  letztlich nicht bei dem einen Semikolon. Bei network tritt das gleiche
  auf. Zumal man den Ansatz komplett vergessen kann, wenn sich die Wege
  unterscheiden. Mal muss der Radfahrer auf die Straße, mal darf der
  Reiter nicht über die Brücke.

 Bei den Vias Verdes in Spanien und den Voies Vertes in Frankreich ist das
 der Normalfall. Beide sind grundsätzlich für Fußgänger, Radfahrer, Skater
 und Reiter bestimmt, aber nicht alle Abschnitte sind für jede Nutzergruppe
 freigegeben bzw. verlaufen unterschiedlich für die Nutzergruppen. Die
 meisten dieser Routen sind derzeit als bicycle getaggt und die
 zugrundeliegenden Wege mit access-Tags versehen.

 Wenn man die Situation über mehrere Relationen lösen will, und
 wahrscheinlich ist das der einzige Weg mit den heute verfügbaren Mitteln,
 dann sollte man Redundanz vermeiden und Abschnitte mit einheitlicher
 Nutzung auch nur einmal erfassen. Das könnte dann z.B. so aussehen:

 Pro einheitlich genutztem Abschnitt eine Relation mit

 route=multi_usage
 nutzungsart=[yes|no] mit nutzungsart=bicycle|hiking|inline_skates...

 und eine Super-Relation ebenfalls vom Typ multi_usage

 Grüße
 Rainer



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




-- 
Volker SCHMIDT
Via del Cristo 28
35127 Padova
Italy

mailto:vosc...@gmail.com
phone +39 049 851 519
personal mobile+39 340 1427 105
skype: volker.schmidt
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


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

2014-05-24 Diskussionsfäden Henning Scholland
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo,

in der IT-Theorie magst du recht haben, dass dies eine saubere
Variante ist, die Redundanz verhindert. OSM ist aber deutlich mehr als
IT-Theorie. Menschen müssen die Routen warten können. Menschen müssen
entscheiden können, was zu tun ist, wenn sie den Weg bearbeiten
wollen. All das wird komplexer. Der typische Mapper hat keine Lust
sich ewig einzulesen, bis er seine Info richtig in OSM platzieren
kann. Entweder er versteht es gleich oder er lässt es. Relationen sind
da ohnehin schon etwas abstrakt. Komplexe Relationskonstrukte blicken
teilweise erfahrene Mapper nicht. Das Problem siehst du beim
ÖPNV-Schema. Es hat einen Grund, warum sich nur sehr wenige damit
befassen.

Die Auswertung wird auch komplexer. Einen Vorteil neben der Redundanz
sehe ich nicht und da würde ich die einfachere Datenstruktur in jedem
Fall bevorzugen. Denn das braucht es, um es vielen zu ermöglichen
daran mitzuwirken und das macht OSM letztlich aus.

Henning

Am 24.05.2014 12:30, schrieb rainerU:
 Wenn man die Situation über mehrere Relationen lösen will, und 
 wahrscheinlich ist das der einzige Weg mit den heute verfügbaren 
 Mitteln, dann sollte man Redundanz vermeiden und Abschnitte mit 
 einheitlicher Nutzung auch nur einmal erfassen. Das könnte dann
 z.B. so aussehen:
 
 Pro einheitlich genutztem Abschnitt eine Relation mit
 
 route=multi_usage nutzungsart=[yes|no] mit
 nutzungsart=bicycle|hiking|inline_skates...
 
 und eine Super-Relation ebenfalls vom Typ multi_usage
 
 Grüße Rainer
 
 
 ___ Talk-de mailing
 list Talk-de@openstreetmap.org 
 https://lists.openstreetmap.org/listinfo/talk-de
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTgSqHAAoJEKXggIeC16WPlaAIALaUA+ojZYyfgw2UEyz3yrpT
G0WuH8NpYhRBnRX/wK5LzU6f8HRmLomHY+c5Sg3+gXfaNmLx7CuMb5JkJTf5HubJ
tcjli+hEzJinePNkVW9tWsF+RhUV2J0vSTOBu0Lau7ihEEZQ0VxamHA75TQWX8LW
LjDQcne99zBp4elrjURp9o2mzbI4aja16mLLcdDLW7+DcH/R0MP3QJV0j7gL52rx
NYTFMNrijRM26V4TIGp2YgH9YfLpxEpxr8H8L4wQNBbDP8vqHlfFvbben5iuYCmH
uueFqxslYNhCCX2eWsMOFn12RDTQgCjomeR6ulkuafBrbQBTIl9JmFFsYbV78D0=
=rGcs
-END PGP SIGNATURE-


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


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

2014-05-23 Diskussionsfäden Henning Scholland
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 22.05.2014 15:53, schrieb Volker Schmidt:
 Kopieren ist immer der falsche Ansatz. Daten sollten, wenn immer
 möglich nur einmal vorhanden sein.

Das ist im allgemeinen auch richtig. Jedoch wird hier ja nur kopiert
um sich Arbeit beim erfassen zu sparen. Natürlich kann man
Superrelationen auch verwenden. Mit jeder Separation der Wege steigt
dann aber auch die Anzahl der benötigten Relationen an und wird recht
unübersichtlich.

Die Semikolon-Variante finde ich auch nur bedingt gut. Es bleibt ja
letztlich nicht bei dem einen Semikolon. Bei network tritt das gleiche
auf. Zumal man den Ansatz komplett vergessen kann, wenn sich die Wege
unterscheiden. Mal muss der Radfahrer auf die Straße, mal darf der
Reiter nicht über die Brücke.

Henning
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTfueTAAoJEKXggIeC16WPDUMH/1VnWD9F+R3BOkyLD6fS3+VP
OLYrKO+W22qgCPmcU9I9UWneEwoM5z87iLmtVcp7Lkqvj9R3U+7iiiWzfE4jthyD
WafS/60b8FEkouk/MREaocS5QQQ+z5HJ99BbuktAXVx5wed1CLLinRDnIyCm95kO
dzrxu9IKQ/alzpLInu9ReTInv1LJw4krAc0G/8TFKrEpVs5HMPOTwwP/fFGNe9MD
BjK4oVXY1CES07rHvrsXu8THhBYH71u/mcg+a4kfnoH4PGlKKWXpiL8Bu6b8DMDd
x4RkX/8JL8gFMZ+CPijP/SypDmU9bYVzS9FYCtKiOThxJbLdrT9ASquwRJqLtEs=
=2I7T
-END PGP SIGNATURE-


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


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

2014-05-23 Diskussionsfäden C.Brause
Hallo und Danke für die vielen Antworten,

Ideen und Einwände hatte ich für mich auch schon gefunden, mit Ausnahme
der Möglichkeit, dass sich der Weg u.U. auf Teilstücken im Detail
unterscheiden. Dass die Auswertung des Semikolons sich schwierig
gestaltet, hört man ja immer wieder. Es scheint aber, wenn auch
vielleicht mit Aufwand, machbar zu sein. Und wie Fly schon sagt, ist das
eine naheliegende Variante, die dem Mapper die Arbeit letztlich in
vielen Bereichen erleichtert.

Mein Kompromiss sieht jetzt erstmal so aus, dass ich das Teilstück, dass
ich kenne erstmal mit Semikolon getrennt gemappt habe (Bei Waymarks
funktioniert das auch, danke Sarah) und mir Gedanken über Kopien der
Route oder eine Superrelation erst Gedanken mache, wenn der Fall
getrennter Streckenführung dann tatsächlich auftaucht.

Falls sich noch Argumente finden, das anders zu lösen, bin ich natürlich
offen.

Viele Grüße,
Christian



Am 23.05.2014 01:52, schrieb fly:
 Am 22.05.2014 15:02, schrieb Sarah Hoffmann:
 Hi,

 On Thu, May 22, 2014 at 01:51:45PM +0200, C.Brause wrote:
 Mein Ansatz wäre jetzt, die Route als Relation mit
 route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten
 Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche
 Wege auch aufgenommen werden könnten/sollten.

 Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca.
 110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die
 Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für
 Skater und Wanderer handelt, in description=* befindet. Zum Auswerten
 ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde,
 damit es wenigstens irgendwo auch zu sehen ist.

 Im Wiki findet sich nichts zu Routen, die für mehr als ein
 Fortbewegungsmittel ausgeschildert sind.

 Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer?
 waymarkedtrails.org unterstützt den Semikolonansatz seit ein paar Wochen, 
 weil ich gefunden habe, dass das a) die Wirklichkeit am genausten abbildet
 und b) für die Mapper so am einfachsten zu warten ist.
 Super, ich begegne immer wieder Situationen, wo das Semikolon die
 naheliegenste und einfachste Lösung ist und wundere mich immer warum
 sich dagegen so gesträubt wird.

 Alles mit yes/no abzubilden ala recycling ist auch keine Lösung und
 konkret ist das wohl eine Route und sollte als ein Objekt auch so
 gehandelt werden.

 cu fly




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


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


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

2014-05-23 Diskussionsfäden Martin Koppenhoefer
Am 23. Mai 2014 11:47 schrieb C.Brause chr_bra...@gmx.de:

 Dass die Auswertung des Semikolons sich schwierig
 gestaltet, hört man ja immer wieder. Es scheint aber, wenn auch
 vielleicht mit Aufwand, machbar zu sein.



Jochens Überlegungen hier:
http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html hast Du
gelesen? Es gibt sicherlich (viele) Fälle, wo eine Auswertung möglich ist,
aber pauschal kann man das nicht sagen. Auch nicht beachtet wird dabei,
dass es evtl. auch (einzige) Werte mit einem Semikolon geben kann, und wie
man das dann ggf. escapen würde falls man Semikolons für sets verwenden
wollte.

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


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

2014-05-23 Diskussionsfäden C.Brause
Hallo Martin,

vielen Dank für den Link, den kannte ich noch nicht. Eigentlich wollte
ich das später lesen, habs jetzt aber doch getan und hier meine Gedanken
dazu:

Die von Jochen aufgeführten Problem sind leider nicht von der Hand zu
weisen. Trotzdem bin ich noch nicht dabei, das Semikolon abzuschaffen.
Vielmehr gilt es in meinen Augen einen Konsens zu finden. Ich weiß, dass
die Diskussion schon alt ist und sich da immernoch keine Lösung
herauskristallisiert hat. Aber hier wir ja vieles erst mehrfach
totdiskutiert, bevor dann ein gemeinsamer Weg gefunden wird.

Um die Themen im Link aufzugreifen:

- Ein (ungeordnetes) Set von Werten, bzw. eine Aufzählung:
Das ist spontan in meinen Augen die sinnvollste Interpretation. Würd
es nur so benutzt gäbe es keine Probleme oder?

- Eine sortierte Liste, bzw. Reihenfolge ist wichtig
Die Nutzung in so einem Kontext kann ich verstehen, macht aber kaum
Sinn. Eine logische Änderung wäre, statt
[seamark:buoy_lateral:colour=red;white;red;white]
besser
[seamark:buoy_lateral:colour:1=red;white;red;white]
[seamark:buoy_lateral:colour:2=white]
[seamark:buoy_lateral:colour:3=red]
[seamark:buoy_lateral:colour:4=white]
oder so zu verwenden. Selbst wenn DAS nicht Ideal sein sollte, die
Richtung wäre ok, denk ich. (Das ist kein neuer Tagging-Vorschlag!)

- Das Editorproblem
Das ist doch sebsterklärend. Das Problem entsteht nicht beim Tagging
oder Mappen, sondern beim Editor. Werden 2 Objekte zusammengefasst,
sollte ein Konfikt angezeigt werden, ohne den Vorschlag, das mit
Semikolon zu verbinden. Weiß man nicht, welcher Wert der richtige ist,
fasst man die Objekte nicht zusammen oder entscheidet sich und hängt ein
erklärendes FIXME dran.

- Importproblem
Ein Import ist doch an sich IMMER mit einem gewissen Mehraufwand
verbunden. Ist es dann noch viel Arbeit das Skript zu erweitern und auf
Konflikte ähnlich wie beim Editorproblem mit FIXME zu reagieren?


Das einzige wirkliche Gegenargument das ich dabei bisher sehe ist der
auch von dir angeführte Fakt, dass das Semikolon durchaus auch Teil
eines Wertes (z.B. Name) sein kann. Das kommt zwar selten vor, aber auch
das muss abgedeckt werden.
Wäre es eine Möglichkeit das Semikolon in irgendeiner Form zu escapen?
Ich habe zwar recht viel mit Rechnern zu tun und programmiere auch, aber
ich bin kein Profi. Ich kann mir vorstellen, dass das mehr Probleme
bringen könnte, als es es löst.
Alternativ könnte man auch ein Aufzählungszeichen überlegen, das auf
einer Zeichenkombination beruht. Z.B.:  ; oder |+| (senkrechte Stiche
mit Pluszeichen)
Die Kombination müsste sich natürlich von Typischen Escapefrequenzen
oder Konstanten von Programmiersprachen unterscheiden. Da verlasse ich
aber dann langsam ganz mein Terrain.

Viele Grüße,
Christian


Am 23.05.2014 11:58, schrieb Martin Koppenhoefer:
 Am 23. Mai 2014 11:47 schrieb C.Brause chr_bra...@gmx.de:

 Dass die Auswertung des Semikolons sich schwierig
 gestaltet, hört man ja immer wieder. Es scheint aber, wenn auch
 vielleicht mit Aufwand, machbar zu sein.


 Jochens Überlegungen hier:
 http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html hast Du
 gelesen? Es gibt sicherlich (viele) Fälle, wo eine Auswertung möglich ist,
 aber pauschal kann man das nicht sagen. Auch nicht beachtet wird dabei,
 dass es evtl. auch (einzige) Werte mit einem Semikolon geben kann, und wie
 man das dann ggf. escapen würde falls man Semikolons für sets verwenden
 wollte.

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


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


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

2014-05-23 Diskussionsfäden NopMap
Thorsten Nau wrote
 ich würde je Fortbewegungsart eine separate route-Relation erstellen. 

+1

Eine dedizierte Relation pro Route ist IMHO die einzig vernünftige Lösung,
auch wenn die Routen für verschiedene Modi zufällig auf dem gleichen
physikalischen Weg liegen.

Wie schon weiter oben geschrieben muß bei der kleinsten Abweichung in der
Wegführung sowieso eine eigene Relation geschaffen werden. Ich halte es für
so extrem selten daß mehrere Routen in allen Details exakt die gleiche
Wegstrecke haben, so daß der Gewinn für einer Sonderregelung für solche
Fälle praktisch gleich Null ist. Der Schaden durch Verwirrung und Relationen
die von den meisten Auswertern nicht ausgewertet werden können ist dagegen
groß.

Der Semikolon-Ansatz löst das Problem nicht mal ansatzweise. An einer
Route-Relation hängen meist noch zahlreiche weitere Werte.
- Es gibt keine Möglichkeit auszudrücken wenn ein Tag nur für eine, aber
nicht alle der Semikolon-Werte gültig sein soll.
- Auch für manche Zusatztags wie network, ref, state, description gibt es
Werte die für jeden Semikolon-Wert anders sein können. Es gibt keine
Möglichkeit das eindeutig auszudrücken, noch mehr Semikolons sind keine
Lösung weil dann immer noch offen ist, welcher Wert zur welchem anderen Wert
gehört. Eine Reihenfolge ist nicht definiert. Dazu kann sich noch die Anzahl
der Werte unterscheiden, z.B. es gibt eine network Einteilung nur für
Wandern und Radeln, aber nicht für's Skaten.

bye, Nop



--
View this message in context: 
http://gis.19327.n5.nabble.com/Rad-Wander-Skate-Routen-tp5807026p5807123.html
Sent from the Germany mailing list archive at Nabble.com.

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


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

2014-05-22 Diskussionsfäden C.Brause
Hallo zusammen,

ich wollte mal eine ausgeschilderte Mehrzweckroute in der Nähe mappen.
Mein Problem ist, dass sie sowohl für Radfahrer, als auch Wanderer und
Skater ausgewiesen ist.

Mein Ansatz wäre jetzt, die Route als Relation mit
route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten
Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche
Wege auch aufgenommen werden könnten/sollten.

Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca.
110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die
Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für
Skater und Wanderer handelt, in description=* befindet. Zum Auswerten
ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde,
damit es wenigstens irgendwo auch zu sehen ist.

Im Wiki findet sich nichts zu Routen, die für mehr als ein
Fortbewegungsmittel ausgeschildert sind.

Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer?

Viele Grüße,
Christian

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


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

2014-05-22 Diskussionsfäden Jochen Topf
On Do, Mai 22, 2014 at 01:51:45 +0200, C.Brause wrote:
 ich wollte mal eine ausgeschilderte Mehrzweckroute in der Nähe mappen.
 Mein Problem ist, dass sie sowohl für Radfahrer, als auch Wanderer und
 Skater ausgewiesen ist.
 
 Mein Ansatz wäre jetzt, die Route als Relation mit
 route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten
 Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche
 Wege auch aufgenommen werden könnten/sollten.
 
 Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca.
 110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die
 Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für
 Skater und Wanderer handelt, in description=* befindet. Zum Auswerten
 ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde,
 damit es wenigstens irgendwo auch zu sehen ist.
 
 Im Wiki findet sich nichts zu Routen, die für mehr als ein
 Fortbewegungsmittel ausgeschildert sind.
 
 Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer?

Semicolons in tags sind sehr problematisch:
http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

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


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

2014-05-22 Diskussionsfäden Thorsten Nau

Hallo Christian,

ich würde je Fortbewegungsart eine separate route-Relation erstellen. 
Wenn erst mal eine Relation existiert, kann diese dann relativ einfach 
kopiert und um das route-Tag entsprechend korrigiert werden. Klar - wenn 
sich mal was an dem Wegverlauf etwas ändern sollte, müßte das dann in 
drei Relationen gemacht werden - aber ich denke, der Aufwand ist 
überschaubar - im Gegensatz zu dem Aufwand, der in den einzelnen 
Anwendungen anfallen würde, wenn etliche neue route-Ausprägungen 
berücksichtigt werden müssten.


Viele Grüße,
Thorsten



Am 22.05.2014 13:51, schrieb C.Brause:

Hallo zusammen,

ich wollte mal eine ausgeschilderte Mehrzweckroute in der Nähe mappen.
Mein Problem ist, dass sie sowohl für Radfahrer, als auch Wanderer und
Skater ausgewiesen ist.

Mein Ansatz wäre jetzt, die Route als Relation mit
route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten
Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche
Wege auch aufgenommen werden könnten/sollten.

Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca.
110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die
Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für
Skater und Wanderer handelt, in description=* befindet. Zum Auswerten
ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde,
damit es wenigstens irgendwo auch zu sehen ist.

Im Wiki findet sich nichts zu Routen, die für mehr als ein
Fortbewegungsmittel ausgeschildert sind.

Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer?

Viele Grüße,
Christian

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



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


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

2014-05-22 Diskussionsfäden Sarah Hoffmann
Hi,

On Thu, May 22, 2014 at 01:51:45PM +0200, C.Brause wrote:
 Mein Ansatz wäre jetzt, die Route als Relation mit
 route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten
 Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche
 Wege auch aufgenommen werden könnten/sollten.
 
 Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca.
 110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die
 Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für
 Skater und Wanderer handelt, in description=* befindet. Zum Auswerten
 ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde,
 damit es wenigstens irgendwo auch zu sehen ist.
 
 Im Wiki findet sich nichts zu Routen, die für mehr als ein
 Fortbewegungsmittel ausgeschildert sind.
 
 Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer?

waymarkedtrails.org unterstützt den Semikolonansatz seit ein paar Wochen, 
weil ich gefunden habe, dass das a) die Wirklichkeit am genausten abbildet
und b) für die Mapper so am einfachsten zu warten ist.

Gruss

Sarah

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


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

2014-05-22 Diskussionsfäden Martin Koppenhoefer


 Am 22/mag/2014 um 14:47 schrieb Thorsten Nau dod...@online.de:
 
 ich würde je Fortbewegungsart eine separate route-Relation erstellen.


+1

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


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

2014-05-22 Diskussionsfäden Volker Schmidt
 ich würde je Fortbewegungsart eine separate route-Relation erstellen.
 Wenn erst mal eine Relation existiert, kann diese dann relativ einfach
 kopiert und um das route-Tag entsprechend korrigiert werden.


Kopieren ist immer der falsche Ansatz. Daten sollten, wenn immer möglich
nur einmal vorhanden sein. (Ich weiß, wir haben tonnenweise importierte
Daten, die irgendwo in einer externen database gepflegt werden, und die wir
unabhängig nochmal in OSM pflegen müssen. Gilt praktisch für alle
importierten Daten) .

Loesungsansatz: Super-Relationen  und/oder neue route values
*Neue route values: *route=cycle_foot | cycle_skates | cycle_foot_skates
usw.
*Asserdem Superrelationen*, die auch einem anderen Problem helfen koennen,
z. B. wenn  dieselbe Strecke fuer ein gutes Stueck zwei verschiedenen
routes angehört (Doppelnummerierung)

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


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

2014-05-22 Diskussionsfäden Bernhard Weiskopf
 Von: Thorsten Nau 
 ich würde je Fortbewegungsart eine separate route-Relation erstellen.

Ich auch. Irgendwo ist vielleicht der Fußweg getrennt von der Straße und
schon funktioniert die gemeinsame Relation nicht mehr, da der Radweg auf der
Straße und der Wanderweg auf dem Gehweg verläuft.

Bernhard



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


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

2014-05-22 Diskussionsfäden fly
Am 22.05.2014 15:02, schrieb Sarah Hoffmann:
 Hi,
 
 On Thu, May 22, 2014 at 01:51:45PM +0200, C.Brause wrote:
 Mein Ansatz wäre jetzt, die Route als Relation mit
 route=bicycle;hiking;inline_skates zu bezeichnen und den mir bekannten
 Renderern (opencyclemap und waymarks) den Hinweis geben, dass solche
 Wege auch aufgenommen werden könnten/sollten.

 Ein Blick auf Taginfo zeigt mir, dass solche Kombinationen insgesamt ca.
 110 mal vorkommen. Gefunden habe ich aber auch Radrouten, bei denen die
 Zusatzinfo, dass es sich auch um eine Ausgewiesene Rundstrecke für
 Skater und Wanderer handelt, in description=* befindet. Zum Auswerten
 ist das natürlich kaum geeignet. Ich vermute, dass das so gelöst wurde,
 damit es wenigstens irgendwo auch zu sehen ist.

 Im Wiki findet sich nichts zu Routen, die für mehr als ein
 Fortbewegungsmittel ausgeschildert sind.

 Was haltet ihr von dem Semicolonansatz und dem Anschreiben der Renderer?
 
 waymarkedtrails.org unterstützt den Semikolonansatz seit ein paar Wochen, 
 weil ich gefunden habe, dass das a) die Wirklichkeit am genausten abbildet
 und b) für die Mapper so am einfachsten zu warten ist.

Super, ich begegne immer wieder Situationen, wo das Semikolon die
naheliegenste und einfachste Lösung ist und wundere mich immer warum
sich dagegen so gesträubt wird.

Alles mit yes/no abzubilden ala recycling ist auch keine Lösung und
konkret ist das wohl eine Route und sollte als ein Objekt auch so
gehandelt werden.

cu fly




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