Re: [Talk-de] Rekordhalter im Relationsfragmentieren

[Bernd Wurst]

Hallo.

Am Sonntag, 18. Januar 2009 schrieb Nop:
> Wo ich grade immer dabei bin, gegen sinnlos zerfitzelte Relationen zu
> wettern, möchte ich Euch den heutigen Brüller nicht vorenthalten.
>
> Ein Nebenprodukt meines Kartenrenderes ist auch ein wenig
> Relationstatistik. Der Gewinner ist eine Relation vom Typ Route mit
> einem Way und exakt 7 Metern Länge. :-)

Na und?
Einer muss anfangen eine Route zu basteln. Ich hab neulich zufällig gesehen, 
dass von seitlich eine Rad-Route auf den Weg kommt und einige hundert Meter 
später ging sie wieder rechts ab.

Seither gibt es eine Relation für diese Rad-Route, da es diese bisher noch 
nicht gab. Wenn jetzt jemand diese Relation sucht, findet er was und sieht 
dass die noch nicht vollständig ist.

Gruß, Bernd

-- 
Fettflecke werden wie neu,
wenn man sie regelmäßig mit Butter einreibt.


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relation Germany (Landmass)

[Sven Anders]

Am Sonntag, 18. Januar 2009 00:04 schrieb Norbert Kück:
> Hallo,
>
> Frederik Ramm schrieb:
> >> *** Achtung! *
> >> Relation #62781 ist die offizielle im Wiki als Staatsgrenze
> >> dokumentierte Relation Germany - NICHT Germany(Landmass).
> >
> > (Nebenbemerkung: Man sollte sich nie darauf verlassen, dass Objekt-IDs
> > konstant bleiben. Zur Vereinfachung kann man die IDs zwar ins Wiki
> > schreiben, aber es muss jedem klar sein, dass sich die ID jederzeit
> > aendern kann. Staatsgrenze der Bundesrepublik Deutschland sollte immer
> > diejenige Relation mit admin_level=2, boundary=administrative,
> > name="Germany" oder so sein, egal welche ID sie hat. Oder?)
> >
> > Kannst Du nochmal in anderen Worten sagen, was das Problem genau ist?
> > Ich habe es ehrlich nicht ganz verstanden. Was genau ist durcheinander
> > gekommen?
>
> Im Zuge des Kreisgrenzenimports wurde auch eine Relation #62781
> name=Germany erzeugt mit eben den oben von dir genannten Tags.
>
> An diese Relation habe ich die in meiner Nachricht genannten Änderungen
> (ein Weg hinzugefügt, einige entfernt) vorgenommen.
>
> Danach (nämlich am 13. Jan.) wurde die Relation # 62781 umbenannt in
> "Germany (Landmass)". Angesichts gehabter Diskussion über Grenzen an/in
> Seegebieten bzw. "richtige" Staatsgrenzen und die konkurrierende
> Darstellung der reinen Landflächen war das für mich (und offensichtlich
> auch für andere) das Signal, dass diese Relation nun der Darstellung der
> reinen Landfläche gewidmet ist. Die Relation hat aber die alten
> boundary/admin_level-Tags behalten.

Ich hab sie umbenannt (das könnt Ihr auch in der History sehen und mir eine  
Mail schicken).

http://www.openstreetmap.org/browse/relation/62781/history

Ich hab sie umbennant, da (zu diesem Zeitpunkt)  Küstenlinien enthalten waren 
und sie so groß war und mit source=..Kreisgrenzen... versehn war, das ich 
angenommen habe, das das die Landgrenzenen seien. 

Sie war so groß das ich mir nicht die Mühe gemacht hatte sie vollständig 
herunter zu laden und sie anzusehen. Das war sicherlich ein Fehler.

Ich habe sie mir aber eben gerade angesehen und festgestellt, das da 
Küstenlinien von Sylt und Neuwerk etc. drinn sind und auch sonst teile der 
außengrenze fehlen. Es sind allerdings recht wenig Küstenlinien drinn, du 
hast also recht es sollte eher die Außengrenze sein.

Ich hab mal (gemäß dem Motto: "Sei Mutig") die letzen Inseln jetzt entfernt 
und dann auch Germany in Germany (Landmass) umbenannt.

Gibt es eigentlich auch eine Relation Germany(Landmass)?

Gruß
Sven

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Bernd Wurst]

Hallo.

Am Samstag, 17. Januar 2009 schrieb André Reichelt:
> Was würdest Du denn von folgendem Alternativvorschlag halten: Anstatt
> die Wege ständig zu stückeln stückelt man sie nur noch da, wo sich
> physikalisch etwas ändert. Damit meine ich, dass die Attribute
> hyghway=x, oneway=yes und name=bla zum Weg gehören. Alle anderen
> Eigenschaften wie Geschwindigkeitsbeschränkungen und ähnliches werden
> per Relations darüber gelegt. Somit würde man sich auch das zerlegen der
> Wege sparen.

Warum ist "oneway" ein physikalisches Attribut und eine 
Geschwindigkeitsbegrenzung nicht?

IMHO sind das beides Beschränkungen die durch einschlägige Schilder definiert 
sind und ohne bauliche Maßnahmen geändert werden können.

Dann stellt sich noch die Frage, ob ein Bürgersteig oder Fahrradweg an der 
Seite ein physikalisches Attribut ist (wäre IMHO so). Ist das so, dann musst 
du viele Wege alleine für sowas wesentlich öfter splitten als dir lieb ist.

Ich halte eine solche Mixtur für widersinnig.


Sobald JOSM mal anfängt, beim Splitten einer Straße zu fragen "Sollen die 
Einzelstücke stattdessen in einer Relation »Rosenstraße« zusammengefasst 
werden?" und zudem noch ein paar andere kleine Helferlein eingebaut werden, 
dann wird der Leidensdruck hier was zu ändern wesentlich geringer und man 
braucht keine solchen Flickschusterlösungen.

Gruß, Bernd

-- 
A: Weil es die Lesbarkeit des Textes verschlechtert.
F: Warum ist TOFU so schlimm?
A: TOFU
F: Was ist das groesste Aergerniss im Usenet?


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] taggen für den Checker - Gehts noch ?

[Gary68]

moin,

also meine checks sind alle im wiki beschrieben. wenn was unklar ist,
bitte fragen. links siehe meine wiki seite oder meine nachrichten mails.

zum noexit. das wurde hier auf der liste diskutiert und stellt einen
sachverhalt deutlicher dar. es gibt tausende wege, die versehentlich
nicht bis an einen anderen herangezeichnet wurden (also ohne
verbindung). und damit nicht die wenigen so richtig gezeichneten
versehentlich korrigiert werden, wird dieses tag dort eingesetzt.

zu meinen checks gibt es meist einen link in die history, da kann man
sehen, ob zwischen berichterstellung und "heute" was gemacht wurde.
manche bugs sind EXTREM schwer zu erkennen! Auch in JOSM und von leuten,
die schon ein paar edits gemacht haben!

zu den checks im allgemeinen. mir würde es vielleicht auch nicht
gefallen, wenn meine arbeit, die im renderer schön aussieht, kritisiert
würde. aber, die daten dienen ja verschiedenen zwecken - und nicht nur
sich selbst. und beim routing sind die meisten der fehler sehr
hinderlich und führen zu suboptimalen bis hin zu falschen ergebnissen.
z.b. große umwege oder straßen, die gar nicht erreichbar sind.

wer diese kritik nicht mag bzw. die fehler nicht beheben mag, der sollte
sie evtl. nicht benutzen? wer allerdings den anspruch hat, dass
irgendwann alles richtig und schön und komplett und konkurrenzfähig
ist... nahezu 100.000 potenzielle "fehler" sprechen eine deutliche
sprache - meine meinung.

noch was: dieses "wir mappen nicht für renderer/checker usw.". das sehe
ich anders. ohne renderer/router etc. (checker natürlich ausgenommen)
gibt es gar keine deutliche sicht auf die daten. keiner sieht sich die
datenbank oder die osm files an (bzw. könnte sie dann ansatzweise
begreifen)! - mal abgesehen von einigen linux grep befehlen für einfache
fragen :-) noexit=yes beschreibt ganz klar einen zustand in der realität
und gibt nicht dem renderer den font und die größe vor zum beschriften
von irgendwas! und es ist im wiki bei den features abgestimmt
dokumentiert.

ps: auch ein renderer könnte diese information sinnvoll nutzen.
ansonsten bin ich mir ziemlich sicher, dass es auf der karte auch so
aussieht, als könne man in oben beschriebenem falle dort einfach
weiterfahren... und das ist eben nicht so.

ciao

gerhard



Am Samstag, den 17.01.2009, 23:13 +0100 schrieb Alexander Schulze:
> Hi,
> 
> is vielleicht nen bischen Offtopic, aber gibts irgendwo ne Erklärung was 
> die bugs bedeuten. Da ich bei einigen bug-Meldungen keine Fehler 
> entdecken kann.
> Das kann natürlich verschiedene Gründe haben (jemand anderes hats schon 
> repariert, nen Fehler bei der Ermittlung und ein falsches Verständnis 
> meinerseits.
> 
> Garry wrote:
>  > In letzter Zeit stosse ich gelegentlich auf tags mit notes wie "noexit,
>  > damit der Check nicht meckert"...
> 
> war da nicht neulich ne Diskussion, wie man anzeigt, dass der Weg noch 
> weiterführt, sprich da noch mal jemand hinmuss. Könnte das der Grund sein?
> 
> > Ich halte das fuer einen Ausdruck von Unzifriedenheit seitens der 
> > Mapper, die sich durch einen Check bevormundet fuehlen, und man sollte 
> > das eventuell zum Anlass nehmen, den Check zu ueberdenken. Qualitaets- 
> > kontrolle ist gut und wichtig, aber wenn sie dazu fuehrt, dass die 
> > Mapper sich auf den Schlips getreten fuehlen und die Lust verlieren, 
> > dann muessen wir das anders aufziehen.
> 
> da kann ich nur sagen, dass ich mich nicht auf den Schlips getreten 
> fühle. Is doch ne feine Sache. Wers nicht nutzen will kanns doch bleiben 
> lassen, oder?
> 
> ___
> 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] Treppen mapping und ORS über Treppen

[Karl Eichwalder]

John07  writes:

> Außerdem ist mir ein Fußweg mit 3 flachen weit auseinanderliegenden 
> Treppenstufen aufgefallen, den man problemlos mit dem Rad runter und 
> hochkommt.

Wenn mir danach ist, trage ich auch die anzahl der stufen ein:

highway=steps
steps=3

Besser wäre vielleicht:

highway=steps
steps:number=3   (oder: amount?)
steps:height=10cm

-- 
Karl Eichwalder

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

Re: [Talk-de] Treppen mapping und ORS über Treppen

[Karl Eichwalder]

"Johann H. Addicks"  writes:

> Gerade Tourenradler sind doch vermutlich die "Standardkunden" für den ORS.
> Und bei denen wird das Rad vermutlich häufig mal gut gepackt sein.
> Mich würden dann 3 Treppenstufen schon stören, auch wenn sie in je 2m 
> Abstand (?) kommen.

Wenn die alternative ein umweg von mehreren 100 m (500, 800, 1000?) um
einige kurven und ein paar kreuzungen wäre, dann würde ich lieber die 3
treppenstufen akzeptieren.  Steigungen wäre auch mitzubenken.

Vielleicht sollte man "1 stufe == 100 m" bei der routen-planung
bewerten, wenn die stufen relativ flach sind (10 cm?) und in der
abwärtsrichtung bewältigt werden müssen.  Aufwärts wäre die formel
vielleicht "1 stufe == 200 m".

-- 
Karl Eichwalder

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

Re: [Talk-de] josm - linienstärke

[Karl Eichwalder]

Ulf Lamping  writes:

> Der dort vorgegebene Zahlenwert wird mit dem aktuellen Zoomlevel 
> verglichen (und zwar mit dem Meterwert der oben links angezeigt wird). 
> Wenn du 0 einstellst werden die Linien immer mit 1Pixel Breite 
> gezeichnet, wenn du 20 (der Defaultwert) nimmst, werden die Linien 
> immer nach den Vorgaben aus dem Stylesheet dargestellt.

Interessant.  Leider nimmt latest dafür keinen Wert an -- wenn ich die
Keyboard Preferences wieder öffne, steht immer nichts drin.  Ich werd's
die Tage noch einmal versuchen.

-- 
Karl Eichwalder

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

Re: [Talk-de] josm - Tastaturbedienung

[Karl Eichwalder]

Christoph Eckert  writes:

>> Ok, danke!  Leider funktioniert Alt-B hier nicht (Mac OS X).  Ich habe
>> die Vermutung, dass "Alt" nur anspringt, wenn wirklich ein Buchstabe des
>> Buttons unterstrichen ist.
>
> "bei mir geht's" in josm-latest.

Bei mir nicht ;-)  vielleicht liegt's an meinem java...

latest scheint nicht mappaint.fillareas=false zu honorieren.  Und nun
komme ich nur noch mit Shift-A in den Draw-Mode.  Ich habe wohl etwas zu
viel herumgespielt.  Ich versuche nachher mal ein anderes java.

-- 
Karl Eichwalder

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

[Talk-de] Rekordhalter im Relationsfragmentieren

[Nop]

Hallo!

Wo ich grade immer dabei bin, gegen sinnlos zerfitzelte Relationen zu 
wettern, möchte ich Euch den heutigen Brüller nicht vorenthalten.

Ein Nebenprodukt meines Kartenrenderes ist auch ein wenig 
Relationstatistik. Der Gewinner ist eine Relation vom Typ Route mit 
einem Way und exakt 7 Metern Länge. :-)

bye
Nop

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

Re: [Talk-de] Treppen mapping und ORS über Treppen

[Johann H. Addicks]

Garry schrieb:
> John07 schrieb:
>> Außerdem ist mir ein Fußweg mit 3 flachen weit auseinanderliegenden 
>> Treppenstufen aufgefallen, den man problemlos mit dem Rad runter und 
>> hochkommt. Ich werde das als ganz kurzes Stück Treppe mappen.

> überdurschnittlich sportlichen eine alternative oder auch für den 
> mittelmässigen Normalfahrer geeignet?

Gerade Tourenradler sind doch vermutlich die "Standardkunden" für den ORS.
Und bei denen wird das Rad vermutlich häufig mal gut gepackt sein.
Mich würden dann 3 Treppenstufen schon stören, auch wenn sie in je 2m 
Abstand (?) kommen.

-jha-


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

Re: [Talk-de] josm - Tastaturbedienung

[Christoph Eckert]

Moin,

> Ok, danke!  Leider funktioniert Alt-B hier nicht (Mac OS X).  Ich habe
> die Vermutung, dass "Alt" nur anspringt, wenn wirklich ein Buchstabe des
> Buttons unterstrichen ist.

"bei mir geht's" in josm-latest.

Beste Grüße,

ce

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

Re: [Talk-de] Frage zu Adress Inspector

[Frederik Ramm]

Hallo,

Norbert Wenzel wrote:
> Ist das ein Fehler in den Daten, bspw. "1090" vs. " 1090" vs. "1090 "? 
> Oder werden noch andere Tags ausgewertet, bspw. addr:country?

Genau letzteres ist der Fall. Die drei Bereiche, die Du ansprichst, 
haben drei verschiedene "country"-Werte: Einmal "AT", einmal "at" und 
einmal nichts. (Lt. http://wiki.openstreetmap.org/wiki/Karlsruhe_Schema 
sollten Kleinbuchstaben für den Ländercode genutzt werden.)

Man kann das herausfinden, indem man auf die schwarzen Nodes oder die 
Gebäude klickt, die das PLZ-Polygon begrenzen, dann sieht man ja rechts 
die Details des Objekts.

> Der These, dass auch andere Tags ausgewertet werden, widerspricht 
> allerdings[1] wo ein Postleitzahlenbereich (2013) um Hollabrunn mit 
> einem anderen Bereich deutlich weiter nördlich und weit außerhalb 
> Österreichs zusammenfällt. 

Hier handelt es sich um einen Ort in Österreich und einen in Norwegen, 
die beide die PLZ 2013 haben und nicht mit einem "country"-Wert versehen 
sind; daher werden sie zusammengeworfen. Wenn Du Hollabrunn ein 
country=at gibst, wird das aufhören.

> Dasselbe gab es vor einiger Zeit auch mit 
> einem Bezirk in Wien und einem Ort in Belgien, das ist aber wieder 
> verschwunden.

Vermutlich, weil zunächst keine Ländercodes getaggt waren und diese dann 
ergänzt wurden!

Bye
Frederik

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

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

Re: [Talk-de] Frage zu Adress Inspector

[Wolfgang W. Wasserburger]

> Hi,
>
> ich hab eine Frage zum Adress Inspector der Geofabrik. So wie ich das
> seh, wird da unter anderem die konvexe Hülle über alle Punkte einer
> bestimmten Postleitzahl erzeugt und als PLZBereich dargestellt. Wird
> dabei nebem dem Feld addr:postcode noch etwas ausgewertet?
>
> Ich frag das deshalb, weil es in Wien[0] teilweise drei
> Postleitzahlenbereiche mit derselben Nummer gibt, die auch teilweise
> überlappen, anstatt eines großen Bereichs. Das macht die Ansicht nicht
> unbedingt einfacher und übersichtlicher.
>
> Ist das ein Fehler in den Daten, bspw. "1090" vs. " 1090" vs. "1090 "?
> Oder werden noch andere Tags ausgewertet, bspw. addr:country?
>
> Der These, dass auch andere Tags ausgewertet werden, widerspricht
> allerdings[1] wo ein Postleitzahlenbereich (2013) um Hollabrunn mit
> einem anderen Bereich deutlich weiter nördlich und weit außerhalb
> Österreichs zusammenfällt. Dasselbe gab es vor einiger Zeit auch mit
> einem Bezirk in Wien und einem Ort in Belgien, das ist aber wieder
> verschwunden. Da ich nicht annehm, dass jemand alle Postleitzahlen
> löscht, hielt ich diesen kleinen (und nicht wirklich störenden) Fehler
> für behoben.
>
> Ich frage übrigens hauptsächlich aus Interesse, nicht weil deshalb der
> Inspector deutlich schlechter benutzbar würde. Nur die mehrfache Anzeige
> von PLZ Regionen ist manchmal etwas störend, wenn diese zu dicht
> gedrängt sind.
>
Wenn ich das richtig verstanden habe, wird country verwendet, wenn es da
ist, wenn nicht wird es anderen Bereichen mit dieser PLZ zugeschlagen, d.h.
der Fehler kann auch in Belgien oder Tschechien liegen

CU W


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

[Talk-de] Frage zu Adress Inspector

[Norbert Wenzel]

Hi,

ich hab eine Frage zum Adress Inspector der Geofabrik. So wie ich das 
seh, wird da unter anderem die konvexe Hülle über alle Punkte einer 
bestimmten Postleitzahl erzeugt und als PLZBereich dargestellt. Wird 
dabei nebem dem Feld addr:postcode noch etwas ausgewertet?

Ich frag das deshalb, weil es in Wien[0] teilweise drei 
Postleitzahlenbereiche mit derselben Nummer gibt, die auch teilweise 
überlappen, anstatt eines großen Bereichs. Das macht die Ansicht nicht 
unbedingt einfacher und übersichtlicher.

Ist das ein Fehler in den Daten, bspw. "1090" vs. " 1090" vs. "1090 "? 
Oder werden noch andere Tags ausgewertet, bspw. addr:country?

Der These, dass auch andere Tags ausgewertet werden, widerspricht 
allerdings[1] wo ein Postleitzahlenbereich (2013) um Hollabrunn mit 
einem anderen Bereich deutlich weiter nördlich und weit außerhalb 
Österreichs zusammenfällt. Dasselbe gab es vor einiger Zeit auch mit 
einem Bezirk in Wien und einem Ort in Belgien, das ist aber wieder 
verschwunden. Da ich nicht annehm, dass jemand alle Postleitzahlen 
löscht, hielt ich diesen kleinen (und nicht wirklich störenden) Fehler 
für behoben.

Ich frage übrigens hauptsächlich aus Interesse, nicht weil deshalb der 
Inspector deutlich schlechter benutzbar würde. Nur die mehrfache Anzeige 
von PLZ Regionen ist manchmal etwas störend, wenn diese zu dicht 
gedrängt sind.

vielen Dank,
Norbert

[0] 
http://tools.geofabrik.de/osmi/?view=addresses&lon=16.35428&lat=48.22612&zoom=15
[1] 
http://tools.geofabrik.de/osmi/?view=addresses&lon=16.10224&lat=48.59914&zoom=9

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

Re: [Talk-de] Relation Germany (Landmass)

[Norbert Kück]

Hallo,

Frederik Ramm schrieb:
>>
>> *** Achtung! *
>> Relation #62781 ist die offizielle im Wiki als Staatsgrenze
>> dokumentierte Relation Germany - NICHT Germany(Landmass).
> 
> (Nebenbemerkung: Man sollte sich nie darauf verlassen, dass Objekt-IDs 
> konstant bleiben. Zur Vereinfachung kann man die IDs zwar ins Wiki 
> schreiben, aber es muss jedem klar sein, dass sich die ID jederzeit 
> aendern kann. Staatsgrenze der Bundesrepublik Deutschland sollte immer 
> diejenige Relation mit admin_level=2, boundary=administrative, 
> name="Germany" oder so sein, egal welche ID sie hat. Oder?)
> 
> Kannst Du nochmal in anderen Worten sagen, was das Problem genau ist? 
> Ich habe es ehrlich nicht ganz verstanden. Was genau ist durcheinander 
> gekommen?

Im Zuge des Kreisgrenzenimports wurde auch eine Relation #62781 
name=Germany erzeugt mit eben den oben von dir genannten Tags.

An diese Relation habe ich die in meiner Nachricht genannten Änderungen 
(ein Weg hinzugefügt, einige entfernt) vorgenommen.

Danach (nämlich am 13. Jan.) wurde die Relation # 62781 umbenannt in 
"Germany (Landmass)". Angesichts gehabter Diskussion über Grenzen an/in 
Seegebieten bzw. "richtige" Staatsgrenzen und die konkurrierende 
Darstellung der reinen Landflächen war das für mich (und offensichtlich 
auch für andere) das Signal, dass diese Relation nun der Darstellung der 
reinen Landfläche gewidmet ist. Die Relation hat aber die alten 
boundary/admin_level-Tags behalten.

Also früher Staatsgrenze mit Zuweisungen die auch so gemeint sind und 
jetzt Landfläche mit ??? Was soll nun dieser Relation zugehören?
Ich habe hier alarmiert, weil hier zum Irrtum eingeladen wird. So heißt 
das Verfahren GIGA - garbage in garbage out.

Versteh mich richtig: Ich brauch die Relation nicht. Die kann 
meinetwegen totaler Schrott sein. Aber wenn das allen so egal ist, werde 
ich die Grenzrelationen künftig ignorieren. Wenn die aber gebraucht 
werden, sollten sie tauglich sein. Das ist #62781 derzeit nicht, da sie 
Landfläche verspricht, Eigenschaften einer Staatsgrenze hat und zum 
Staatsgebiet gehörendes Seegebiet zum Teil enthält, zum Teil aber auch 
nicht (wenn Leute vom Namen auf den Inhalt schließen).

Gruß
nk


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

Re: [Talk-de] Haltestellen taggen - Neuer Vorschlag - konkretisiert! (WAR: Re: ÖPNV Haltestellenverzei chnis)

[Gerrit Lammert]

Hi Frederik.

Frederik Ramm wrote:
> Es gibt einen europaweiten Standard fuer OePNV-Daten, der heisst 
> "Transmodel". Ich bin kein Experte dafuer, aber mir scheint, dass die 
> meisten Verkehrsverbuende in irgendeiner Form Modelle einsetzen, die zu 
> Transmodel kompatibel sind, siehe z.B. das Dokument des Verbandes 
> deutscher Verkehrsunternehmen hier:

Danke für die Hinweise.
Eines meiner größten Probleme mit OSM ist, dass viele ständig meinen, 
dass Rad neu erfinden zu müssen, anstatt sich zumindest anzusehen, wie 
andere das machen und ob es Sinn macht.
Von daher bin ich sehr für ein "Standard"-kompatibles Schema.

Gerrit

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

Re: [Talk-de] taggen für den Checker - Gehts noch ?

[Alexander Schulze]

Hi,

is vielleicht nen bischen Offtopic, aber gibts irgendwo ne Erklärung was 
die bugs bedeuten. Da ich bei einigen bug-Meldungen keine Fehler 
entdecken kann.
Das kann natürlich verschiedene Gründe haben (jemand anderes hats schon 
repariert, nen Fehler bei der Ermittlung und ein falsches Verständnis 
meinerseits.

Garry wrote:
 > In letzter Zeit stosse ich gelegentlich auf tags mit notes wie "noexit,
 > damit der Check nicht meckert"...

war da nicht neulich ne Diskussion, wie man anzeigt, dass der Weg noch 
weiterführt, sprich da noch mal jemand hinmuss. Könnte das der Grund sein?

> Ich halte das fuer einen Ausdruck von Unzifriedenheit seitens der 
> Mapper, die sich durch einen Check bevormundet fuehlen, und man sollte 
> das eventuell zum Anlass nehmen, den Check zu ueberdenken. Qualitaets- 
> kontrolle ist gut und wichtig, aber wenn sie dazu fuehrt, dass die 
> Mapper sich auf den Schlips getreten fuehlen und die Lust verlieren, 
> dann muessen wir das anders aufziehen.

da kann ich nur sagen, dass ich mich nicht auf den Schlips getreten 
fühle. Is doch ne feine Sache. Wers nicht nutzen will kanns doch bleiben 
lassen, oder?

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

Re: [Talk-de] Haltestellen taggen - Neuer Vorschlag - konkretisiert! (WAR: Re: ÖPNV Haltestellenverzei chnis)

[Frederik Ramm]

Hallo,

Gerrit Lammert wrote:
> So, ich hab mich nochmal der Anmerkungen von Patrick angenommen und mein 
> Schema etwas konkretisiert. 

Ich moechte dringend raten, bevor sich hier mit tollen Schemata 
verkuenstelt wird: Lest bitte auf der "talk-transit"-Mailingliste mit, 
die gibt es seit Anfang Januar, dort geht es speziell um den 
oeffentlichen Personen(nah?)verkehr. In Grossbritannien soll demnaechst 
ein groesseres Netz von Nahverkehrsdaten (NAPTAN-Datensatz) importiert 
werden, und wie das genau laufen soll, wird auf dieser Liste diskutiert 
werden.

Es gibt einen europaweiten Standard fuer OePNV-Daten, der heisst 
"Transmodel". Ich bin kein Experte dafuer, aber mir scheint, dass die 
meisten Verkehrsverbuende in irgendeiner Form Modelle einsetzen, die zu 
Transmodel kompatibel sind, siehe z.B. das Dokument des Verbandes 
deutscher Verkehrsunternehmen hier:

http://www.vdv.de/wir_ueber_uns/vdv_projekte/oepnv_datenmodell.html?pe_id=47

(VDV 452 ab ca. Seite 80 kommt Transmodel zur Diskussion).

Es ist abzusehen, dass wir ueber kurz oder lang viele Daten von 
Verkehrsunternehmen importieren duerfen. Es ist daher zwar nicht 
zwingend notwendig, aber doch sicherlich sinnvoll, sich Transmodel 
genauer anzusehen und zu ueberlegen, ob wir uns von diesem Konzept 
eventuell das eine oder andere klauen koennen.

Diese ganzen Fragen - wieviele Objekte machen gemeinsam eine Haltestelle 
aus, wie wird das evtl. mit der Strasse verknuepft, wie ist das mit 
Umsteigebeziehungen, wie ist das wenn nebendran der Bahnhof noch dazu 
gehoert oder nicht, und so weiter - das sind alles Sachen, ueber die 
sich Leute, die damit beruflich zu tun haben, schon recht lang Gedanken 
machen.

OSM hat keine Tradition, fremde Ideen, Konzepte und Datenmodelle zu 
uebernehmen, aber trotzdem ist es gut, diese zumindest zu *kennen*.

Und, wie gesagt, es waere m.E. sehr sinnvoll, wenn man hier zumindest 
versucht, sich mit den Englaendern auszutauschen, bei denen das Thema 
auch gerade massiv an Bedeutung gewinnt.

Bye
Frederik

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

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

Re: [Talk-de] Haltestellen taggen - Neuer Vorschlag - konkretisiert! (WAR: Re: ÖPNV Haltestellenverzei chnis)

[Gerrit Lammert]

Hi.

So, ich hab mich nochmal der Anmerkungen von Patrick angenommen und mein 
Schema etwas konkretisiert. Die Funktion von highway=platform ist nun 
eine andere.

Ein Beispiel, wo ich zwei Haltestellen so eingetragen habe, findet sich 
hier:
http://www.informationfreeway.org/?lat=53.901037995797786&lon=10.740937690645763&zoom=17&layers=BF000F

a) der ungefähre Haltepunkt des Busses wird AUF dem Weg mit
{highway=bus_stop}
angelegt.
b) der Platz des Bussteigs (wo man wartet) wird jeweils NEBEN der Straße 
  angelegt und erhält die Tags
{highway=platform, [shelter=yes], ...}
c) alles wird in eine Relation gepackt mit
{type=site, site=bus_stop, name=Haltestellenname, ...}

In der Regel reicht es wohl einen einzigen Knoten mit highway=bus_stop 
zu haben (wie bei der Haltestelle "Waldstraße", links). Wenn es aber 
Fürs Routing der Busse einen Unterschied machen könnte (etwa bei 
Kreuzungen mit Linienverkehr in alle Richtungen), können mehrere Halte 
eingesetzt werden (siehe "Eichenweg", rechts). Hier kann dann die 
relation-role wie schon bei den Busrouten angeben in welche Richtung 
dies ein Halt ist.

Diese logischen Haltepunkte werden in die Route-Relation der Buslinie 
aufgenommen (Siehe Linie 12 im Beispiel).

Die Elemente dieser Busstation bestehen fast alle bereits so zur Verfügung.
highway=bus_stop, shelter=yes
   http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop
highway=platform
   http://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform
relation:type=site
   http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site

Neu ist vor allem die Spezialisierung der Relation mit site=bus_stop 
(könnte auch nen anderen Namen bekommen) und das Zusammenspiel dieser 
Komponenten.

Abwärtskompatibilität:
Übergangsweise kann man
{name=Haltestellenname, operator=Betreiber, ...}
noch an einen highway=bus_stop Knoten hängen, so dass es schön gerändert 
wird.

Dieses Schema lässt sich wunderbar auf Schienengebundenen Verkehr 
übertragen und ist auch kompatibel zu highway=bus_station oder railway=halt

Zusammenfassung:
- Es ist komplett kompatibel, Rendern funktioniert wie gehabt.
- Es kann der Ort des Haltestellenschildes/-häusschens getaggt (und 
später gerendert) werden. Damit sind wichtige Infos für Busbenutzer 
vorhanden.
- Es gibt einen eindeutigen Haltepunkt AUF dem Weg, dieser wird in die 
Route-relation eingefügt. Damit ist die Computerverwertbarkeit etwa für 
Routing in Verkehrssimulationen etc.
- Der Mehraufwand ist sehr vertretbar und sinkt mit der Komplexität der 
Kreuzung
--- Bislang: 2-x Knoten mit jeweils ca 3-5 Attributen
--- Neu: 3-x Knoten mit jeweils 1-3 Attribut und einer Relation mit den 
gemeinsamen Attributen

Gerrit

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

Re: [Talk-de] Computerteddy: Datenproblem!

[Garry]

Carsten Schwede schrieb:
> Hallo,
>
> also ich kann beim Besten Willen nirgendwo Löcher in den Daten 
> entdecken. Ich nehme mal an, das Gebiet was Du meinst ist südlich von 
> Hamburg zwischen Lüneburg und der A7. Aber das ist bei mir völlig 
> normal, alle Wege da, POIs sind da nicht allzuviele.
>
> Ich habs eben nochmal mit Mapsource 6.13.7 getestet, in QLandkarte und 
> auf dem Etrex Vista HCx. Überall alles in Ordnung.
>
>   
Ich nehme an Holger hat gerde den gleichen Datensatz wie ich auch - da 
war rund um Freiburg auch mal plötzlich
die Karte weg...

Garry


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

Re: [Talk-de] Treppen mapping und ORS über Treppen

[Garry]

John07 schrieb:
> Außerdem ist mir ein Fußweg mit 3 flachen weit auseinanderliegenden 
> Treppenstufen aufgefallen, den man problemlos mit dem Rad runter und 
> hochkommt. Ich werde das als ganz kurzes Stück Treppe mappen.
> Toll wäre, wenn ORS über kurze Treppenstücke mit dem Rad routen könnte. 
> Lieber heb ich das Rad ein paar Stufen hoch, als das ich außen herum 
> fahren muss
Wenn Du den Aufwand das zu mappen für gerechtfertigt hälst...
Die die sowas auf ihrem täglichen Weg haben werden solche Abkürzungen 
bald selbst entdecken
und bei Bedarf nutzen. Für Einmal-Nutzer sind solche Angaben zu 
unzuverlässig  - ist das nur für den
überdurschnittlich sportlichen eine alternative oder auch für den 
mittelmässigen Normalfahrer geeignet?

Garry


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

Re: [Talk-de] taggen für den Checker - Gehts noch ?

[Frederik Ramm]

Hallo,

Garry wrote:
> In letzter Zeit stosse ich gelegentlich auf tags mit notes wie "noexit, 
> damit der Check nicht meckert"...
> 
> Gehts eigentlich noch? - "Wir taggen nicht für den Renderer und nicht 
> für den Router"... aber für den Checker?

Ich halte das fuer einen Ausdruck von Unzifriedenheit seitens der 
Mapper, die sich durch einen Check bevormundet fuehlen, und man sollte 
das eventuell zum Anlass nehmen, den Check zu ueberdenken. Qualitaets- 
kontrolle ist gut und wichtig, aber wenn sie dazu fuehrt, dass die 
Mapper sich auf den Schlips getreten fuehlen und die Lust verlieren, 
dann muessen wir das anders aufziehen.

Bye
Frederik

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

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

Re: [Talk-de] Relation Germany (Landmass)

[Frederik Ramm]

Hallo,

Norbert Kück wrote:
> Hallo,
> 
> da ich nicht glaube, dass alle die Diskussion über Seegrenzen intensiv
> lesen, habe ich hier eine auch für Binnenlandbewohner interessante
> Nachricht extrahiert:
> 
> *** Achtung! *
> Relation #62781 ist die offizielle im Wiki als Staatsgrenze
> dokumentierte Relation Germany - NICHT Germany(Landmass).

(Nebenbemerkung: Man sollte sich nie darauf verlassen, dass Objekt-IDs 
konstant bleiben. Zur Vereinfachung kann man die IDs zwar ins Wiki 
schreiben, aber es muss jedem klar sein, dass sich die ID jederzeit 
aendern kann. Staatsgrenze der Bundesrepublik Deutschland sollte immer 
diejenige Relation mit admin_level=2, boundary=administrative, 
name="Germany" oder so sein, egal welche ID sie hat. Oder?)

Kannst Du nochmal in anderen Worten sagen, was das Problem genau ist? 
Ich habe es ehrlich nicht ganz verstanden. Was genau ist durcheinander 
gekommen?

Bye
Frederik

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

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Garry]

André Reichelt schrieb:
> Was würdest Du denn von folgendem Alternativvorschlag halten: Anstatt
> die Wege ständig zu stückeln stückelt man sie nur noch da, wo sich
> physikalisch etwas ändert. Damit meine ich, dass die Attribute
> hyghway=x, oneway=yes und name=bla zum Weg gehören. Alle anderen
> Eigenschaften wie Geschwindigkeitsbeschränkungen und ähnliches werden
> per Relations darüber gelegt. Somit würde man sich auch das zerlegen der
> Wege sparen.
>   
Damit erhöst Du den Aufwand für z.B. Routing-Anwendungen.
Was man bisher einfach durch Filtern für entsprechende Anwendungen 
passend machen konnte muss man
dann erst umständlich aus vielen Informationen zusammensetzen.

Garry

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

[Talk-de] taggen für den Checker - Gehts noch ?

[Garry]

In letzter Zeit stosse ich gelegentlich auf tags mit notes wie "noexit, 
damit der Check nicht meckert"...

Gehts eigentlich noch? - "Wir taggen nicht für den Renderer und nicht 
für den Router"... aber für den Checker?



Garry

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

Re: [Talk-de] josm - linienstärke

[Frederik Ramm]

Hi,

Karl Eichwalder wrote:
> wie kann man dieses gummiband auf 1 pixel reduzieren
> oder ganz abschalten?

draw.helper-line=false

Bye
Frederik

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

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

Re: [Talk-de] Relation für Lange Ways

[Martin Simon]

Am 17. Januar 2009 19:16 schrieb Frederik Ramm :

> Das ist ein Missverstaendnis. Es geht nicht darum, dem Renderer das
> Leben leichter zu machen (der Renderer hat ja sogar mehr Aufwand, wenn
> er die Relation nutzen muss). Es geht darum, die Realitaet moeglichst
> gut abzubilden, und da erwarte ich von einem ordentlichen Datenmodell,
> dass die Kaiserstrasse in Karlsruhe auch als Objekt in der Datenbank
> existiert, so dass ich sagen kann "gib mir die Kaiserstrasse in
> Karlsruhe" - und nicht "gib mir alle Asphaltflaechen in Karlsruhe, die
> den Namen Kaiserstrasse haben" oder so.

Was ist denn "die Straße"?

Alles was denselben Namen trägt und zusammen hängt? Dann haben wir
schnell völlig unterschiedliche Flächen als "ein Objekt", nur aufgrund
des gleichen Namens.
Alles was baulich gleich ist? (dann hast du 2 verschiedene "Straßen",
wenn z.B. ein Teil einer Straße nun ein Fußweg oder eine Fußgängerzone
ist(wie deine Kaiserstraße))
Alles was auf derselben Trasse verläuft? (z.B.: Ortsumgehung,
"blastraße" wird als "blubbstraße" um den Ort herumgeführt, die "alte"
trasse knickt als "blastraße" ab und führt durch den Ort)
Alles mit derselben Referenznummer? Da wirds dann ganz wild...


Meiner Meinung nach gibt es keine Straßen, sondern nur "Schnipsel" -
genau so, wie wir es bei OSM auch momentan abbilden.

Wenn wir alle zusammenhängenden Schnipsel haben wollen, die den Namen
Kaiserstraße tragen, sollten wir auch genau danach suchen und nicht in
unseren Daten eine Einheit ("das ist *eine* Straße") definieren, die
es eigentlich so gar nicht gibt.

Grüße,
Martin

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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Norbert Kück]

Markus schrieb:
>> "Bekanntmachung der Proklamation der Bundesregierung 
> 
> Ja, so steht es im OSM-Wiki.
> Wenn Du den Link hast: kannt Du ihn bitte dort einfügen?
Hab den Link nicht präsent, kann aber zwei wichtige Quellen für 
bundesrechtliche Grundlagen nennen:

http://frei.bundesgesetzblatt.de/
wenn man auf die Bekanntmachung als PDF (nur lesen) verweisen will. 
BGBl. I ab 1998.

http://www.gesetze-im-internet.de/
bietet die Suche nach Gesetzen und Verordnungen. Hat den Vorteil, dass 
Änderungen (nach etwas Wartezeit) eingepflegt werden. Man hat dann einen 
Text zum Lesen und nicht das Gesetz und das 1. Änderungsgesetz und das 
2. Ä...

Gruß
nk

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

Re: [Talk-de] Treppen mapping und ORS ?ber Treppen

[Pascal Neis]

Hi,

>>> Toll w?re, wenn ORS ?ber kurze Treppenst?cke mit dem Rad routen k?nnte.
>>> Lieber heb ich das Rad ein paar Stufen hoch, als das ich au?en herum
>>> fahren muss.
>>> 
>>>   
>> Ja, ich auch. ?hnliches gilt IMHO f?r einige reine Fu?wege, die man lieber 
>> entlangschieben kann, als gro?e Umwege zu machen (bestes Beispiel: 
>> Fu?g?ngerbr?cken).
>>
>> Allerdings wird das f?r die 65-j?hrige Oma, die mit dem Rad Einkaufen f?hrt 
>> evtl. schwierig, das Rad ?ber f?nf Stufen zu heben. Ebenso f?r die 80-
>> j?hrige Oma mit Rollator. Ich glaube aber auch, dass die Intelligenz da auch 
>> mittelfristig eher in den Router muss, da wir unser Datenmodell auch auf 
>> sehr lange Sicht mit solch komplexen Details ned vollst?ndig bekommen. Man 
>> br?uchte eventuell die Option "Kurze Routen/Sichere Routen bevorzugen" mit 
>> einer entsprechenden Erkl?rung, bei der eine kurze Route eine mit einer Art 
>> "fuzzy"-Regelung gesucht wird, die sich nicht Streng an alle Regeln h?lt und 
>> kurze Treppen auch mal f?r Radfahrer freigibt.
>>   
>> 
> Ja, ich glaube auch, dass es im Endeffekt auf Presets bzw. 
> Experteneinstellungen herauslaufen muss. Es gibt dann z.B. das Preset 
> "Radfahrer", das routet nicht ?ber Fu?wege und ?ber Treppen, im 
> Expertenmodus kann man dann aber Treppen und Fu?wege f?r kurze Strecken 
> einschalten.
> Genauso kann man Presets f?r Radfahrer haben und als Experte dann 
> nochmal MTB, Rennrad etc. ausw?hlen. Wer dann immernoch nicht zufrieden 
> ist kann dann in den tiefsten Modus, wo er einzelne Stra?entypen, wie 
> z.B. tertiary an- oder ausschalten kann.
> Bleibt trotzdem noch die Frage bzgl. des Taggings der Treppen mit 
> Kinderwagenerweiterung.
>   

Jonas hatte schonmal angefangen etwas zum Thema: Besseres Radrouting
zu verfassen, vgl. 
http://wiki.openstreetmap.org/wiki/Talk:OpenRouteService#Besseres_Radrouting
dort könnt ihr es gerne weiter fortführen ...
oder hier weitere Ideen sammenln und dort zusammentragen?!

cheers
pascal


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

Re: [Talk-de] addr:via Was: Addresssuche - Zuordnu ng der Straße Was: News auf ORS

[Florian Lohoff]

On Sat, Jan 17, 2009 at 03:08:29PM +0100, Tobias Knerr wrote:
> > Hmm, irgendwie gefällt mir das erheblich besser als das umständliche
> > rumbasteln mit Relationen (siehe [1])um eine andere Zufahrtsstraße
> > anzugeben. 
> 
> Ich halte addr:via für wenig hilfreich. Bei längeren Straßen zu ungenau
> (ok, man kann mal wieder die kürzeste Verbindung ermitteln, aber die ist
> halt nicht immer richtig), und außerdem, wie du schon gesagt hast:
> 
> > eine unbenannte Straße, wie eine z.B. eine Zufahrt (highway=service)
> 
> Wenn man eh nicht alles damit abdecken kann und damit die
> Relation-Variante auch unterstützen muss, braucht man dann wirklich eine
> "abgespeckte" Version auch noch einbauen? Der Aufwand, dauerhaft in
> allen Anwendungen zwei Varianten abzudecken, dürfte wohl höher sein, als
> eine vernünftige Editor-Unterstützung einzubauen, mit der man z.B. einen
> Zugangspunkt aus einer Hausnummer "herausziehen" kann.
> 
> Nebenbei hat der Zugang nichts mit der Anschrift zu tun und damit m.E.
> kein "addr"-Präfix verdient.

Naja - Was ist denn der zielpunkt zu dem du ansteuerst denn? Eine
GeoKoordinate? Die haengt ja explizit am Node.

Ich sehe die Physische erreichbarkeit der Postalischen Addressen schon
als attribut der Addresse. Ist aber eher eine nebensaechlichkeit.

Das via war nur ein gedanke den ich so hatte. Der Punkt ist das ich das
route mich einfach zum naechstgelegenen Punkt schon 95% der faelle
erschlaegt. Was dann fehlt sind eben Postalische addressen die ueber die
in der Adresse angegebene Straße nicht erreichbar sind weil sie eben
dort nicht (mehr) liegt.

D.h ich gehe davon aus das der Routingalgorithmus mich erstmal bis zu
dem Straßenabschnitt routet zu dem die Hausnummer gehoert und dann
entsprechende service roads noch benutzt um naeher dranzukommen.

Uebertragen auf das via waere das so das der Routing algorithmus mich
nicht ueber die Straße der originaeren addresse schickt sondern routet
zum naechstgelegenen punkt auf der straße im via, und dann ggfs ueber
service roads noch naeher an die addresse ...

Mir fehlen im moment noch komplexe beispiele die sich damit nicht
abbilden lassen.

Die relation jedenfall ist so undokumentiert, unverstaendlich und
komplex das ich nicht sehe wie der otto-normal-mapper das anwenden soll.

Flo
-- 
Florian Lohoff  f...@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


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

Re: [Talk-de] Haltestellen taggen - Neuer Vorschlag (WAR: Re: ÖPNV Haltestellenverzeichnis)

[Gerrit Lammert]

Hi Patrick.

Patrick Hanft wrote:
> * Grundsätzlich muss man dabei aber IMHO auch eine Flexibilität erlauben, 

Die Flexibilität war gerade das was Hintergrund meines Vorschlages war. 
Momentan wird versucht, vieles in Knoten abzubilden, was da eigentlich 
nicht hingehört. Zudem geht der Zusammenhang bei Haltestellen desselben 
Namens mit verschiedenen Positionen (Straßenseiten) verloren.
Mein Vorschlag war nur ein Anfang, in die Relation können auch gerne 
Sitzbänke und Fahrkartenautomaten, wenn das jemand für sinnvoll hält.
Momentan gibt es den Ansatz
1) Eine logische Haltestelle, die alle tatsächlichen haltepunkte 
irgendwo auf der Kreuzung zusammenfasst, oder
2) Positionen der einzelnen Wartehäusschen, wodurch ein expliziter Bezug 
zur Straße flöten geht. Ich hab mal Simulationen mit Busnetzen gemacht, 
solche "Punkte in der Nähe der Straße" sind dafür denkbar ungeeignet.
Mein Ansatz verbindet beides.

> * Konkret meine ich damit zwei Punkte, die mir an deinem Vorschlag so nicht 
> ganz gefallen: Zunächst finde ich es wichtig, dass ein solcher Vorschlag 
> einigermaßen abwärtskompatibel zum derzeitigen Vorgehen sein sollte: Ein 
> node sollte IMHO nicht unbedingt platform heißen müssen, um die 

Namen sind natürlich Schall und Rauch. Aber Plattform wird bereits für 
genau so etwas verwendet.

> * Ähnlich halte ich es auch für nicht unbedingt sinnvoll, "vorzuschreiben", 
> dass bus_stops ein node des Ways sein sollen. Das ist oftmals nicht die 
> gängige Praxis und das wird vermutlich auch niemals so "auszurotten" sein. 

Der Platz an dem der Bus hält ist aber nun mal eher mit der Straße 
verbunden, als mit irgendeinem völlig frei stehendem Platz 2 Meter 
daneben. Vor allem für Routing etc wichtig.
Davon ab zeichne ich Haltestellen momentan auch noch als Punkte neben 
der Straße. Aber ich fände es wichtig, wenn beide Aspekte verbunden 
sind. Daher den "logischen" Haltepunkt (aus Fahrzeugsicht) auf der 
Straße (für Routing etc.) und den Ort der Haltestelle aus Fußgängersicht 
(Häusschen, Fahrplantafel, Bänke) daneben. Damit sollte jeder glücklich 
werden...

> Außerdem kann ich mir auch vorstellen, dass es Fälle geben mag, in denen man 
> es nicht verwenden mag (so wie es mir schon manchmal widerstrebt bei 
> Straßenbahnen - wo das Setzen des Nodes auf die Linie eher gängige Praxis 
> ist - dies zweimal zu tun, wenn zwei Einzelhaltestellen der jeweiligen 
> Gegenrichtung sehr weit voneinander entfernt sind.), oder man es auch aus 
> versehen nicht verwendet (und sei es, weil in Potlatch der Node 
> versehentlich neben statt auf dem Weg landet).

Verstehe ich nicht. Es wird doch niemand gezwungen mehr Details zu 
mappen als jetzt.

> * Da wir unglaublich viele Menschen haben, die unsere Daten bearbeiten und 
> dabei so unglaublich viele Wissensstände vorhanden sind, werden unsere Daten 
> in gewisser Hinsicht immer Inkonsistenzen aufweisen, ich bin der Meinung, 
> dass unsere Router, Renderer und andere Werkzeuge, mit solchen kleinen 
> Unzulänglichkeiten lernen müssen umzugehen. Und da glaube ich ist - auch 
> dank Route-Relationen und Algorithmen mit bisschen mehr Toleranz - es 
> einfacher, dem Router beizubringen, mit solchen Dingen umzugehen, als den 
> Datenbestand komplett anzupassen. Denn wie ein Grundsatz aus der 
> Softwaretechnik sagt: In einem komplexen IT-System sind Daten immer 
> beständiger als Funktionen.

Ich will keine Revolution. Ich bin nur selbst sehr gefrusstet, was das 
taggen von Haltestellen angeht (aktuell bei Bahnhöfen und deren Einfügen 
in Train-Relationen). Ich will einen Datensatz, mit dem ich die Realität 
abbilden kann. Und ich will einen Konsens darüber, damit nicht 
irgendwann alles was ich mache umsonst war.

> Vielleicht teilt ja manch einer meinen grundsätzlichen Standpunkt. Ich 
> glaube aber, dass wir nicht weit voneinander sind und ich deinen Vorschlag 
> im wesentlichen begrüße. In Kurzfassung glaub ich nur, dass es womöglich 
> schwierig wird, die Nodes _auf_ der Straße zu "wollen", und von 
> highway=bus_stop zu highway=platform wechseln zu wollen.

Wie gesagt: Namen=geschenkt
Ich will nur endlich einen brauchbaren zustand erreichen. Da hat sich im 
letzten jahr nicht viel getan. Aber mit der öpnvkarte.de sollte das 
langsam mal losgehen!

Gruß,

Gerrit

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

Re: [Talk-de] josm - linienstärke

[Ulf Lamping]

André Reichelt schrieb:
> Karl Eichwalder schrieb:
>> Gibt es die möglichkeit, alle linien nur 1 pixel breit zu machen?
> 
> Wie wäre es denn mit dem Wireframe-Mode? Das sollte genau diesen Effekt
> bringen.
> 

Dafür sind dann aber keine Icons vorhanden und auch nicht wirklich 
irgendwelche Farben ... und mit der aktuellen JOSM Version auch von der 
Performance (zumindest auf meiner Maschine) nahezu identisch.


Schau mal ob du in deiner Version schon in den Erweiterten Einstellungen 
den neuen Parameter "mappaint.strokes" findest - ansonsten Update ;-). 
Mit dem kannst du einstellen ob bei den Linien "Sondereffekte" (Breite, 
gestrichelt, ...) gezeichnet werden.

Der dort vorgegebene Zahlenwert wird mit dem aktuellen Zoomlevel 
verglichen (und zwar mit dem Meterwert der oben links angezeigt wird). 
Wenn du 0 einstellst werden die Linien immer mit 1Pixel Breite 
gezeichnet, wenn du 20 (der Defaultwert) nimmst, werden die Linien 
immer nach den Vorgaben aus dem Stylesheet dargestellt.

Ich hab diese Einstellung irgendwann in den letzten Tagen eingebaut, 
weil ich bei meinen Performanceverbesserungen festgestellt habe, das 
gerade dieses Feature vergleichsweise sehr viel Performance kostet.

Bei mir steht der Wert aktuell auf 250, das ist aus meiner Sicht ein 
guter Kompromiß zwischen Performance und Details (ja ich weiß, das sehen 
bestimmt viele wieder anders).


Das ist alles noch sehr sehr frisch, also nicht beleidigt sein wenn sich 
an diesen Mechanismen unkommentiert noch was ändert ...

Gruß, ULFL

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

[Talk-de] Relation Germany (Landmass)

[Norbert Kück]

Hallo,

da ich nicht glaube, dass alle die Diskussion über Seegrenzen intensiv
lesen, habe ich hier eine auch für Binnenlandbewohner interessante
Nachricht extrahiert:

*** Achtung! *
Relation #62781 ist die offizielle im Wiki als Staatsgrenze
dokumentierte Relation Germany - NICHT Germany(Landmass).
Diese Relation wurde laut History am 13. Januar in Germany (Landmass)
UMBENANNT.
***

Dadurch sind wahrscheinlich einige Zuordnungen durcheinander gekommen.
Sicher ist:
Ich habe VOR der Umbenennung die 12Meilenzone zugefügt und einige auf
Küstenlinien laufende Grenzen getilgt. Das passt für Staatsgrenze, aber
nicht für Landmass.

Wer repariert das jetzt? Und wie? Welche Zuordnungen wurden mit welchem
Gedanken (Staatsgrenze vs. Landfläche) gemacht?

Gruß
nk


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

Re: [Talk-de] josm - linienstärke

[Detlef Reichl]

Am Samstag, den 17.01.2009, 19:42 +0100 schrieb André Reichelt:
> Karl Eichwalder schrieb:
> > Gibt es die möglichkeit, alle linien nur 1 pixel breit zu machen?
> 
> Wie wäre es denn mit dem Wireframe-Mode? Das sollte genau diesen Effekt
> bringen.
> 
Hallo,

hatte ich auch schon mal ausprobiert, da mir eine Wireframe-Darstellung
eher behagen würde. Allerdings fehlen einem dann das Frabschema und die
die verschieden Strichtypen (gepunktet, gestrichelt, ...)

Der Mappaint-Modus mit 1 Pixel-Breite wäre für mich auch optimal.

Grüßle, detlef


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

Re: [Talk-de] Computerteddy: Datenproblem!

[Carsten Schwede]

Hallo,

also ich kann beim Besten Willen nirgendwo Löcher in den Daten 
entdecken. Ich nehme mal an, das Gebiet was Du meinst ist südlich von 
Hamburg zwischen Lüneburg und der A7. Aber das ist bei mir völlig 
normal, alle Wege da, POIs sind da nicht allzuviele.

Ich habs eben nochmal mit Mapsource 6.13.7 getestet, in QLandkarte und 
auf dem Etrex Vista HCx. Überall alles in Ordnung.



-- 
Viele Grüße
Carsten


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

Re: [Talk-de] josm - Tastaturbedienung

[Detlef Reichl]

Am Samstag, den 17.01.2009, 19:48 +0100 schrieb Karl Eichwalder:
> Ok, danke!  Leider funktioniert Alt-B hier nicht (Mac OS X).  Ich habe
> die Vermutung, dass "Alt" nur anspringt, wenn wirklich ein Buchstabe des
> Buttons unterstrichen ist.

Hallo,

mit Unterstrichen hat es nichts zu tun. Ich habe es bei mir auf Alt+A
geändert und da ist auch nichts unterstrichen.

Aber Du kannst die Tastenkombinationen in den Einstellungen doch ändern.
Ob dort Apfel+* unterstützt wird kann ich dir allerdings auch nicht
sagen (habe mein OS X von der Platte geputzt).

Grüßle, detlef


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

Re: [Talk-de] Treppen mapping und ORS über Treppen

[John07]

Patrick Hanft schrieb:
> John07 wrote:
>
>   
>> Toll wäre, wenn ORS über kurze Treppenstücke mit dem Rad routen könnte.
>> Lieber heb ich das Rad ein paar Stufen hoch, als das ich außen herum
>> fahren muss.
>> 
>
> Ja, ich auch. Ähnliches gilt IMHO für einige reine Fußwege, die man lieber 
> entlangschieben kann, als große Umwege zu machen (bestes Beispiel: 
> Fußgängerbrücken).
>
> Allerdings wird das für die 65-jährige Oma, die mit dem Rad Einkaufen fährt 
> evtl. schwierig, das Rad über fünf Stufen zu heben. Ebenso für die 80-
> jährige Oma mit Rollator. Ich glaube aber auch, dass die Intelligenz da auch 
> mittelfristig eher in den Router muss, da wir unser Datenmodell auch auf 
> sehr lange Sicht mit solch komplexen Details ned vollständig bekommen. Man 
> bräuchte eventuell die Option "Kurze Routen/Sichere Routen bevorzugen" mit 
> einer entsprechenden Erklärung, bei der eine kurze Route eine mit einer Art 
> "fuzzy"-Regelung gesucht wird, die sich nicht Streng an alle Regeln hält und 
> kurze Treppen auch mal für Radfahrer freigibt.
>   
Ja, ich glaube auch, dass es im Endeffekt auf Presets bzw. 
Experteneinstellungen herauslaufen muss. Es gibt dann z.B. das Preset 
"Radfahrer", das routet nicht über Fußwege und über Treppen, im 
Expertenmodus kann man dann aber Treppen und Fußwege für kurze Strecken 
einschalten.
Genauso kann man Presets für Radfahrer haben und als Experte dann 
nochmal MTB, Rennrad etc. auswählen. Wer dann immernoch nicht zufrieden 
ist kann dann in den tiefsten Modus, wo er einzelne Straßentypen, wie 
z.B. tertiary an- oder ausschalten kann.
Bleibt trotzdem noch die Frage bzgl. des Taggings der Treppen mit 
Kinderwagenerweiterung.
Gruß
Jonas
P.S. Pascal Neis von ORS mal CC gesetzt.


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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Norbert Kück]

Markus schrieb:
> Das BGBl /ist/ amtlich, die haben die Daten auch vom Bundesamt.
War mir klar.
nk


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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Hatto von Hatzfeld]

Markus wrote:

> Hallo Fabian,
> 
>> wie legt man Relationen über Teile von Wegen?
> 
> Grafisch-intuitiv:
> a) alle im geladenen Fenster enthaltenen Realationen werden gelistet
> b) eine Relation anklicken und alle damit verbundenen Linien werden
> hervorgehoben
> c) eine (Teil)Linie anklicken und alle damit verbundenen Relationen
> werden gelistet
> d) mit "Hinzufügen" kann eine markierte (Teil)Linie in eine Relation
> eingefügt werden
> e) mit "Neu" kann für eine markierte Linie eine neue Relation angelegt
> werden

Die Frage war doch wohl so gemeint: Was ist dann in der Relation, wenn nur
eine Teillinie gemeint ist? Fabians naheliegender Gedanke war: zwei Knoten 
mit den Rollen start und end (sowie der Weg). Müsste eigentlich
funktionieren, verlangt aber vom Editor viel "Mitdenken" - zum Beispiel
wenn ein Node gelöscht wird, der in irgendeiner derartigen Relation die
Rolle "end" hat.

Gruß,
Hatto


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

Re: [Talk-de] josm - Tastaturbedienung

[Karl Eichwalder]

Ulf Lamping  writes:

> Wieso, sind bei dir keine Tooltips vorhanden?

Damit hatte ich nicht gerechnet

> Bei mir kommt der Erklärungstext und dahinter (Alt+B).

Ok, danke!  Leider funktioniert Alt-B hier nicht (Mac OS X).  Ich habe
die Vermutung, dass "Alt" nur anspringt, wenn wirklich ein Buchstabe des
Buttons unterstrichen ist.

-- 
Karl Eichwalder

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

Re: [Talk-de] josm - linienstärke

[André Reichelt]

Karl Eichwalder schrieb:
> Gibt es die möglichkeit, alle linien nur 1 pixel breit zu machen?

Wie wäre es denn mit dem Wireframe-Mode? Das sollte genau diesen Effekt
bringen.

André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Existenzkrise: Wofür Wege?

[André Reichelt]

Fabian Schmidt schrieb:
> Und wie legt man Relationen über Teile von Wegen? Indem man zwei Knoten
> mit den Rollen start und end (sowie den Weg) aufnimmt?

Jop, genau. Man müsste natürlich an der Darstellung im Editor noch
arbeiten. Man müsste irgendwie erkenntlich machen, dass dieser Punkt,
den man gerade veschieben will, Anfang oder Ende einer Relation ist.



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Treppen mapping und ORS über Treppen

[Patrick Hanft]

John07 wrote:

> Toll wäre, wenn ORS über kurze Treppenstücke mit dem Rad routen könnte.
> Lieber heb ich das Rad ein paar Stufen hoch, als das ich außen herum
> fahren muss.

Ja, ich auch. Ähnliches gilt IMHO für einige reine Fußwege, die man lieber 
entlangschieben kann, als große Umwege zu machen (bestes Beispiel: 
Fußgängerbrücken).

Allerdings wird das für die 65-jährige Oma, die mit dem Rad Einkaufen fährt 
evtl. schwierig, das Rad über fünf Stufen zu heben. Ebenso für die 80-
jährige Oma mit Rollator. Ich glaube aber auch, dass die Intelligenz da auch 
mittelfristig eher in den Router muss, da wir unser Datenmodell auch auf 
sehr lange Sicht mit solch komplexen Details ned vollständig bekommen. Man 
bräuchte eventuell die Option "Kurze Routen/Sichere Routen bevorzugen" mit 
einer entsprechenden Erklärung, bei der eine kurze Route eine mit einer Art 
"fuzzy"-Regelung gesucht wird, die sich nicht Streng an alle Regeln hält und 
kurze Treppen auch mal für Radfahrer freigibt.

gruß,
Patrick



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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Markus]

Hallo Norbert,

> Michael hat die Werte aus dem BGBl in OSM verwendet
> prüfen, ob seine Koordinaten mit den amtlichen übereinstimmen.

Das BGBl /ist/ amtlich, die haben die Daten auch vom Bundesamt.
Sorry, hatte die Mail von Michael nicht gesehen.

Gruss, Markus

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

[Talk-de] josm - linienstärke

[Karl Eichwalder]

Gibt es die möglichkeit, alle linien nur 1 pixel breit zu machen?  Falls
das nicht geht, wie kann man dieses gummiband auf 1 pixel reduzieren
oder ganz abschalten?

-- 
Karl Eichwalder

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

Re: [Talk-de] josm - Tastaturbedienung

[Ulf Lamping]

Karl Eichwalder schrieb:
> Mit welcher tastenkombination kann man eigentlich diesen Add-button
> aktivieren, um tags hinzuzufügen?  Falls es noch keine gibt, möchte ich
> "+" vorschlagen; vielleicht ist das ja schon so gedacht, aber es
> funktioniert hier nicht (Mac OS X).  Ich glaube, ich habe josm 1212.
> 
> Früher konnte man einer wilden Tab, Shift-Tab, Tab-sequenz die
> properties aktivieren und dann irgendwie "Add" auslösen.  Momentan
> scheint es nur über Alt-i (für Edit), Space (um mit Ok das Popup
> wegzubekommen), Shift-Tab (um den Focus auf "Add" zu bekommen) und dann
> Space, um tags hinzuzufügen.
> 

Wieso, sind bei dir keine Tooltips vorhanden?

Bei mir kommt der Erklärungstext und dahinter (Alt+B).

Gruß, ULFL

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Markus]

Hallo Fabian,

> wie legt man Relationen über Teile von Wegen? 

Grafisch-intuitiv:
a) alle im geladenen Fenster enthaltenen Realationen werden gelistet
b) eine Relation anklicken und alle damit verbundenen Linien werden 
hervorgehoben
c) eine (Teil)Linie anklicken und alle damit verbundenen Relationen 
werden gelistet
d) mit "Hinzufügen" kann eine markierte (Teil)Linie in eine Relation 
eingefügt werden
e) mit "Neu" kann für eine markierte Linie eine neue Relation angelegt 
werden

Gruss, Markus

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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Norbert Kück]

Markus schrieb:
> 
>> in der Ostsee 37 verbundene Punkte 
> 
> Diese habe ich als amtliche Koordinaten.
> Kannst Du damit etwas anfangen?
Wozu? Michael hat doch gerade erklärt, dass er die Werte aus dem BGBl. 
in OSM verwendet hat. Du kannst ja mal prüfen, ob seine Koordinaten mit 
den amtlichen übereinstimmen.

Gruß
nk

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

[Talk-de] josm - Tastaturbedienung

[Karl Eichwalder]

Mit welcher tastenkombination kann man eigentlich diesen Add-button
aktivieren, um tags hinzuzufügen?  Falls es noch keine gibt, möchte ich
"+" vorschlagen; vielleicht ist das ja schon so gedacht, aber es
funktioniert hier nicht (Mac OS X).  Ich glaube, ich habe josm 1212.

Früher konnte man einer wilden Tab, Shift-Tab, Tab-sequenz die
properties aktivieren und dann irgendwie "Add" auslösen.  Momentan
scheint es nur über Alt-i (für Edit), Space (um mit Ok das Popup
wegzubekommen), Shift-Tab (um den Focus auf "Add" zu bekommen) und dann
Space, um tags hinzuzufügen.

-- 
Karl Eichwalder

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

Re: [Talk-de] Haltestellen taggen - Neuer Vorschlag (WAR: Re: ÖPNV Haltestellenverzeichnis)

[Patrick Hanft]

Hi, 

ich möchte jetzt nicht auf jedes Detail deines Vorschlages eingehen, da ich 
mich auch nicht in jedes einzelne mögliche Problem eindenken möchte, aber 
dennoch ein paar Anmerkungen von mir:

* Grundsätzlich finde ich die Vorstellung einer Sammelrelation für 
Haltestellen sinnvoll. Das kann helfen, Probleme, die man beim derzeitigen 
modellieren von ÖPNV-Strukturen hat, zu beheben.

* Grundsätzlich muss man dabei aber IMHO auch eine Flexibilität erlauben, 
die womöglich auf Kosten der 100%igen Spezifikation geht. Warum? Nach meiner 
Erfahrung mit OSM, bin ich der Meinung, dass ein Tagging-Schema nur maximal 
so komplex sein sollte, wie es der konkrete Anwendungsfall absolut notwendig 
macht. Kein Anfänger ist bereit, für das schnelle Hinzufügen einer einfachen 
Haltestelle, sofort das Anlegen einer komplexen Relation zu erlernen. Unsere 
Editoren sind außerdem nicht so weit, mit solchen Problemen umzugehen und 
außerdem können wir jetzt noch nicht alle Anforderungen an eine solche 
Relation abschätzen, die zukünftige mögliche Anwendungen haben könnten. 
Vielleicht kommt es ja mal tatsächlich zu einem automatischen 
Nahverkehrsrouting, das dann ganz andere Notwendigkeiten noch haben könnte? 
Deshalb glaube ich, dass es besser ist, nicht allzu viel zu genau (und ich 
sag mal zu "ungewohnt") vorzuschreiben.

* Konkret meine ich damit zwei Punkte, die mir an deinem Vorschlag so nicht 
ganz gefallen: Zunächst finde ich es wichtig, dass ein solcher Vorschlag 
einigermaßen abwärtskompatibel zum derzeitigen Vorgehen sein sollte: Ein 
node sollte IMHO nicht unbedingt platform heißen müssen, um die 
physikalische Repräsentation dieser Haltestelle darzustellen, denn es kann 
und würde vermutlich sehr lange dauern, Vorlagen in Editoren und Renderen 
das neue Verhalten beizubringen. IMHO ist es deutlich sinnvoller, wenn ein 
Renderer etwas wenigstens altmodisch rendert, als dass er es gar nicht 
rendert. Konkretes Beispiel dafür: Dass die cyclemap immer noch nicht das 
path-Tag so rendert, wie es von vielen erwartet würde, hält denke ich immer 
noch eine Reihe von Leuten ab, es überhaupt zu verwenden. Ich verstehe 
nicht, warum nicht einzelne nodes mit "bus_stop" zu einer Relation 
zusammengefasst werden können sollen. Platform kann man meinetwegen trotzdem 
verwenden, wenn man findet, dass es etwas besser abbildet und ein Renderer 
das dann auch unterstützt.

* Ähnlich halte ich es auch für nicht unbedingt sinnvoll, "vorzuschreiben", 
dass bus_stops ein node des Ways sein sollen. Das ist oftmals nicht die 
gängige Praxis und das wird vermutlich auch niemals so "auszurotten" sein. 
Außerdem kann ich mir auch vorstellen, dass es Fälle geben mag, in denen man 
es nicht verwenden mag (so wie es mir schon manchmal widerstrebt bei 
Straßenbahnen - wo das Setzen des Nodes auf die Linie eher gängige Praxis 
ist - dies zweimal zu tun, wenn zwei Einzelhaltestellen der jeweiligen 
Gegenrichtung sehr weit voneinander entfernt sind.), oder man es auch aus 
versehen nicht verwendet (und sei es, weil in Potlatch der Node 
versehentlich neben statt auf dem Weg landet).

* Da wir unglaublich viele Menschen haben, die unsere Daten bearbeiten und 
dabei so unglaublich viele Wissensstände vorhanden sind, werden unsere Daten 
in gewisser Hinsicht immer Inkonsistenzen aufweisen, ich bin der Meinung, 
dass unsere Router, Renderer und andere Werkzeuge, mit solchen kleinen 
Unzulänglichkeiten lernen müssen umzugehen. Und da glaube ich ist - auch 
dank Route-Relationen und Algorithmen mit bisschen mehr Toleranz - es 
einfacher, dem Router beizubringen, mit solchen Dingen umzugehen, als den 
Datenbestand komplett anzupassen. Denn wie ein Grundsatz aus der 
Softwaretechnik sagt: In einem komplexen IT-System sind Daten immer 
beständiger als Funktionen.


Vielleicht teilt ja manch einer meinen grundsätzlichen Standpunkt. Ich 
glaube aber, dass wir nicht weit voneinander sind und ich deinen Vorschlag 
im wesentlichen begrüße. In Kurzfassung glaub ich nur, dass es womöglich 
schwierig wird, die Nodes _auf_ der Straße zu "wollen", und von 
highway=bus_stop zu highway=platform wechseln zu wollen.

grüße,
Patrick



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

Re: [Talk-de] Relation für Lange Ways

[Frederik Ramm]

Hallo,

Sven Rautenberg wrote:
> Das Beispiel der Autobahn ist so ein Mittelding: Ich halte es für extrem
> sinnvoll, wenn jedes einzelne Teilstück sein zugehöriges ref-Tag trägt.
> Ich kann auch nur halbwegs nachvollziehen, warum man den gesamten
> Straßenzug nochmal zusätzlich in eine Relation stecken will. Was wird
> dadurch gewonnen? Genausogut kann man doch die API nach Wegelementen mit
> "ref=A 5" befragen und erhält im Prinzip dasselbe. Zugegeben, eine
> weltweite Abfrage liefert vermutlich mehr als nur die Autobahn in
> Karlsruhe, und in der Relation könnten sich auch noch weitere verbundene
> Informationen befinden.

Genau. Und die Bezeichnung "A5" braucht streng genommen auch nur ein 
einziges Mal in der Datenbank zu stehen und nicht 1435mal.

> Da ist nur die Frage: Welchen Sinn hat die
> Zuordnung solcher Informationen heute für welche Anwendung?

Ich beschaeftige mich nicht so sehr damit, welchen Sinn irgendwas 
"heute" hat. Wir sind uns alle darueber einig, dass der Support fuer 
Relationen in Editoren und Rendereren verbessert werden muss. Das ist 
aber fuer mich kein Grund, Relationen nicht zu verwenden.

> Ein in meinen Augen nun wirklich absurder Vorschlag ist, alle
> Einzelteile einer durchgehenden Straße in eine Relation zu packen, um
> dann nur der Relation den durchgehenden Straßennamen zu geben, damit das
> Rendering z.B. auf Brücken nicht ständig den Namen wiederholt.

Das ist ein Missverstaendnis. Es geht nicht darum, dem Renderer das 
Leben leichter zu machen (der Renderer hat ja sogar mehr Aufwand, wenn 
er die Relation nutzen muss). Es geht darum, die Realitaet moeglichst 
gut abzubilden, und da erwarte ich von einem ordentlichen Datenmodell, 
dass die Kaiserstrasse in Karlsruhe auch als Objekt in der Datenbank 
existiert, so dass ich sagen kann "gib mir die Kaiserstrasse in 
Karlsruhe" - und nicht "gib mir alle Asphaltflaechen in Karlsruhe, die 
den Namen Kaiserstrasse haben" oder so.

> Stichwort Redundanz: Ich glaube, dass es in OSM Redundanz geben muß,
> weil dadurch die Informationen leichter in einem konsistenzen Zustand
> gehalten werden können. Wenn ich die Gültigkeit einer Information
> lediglich anhand einer einzigen Quelle bewerten muß, dann kann ich die
> Info glauben, oder nicht. Geben mir zwei oder mehr Quellen gleichartige
> Informationen, dann hebt das die Vertrauensbasis schon erheblich.
> Außerdem wird es immer wieder vorkommen, dass gleichartige Dinge
> unterschiedlich getaggt werden - Redundanzen helfen dann dabei, zu
> ermitteln, was tatsächlich gemeint ist.

Das ist grundsaetzlich auch meine Meinung. Wobei man es uebertreiben 
kann mit der Redundanz.

Bye
Frederik

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

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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Markus]

Hallo Norbert,

> Es ging bei dem Thread nicht um eine globale Betrachtung

ich weiss, aber bei einer Weltkarte schadet etwas globale Info nicht.

> "Bekanntmachung der Proklamation der Bundesregierung 

Ja, so steht es im OSM-Wiki.
Wenn Du den Link hast: kannt Du ihn bitte dort einfügen?

> in der Ostsee 37 verbundene Punkte 

Diese habe ich als amtliche Koordinaten.
Kannst Du damit etwas anfangen?

Gruss, Markus

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Fabian Schmidt]

Am 17.01.09 schrieb André Reichelt:


Eigenschaften wie Geschwindigkeitsbeschränkungen und ähnliches werden
per Relations darüber gelegt. Somit würde man sich auch das zerlegen der
Wege sparen.


Und wie legt man Relationen über Teile von Wegen? Indem man zwei Knoten 
mit den Rollen start und end (sowie den Weg) aufnimmt?



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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Norbert Kück]

Markus schrieb:
>>> Staatsgrenze ist eine Linie, die 12 Seemeilen von der sogenannten 
>>> Basislinie bzw. Niedrigwasserlinie entfernt ist.
> 
> Das gilt nicht für alle Länder.
> Die Grenze liegt bei 3 Seemeilen.
> Die Länder haben aber die Option, diese auf 12 Seemeilen zu erweitern 
> und einige haben das gemacht.
Es ging bei dem Thread nicht um eine globale Betrachtung, sondern um die
bundesdeutsche Grenze. Und die ist seeseitig durch die
"Bekanntmachung der Proklamation der Bundesregierung vom 11. November
1994" (BGBl. I S. 3428) bestimmt. In der Nordsee die 12Meilenzone und
zusätzlich die Tiefwasserreede (derzeit in OSM noch nicht enthalten), in
der Ostsee 37 verbundene Punkte und ein Stück 12Meilenzone.

Gruß
nk


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

[Talk-de] Computerteddy: Datenproblem!

[Holger Issle]

Hi Carsten,

in meinen Daten fehlen einige Daten im Bereich N53 E10 bis N54 E10,2
Da sind nur ein paar POI zu sehen, aber keine Wege und Flächen. Mein
Daten satz ist der von vor 2 Wochen, und der von Bernd der mich auf
das hingewiesen hat von dieser Woche. 

Kannst Du da mal reinschauen? Mein Viewer ist die neueste (und wieder
fixe) Version von MapSource 6.15.3 von
http://www8.garmin.com/support/download_details.jsp?id=209
-- 

Ciao,
Holger (GUS-KOTAL, GUS#1100, GRR#51)

90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm
95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!)

cu @ http://www.issle.de


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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Sven Anders]

Am Samstag, 17. Januar 2009 05:08 schrieb Lars Francke:
> Nabend!
>
> Ich brauchte für den Kreis Pinneberg grad mal wieder eine
> "funktionierende" Relation und habe dabei gesehen, dass im Norden ganz
> schoenes Chaos herrscht.
>
> 1) Wir haben uns ja geeinigt, dass es pro Land und Kreis zwei
> Relationen geben soll. Einmal eine, die die reine Landmasse umfasst
> und einmal eine, die die administrative Grenze darstellt.

Ich würde sagen, aber nur, wenn es einen Unterschied gibt, gibt es keinen, 
sollte es nur noch eine Relation geben.

> 2) Da die Küstenlinie ja eh gerendert wird und die dort verlaufenden
> Landmasse-Relation soweit ich weiß keine administrative Grenzen sind
> sollten diese nicht extra gerendert werden

Ja, man sollte vor Ort (oder per Luftbild etc.) entscheiden, welche Linie den 
Küstenverlauf besser darstellt und diese nehmen. Und die dann 
natural=coastline taggen.

> 3) Wir haben an den Küsten und den Inseln fast überall doppelte
> Linien: Einmal die Küstenlinie und einmal Grenzen, die durch den
> INFAS-Import gekommen sind

Siehe 2

> 4) Es gibt die Relation Germany (Landmass), mal abgesehen davon, dass
> ich da einfach den deutschen Namen verwenden würde stellt die nicht
> nur die Landmasse dar sondern beinhaltet auch die Seegrenzen

Wir sollten IMHO auch hier zwei Relationen anlegen 

> 5) Da type=boundary abgeschafft wurde koennen Renderer nur noch anhand
> von admin_level eine Grenze erkennen (zumindest so wie im Moment im
> Norden getaggt ist). An gewissen Stellen führt das dazu, dass wir in
> Schleswig-Holstein vier beinahe parallel verlaufende Grenzlinien
> haben. Das sieht nicht nur gerendert ziemlich mies aus sondern macht
> das editieren auch extrem anstrengend, da überall verschiedene
> Relationen dranhängen.

Ja, deshalb bin ich bereits dabei die alten Landgrenzen zu löschen. Die 
verwirren sowieso nur.

> 6) Manche Relationen sind noch type=boundary und manch andere sind
> type=multipolygon. Manche derer, die nun multipolygon sind wurden
> einfach "umbenannt" ohne die Rollen zu vergeben. Das das nicht
> unbedingt notwendig ist weiß ich selbst aber mich würde interessieren
> was hier der Standard im Rest Deutschlands ist.

Ich spreche mich für multipolygon aus, denn damit können wir sowas wie Neuwerk 
(zu Hamburg) abbilden. 

> 7) Anstatt die bestehenden Relationen, die im Wiki dokumentiert waren
> (und die ich in meinen Programmen verwendet habe ;-) ) zu ändern
> wurden neue angelegt und die alten geloescht..

> Daher hier was ich tun werde wenn es keine all zu großen Einwände gibt:
> - Doppelte Küstenliniengrenzen loeschen und die Landmasserelationen
> auf die Küstenlinie legen (laut Frederik und noch einem fleißigen
> Helfer aus Kiel dessen Namen ich grad nicht mehr weiß sind die
> Küstenlinien wahrscheinlich genauer als die INFAS-Daten).

Okay, ich würde das im Einzelfall prüfen, aber mach man.

> - Den Landmasse-Relationen und Wegen das admin_level-Tag aberkennen
> bzw. durch ein landmass_admin_level o.ä. ersetzen (und ja das ist mehr
> oder weniger ausschließlich für die Renderer)

Okay.

> - Die Relation Germany (Landmass) in "Deutschland (Landmasse)"
> umbenennen und die Seegrenzen loeschen. Dafür die alte
> Deutschlandrelation aktualisieren
> (http://www.openstreetmap.org/browse/relation/51477)

Ja, wenn du willst.
> - Die Wikiseiten http://wiki.openstreetmap.org/wiki/DE:Grenze und
> http://wiki.openstreetmap.org/wiki/Schleswig-Holstein mit den neuen
> Relationen aktualisieren.

Ich verstehe nicht wofür wir die Wikiseite mit irgendwelchen IDs brauchen, 
aber wenn du sie haben möchtest bitte.


> Meine Fragen:
> - Es gab einen Vorschlag dafür wie die Landmasserelationen getaggt
> werden koennten. Gab es da eine Einigung?

Jochen hatte auf talk-de einen Vorschlag, ich habe ihn aber auch nicht mehr in 
meiner Mailbox. Außerdem ist der nicht international diskutiert worden.


> - Ist noch irgendwer in SH aktiv was die Grenzen angeht? 

Ich würde mich in den nächsten Tagen dort austoben und ähnliches machen, wie 
du. Wenn ich aber dabei mehr störe würde ich mich auch zurückhalten, hab 
sowieso genug Baustellen.


> So. Das ganze ist sehr Schleswig-Holstein zentriert. Ich habe erstmal
> nicht vor ähnliche Anpassungen für Niedersachsen oder MV zu
> unternehmen. Das wird schon genug Zeit kosten :)
> Ich freue mich über jeden Kommentar und bin gespannt was ich so
> vergessen und übersehen habe.

Würde das auch für MV und NDS machen (coastlines überprüfen). Aber eben nicht 
mit festen Ende etc.

Danke Deine Mail war gut, vergesse immer wieder zu komunizieren, und das gibt 
dann eher mehr Probleme.

Gruß
Sven

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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Markus]

Hallo Norbert, hallo Frederik,

>> Staatsgrenze ist eine Linie, die 12 Seemeilen von der sogenannten 
>> Basislinie bzw. Niedrigwasserlinie entfernt ist.

Das gilt nicht für alle Länder.
Die Grenze liegt bei 3 Seemeilen.
Die Länder haben aber die Option, diese auf 12 Seemeilen zu erweitern 
und einige haben das gemacht.

Für Buchten, Fjorde, vorgelagerte Inseln gibt es Sonderregeln.

> Diese Definition in dieser simplen Form bedeutet aber, dass es 
> Seegebiete gäbe, die sowohl innerhalb Deutschlands als auch innerhalb 
> Dänemarks liegen, oder? 

Länder die einander näher liegen als der doppelte Abstand der 
seewärtigen Ländergrenze, ziehen ihre Grenze in der "Hälfte", oder 
verhandeln sie individuell.

Details siehe:
http://wiki.openstreetmap.org/wiki/de:Grenze#Verwaltungsgrenzen:_Seewärtige_Grenze

Gruss, Markus

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

Re: [Talk-de] Relation für Lange Ways

[Gerrit Lammert]

Hi Sven.

Sven Rautenberg wrote:
> Ein in meinen Augen nun wirklich absurder Vorschlag ist, alle
> Einzelteile einer durchgehenden Straße in eine Relation zu packen, um
> dann nur der Relation den durchgehenden Straßennamen zu geben, damit das
> Rendering z.B. auf Brücken nicht ständig den Namen wiederholt. Da sage
> ich mir: Wenn ein Renderer wirklich will, dass gleiche Straßennamen
> schöner verteilt werden, dann wird er so programmiert werden, dass er
> die Namensidentität der Einzelteile erkennt und selbst zusammenfaßt. Für
> sowas braucht es keine Relation.

Gerade das ist für mich ein Paradebeispiel für sinnvolle Relationen.
Einfach, weil es der Realität entspricht, dass ich EINEN Namen für das 
zu benennende Objekt habe. Die Aufteilung der Straße in Segmente ist 
doch ziemlich willkürlich, je nachdem wo eine Kreuzung, oder einfach nur 
ein Knick in der Straße ist, beginnt ein neues Segment.
Beispiel:
Du bist ja nun ein Mensch und heißt Sven. Nach Deiner Logik ist dass 
unsinnig, DIR den Namen zu geben, man kann den ja auch einfach an die 
Körperteile dranhängen.
Natürlich kann man ja herausfinden das Bein-von-Sven + Bein-von-Sven + 
Arm-von-Sven + Arm-von-Sven + Rumpf-von-Sven + Kopf-von-Sven einen 
zusammengehörigen Organismus Namens Sven beschreibt, aber das ist IMHO 
weder besonders elegant noch effizient... ;-)

Gerrit

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Gerrit Lammert]

André Reichelt wrote:
> Was würdest Du denn von folgendem Alternativvorschlag halten: Anstatt
> die Wege ständig zu stückeln stückelt man sie nur noch da, wo sich
> physikalisch etwas ändert. Damit meine ich, dass die Attribute
> hyghway=x, oneway=yes und name=bla zum Weg gehören. Alle anderen
> Eigenschaften wie Geschwindigkeitsbeschränkungen und ähnliches werden
> per Relations darüber gelegt. Somit würde man sich auch das zerlegen der
> Wege sparen.

Ja, ich denke genau so wird es kommen (müssen). und das ist ja auch gut so.
Der andere Vorschlag (nur noch Nodes und Relation) war eher 
gedankenspielerischer Natur. Auch wenn ich es gut fände, es wäre ein 
ziemlicher Paradigmenwechsel und dafür ist der Leidensdruck nicht groß 
genug (und wikrd es hoffentlich auch nicht werden).

Gerrit

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Gerrit Lammert]

Hi.

Karl Eichwalder wrote:
> Das der knoten-ansatz wird spätentens dann extrem kompliziert, wenn
> knoten eingefügt oder gelöscht werden...

Verstehe ich nicht. Ist doch nicht anders als jetzt.
Wenn ich z.B. Knoten zwei Lösche, macht das einzig bei
rel(2,3):highway=incline
Probleme. Das würde es jetzt aber auch tun, wenn ich in einem Segment 
mit Gefälle den Anfangsknoten lösche...

Gerrit

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Gerrit Lammert]

Hallo.

Bernd Wurst wrote:
> Am Samstag, 17. Januar 2009 schrieb Gerrit Lammert:
>> Ich finde es wahnsinnig umständlich, das ich ständig Wege in einzelne
>> Segmente zerlegen muss, weil z.B. nur ein Teil des Weges zur Buslinie
>> gehört. Und wenn dann die "Dorfstraße" zur Einbahnstraße wird, muss ich
>> oneway=yes bei 20 Segmenten ergänzen.
> 
> Naja, wenn die alle in einer Relation sind (müssen sie sein, wenn der Rest 
> deiner "Forderung" wahr werden soll), dann kannst du die Realtion gesammelt 
> markieren und das oneway=yes damit an alle Wege dran machen.

Genau.

>> muss. Ich denke das Datenmodell geht unaufhaltsam in die Richtung, es
>> wird Zeit, das die Editoren und die allgemeine Herangehensweise nachziehen.
> 
> Noch nicht.
> 
> Bisher sind Relationen ungeordnet. Du hättest also keinen Anhaltspunkt in 
> welcher Reihenfolge eine Relation über mehrere Punkte geht sondern müsstest 
> mit travelling-salesman-algorithmen arbeiten um den wahrscheinlichsten 
> verlauf zu finden. 

Manche Dinge wie Name, surface, ... setzen ja aber keine Ordnung 
innerhalb der Relation voraus.

> mit API 0.6 sollen Realtionen streng geordnet werden und bleiben und damit 
> ist 
> dein Konzept prinzipiell denkbar.

Ah, wusste ich nicht. Schön!

> 
>> Es gibt nur noch Knoten und Relationen.
>> [...]
>>
>> ||
>> ||
>> 1---234
>>
>> 1,2,3,4 sind die Knoten, die den Verlauf der Straße angeben.
>> Dazu gibt es etwa folgende Relationen mit den Nodes als Member:
>> rel(4):highway=noexit
>> rel(3):highway=traffic-lights
>> rel(1,2,3,4):highway=residential
>> rel(1,2,3,4):name=Dorfstraße
>> rel(1,2,3):paved=asphalt
>> rel(3,4):paved=cobblestone
>> rel(1,2,3):oneway=yes
>> rel(2,3):highway=incline
>> ...
> 
> Du bist dir sicher, dass das einfacher ist als was wir bisher haben? :-)
> Ich finde das (ein Attribut pro Relation) einen großen Rückschritt.

Naja, es vereinfacht halt enorm die Datenstruktur. Und dies wiederrum 
Vereichfacht den Zugriff darauf. Natürlich wird das in Funktionen gekapselt.
Wenn ich alle Attribute zu einem Node haben will, brauch ich ja nur eine 
Funktion, die mir alle Relationen liefert, in denen der gesuchte Node 
enthalten ist.

Gerrit

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

[Talk-de] Treppen mapping und ORS über Treppen

[John07]

Hi,
beim mappen ist mir folgendes aufgefallen: Häufig haben Treppen hier 
noch nebendran so eine extra Spur für Kinderwagen zum runterschieben. 
Das Rad kann man da auch gut runterschieben, Rollstuhl runterfahren wäre 
wohl sehr schwierig (alleine) Wie mappt man soetwas? Das sind meist 
kurze Stücke, mit einer kleinen Plattform dazwischen und dann wieder 
Treppe...
Außerdem ist mir ein Fußweg mit 3 flachen weit auseinanderliegenden 
Treppenstufen aufgefallen, den man problemlos mit dem Rad runter und 
hochkommt. Ich werde das als ganz kurzes Stück Treppe mappen.
Toll wäre, wenn ORS über kurze Treppenstücke mit dem Rad routen könnte. 
Lieber heb ich das Rad ein paar Stufen hoch, als das ich außen herum 
fahren muss.
Gruß
Jonas

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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Michael Schmitt]

Norbert Kück schrieb:
> Hallo,
>
> Frederik Ramm schrieb:
>
>   
>> Diese Definition in dieser simplen Form bedeutet aber, dass es 
>> Seegebiete gäbe, die sowohl innerhalb Deutschlands als auch innerhalb 
>> Dänemarks liegen, oder? 
>> 
> Nein, das kommt  nicht vor. So simpel ist das Seerechtsübereinkommen 
> natürlich nicht. Das Seerecht sieht vor, dass in Meeresengen von weniger 
> als 24 sm Weite die 12 sm nicht gelten, sondern man sich die Fläche (in 
> der Regel mittig) teilt (Art. 15 SrUe). Diese Teilung gilt nicht, wenn 
> es andere Regelungen gibt. Schönes Beispiel Dollart. Da gibt es drei 
> Grenzverläufe: Version NL, Version DE und die Linie des Zusatzabkommens 
> zum Ems-Dollart-Vertrag. Wollte ohnehin mal fragen, wie wir das zeichnen 
> wollen. ;-) Im Augenblick ist nur die Version NL drin - und die 
> scheinbar auch nicht ganz stimmig.
>
> Ich habe nur die Grenze in der Nordsee bearbeitet. Da war alles klar. 
> Die Dänen hatten schon ihre 12 sm gezeichnet und einfach die frühere 
> Grenze DK/DE verlängert. Daran habe ich angeschlossen. Vergleich mit 
> offiziellen Karten bestätigt den Verlauf.
>
>   
>> Ich habe zumindest den Eindruck, dass einige der 
>> aktuell eingetragen 12-Seemeilen-Linien näher an Dänemark als an 
>> Deutschland liegen. Oder täuscht das?
>> 
> Du meinst die Ostsee? Nicht meine Rennstrecke, nicht genau angesehen.
> Gruß
> nk
>   
Die Punkte dort habe ich in einer amtlichen Veröffentlichung 
(Bundesgesetzblatt oder so ähnlich) gefunden und ensprechend mit der 
source markiert.

Gruss  mikes


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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[André Reichelt]

Was würdest Du denn von folgendem Alternativvorschlag halten: Anstatt
die Wege ständig zu stückeln stückelt man sie nur noch da, wo sich
physikalisch etwas ändert. Damit meine ich, dass die Attribute
hyghway=x, oneway=yes und name=bla zum Weg gehören. Alle anderen
Eigenschaften wie Geschwindigkeitsbeschränkungen und ähnliches werden
per Relations darüber gelegt. Somit würde man sich auch das zerlegen der
Wege sparen.

Gruß
André



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Norbert Kück]

Hallo,
Lars Francke schrieb:
> Ich habe das letztes mal schon gesagt: Die 3sm-Grenze habe ich damals
> gezeichnet und zwar ohne Beachtung irgendwelcher Abstände oder realer
> Grenzverläufe. Mein einziges Kriterium war eine durchgehende
Ok, ist mir wohl durchgegangen, dass das dermaßen grob ist.

> Grenzlinie zu schaffen die alle Inseln einschließt. Daher habe ich die
> vollkommen willkürlich gewählten Grenzen gestern geloescht (wo sie
> nicht mehr in Relationen stecken also hauptsächlich in SH). Die haben
> für mich keinerlei historischen Wert.
Gut, dann wäre das auch keine gute Grundlage für die Zeichnung des
Nationalparks gewesen.

> Relation 62781: Germany (Landmass) beinhaltet sehr wohl (zumindest zu
> diesem Zeitpunkt und gestern nacht) die 12sm-Grenze:
> http://betaplace.emaitie.de/webapps.relation-analyzer/osm.jsp?relationId=62781
Gut, dass du das so sicher sagst!

*** Achtung! *
Relation #62781 ist die offizielle im Wiki als Staatsgrenze 
dokumentierte Relation Germany - NICHT Germany(Landmass).
Diese Relation wurde laut History am 13. Januar in Germany (Landmass) 
UMBENANNT.
***

Ich möchte nicht wissen, was dadurch jetzt alles schief gelaufen ist.
Habe mich schon gewundert, dass ich die Seegrenze an Landmass 
angeschlossen haben soll.

> Relation 51477 ist einfach noch nicht umgestellt, ich habe die
> 12sm-Grenze dort nachgetragen.
Na denn ...

>>> - Die Relation Germany (Landmass) in "Deutschland (Landmasse)"
>>> umbenennen
>> Würde ich nicht tun. Immerhin ist das etwas von möglicherweise
>> internationalem Interesse.
> 
> Dafür gibt es name:en - wir haben hier in Deutschland überall im
> name-Tag den deutschen Namen.
Siehe oben. Relation #62781 ist nicht die Landfläche, sondern die 
Staatsgrenze - bzw. sollte es sein.
> 
> 
> Oben schriebst Du doch aber, dass Dir die Landmasse-Relationen egal
> sind. 51477 ist KEINE Landmasse-Relation sondern eine mit den
> Seegrenzen. Warum ist die Dir dann egal? type=boundary ist sie einfach
> nur weil noch niemand sie umgestellt hat.
Muss man sie umstellen? Es wurde doch für die Staatsgrenze die Relation 
#62771 geschaffen.

>>> - Gibt es noch mehr Relationen oder Wege, die man zusammenfassen
>>> koennte? Soweit ich mich erinnere gab es z.B. mindestens drei
>>> Deutschland-Relationen
>> Das Konzept mit je einer Multipoligon-Relation für den Staat, jedes Land
>> und jeden Kreis finde ich perfekt. Zusätzliche Landfläche-Relationen,
>> die nach Bedarf Grenzen durch Küstenlinien ersetzen, kann man machen.
>> Für mehr sehe ich keinen Bedarf.
> 
> Ich auch nicht. Daher meine Frage ob es noch mehr redundante
> Relationen gibt, die man zusammenfassen koennte.
Die typ=boundary kann m.E. weg.

>>> - multipolygon für Grenzen ist nun vollständig akzeptiert und
>>> adoptiert?
>> Offenbar nicht - siehe oben. Schade eigentlich.
> 
> Der, der immer dagegen genoergelt hatte war ich aber ich habe meine
> Meinung geändert nur noch nicht die Relationen umgestellt :)
Das verstehe ich noch nicht. Welche Relationen muss man umstellen? Hat 
nicht jeder Kreis, jedes Land und der Bund eine Multipolygon-Relation 
bekommen?

> Ich glaube weiterhin, dass wir beide das gleiche
> Ziel verfolgen auch wenn das in den Mails manchmal nicht so klingt ;-)
Ganz mein Eindruck.

> Ich wollte in NI niemandem in die Arbeit reinpfuschen daher habe ich
> die alte Grenze nicht angefasst - 
Dann haben wir ja auch beide dieselbe Zurückhaltung gegenüber Nachbars 
Vorgarten. :-)

> aber wie oben erwähnt ist die komplett an den Haaren herbeigezogen
Ok. Bei dem "Wert" schmeißen wir das weg.

> Ah...und es wäre cool wenn wir bei obsolete_boundary bleiben koennten
> (für veraltete oder nicht korrekte Grenzen), einfach damit man sie im
> OSM-Inspector sehen kann.
Im allgemeinen ja. Aber hier konkret wollte ich (und für die 
Kreisgrenzen im Wasser möchte ich das immer noch) die Linien für die 
breite Masse unsichtbar machen - gerade auch im OSM-Inspector. Es sollte 
niemand zu einer schnellen Löschaktion aufgerufen werden.

Gruß
nk

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

Re: [Talk-de] Relation für Lange Ways

[Bernd Wurst]

Hallo.

Am Samstag, 17. Januar 2009 schrieb Sven Rautenberg:
> Ich kann auch nur halbwegs nachvollziehen, warum man den gesamten
> Straßenzug nochmal zusätzlich in eine Relation stecken will. Was wird
> dadurch gewonnen? Genausogut kann man doch die API nach Wegelementen mit
> "ref=A 5" befragen und erhält im Prinzip dasselbe.

Was ist mit Streckenabschnitten, die zu mehr als einer Autobahn gehören?
Bei Autobahnen passiert das weniger oft, aber grade bei Bundesstraßen sieht 
man das häufig.

Klar, man hätte für den Zweck auch eine verbindliche 
Array-Simulations-Konvention aufschreiben können, aber so ist es technisch 
einfacher, die Daten zu nutzen.

Du lädst einfach http://api.[...]/relation/12345/full und bekommst alles was 
du brauchst um die betreffende Strecke zu visualisieren oder sonstwie zu 
nutzen. Aus Sicht der Nutzung ist die Relation hier einfach prima. :)

Und grade für z.B. Multipolygon war es sicherlich nötig, irgend einen neuen 
Datentypen zu erfinden.

Gruß, Bernd

-- 
People who ask, `Can I ask you a question?' don't really give you a
choice, do they?


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relation für Lange Ways

[Sven Rautenberg]

Frederik Ramm schrieb:
> Durch Karlsruhe verläuft die A5. Sie besteht aus vielen einzelnen Ways. 
> Die sind derzeit alle noch mit "highway=motorway, ref=A5" getaggt. 
> Zugleich befinden sie sich in einer Relation für die A5. Die Vererbung 
> von Tags (alles bis auf "type" wird abwärts vererbt, Way schlägt 
> Relation) ist derzeit, wie Du vermutlich weisst, noch nicht 
> flächendeckend implementiert, das heisst, man kann das 
> "highway=motorway, ref=A5" an den einzelnen Ways noch nicht entfernen, 
> aber eines Tages wird man das können und einfach nur die Relation 
> entsprechend taggen. Das einzelne Wegstück wird dann unter Umständen 
> *gar keine* Tags mehr haben (genauso wie Nodes oft *gar keine* Tags 
> haben, weil sie eben nur als Bausteine für einen Way gebraucht werden).

Ich weiß nicht, ob dieses Streben nach totaler DB-Normalisierung und
Abwesenheit von Redundanz in OSM überhaupt sinnvoll ist.

Ich habe bei etlichen beschriebenen Anwendungen von Relationen so meine
Verständnisprobleme, welchen Zweck sie eigentlich erfüllen sollen, bzw.
welchen Sinn es machen soll, in die entsprechende Generierung manuelle
Arbeit hineinzustecken, anstatt es maschinell zu erledigen.

Das Beispiel der Autobahn ist so ein Mittelding: Ich halte es für extrem
sinnvoll, wenn jedes einzelne Teilstück sein zugehöriges ref-Tag trägt.
Ich kann auch nur halbwegs nachvollziehen, warum man den gesamten
Straßenzug nochmal zusätzlich in eine Relation stecken will. Was wird
dadurch gewonnen? Genausogut kann man doch die API nach Wegelementen mit
"ref=A 5" befragen und erhält im Prinzip dasselbe. Zugegeben, eine
weltweite Abfrage liefert vermutlich mehr als nur die Autobahn in
Karlsruhe, und in der Relation könnten sich auch noch weitere verbundene
Informationen befinden. Da ist nur die Frage: Welchen Sinn hat die
Zuordnung solcher Informationen heute für welche Anwendung?

Ein in meinen Augen nun wirklich absurder Vorschlag ist, alle
Einzelteile einer durchgehenden Straße in eine Relation zu packen, um
dann nur der Relation den durchgehenden Straßennamen zu geben, damit das
Rendering z.B. auf Brücken nicht ständig den Namen wiederholt. Da sage
ich mir: Wenn ein Renderer wirklich will, dass gleiche Straßennamen
schöner verteilt werden, dann wird er so programmiert werden, dass er
die Namensidentität der Einzelteile erkennt und selbst zusammenfaßt. Für
sowas braucht es keine Relation.

Andererseits: Relationen können natürlich auch wertvolle
Zusatzinformationen zu einer Gruppe von Wegstücken hinzufügen,
beispielsweise die Nutzung durch eine Buslinie. Diese Art von Extra-Info
könnte man natürlich auch in Tags packen, das ist aber weitaus weniger
schön, weil es sich doch eher um eine Art Meta-Information handelt.

Stichwort Redundanz: Ich glaube, dass es in OSM Redundanz geben muß,
weil dadurch die Informationen leichter in einem konsistenzen Zustand
gehalten werden können. Wenn ich die Gültigkeit einer Information
lediglich anhand einer einzigen Quelle bewerten muß, dann kann ich die
Info glauben, oder nicht. Geben mir zwei oder mehr Quellen gleichartige
Informationen, dann hebt das die Vertrauensbasis schon erheblich.
Außerdem wird es immer wieder vorkommen, dass gleichartige Dinge
unterschiedlich getaggt werden - Redundanzen helfen dann dabei, zu
ermitteln, was tatsächlich gemeint ist.

Viele Grüße
Sven

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

Re: [Talk-de] Superrelationen

[Tobias Knerr]

Karl Eichwalder schrieb:
>> Vielleicht sollte man es etwas einfacher als "Gruppe" bezeichnen?
> 
> Oder "Verknüpfung"...

Auch wenn es einen gewissen Abschreckungseffekt gibt, ist der Name
sicher nicht das Hauptproblem, sondern schlicht und einfach der
Editorsupport. Ein wenig vielleicht noch die Dokumentation, aber zu
allererst der Editorsupport.

Das m.E. wichtigste hier: Man sieht Relationen nicht, man kann sie nicht
"anfassen". Wahrscheinlich wäre es für viele Anwendungsfälle sogar
besser gewesen, man hätte einfach erlaubt, dass auch Nodes und Ways
Assoziationen (Member) besitzen. Dann könnte ich eine Brücke "malen" und
die Ways "ankleben", statt eine Brückenfläche und Ways in eine
unsichtbare Brückenrelation zu packen. Ich könnte einen Zugang zu einem
Haus hinzufügen, statt den Punkt und das Haus in eine unsichtbare
roadAccess-Relation zu stecken. Und so weiter. Man hätte einfach einen
natürlichen "Anfasser".

Bis zu einem gewissen Grad kann man das natürlich durch Abstraktion im
Editor kompensieren, und manchmal braucht man wirklich echte Relationen,
aber auch bei denen kommt es darauf an, sie sichtbar und anklickbar zu
machen.

Tobias Knerr

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Karl Eichwalder]

Gerrit Lammert  writes:

> Eine Dorfstraße könnte dann so aussehen:
>
> ||
> ||
> 1---234
>
> 1,2,3,4 sind die Knoten, die den Verlauf der Straße angeben.
> Dazu gibt es etwa folgende Relationen mit den Nodes als Member:
> rel(4):highway=noexit
> rel(3):highway=traffic-lights

etc.  Das wird nicht funktionieren.  Das hantieren mit wegstücken finde
ich prima; denn es ist ziemlich direkt von der realität abgemalt und
somit gut nachvollziehbar.  Dafür braucht's keine speziellen eidtoren
und nix.

Ich fand die ehemaligen segmente auch gut ;-)

Das der knoten-ansatz wird spätentens dann extrem kompliziert, wenn
knoten eingefügt oder gelöscht werden...

-- 
Karl Eichwalder

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

Re: [Talk-de] Existenzkrise: Wofür Wege?

[Bernd Wurst]

Hallo.

Am Samstag, 17. Januar 2009 schrieb Gerrit Lammert:
> Ich finde es wahnsinnig umständlich, das ich ständig Wege in einzelne
> Segmente zerlegen muss, weil z.B. nur ein Teil des Weges zur Buslinie
> gehört. Und wenn dann die "Dorfstraße" zur Einbahnstraße wird, muss ich
> oneway=yes bei 20 Segmenten ergänzen.

Naja, wenn die alle in einer Relation sind (müssen sie sein, wenn der Rest 
deiner "Forderung" wahr werden soll), dann kannst du die Realtion gesammelt 
markieren und das oneway=yes damit an alle Wege dran machen.


> muss. Ich denke das Datenmodell geht unaufhaltsam in die Richtung, es
> wird Zeit, das die Editoren und die allgemeine Herangehensweise nachziehen.

Noch nicht.

Bisher sind Relationen ungeordnet. Du hättest also keinen Anhaltspunkt in 
welcher Reihenfolge eine Relation über mehrere Punkte geht sondern müsstest 
mit travelling-salesman-algorithmen arbeiten um den wahrscheinlichsten 
verlauf zu finden. 

mit API 0.6 sollen Realtionen streng geordnet werden und bleiben und damit ist 
dein Konzept prinzipiell denkbar.


> Es gibt nur noch Knoten und Relationen.
> [...]
>
> ||
> ||
> 1---234
>
> 1,2,3,4 sind die Knoten, die den Verlauf der Straße angeben.
> Dazu gibt es etwa folgende Relationen mit den Nodes als Member:
> rel(4):highway=noexit
> rel(3):highway=traffic-lights
> rel(1,2,3,4):highway=residential
> rel(1,2,3,4):name=Dorfstraße
> rel(1,2,3):paved=asphalt
> rel(3,4):paved=cobblestone
> rel(1,2,3):oneway=yes
> rel(2,3):highway=incline
> ...

Du bist dir sicher, dass das einfacher ist als was wir bisher haben? :-)
Ich finde das (ein Attribut pro Relation) einen großen Rückschritt.

Gruß, Bernd

-- 
Wenn man Tiere nicht essen soll, warum sind Sie dann aus Fleisch?
  -  Quelle: http://german-bash.org/action/show/id/106951


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Existenzkrise: Wofür Wege?

[Gerrit Lammert]

Hallo zusammen.

Ich habe mich gerade durch den Superrelationen-Thread gelesen und ich 
denke die ganze Verwirrung und Komplexität bezüglich Relationen beruht 
hauptsächlich auf dem gewachsenen Zustand.

Ich finde es wahnsinnig umständlich, das ich ständig Wege in einzelne 
Segmente zerlegen muss, weil z.B. nur ein Teil des Weges zur Buslinie 
gehört. Und wenn dann die "Dorfstraße" zur Einbahnstraße wird, muss ich 
oneway=yes bei 20 Segmenten ergänzen.

Einiges wird wohl demnächst eh geändert werden (name kommt in die 
Relation und nicht mehr an den Weg etc.), aber ich denke man könnte mal 
langsam darüber nachdenken ob man nicht mit den Altlasten aufräumt um 
die tatsächlich relevanten Teile einfacher gestalten zu können.
Relationen sollten das zentrale Werkzeug in allen Editoren werden, nicht 
wie jetzt etwas, das man im Untermenü mit viel Klick-Aufwand bearbeiten 
muss. Ich denke das Datenmodell geht unaufhaltsam in die Richtung, es 
wird Zeit, das die Editoren und die allgemeine Herangehensweise nachziehen.



Zumindest gedanklich könnte man auch überlegen, das zugrunde liegende 
Datenmodell radikal zu vereinfachen:

Es gibt nur noch Knoten und Relationen.
Immer wenn etwas eine Strecke oder Fläche betrifft (Straßenname, 
Oberfläche, Einbahnstraße...), dann ist das eine Relation, ebenso wie 
jede Eigenschaft einzelner Knoten.
Andere Datenstrukturen (Ways...) gibt es nicht.
Jede Relation hat genau ein Attribut.

Eine Dorfstraße könnte dann so aussehen:

||
||
1---234

1,2,3,4 sind die Knoten, die den Verlauf der Straße angeben.
Dazu gibt es etwa folgende Relationen mit den Nodes als Member:
rel(4):highway=noexit
rel(3):highway=traffic-lights
rel(1,2,3,4):highway=residential
rel(1,2,3,4):name=Dorfstraße
rel(1,2,3):paved=asphalt
rel(3,4):paved=cobblestone
rel(1,2,3):oneway=yes
rel(2,3):highway=incline
...

Der Vorteil ist, das diese Relationen alle unabhängig voneinander sind.
Z.B. hängen nicht mehr alle von der Richtung des zugrunde liegenden 
Weges ab. Im Beispiel ist der erste Abschnitt der Dorfstraße eine 
Einbahnstraße. Wenn diese nun die Richtung ändert, muss ich nicht 
beachten, dass auch das "rel(2,3):highway=incline" seine Richtung ändern 
muss.
Ich ändere einfach "rel(1,2,3):oneway=yes" in "rel(3,2,1):oneway=yes" 
und alles andere bleibt gleich.

Natürlich würde man im Editor einige Hilfsmittel haben, damit man nicht 
ständig alle Knoten einzeln markieren müsste.
Wenn die ganze Straße nun ein maxspeed=30 bekommen soll, könnte ich als 
Benutzer eventuell die Straße (etwa rel(1,2,3,4):highway=residential) 
anklicken und ähnlich wie jetzt ein maxspeed=30 "hinzufügen". 
tatsächlich würde jedoch eine neue Relation
rel(1,2,3,4):maxspeed=30
mit den gleichen Knoten angelegt werden.


Das war etwas jetzt alles etwas aus der Hüfte geschossen und vielleicht 
nicht ganz verständlich, aber ich hoffe, damit etwas zum 
Gedankenaustausch anzuregen, denn die Relationen werden auch im 
bestehenden Datenmodell immer wichtiger und sollten deutlich besser 
bedienbar werden.

Gerrit

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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Norbert Kück]

Hallo,

Frederik Ramm schrieb:

> Diese Definition in dieser simplen Form bedeutet aber, dass es 
> Seegebiete gäbe, die sowohl innerhalb Deutschlands als auch innerhalb 
> Dänemarks liegen, oder? 
Nein, das kommt  nicht vor. So simpel ist das Seerechtsübereinkommen 
natürlich nicht. Das Seerecht sieht vor, dass in Meeresengen von weniger 
als 24 sm Weite die 12 sm nicht gelten, sondern man sich die Fläche (in 
der Regel mittig) teilt (Art. 15 SrUe). Diese Teilung gilt nicht, wenn 
es andere Regelungen gibt. Schönes Beispiel Dollart. Da gibt es drei 
Grenzverläufe: Version NL, Version DE und die Linie des Zusatzabkommens 
zum Ems-Dollart-Vertrag. Wollte ohnehin mal fragen, wie wir das zeichnen 
wollen. ;-) Im Augenblick ist nur die Version NL drin - und die 
scheinbar auch nicht ganz stimmig.

Ich habe nur die Grenze in der Nordsee bearbeitet. Da war alles klar. 
Die Dänen hatten schon ihre 12 sm gezeichnet und einfach die frühere 
Grenze DK/DE verlängert. Daran habe ich angeschlossen. Vergleich mit 
offiziellen Karten bestätigt den Verlauf.

> Ich habe zumindest den Eindruck, dass einige der 
> aktuell eingetragen 12-Seemeilen-Linien näher an Dänemark als an 
> Deutschland liegen. Oder täuscht das?
Du meinst die Ostsee? Nicht meine Rennstrecke, nicht genau angesehen.
Gruß
nk


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

Re: [Talk-de] Superrelationen

[Markus]

Hallo Karl,

>> Relationen sind ein sehr einfaches und logisches Prinzip 
>> Vielleicht sollte man es etwas einfacher als "Gruppe" bezeichnen?

Das *Problem ist das Handling* (nicht die Bezeichnung).

Ich weiss was eine Relation ist.
Aber wie ich damit in JOSM arbeiten kann finde ich nirgends erklärt.
Beim Frankenweg scheitere ich damit kläglich...

Gruss, Markus

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

Re: [Talk-de] addr:via Was: Addresssuche - Zuordn ung der Straße Was: News auf ORS

[Tobias Knerr]

Fabian -Patzi- Patzke schrieb:
> Florian Lohoff schrieb:
>>  addr:via=Brockstraße
>> [...]
>> um die Postalische Adresse von der Anfahrtsaddresse zu trennen.
> 
> Hmm, irgendwie gefällt mir das erheblich besser als das umständliche
> rumbasteln mit Relationen (siehe [1])um eine andere Zufahrtsstraße
> anzugeben. 

Ich halte addr:via für wenig hilfreich. Bei längeren Straßen zu ungenau
(ok, man kann mal wieder die kürzeste Verbindung ermitteln, aber die ist
halt nicht immer richtig), und außerdem, wie du schon gesagt hast:

> eine unbenannte Straße, wie eine z.B. eine Zufahrt (highway=service)

Wenn man eh nicht alles damit abdecken kann und damit die
Relation-Variante auch unterstützen muss, braucht man dann wirklich eine
"abgespeckte" Version auch noch einbauen? Der Aufwand, dauerhaft in
allen Anwendungen zwei Varianten abzudecken, dürfte wohl höher sein, als
eine vernünftige Editor-Unterstützung einzubauen, mit der man z.B. einen
Zugangspunkt aus einer Hausnummer "herausziehen" kann.

Nebenbei hat der Zugang nichts mit der Anschrift zu tun und damit m.E.
kein "addr"-Präfix verdient.

Tobias Knerr

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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Frederik Ramm]

Hallo,

Norbert Kück wrote:
> Staatsgrenze ist eine Linie, die 12 Seemeilen von der sogenannten 
> Basislinie bzw. Niedrigwasserlinie entfernt ist.

Diese Definition in dieser simplen Form bedeutet aber, dass es 
Seegebiete gäbe, die sowohl innerhalb Deutschlands als auch innerhalb 
Dänemarks liegen, oder? Ich habe zumindest den Eindruck, dass einige der 
aktuell eingetragen 12-Seemeilen-Linien näher an Dänemark als an 
Deutschland liegen. Oder täuscht das?

Bye
Frederik

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

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

Re: [Talk-de] addr:via Was: Addresssuche - Zuordn ung der Straße Was: News auf ORS

[Fabian -Patzi- Patzke]

Florian Lohoff schrieb:
> On Sat, Jan 17, 2009 at 12:03:10AM +0100, Gerd v. Egidy wrote:
> Irgendwie fuehle ich die notwendigkeit von:
> 
>   addr:via=Brockstraße
> 
> bzw
> 
>   addr:via=Alt Hammoor
> 
> um die Postalische Adresse von der Anfahrtsaddresse zu trennen.

Hmm, irgendwie gefällt mir das erheblich besser als das umständliche
rumbasteln mit Relationen (siehe [1])um eine andere Zufahrtsstraße
anzugeben. Allerdings hat die Relation noch einen Vorteil, man kann
einen definitiven Punkt bzw. eine unbenannte Straße, wie eine z.B. eine
Zufahrt (highway=service), angeben, über den eine Adresse erreicht
werden kann.
Dennoch halte ich addr:via=* für eine einfache Variante einer
Zufahrtsangabe.

Grüße, Fabian

[1]
http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Giving_hints_about_the_road-access_.28optional.29



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Lars Francke]

Hallo,

> Es ist etwas unübersichtlich, ja. Nur man bekommt da auch Ordnung rein.

das probieren wir ;-)

[12sm-Grenzen von Dir gezeichnet]

Ich habe das letztes mal schon gesagt: Die 3sm-Grenze habe ich damals
gezeichnet und zwar ohne Beachtung irgendwelcher Abstände oder realer
Grenzverläufe. Mein einziges Kriterium war eine durchgehende
Grenzlinie zu schaffen die alle Inseln einschließt. Daher habe ich die
vollkommen willkürlich gewählten Grenzen gestern geloescht (wo sie
nicht mehr in Relationen stecken also hauptsächlich in SH). Die haben
für mich keinerlei historischen Wert.

>> 1) Wir haben uns ja geeinigt, dass es pro Land und Kreis zwei
>> Relationen geben soll. Einmal eine, die die reine Landmasse umfasst
>> und einmal eine, die die administrative Grenze darstellt.
> Wobei nach meiner Ansicht ersteres nice to have ist.

Ich kümmere mich persoenlich auch nicht um die Landmasserelationen.
(Also jetzt im Update kümmere ich mich schon drum aber mich
interessieren sie nicht weiter)

>> 4) Es gibt die Relation Germany (Landmass), mal abgesehen davon, dass
>> ich da einfach den deutschen Namen verwenden würde stellt die nicht
>> nur die Landmasse dar sondern beinhaltet auch die Seegrenzen
> So ganz stimmt das nicht. Die Linie der 12-Meilen-Zone ist NICHT
> Mitglied von Germany(Landmass). Allerdings ist sie in die
> Boundary-Relation #51477 eingebunden worden. Da ist das
>> 5) Da type=boundary abgeschafft wurde
> wohl noch nicht überall angekommen/akzeptiert.

Relation 62781: Germany (Landmass) beinhaltet sehr wohl (zumindest zu
diesem Zeitpunkt und gestern nacht) die 12sm-Grenze:
http://betaplace.emaitie.de/webapps.relation-analyzer/osm.jsp?relationId=62781
Relation 51477 ist einfach noch nicht umgestellt, ich habe die
12sm-Grenze dort nachgetragen.

>> - Die Relation Germany (Landmass) in "Deutschland (Landmasse)"
>> umbenennen
> Würde ich nicht tun. Immerhin ist das etwas von möglicherweise
> internationalem Interesse.

Dafür gibt es name:en - wir haben hier in Deutschland überall im
name-Tag den deutschen Namen.

>> Dafür die alte Deutschlandrelation aktualisieren
>> (http://www.openstreetmap.org/browse/relation/51477)
> Ich halte diese Relation inzwischen für überflüssig und habe sie daher
> bewusst nicht bearbeitet. Aber das sehen andere anders (siehe
> nachträglicher Eintrag der 12-Meilen-Zone).

Oben schriebst Du doch aber, dass Dir die Landmasse-Relationen egal
sind. 51477 ist KEINE Landmasse-Relation sondern eine mit den
Seegrenzen. Warum ist die Dir dann egal? type=boundary ist sie einfach
nur weil noch niemand sie umgestellt hat.

>> - Gibt es noch mehr Relationen oder Wege, die man zusammenfassen
>> koennte? Soweit ich mich erinnere gab es z.B. mindestens drei
>> Deutschland-Relationen
> Das Konzept mit je einer Multipoligon-Relation für den Staat, jedes Land
> und jeden Kreis finde ich perfekt. Zusätzliche Landfläche-Relationen,
> die nach Bedarf Grenzen durch Küstenlinien ersetzen, kann man machen.
> Für mehr sehe ich keinen Bedarf.

Ich auch nicht. Daher meine Frage ob es noch mehr redundante
Relationen gibt, die man zusammenfassen koennte.

>> - multipolygon für Grenzen ist nun vollständig akzeptiert und
>> adoptiert?
> Offenbar nicht - siehe oben. Schade eigentlich.

Der, der immer dagegen genoergelt hatte war ich aber ich habe meine
Meinung geändert nur noch nicht die Relationen umgestellt :)

> Für NI ist der Drops schon weitgehend gelutscht. Da bleibt noch zu
> klären, was man mit den Kreisgrenzen am/im Nordseewasser macht und ob
> man  die 3Meilenzone als historische Grenze konserviert. Wäre schön,
> wenn es (zumindest) unter den Küstenlandbewohnern Konsens gäbe.
> Und dann natürlich die Frage nach DER RICHTIGEN Küstenlinie. Ich
> fürchte, dass jede pauschale/schematische Entscheidung falsch ist. Man
> muss wohl lokal prüfen, bevor man etwas verschlimmbessert oder Daten
> vernichtet.

Ich finde die von Dir gezeichneten Grenzen sehen sehr gut aus. Vielen
Dank für die Arbeit. Ich glaube weiterhin, dass wir beide das gleiche
Ziel verfolgen auch wenn das in den Mails manchmal nicht so klingt ;-)
Ich wollte in NI niemandem in die Arbeit reinpfuschen daher habe ich
die alte Grenze nicht angefasst - aber wie oben erwähnt ist die
komplett an den Haaren herbeigezogen und Deine 12sm Grenze auf jeden
Fall vorzuziehen.

Ah...und es wäre cool wenn wir bei obsolete_boundary bleiben koennten
(für veraltete oder nicht korrekte Grenzen), einfach damit man sie im
OSM-Inspector sehen kann.

Gruß,
Lars

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

Re: [Talk-de] Abbiegereglungen [war: Superrelationen]

[Detlef Reichl]

Am Samstag, den 17.01.2009, 14:15 +0100 schrieb Karl Eichwalder:
> Detlef Reichl  writes:
> 
> > Da gibt es auf der einen Seite mehrere Werte wie no_left_turn,
> > no_right_turn, no_straight_on, ... und auf der anderen Seite heißt es
> > dann in der Erklärung, das eigentlich nur das no_ bzw. das only_ am
> > Anfang relevant wären. Warum reduziert man es dann nicht einfach darauf?
> > -> only_this_way und not_this_way.
> 
> Ja, ungefähr so.  Ich sage nur: noexit=yes ;)  Es ist eigentlich eine
> grundregel, dass man nichts verneintes ins label (attribut-name) tun
> darf.  Deswegen sollten wir das umstellen auf:
> 
> exit=no
> right_turn=no
> straight_on=no
> etc.
> 
Hallo,

das ist für Realtionselemente so aber nicht möglich, da der Wert schon
mit der ID des jeweiligen Wegs belegt ist. Deshalb wurde da aus dem
right_turn=no ein no_right_turn.

Wenn man nur mit "no"-Werten arbeitet bildet man wieder nicht das ab,
was auf dem Schild zu sehen ist, wodurch bei Karten die Schilder
einzeichnen wollen etwas erscheint, das nicht der realen
Straßenbeschilderung entspricht.

Zwei Werte wie von mir vorgeschlagen only_this_way und not_this_way zu
nehmen ist einfach nur eine Arbeitserleichterung. Wenn du eine Kreuzung
hast, von der sechs Wege abzweigen und es ist nur erlaubt ein eine
bestimmt Richtung zu fahren, würde dort ein einzelner only_this_way
reichen, anstatt an fünf Wegen ein not_this_way zu setzen.

Grüßle, detlef


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

Re: [Talk-de] News auf ORS

[Hatto von Hatzfeld]

Marc Schütz wrote:

> Hatto schrieb:
>> Zur vereinfachten Demo habe ich hier einmal den Weg von der echten
>> Position des Adress-Nodes zu der mit der Suche ermittelten Position "Im
>> Weidenbruch 46, Köln" verlinkt:
>>
http://data.giub.uni-bonn.de/openrouteservice/index.php?start=7.0278436,50.979942&end=7.0278114,50.9803202&pref=Shortest&lang=de
> 
> Ich glaube, dein Fall ist eher die Ausnahme. Normalerweise gehört ja ein
> Haus zu der Straße, in der es den Eingang hat. Für Fälle wie diesen sieht
> das Karlsruhe-Schema eine Relation vor (die wahrscheinlich von ORS noch
> nicht ausgewertet würde): 
>
http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Giving_hints_about_the_road-access_.28optional.29
 
In die deutsche Übersetzung dieser Seite habe ich diese Möglichkeit eines
Hinweises auf einen Zugang nicht eingebaut, weil ich den englischen Text
nicht verstanden habe. Vielleicht könnte mir (oder besser noch: im Wiki)
jemand mal erklären, welcher "way" da als "accessto" in die Relation
aufgenommen und ob denn nicht irgendwie auch der Adress-Node eingebaut
werden soll. Oder steht da einfach nur versehentlich "way" statt "node"?
Was für ein und warum überhaupt irgendein Weg als "accessfrom" einzutragen
ist, ist mir im Übrigen auch nicht klar, vor allem wenn es nur eine Zufahrt
gibt.

Im Übrigen kommt es hier in Köln recht oft vor, dass der Zugang zu einem
Haus von einer anderen Straße aus geht - wenn auch meist nur bei Häusern an
einer Straßenecke und damit nur um ein paar Meter daneben und nicht so weit
entfernt wie im oben geschilderten Fall.

Im obigen Fall muss ich übrigens den access-node fast auf dieselbe Stelle
setzen wie den adress-node, was auch sehr wenig intuitiv ist. Da wäre es
m.E. sinnvoller, wenn man die Sache umdreht, d.h. wenn der Suchalgorithmus
immer die nächstliegende Straße nimmt (unabhängig von deren Namen) und man
im Fall, dass der Zugang sich wirklich an einer entfernter liegenden Straße
befindet, dorthin einen access-node setzt. Es ist ja auch nicht so, dass
überall und in allen Ländern die postalische Adresse den Namen der Straße,
an der das jeweilige Gebäude steht, enthält; dies aber wird vom obigen
Suchalgorithmus anscheinend erwartet.

Grüße,
Hatto



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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Lars Francke]

Moin,

und vielen Dank für die Antworten.

>> 1) Wir haben uns ja geeinigt, dass es pro Land und Kreis zwei
>> Relationen geben soll. Einmal eine, die die reine Landmasse umfasst
>> und einmal eine, die die administrative Grenze darstellt.
>
> Ausser, sie sind identisch, dann reicht eine Relation, oder?

Genau, ja. Da habe ich mich unklar ausgedrückt.

>> 5) Da type=boundary abgeschafft wurde koennen Renderer nur noch anhand
>> von admin_level eine Grenze erkennen (zumindest so wie im Moment im
>> Norden getaggt ist).
>
> Eigentlich sollte man das an boundary=administrative erkennen und nicht
> an admin_level!

Okay dann fehlt das Tag an einigen Relationen und ich habe einfach
vergessen, dass es das gab. Und jetzt wo ich ein zweites mal gucke
kann es sein, dass ich mich gestern verguckt habe und die
Landmasse-Dinger tatsächlich mit boundary=administrative getaggt sind.
Dann werde ich nur das loeschen und nicht admin_level. Es gab einen
Vorschlag für das Tagging der Landmasse aber ich finde den nicht mehr.
Daher denke ich mir da einfach was aus und suche mir im Wiki ein
hübsches Plätzchen wo ich das dokumentiere :)

Gruß,
Lars

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

Re: [Talk-de] Superrelationen

[Karl Eichwalder]

Bernd Wurst  writes:

> Aber mal im Ernst. Ich glaube wenn man den Relationen irgendwie den 
> mystischen 
> Ruf nehmen könnte (vielleicht liegt's an dem Namen, mit dem die meisten Leute 
> nichts anfangen können), würden es die meistenm Leute einfach so kapieren. 
> Relationen sind (da bin ich nach wie vor der Überzeugung) ein sehr einfaches 
> und logisches Prinzip und man muss wirklich kein Informatiker sein um das zu 
> kapieren.

Das sehe ich so auch.

> Vielleicht sollte man es etwas einfacher als "Gruppe" bezeichnen?

Oder "Verknüpfung"...

-- 
Karl Eichwalder

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

Re: [Talk-de] Abbiegereglungen [war: Superrelationen]

[Karl Eichwalder]

Detlef Reichl  writes:

> Da gibt es auf der einen Seite mehrere Werte wie no_left_turn,
> no_right_turn, no_straight_on, ... und auf der anderen Seite heißt es
> dann in der Erklärung, das eigentlich nur das no_ bzw. das only_ am
> Anfang relevant wären. Warum reduziert man es dann nicht einfach darauf?
> -> only_this_way und not_this_way.

Ja, ungefähr so.  Ich sage nur: noexit=yes ;)  Es ist eigentlich eine
grundregel, dass man nichts verneintes ins label (attribut-name) tun
darf.  Deswegen sollten wir das umstellen auf:

exit=no
right_turn=no
straight_on=no
etc.

Glücklicherweise habe wir ja schon "oneway=yes" und nicht etwa
no_both_directions...

-- 
Karl Eichwalder

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

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Norbert Kück]

Hallo,

Lars Francke schrieb:
> Ich brauchte für den Kreis Pinneberg grad mal wieder eine
> "funktionierende" Relation und habe dabei gesehen, dass im Norden ganz
> schoenes Chaos herrscht.
Es ist etwas unübersichtlich, ja. Nur man bekommt da auch Ordnung rein.

Anfang des Monats habe ich mich um die Grenzen an der NI-Nordseeküste 
gekümmert, weil für mich die Staats- und Landesgrenze auf der 
Küstenlinie unerträglich war. Grundlage: Die Karte soll die Realität 
zeigen. Durch Quellen belegbare Realität ist:
Staatsgrenze ist eine Linie, die 12 Seemeilen von der sogenannten 
Basislinie bzw. Niedrigwasserlinie entfernt ist.
In der Bundesrepublik Deutschland gibt es kein bundesunmittelbares 
Gebiet (der Bund kann nur EIGENTÜMER von Flächen sein).

Entsprechend habe ich die 12-Meilenzone eingetragen (für die gesamte 
deutsche Nordsee), die Landesgrenze NI ebenfalls darauf verlegt und die 
INFAS-Grenzen, soweit sie Land und Wasser trennen auf admin_level=6 
gesetzt und aus den neuen Relationen Germany und Niedersachsen entfernt. 
Die alten im Wasser verlaufenden Staats- und Kreisgrenzen habe ich von 
obsolete_boundary auf _boundary umgetaggt, um sie weiter unsichtbar für 
Renderer zu halten aber vor schematischen Löschaktionen zu schützen, weil:
Die alte Staatsgrenze ist die Linie der Dreimeilenzone und war bis Ende 
1994 gültig. Man könnte sie als (standardmäßig nicht gerenderte) 
historische Grenze erhalten und sie wird ja in SH streckenweise als 
Begrenzung des Nationalparks Wattenmeer genutzt. Die im Wasser 
verlaufenden alten Kreisgrenzen könnten richtig sein, sollten daher 
zumindest bis zur Klärung erhalten werden.
Damit ist in der gerenderten Karte einiges an Übersichtlichkeit gewonnen 
und objektiv falsche Darstellung beseitigt.
Die alten Relationen mit typ=boundary habe ich bisher nicht angefasst, 
denke aber, dass sie entfallen können und sollten.
Ich bin bewusst in mehreren Schritten vorgegangen (erst Staatsgrenze, 
dann Landesgrenze). Macht mehr Arbeit, aber man braucht nicht so viele 
Dinge gleichzeitig präsent zu haben.

Ich könnte mir vorstellen, dass man so auch die SH-Nordseeküste behandelt.

> 1) Wir haben uns ja geeinigt, dass es pro Land und Kreis zwei
> Relationen geben soll. Einmal eine, die die reine Landmasse umfasst
> und einmal eine, die die administrative Grenze darstellt.
Wobei nach meiner Ansicht ersteres nice to have ist.

> 2) Da die Küstenlinie ja eh gerendert wird und die dort verlaufenden
> Landmasse-Relation soweit ich weiß keine administrative Grenzen sind
> sollten diese nicht extra gerendert werden
Sehe ich auch so. Allerdings zeigen die im WWW verfügbaren 
elektronischen Verwaltungsgrenzen nur die Landflächen an. Ich führen das 
nicht auf den tatsächlichen Grenzverlauf zurück sondern darauf, dass die 
eingesetzte Software (ESRI) zwingend geschlossene Polygone für Flächen 
verlangt und auf den gebräuchlichen analogen Karten die Grenzverläufe im 
Wasser nur unvollständig abgebildet sind.

> 4) Es gibt die Relation Germany (Landmass), mal abgesehen davon, dass
> ich da einfach den deutschen Namen verwenden würde stellt die nicht
> nur die Landmasse dar sondern beinhaltet auch die Seegrenzen
So ganz stimmt das nicht. Die Linie der 12-Meilen-Zone ist NICHT 
Mitglied von Germany(Landmass). Allerdings ist sie in die 
Boundary-Relation #51477 eingebunden worden. Da ist das
> 5) Da type=boundary abgeschafft wurde 
wohl noch nicht überall angekommen/akzeptiert.


> Daher hier was ich tun werde wenn es keine all zu großen Einwände gibt:
Siehe auch oben.
> - Doppelte Küstenliniengrenzen loeschen
Welche ist die besser? Im ersten Schritt reicht maskieren vollkommen aus.

> und die Landmasserelationen
> auf die Küstenlinie legen (laut Frederik und noch einem fleißigen
> Helfer aus Kiel dessen Namen ich grad nicht mehr weiß sind die
> Küstenlinien wahrscheinlich genauer als die INFAS-Daten).
Das kann man so nicht sagen. Im Vergleich mit anderen Karten und 
Luftbildern an der NI-Nordseeküste (insbes. Inseln) liegen die alten 
Küstenlinien teilweise deutlich daneben und die INFAS-Daten erscheinen 
deutlich plausibler. Da müsste man mal die offiziellen Shape-Dateien 
darüber legen, oder die Inseln bei geeignetem Wasserstand ablaufen.

> - Den Landmasse-Relationen und Wegen das admin_level-Tag aberkennen
Ja.

> bzw. durch ein landmass_admin_level o.ä. ersetzen (und ja das ist mehr
> oder weniger ausschließlich für die Renderer)
Eigentlich nicht einmal für die Standard-Render, sondern nur für 
Spezialfälle/Anfragen. Dafür reicht die Relation an sich.

> - Die Relation Germany (Landmass) in "Deutschland (Landmasse)"
> umbenennen 
Würde ich nicht tun. Immerhin ist das etwas von möglicherweise 
internationalem Interesse.

> und die Seegrenzen loeschen. 
Siehe oben.

> Dafür die alte Deutschlandrelation aktualisieren
> (http://www.openstreetmap.org/browse/relation/51477)
Ich halte diese Relation inzwischen für überflüssig und habe sie daher 
bewusst nicht bearbeitet. Aber das sehen andere anders (

Re: [Talk-de] Addresssuche - Zuordnung der Straße Wa s: News auf ORS

[Florian Lohoff]

On Sat, Jan 17, 2009 at 12:03:10AM +0100, Gerd v. Egidy wrote:
> Vielleicht muß man das dynamisch machen. 500m in der Stadt sind eigentlich 
> schon viel zu viel. Worauf es ja ankommt ist, daß man ein Haus nicht einer 
> völlig falschen Straße zuordnet. Daher sollte die nähste Straße wirklich 
> signifikant die nähste sein.
> 
> Wie wäre es damit:
> 
> In alle Richtungen rund um den Node (oder den Schwerpunkt wenn building aus 
> mehreren Nodes) die nähsten Straßen herausfinden. Es gilt jeweils die 
> kürzeste 
> Distanz zu einer Straße.
> 
> Abstand Hausnummer <-> nächstgelegene Straße: d1
> Abstand Hausnummer <-> zweitnächstgelegene Straße: d2
> 
> Wenn d2 / d1 > x dann die Hausnummer der nächstgelegenen Straße zuordnen, 
> ansonsten kein Treffer.
> 
> Für x könnte man jetzt z.B. 125% nehmen und damit wäre dann klar, daß die 
> nähste Straße schon sigifikant näher sein muß als die zweitnähste.

Trivialloesung:

Mit addr:street tag 800-1000m - ohne addr:street 100m - fertig ist die
laube. Ich setze eigentlich ueberall ein addr:street tag um ein ganz
explizit zu machen und mir keine Gedanken ueber das Node Placement
machen zu muessen - Den setze ich nach "gut duenken" mittig auf das
Haus. Problematisch wird ja sonst wenn jemand ohne nachdenken Straßen
verschiebt - und wenn es nur um 12cm sind - Mit einem mal stimmen die
adressen nicht mehr -> doof !

Das ganze im ORS find ich sowieso noch nicht so gluecklich geloest. Im
moment wird die addresse auf die originaere Straße zurueckgefuehrt. d.h.
das routing fuehrt mich an diesen Punkt.

Schoener waere IMHO wenn wirklich der punkt der Addresse gezeigt werden
wuerde und auch ein routing moeglichst dicht an diesen Punkt.

Das wuerde/koennte automatisch dazu fuehre das auch Hofzufahrten in der
Wegbeschreibung auftauchen wenn sie denn naeher an die Addresse fuehren
was derzeit nicht der fall ist - weil auf der zugeordneten Straße schon
das ziel erreicht ist.

Noch fieser sind eigentlich faelle ich die ich hier regelmaessig habe wo
zwar die Addresse eine Hausnummer auf Straße A ist - Das Haus aber
nur/hauptsaechlich über Straße B erreichbar. Meistens sind das nur
50-100m um die Ecke aber fuer jemanden dem im Dunkeln vom Navi gesagt
bekommt - "Sie haben das Ziel erreicht" doch reichlich verwirrend.

Hier 2 Beispiele:

http://tools.geofabrik.de/osmi/?view=addresses&lon=8.36582&lat=51.78390&zoom=17

Die Hausnummer 250 (Bokeler Straße) hat keine zufahrt von der Bokeler
Straße sondern nur von der Brockstraße.

Hausnummer 259 (Bokeler Straße) hat zwar eine zufahrt von der Bokeler
Straße (durch den Wald) die aber niemand benutzt weil zugewachsen und
auch eher was fuer leute die ihrem Auto viel zumuten/zutrauen. D.h.
alle benutzen den weg via "Alt Hammoor" der besser und auch breiter
ausgebaut ist.

http://tools.geofabrik.de/osmi/?view=addresses&lon=8.36551&lat=51.77654&zoom=18

Hammoor Hausnummer 46 hat keine zufahrt vom Hammoor - Da ist eine große
Hecke so das man das Haus nicht einmal sieht. Zufahrt nur via Alt
Hammoor d.h. 50m um die Ecke ...

Irgendwie fuehle ich die notwendigkeit von:

addr:via=Brockstraße

bzw

addr:via=Alt Hammoor

um die Postalische Adresse von der Anfahrtsaddresse zu trennen.

Flo
-- 
Florian Lohoff  f...@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


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

Re: [Talk-de] (Abbiege)reglungen [war: Superrelationen] - JOSM

[Jan Tappenbeck]

Moin !

bei der ganzen Diskussion um dieses Thema sollten wir nicht vergessen, 
dass das derzeitige Eingabe System, bezogen auf JOSM da ich andere 
Editoren nicht kenne, sehr "abschreckend" ist. Besonders für die 
Anfänger !!!

Ich würde es begrüßen, wenn der Erfassungsdialog entsprechende Wizards 
oder Eingabeformulare für die verschiedenen Relationsformen 
bereitstellen würde. Ideen hierzu habe ich an anderer Stelle schon 
einmal gepostet.

Darüberhinaus müßte in JOSM die verschiedenen Realationen besser 
darstellen können - um zu sehen was schon vorhanden ist. Derzeit wird 
dieses nicht visualisiert und gilt besonders für die Abbiegerelationen.

Eine Idee wäre zum Beispiel in JOSM Ansichten RELATIONEN / POI 
einzurichten. Dann kann man themenbezogen sich die Dinge ansehen und es 
ist nicht alles so überladen letztendlich.

Gruß Jan :-)


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

Re: [Talk-de] [tagging] Feature Proposal - RFC - (Exclusive usage rights)

[Hatto von Hatzfeld]

Nop wrote:

> Es herrscht eine grundsätzlche Uneinigkeit über die Bedeutung von
> access=designated (und die davon abgeleitete Verwendung von
> highway=footway, highway=cycleway). 
> 
> Dieses Proposal will den Gegensatz auflösen [...]: 
>
http://wiki.openstreetmap.org/wiki/Proposed_features/Exclusive_usage_rights.

Könnte es sein, dass die Darstellung unter "B: mixed interpretation" genau
vertauscht ist? Ich jedenfalls habe "highway=footway" immer als für
Fahrräder verboten angesehen, soweit kein "bicycle=yes" vorhanden ist,
während "highway=path" und folglich auch "highway=path; foot=designated"
mir keinerlei Aussage über Fahrräder zu machen scheint.

Im Übrigen habe ich den Verdacht, dass vom Wortverständnis "path" versus
"footway" für viele ein "path" generell etwas weniger Formelles (Geplantes)
darstellt als ein footway oder cycleway und sie vielleicht daher den neuen
Tag "path" befürwortet haben (z.B. für Trampelpfade, Gebirgswege etc.).

Gruß,
Hatto



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

[Talk-de] Haltestellen taggen - Neuer Vorschlag (WAR: Re: ÖPNV Haltestellenverzeichnis)

[Gerrit Lammert]

Hi zusammen.

Tobias Wendorff wrote:
 > [Bushaltestellen Taggen]
> Frederik Ramm hatte vorgeschlagen für Berechnungen einfach das
> Lot zu fällen und eine direkte Luftlinie zu gehen. Das kann
> natürlich auch zu Problemen kommen, funktioniert aber in den
> meisten Fällen.

Nur mal so ins unreine, da mich die Frage auch beschäftigt, wie 
Haltestellen denn nun getaggt werden sollen:
Wie wäre es, wenn man
a) für jede physische Haltestelle einen Node "platform" an jede Stelle 
der Straße machen, wo der Bus hält. Dieser Node wird in die 
Bus-Route-Relation aufgenommen.
b) weitere dazugehörige Orte (Wartehäusschen, Haltestellenschild, ...) 
ebenfalls eintragen
c) Das alles in eine Relation zur Haltestelle machen.

Beispiele:

Bus
===
|
A
-B-|---<--
---|-C->--
| D
|

Hier haben wir eine vierspurige Straße (waagerecht) und eine normale 
Straße (senkrecht). An ihr gibt es 4 Stellen wo Busse halten. Alle diese 
Haltestellen gehören zu der Haltestelle "Rathaus". Getaggt wird so:

A Haltestelle auf beiden Seiten der Straße
{highway=platform, direction=both}
B Haltestelle nur rechts
{highway=platform, direction=lane}
C Haltestelle nur rechts
{highway=platform, direction=lane}
D Wartehäusschen
{amenity=shelter, relation=bus_stop}

Und in der Relation dann
type=conglomerate
conglomerate=bus_stop
name=Rathaus
operator=...
usw.

Natürlich könnten noch weitere Tags dran, wie z.B. welche Linien halten etc.

Platform befindet sich auf dem Weg, was für Routenberechnung etc 
sinnvoll ist. Durch geographisch korrektes taggen von Wartehäuschen, 
Haltestellenschild etc ist trotzdem auf der Karte sofort ersichtlich wo 
genau was ist.
Der Haltestellenname würde einfach im Schwerpunkt der Relation-Members 
gerendert werden.
So kann man praktisch beliebig erweitern und der Zusammenhang 
untereinander ist durch die Relation gewährleistet.

Bahn

Dieses Schema würde auch mit den Problemen bei Bahnhöfen aufräumen:
### = Gleis
=== = Bahnsteig
! = Fußgängerbrücke/-tunnel

!
---o!-
|   !|
###|##1!|#
|===!|
###|##2!|#
###|##3!|#
|===!|
###|##4#|#
||

o ist die Bahnhofshalle
{amenity=bus_station, building=yes, ...}
1-4 sind die Gleise. Diese Nodes werden in die Train-Routes aufgenommen.
{railyway=platform, ref=x, ...}
usw.

Alles kommt wieder in eine Relation mit Namen und so weiter.

Wenn ihr das jetzt nicht zerreißt, mach ich daraus mal ein Proposal...
Für bessere Namensvorschläge (besonders bei "conglomerate" wäre ich 
dankbar,-)


Gerrit

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

[Talk-de] Nachrichten von Gary68

[Gary68]

Hallo alle zusammen,

anbei die Nachrichten von Gary68...

NEU DIESE WOCHE: Alle bugs als GPX. Etwa 80.000 bugs. Nicht alle aus
Deutschland, aber die meisten.

Alle bugs als GPX file
http://www.gary68.de/osm/qa/gpx/allbugs.gpx  
ODER ein Extrakt daraus:
http://www.gary68.de/osm/qa/gpx/extract.htm 
ODER als PERMALINK
http://www.gary68.de/osm/qa/gpx/extract.php?left=7&right=8&top=49&bottom=48 

Evtl. werden noch kleine Verbesserungsvorschläge eingebaut...
- Sortierung
- Position und Radius (Zoom) als Eingabemöglichkeit.

Mapping Quality
http://wiki.openstreetmap.org/wiki/Mapping_Quality 
Version 2.0 des Programms veröffentlicht.


MotorwayCheck
http://wiki.openstreetmap.org/wiki/MotorwayCheck 


OSB Reports
http://wiki.openstreetmap.org/wiki/OSB_Reports 
KLeine Aktion zur Reduktion der Bugs gestartet, aber das war wohl mehr
ein Tropen auf den heißen Stein...

Osmdiff 
http://wiki.openstreetmap.org/wiki/Osmdiff_reports 
ACHTUNG: Ich stelle die Datenbeschaffung um auf die Geofabrik. Manche
Städte haben einfach zu viele Details mittlerweile. Daher wird es diese
und ggf. teilweise nächste Woche etwas wüst aussehen. Dafür kann ich
dann beliebig große Bereiche darstellen.


SomeChecks (Area)
http://wiki.openstreetmap.org/wiki/SomeChecks 

SomeChecks (double nodes in ways)
http://wiki.openstreetmap.org/wiki/SomeChecks 


Unmapped Places
http://wiki.openstreetmap.org/wiki/Unkartografiert 


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


Checks sind diese Woche nicht so viele gelaufen :-( Aber das kommt
wieder.

Ciao

Gerhard 
Gary68



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

Re: [Talk-de] Abbiegereglungen [war: Superrelationen]

[Bernd Wurst]

Hallo.

Am Samstag, 17. Januar 2009 schrieb Detlef Reichl:
> Dafür
> würde es in der von mir beschriebenen Weise ja auch reichen.

Du sagtest "not_this_way", aber in Wahrheit sollen die Router doch auf "no_*" 
prüfen. ;-))

Ich denke diese kleine Pingeligkeit macht einen entscheidenden Unterschied. 
Dieses Proposal suggeriert, man solle da halt irgendwas umgangssprachliches 
reinschreiben. Das wird aber nicht funktionieren.

Aber kommt Zeit, kommt Rat. Wir werden sehen. :)

Gruß, Bernd

-- 
If Bill Gates had a penny for every time Windows crashed...
...oh wait, he does.  -  Quelle unbekannt


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Superrelationen

[Bernd Wurst]

Hallo.

Am Samstag, 17. Januar 2009 schrieb Frederik Ramm:
> > Vielleicht sollte man es etwas einfacher als "Gruppe" bezeichnen?
> Damit deckst Du aber nur einen kleinen Teil der moeglichen Nutzungen ab,
> denn Relationen koennen auch benutzt werden, um abstrakte Einheiten aus
> der Realitaet zu modellieren: "Diese Relation repraesentiert den
> Kreisverband Karlsruhe der Arbeiterwohlfahrt". 

Dein Beispiel ist aber IMHO auch etwas, was jemand als "Gruppierung von 
Objekten" verstehen würde, oder? ;-)


> Oder beispielsweise die 
> kuerzlich beschriebene Brueckenrelation (Member sind Ways, die die
> Bruecke selbst beschreiben, Ways, die drunter durch gehen, und
> solche,die oben drüber gehen) - das kann man kaum noch eine "Gruppe"
> nennen. 

Abseits dessen, dass ich nicht glaube dass sich solche eine Idee wirklich in 
der Breite durchsetzt, gebe ich dir recht.
Aber siehe unten.


> Der Begriff "Gruppe" suggeriert, dass hier mehrere gleichartige Objekte
> zusammengefasst werden, und das ist halt nur ein Teilaspekt.

Richtig, aber der wichtigste.
Selbstverständlich kann man mit dem Realtion-Typ extrem vielfältige und 
beliebig umständliche Konstruktionen produzieren.
Das Problem das ich hier jetzt grade sehe ist doch aber, dass ein extrem 
großer Teil der Leute von vorneherein sehr allergisch auf das Wort "Relation" 
reagiert, weil "das kapiert keiner".

Daher wäre es (nicht im technischen Sinne sondern nur im Dialog mit den 
Betroffenen) eine Option, nur einen Teilaspekt, nur eine begrenzte Anwendung 
von Relationen zu erklären und zu sagen: So geht's, da gibst du das ein, dort 
dieses und dann hast du einen Wanderweg eingetragen.

Für die Dinge, die man jetzt aktuell in der Masse braucht, reicht der 
Gruppenbegriff IMHO noch aus.

Komplexere Relationen-Konstrukte sind als Forschungsobjekt brauchbar, werden 
aber erst von der genannten Zielgruppe genutzt werden (können), wenn es eine 
Editor-Unterstützung dafür gibt.


> > 1. Einfache Gruppe von Objekten:
> > Fiktives Beispiel: Alle Kaugummiautomaten in Baden-Würrtemberg.
> > Eine sinnfreie Relation aber technisch möglich und wurde mit vielen
> > Objekt-Arten bereits so gemacht.
> Ja, und die meisten davon gehören IMHO hochkant wieder rausgeschmissen,
> weil sie unnützes Exempel deutschen (?) Ordnungswahns sind. Dass etwas
> ein Kaugummiautomat ist und dass er in Ba-Wue ist, das findet man auch
> ohne Relation heraus.

Das meine ich mit "Eine sinnfreie Relation". Ich bin da durchaus deiner 
Meinung. Diese Verwendung zeigt aber, welch einfacher Datentyp eine Relation 
eigentlich ist.


> > 3. Flächenbegrenzungen ("Multipolygone"):
> Mittlerweile auf Platz 2 in der Nutzungshäufigkeit verdränkt. Wird
> dringend gebraucht, ist aber eigentlich natürlich nur eine faule Ausrede
> dafür, dass wir keinen richtigen grundlegenden "Polygon"-Datentyp haben.
> Eine Multipolygon-Relation ist m.E. "logisch" eine Ebene unter den
> anderen Relationen angesiedelt, auf gleicher Hoehe wie Nodes und Ways.

Da JOSM das jetzt schon im Mappaint unterstützt, gehe ich stark davon aus, 
dass es nur noch eine Frage der Zeit ist, bis das in einer extra-Funktion, 
nicht im normalen Relations-Editor, bearbeitet werden kann. Dann werden die 
Leute das als separaten Datentyp akzeptieren, völlig egal wie es letztlich 
gespeichert wird.

Was den Polygon-Datentyp angeht: Du wirst immer die Möglichkeit brauchen, so 
etwas aus mehreren gegebenen Polygonen oder Linien zusammen zu setzen. Denn 
eine Multipolygon-Relation die den kompletten Schwarzwald abdeckt, will 
keiner hoch- und runterladen, ein Polygon das die Außengrenzen von Bayern en 
detail darstellt ebenso.
Ich finde die Speicherung in einer Relation eigentlich ganz angenehm und denke 
nicht, dass das dringend verändert werden müsste.

Gruß, Bernd

-- 
Faulheit ist die Mutter aller Erfindungen.


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Abbiegereglungen [war: Superrelationen]

[Detlef Reichl]

Am Samstag, den 17.01.2009, 12:37 +0100 schrieb Bernd Wurst:
> Hallo.
> 
> Am Samstag, 17. Januar 2009 schrieb Detlef Reichl:
> > die Abbiegeregelungen sind vom Prinzip her ja ganz einfach, nur meiner
> > Meinung nach viel zu kompliziert umgesetzt.
> >
> > Da gibt es auf der einen Seite mehrere Werte wie no_left_turn,
> > no_right_turn, no_straight_on, ... und auf der anderen Seite heißt es
> > dann in der Erklärung, das eigentlich nur das no_ bzw. das only_ am
> > Anfang relevant wären. Warum reduziert man es dann nicht einfach darauf?
> > -> only_this_way und not_this_way.
> >
> > Das würde es für die meisten Mapper einfacher machen das System zu
> > verstehen.
> 
> Genau das.
> Ich gehe nicht davon aus, dass irgend jemand in einer Endanwendung das 
> aktuelle Schema auswertet oder dies fest vor hat. Es ist einfach zu 
> unlogisch.
> 
Hallo,

ich kann mir gut vorstellen, das es von Routern ausgewertet wird. Dafür
würde es in der von mir beschriebenen Weise ja auch reichen.

Wie Frederik aber schon schrieb, ist der Gedanke dahinter wohl die
Möglichkeit zu haben, das passende Schild in die Karte rendern zu
lassen. Hierfür die Abbildung der Schilder zu nehmen fände ich
allerdings mehr als unhandlich, da die Schilder um sie überhaupt zu
verstehen in die passende Richtung gedreht werden müssten. Leute denen
es am Räumlichen Vorstellungsvermögen fehlt, müssten dann allerdings die
Karte drehen um das Schild richtig erfassen zu können. Bei einer Karte
OK, bei den meisten Monitoren aber eher schwierig ;-).

Es wäre meiner Meinung nach weit aus sinnvoller einfach Pfeile über die
Kreuzungen laufen zu lassen die darstellen, wie man fahren darf. Das
lässt sich gut erkennen, egal aus welcher Richtung man schaut und ist
wiederum mit "meinem" System realisierbar.

Grüßle, detlef


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

Re: [Talk-de] Superrelationen

[Bernd Wurst]

Hallo.

Am Samstag, 17. Januar 2009 schrieb Ekkehart:
> Naja solange wir nur von einfachen Relationen reden, die ein paar Ways
> gruppieren, stimme ich Dir ja auch zu. Aber wenn da drüber nochmal eine
> Weggruppenrelation ist und darüber nochmal eine Netzwerkrelation und
> vielleicht noch eine Kategorierelation (damit alles schön aufgeräumt
> ist) und in Tags werden von ganz oben vererbt, außer in irgendeiner
> Hierarchiestufe steht schon ein Wert: Da sag ich: Als Informatiker
> verstehe ich die Struktur aber ohne exzellente Softwareunterstützung
> verliere ich den Überblick, was wo definiert ist, welcher Wert woher
> kommt und was am Schluß im Renderer genau dabei rauskommt.

Eigentlich kennt jeder eine Gruppe (z.B. Fußball-Mannschaft) die als ganzes 
wieder in einer Gruppe (Fußball-Abteilung) ist und diese ist dann wieder in 
einer Gruppe (Sportverein).

Man muss ja nicht alles mit allen Mitgliedern im Kopf haben, das ist klar.

Dass wir hier ohne viel besere Editorunterstützung mehr Chaos produzieren als 
es nützt ist auch klar. 
Aber am reinen Verständnis würde ich sagen sollte es nicht liegen, auch bei 
Nicht-Informatikern.

Das Problem kann dann entstehen, wenn der Editor eben da nicht 
genug "intelligent" macht und daher jeder versucht, alle Beziehungen im Kopf 
zu durchdenken. Das wird komplex. :)


> Ich sehe das wichtigste Mittel, solche komplexen Dinge den Leuten nahe
> zu bringen in einer guten Editorsoftware, die es übersichtlich
> aufbereitet, die wichtigsten Probleme von vornherein vermeidet und Dir
> hilft, die Übersicht zu bewahren.

Genau. Ich sehe das Ziel in diversen Plugins, die jeweils eine Art Relation 
(siehe vorige Mail) total simpel verwalten kann. Keinen heiligen 
Über-Relations-Editor, der alles kann was Relations können und daher wieder 
zu komplex wird.


> Problem1: "Unerwünschte Vererbung"
> - wenn ich jetzt die Vererbung einfach flächendeckend einschalte, erbt
> jeder Punkt und jeder Way von einer der Relationen alle tags, also auch
> den Namen
> - somit erscheint auf der Karte "Europäischer Fernwanderweg E3" auf
> jedem Pfad, Feldweg, Wegweiser, Parkplatz, Grillhütte usw.

Der Typ "route" sollte seinen Namen per Definition nicht vererben.
Ich denke genau wie man bei diversen highway-Typen bisher blind davon ausgeht, 
dass jeder wissen muss ob darauf ein Auto fahren kann, so wird es auch bei 
Realtions einige bekannte Typen geben, bei denen solche Sachen einfach 
Konvention sind.
Vermutlich muss eine route-Relation gar nichts vererben.


> Problem2: "Mehrfachvererbung"
> - wenn ein way oder node zu mehreren Relationen gehört, was ja ganz
> normal ist für Wanderwege, dann ist es zufällig, welches Tag er bekommt.
> Bei Relationen ist keine Reihenfolge definiert und die Relation die von
> einer Clientsoftware zufällig als erstes ausgewertet wird, vererbt ein
> Tag, jede weitere findet es schon ausgefüllt vor und vererbt nicht.
> - die Auswertungsreihenfolge ist zufällig und kann bei jedem Lauf eines
> Renderers bzw. bei jedem Datenbankaufruf anders sein. D.h. die
> Eigenschaften der Elemente springen willkürlich zwischen den Tags
> verschiedener Relationen hin- und her.

Wie gesagt, Vererbung macht bei vielen Relations-Typen wenig Sinn. Bei manchen 
schon. Aber bei denen erwarte ich, dass es entweder mit korrekten Daten zu 
keinen Mehrfachvererbungen kommen kann (aufgrund einer passenden Konvention 
bzw. Spezifikation im Wiki) oder dass es z.B. zu einem 
ref="B 14 / B 27" aufgelöst wird, wenn ein Stückchen Straße zu zwei 
Bundesstraßen gehört.


> Und diese Problem treten in einer _korrekt_ verknüpften Hierarchie auf.
> Von daher erwarte ich das eine oder andere Chaos. :-)

Klar. 
Wie gesagt, langfristig erwarte ich spezialisierte Editor-Plugins, die so 
etwas koordinieren können.

Gruß, Bernd

-- 
Es vergeht kein Tag an dem ich nicht alles wieder infrage stelle.
  -  André Gide (frz. Schriftsteller)


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Superrelationen

[Frederik Ramm]

Hallo Klaus bzw. Ekkehart bzw. Nop (vielleicht entscheidest Du Dich mal 
für eins, das würde die Sache vereinfachen),

> Und noch ein ganz einfaches Beispiel zu den Problemen der Vererbung:
> - Wanderwege werden durch Relationen dargestellt

Bei Route-Relationen grundsätzlich keine Vererbung. Routen sind keine 
"Superways". Vererbung sehe ich nur bei den echten Superways, also da, 
wo wir *eigentlich* auch einen kompletten Way nehmen koennen, dies aber 
aus Pragmatismus nicht tun.

Gedanklich muss man das denke ich so trennen: Die Superways (oder 
"collected ways") haben konstitutiven Charakter. Umgangssprachlich würde 
ich sagen: In dem Moment, in dem die Strasse gebaut wird, ist schon 
klar, dass sie zu der Superrelation "A5" gehören wird, und das wird sich 
auch nie (oder nur durch aufwendige bürokratische Verfahren) ändern. Man 
sagt nicht: Hier ist eine Strasse, und übrigens ist es die A5 - das hier 
*ist* die A5, das ist ein Wesensaspekt der Strasse.

Eine Route hat attributiven Charakter: "Hier ist eine Straße, und 
übrigens führt auch der Westerwald-Wanderweg hier lang". Das war nicht 
klar, als die Straße gebaut wurde, und das kann sich auch von heute auf 
morgen ändern. Es ist kein Wesensaspekt der Strasse, dass der 
Westerwald-Wanderweg über sie führt.

Ich weiss, dass diese meine Unterscheidung nicht vollumfänglich dem 
derzeitigen Gebrauch entspricht (auch konstitutive Relationen werden 
z.T. als "Route" getaggt), aber das kriegt man schon hin mit der Zeit.

Bye
Frederik

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

Re: [Talk-de] Abbiegereglungen [war: Superrelationen]

[Bernd Wurst]

Hallo.

Am Samstag, 17. Januar 2009 schrieb Detlef Reichl:
> die Abbiegeregelungen sind vom Prinzip her ja ganz einfach, nur meiner
> Meinung nach viel zu kompliziert umgesetzt.
>
> Da gibt es auf der einen Seite mehrere Werte wie no_left_turn,
> no_right_turn, no_straight_on, ... und auf der anderen Seite heißt es
> dann in der Erklärung, das eigentlich nur das no_ bzw. das only_ am
> Anfang relevant wären. Warum reduziert man es dann nicht einfach darauf?
> -> only_this_way und not_this_way.
>
> Das würde es für die meisten Mapper einfacher machen das System zu
> verstehen.

Genau das.
Ich gehe nicht davon aus, dass irgend jemand in einer Endanwendung das 
aktuelle Schema auswertet oder dies fest vor hat. Es ist einfach zu 
unlogisch.

Ebenfalls unlogisch ist die Unterscheidung unterschiedlicher 
Verkehrsteilnehmer. 

Ich hoffe (wie gesagt) noch auf einen Vorschlag, der das ganze logischer und 
konsistent umsetzt. :)

Gruß, Bernd

-- 
Fachbegriffe der Informatik (#239): MacOS X
   Unix für Weicheier.
(Manfred Worm Schäfer)


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Abbiegereglungen [war: Superrelationen]

[Frederik Ramm]

Hallo,

Detlef Reichl wrote:
> Da gibt es auf der einen Seite mehrere Werte wie no_left_turn,
> no_right_turn, no_straight_on, ... und auf der anderen Seite heißt es
> dann in der Erklärung, das eigentlich nur das no_ bzw. das only_ am
> Anfang relevant wären. Warum reduziert man es dann nicht einfach darauf?
> -> only_this_way und not_this_way.

Eine reizvolle Idee, aber es gibt einen Grund für das aktuelle 
Verfahren. Das mit dem "no_left_turn" kommt daher, dass die Leute sich 
ueberlegt haben, wie man das auf der Karte darstellt (mit so einem 
typischen Verkehrszeichen eben). Nun könnte man denken: Das sieht der 
Rechner doch, da ist eine Strasse mit only-this-way in eine Strasse, die 
im Winkel 78.1° nach links abgeht, klare Sache, da muss so ein weisser 
Linkspfeil auf blauem Grund hin. - Leider ist das in der Realität eine 
komplizierte Sache, auch wegen der Ungenauigkeit unserer Datenerfassung. 
Da kann es sein, dass wir eine Kreuzung im Datenbestand haben, wo es 
nach Datenlage 35° links ab geht, und in der Realität ist dort ein "only 
left turn"-Verkehrszeichen, und an einer anderen Kreuzung mit 
identischer Datenlage ist in der Realität ein "only 
geradeaus"-Verkehrszeichen! Das hängt zum Teil auch davon ab, wie die 
weissen Linien auf die Strasse gemalt sind und nicht (nur), wie der 
Asphalt verläuft. Nun wäre es reichlich doof, wenn unser Renderer (so er 
denn mal Verkehrszeichen an solchen Kreuzungen anzeigt!) hier dann ein 
Zeichen "synthetisieren" würde, das nicht dem entspricht, was man sieht, 
wenn man an die Kreuzung kommt. Daher die explizite Nennung. Das ist 
sozusagen "tagging für den Renderer" ;-)

Bye
Frederik



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

Re: [Talk-de] Superrelationen

[Frederik Ramm]

Hallo,

> Vielleicht sollte man es etwas einfacher als "Gruppe" bezeichnen?

Damit deckst Du aber nur einen kleinen Teil der moeglichen Nutzungen ab, 
denn Relationen koennen auch benutzt werden, um abstrakte Einheiten aus 
der Realitaet zu modellieren: "Diese Relation repraesentiert den 
Kreisverband Karlsruhe der Arbeiterwohlfahrt". Oder beispielsweise die 
kuerzlich beschriebene Brueckenrelation (Member sind Ways, die die 
Bruecke selbst beschreiben, Ways, die drunter durch gehen, und 
solche,die oben drüber gehen) - das kann man kaum noch eine "Gruppe" 
nennen. Relationen können auch eingesetzt werden, um ein Teilstück eines 
Ways zu beschreiben, oder nimm z.B. die "site"-Relation, mit der Du 
sagen kannst "hier ist ein Gelände, darauf stehen diese Häuser, das da 
ist der Zaun drumrum und an der Stelle ist die Zufahrt für den 
Lieferverkehr".

Der Begriff "Gruppe" suggeriert, dass hier mehrere gleichartige Objekte 
zusammengefasst werden, und das ist halt nur ein Teilaspekt.

> 1. Einfache Gruppe von Objekten:
> Fiktives Beispiel: Alle Kaugummiautomaten in Baden-Würrtemberg. 
> Eine sinnfreie Relation aber technisch möglich und wurde mit vielen 
> Objekt-Arten bereits so gemacht.

Ja, und die meisten davon gehören IMHO hochkant wieder rausgeschmissen, 
weil sie unnützes Exempel deutschen (?) Ordnungswahns sind. Dass etwas 
ein Kaugummiautomat ist und dass er in Ba-Wue ist, das findet man auch 
ohne Relation heraus.

> 2. Zusammenfassung mehrerer Einzelstücke zu einem Ganzen:

Das ist wohl derzeit der Hauptnutzen, ja.

> 3. Flächenbegrenzungen ("Multipolygone"):

Mittlerweile auf Platz 2 in der Nutzungshäufigkeit verdränkt. Wird 
dringend gebraucht, ist aber eigentlich natürlich nur eine faule Ausrede 
dafür, dass wir keinen richtigen grundlegenden "Polygon"-Datentyp haben. 
Eine Multipolygon-Relation ist m.E. "logisch" eine Ebene unter den 
anderen Relationen angesiedelt, auf gleicher Hoehe wie Nodes und Ways.

Bye
Frederik


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

Re: [Talk-de] Superrelationen

[Ekkehart]

Hallo!


Bernd Wurst schrieb:
> Aber mal im Ernst. Ich glaube wenn man den Relationen irgendwie den 
> mystischen 
> Ruf nehmen könnte (vielleicht liegt's an dem Namen, mit dem die meisten Leute 
> nichts anfangen können), würden es die meistenm Leute einfach so kapieren. 
> Relationen sind (da bin ich nach wie vor der Überzeugung) ein sehr einfaches 
> und logisches Prinzip und man muss wirklich kein Informatiker sein um das zu 
> kapieren.
> 
> Vielleicht sollte man es etwas einfacher als "Gruppe" bezeichnen?

Naja solange wir nur von einfachen Relationen reden, die ein paar Ways 
gruppieren, stimme ich Dir ja auch zu. Aber wenn da drüber nochmal eine 
Weggruppenrelation ist und darüber nochmal eine Netzwerkrelation und 
vielleicht noch eine Kategorierelation (damit alles schön aufgeräumt 
ist) und in Tags werden von ganz oben vererbt, außer in irgendeiner 
Hierarchiestufe steht schon ein Wert: Da sag ich: Als Informatiker 
verstehe ich die Struktur aber ohne exzellente Softwareunterstützung 
verliere ich den Überblick, was wo definiert ist, welcher Wert woher 
kommt und was am Schluß im Renderer genau dabei rauskommt.

Ich sehe das wichtigste Mittel, solche komplexen Dinge den Leuten nahe 
zu bringen in einer guten Editorsoftware, die es übersichtlich 
aufbereitet, die wichtigsten Probleme von vornherein vermeidet und Dir 
hilft, die Übersicht zu bewahren.


Und noch ein ganz einfaches Beispiel zu den Problemen der Vererbung:
- Wanderwege werden durch Relationen dargestellt
- Ein Way kann zu mehreren Wanderwegen gehören
- eine Relation sollte einen Namen haben, sonst kann man im Editor 
überhaupt nichts damit anfangen.
- eine Wanderwegrelation soll laut Wiki auch interessante Punkte entlang 
des Weges wie z.B. Wegweiser, Feuerstellen, Sendemasten, Parkplätze usw. 
enthalten [1]
- solche Punkte haben nicht notwendigerweise einen Namen
- die ways in der Relation (footway, path, tracks) haben meist keinen Namen

Problem1: "Unerwünschte Vererbung"
- wenn ich jetzt die Vererbung einfach flächendeckend einschalte, erbt 
jeder Punkt und jeder Way von einer der Relationen alle tags, also auch 
den Namen
- somit erscheint auf der Karte "Europäischer Fernwanderweg E3" auf 
jedem Pfad, Feldweg, Wegweiser, Parkplatz, Grillhütte usw.

Problem2: "Mehrfachvererbung"
- wenn ein way oder node zu mehreren Relationen gehört, was ja ganz 
normal ist für Wanderwege, dann ist es zufällig, welches Tag er bekommt. 
Bei Relationen ist keine Reihenfolge definiert und die Relation die von 
einer Clientsoftware zufällig als erstes ausgewertet wird, vererbt ein 
Tag, jede weitere findet es schon ausgefüllt vor und vererbt nicht.
- die Auswertungsreihenfolge ist zufällig und kann bei jedem Lauf eines 
Renderers bzw. bei jedem Datenbankaufruf anders sein. D.h. die 
Eigenschaften der Elemente springen willkürlich zwischen den Tags 
verschiedener Relationen hin- und her.

Und diese Problem treten in einer _korrekt_ verknüpften Hierarchie auf. 
Von daher erwarte ich das eine oder andere Chaos. :-)


mach's gut

   Klaus


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

talk-de@openstreetmap.org

[Sascha Silbe]

On Fri, Jan 16, 2009 at 10:19:25PM +0100, Tobias Wendorff wrote:


Okay, ich sag's dem Prof am Montag. Ich frage mich echt, wofür
ich Studiengebühren zahle.

Dafür, daß das Land die Heizkosten nicht mehr zahlen muß.
FUp2 privat.

CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

Re: [Talk-de] News auf ORS

[Marc Schütz]

> Aufgefallen ist mir auch etwas im Fall, dass die addr:street sich vom Namen
> der nächstliegenden Straße unterscheidet. Da wird der nächste Punkt der
> namensgleichen Straße und nicht einer auf der nächstliegenden Straße
> genommen. Das mag manchmal sinnvoll sein; aber zum Beispiel bei "Im
> Weidenbruch 46, Köln" wird auf diese Weise eine Stelle beim Tunneleingang
> der Straße "Im Weidenbruch" angezeigt, während die richtige Zufahrt am
> Melissenweg liegen und am "Melissenweg 20, Köln" vorbeiführen würde. - Zur
> vereinfachten Demo habe ich hier einmal den Weg von der echten Position des
> Adress-Nodes zu der mit der Suche ermittelten Position "Im Weidenbruch 46,
> Köln" verlinkt:
> http://data.giub.uni-bonn.de/openrouteservice/index.php?start=7.0278436,50.
>979942&end=7.0278114,50.9803202&pref=Shortest&lang=de
>

Ich glaube, dein Fall ist eher die Ausnahme. Normalerweise gehört ja ein Haus 
zu der Straße, in der es den Eingang hat. Für Fälle wie diesen sieht das 
Karlsruhe-Schema eine Relation vor (die wahrscheinlich von ORS noch nicht 
ausgewertet würde):

http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Giving_hints_about_the_road-
access_.28optional.29

Grüße, Marc



signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nochmal See- und Landgrenzen bzw. Relationen im Norden (SH)

[Frederik Ramm]

Hallo,

Lars Francke wrote:
> 1) Wir haben uns ja geeinigt, dass es pro Land und Kreis zwei
> Relationen geben soll. Einmal eine, die die reine Landmasse umfasst
> und einmal eine, die die administrative Grenze darstellt.

Ausser, sie sind identisch, dann reicht eine Relation, oder?

> 5) Da type=boundary abgeschafft wurde koennen Renderer nur noch anhand
> von admin_level eine Grenze erkennen (zumindest so wie im Moment im
> Norden getaggt ist).

Eigentlich sollte man das an boundary=administrative erkennen und nicht 
an admin_level!

> Daher hier was ich tun werde wenn es keine all zu großen Einwände gibt:
> - Doppelte Küstenliniengrenzen loeschen und die Landmasserelationen
> auf die Küstenlinie legen (laut Frederik und noch einem fleißigen
> Helfer aus Kiel dessen Namen ich grad nicht mehr weiß sind die
> Küstenlinien wahrscheinlich genauer als die INFAS-Daten).

Die urspruebglichen Kuestenlinien aus dem PGS-Import waren recht 
schlecht, aber mittlerweile ist da ja sehr viel von Hand dran gearbeitet 
worden, daher wuerde ich mal annehmen, unsere Kuestenlinien sind recht gut.

> - multipolygon für Grenzen ist nun vollständig akzeptiert und
> adoptiert? 

Es gab hier auf der ML zuletzt noch vereinzelte Gegenstimmen, dafuer 
aber auch auf der engl. Liste positives Feedback und ich glaube, es ist 
einfach sinnvoll.

> Wenn ja wie sieht das mit den role-Werten aus: Wird "outer"
> einfach als Standard genommen und nicht explizit getaggt?

Ich wuerde sagen: Ein Client sollte annehmen, dass "keine role" einem 
"outer" entspricht. Trotzdem wuerde ich, wenn ich automatisiert etwas 
aender und/oder es gerade nicht viel Arbeit macht, explizit ein "outer" 
setzen, weil das die Sache klarer macht.

Bye
Frederik

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