Re: [Talk-de] INFAS Kreisgrenzen

[Bernd Wurst]

Hallo.

Am Mittwoch, 31. Dezember 2008 schrieb Frederik Ramm:
> Ich habe den Import jetzt angestossen, allerdings geht der Upload doch
> etwas gemächlich, so dass der groesste Teil des 31.12. wohl noch damit
> herumgeht, die Daten hochzuladen.

Die Nodes sind bei mir schon da, der Way darauf noch nicht. ;-))
Ich bin gespannt. :)

Gruß, Bernd

-- 
Die Erde hat sich zuerst mit uns angelegt, und jetzt, wo sie
verliert, will sie sich aus dem Staub machen!
  -  Mr. Burns, The Simpsons



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] Ende eines Tracks

[Karl Eichwalder]

"Johann H. Addicks"  writes:

> Karl Eichwalder schrieb:
>
>>> in vielen Zügen.
>> 
>> Leider sind es eher wenige Züge und es werden noch weniger :-(  Zudem
>> wird es immer schwieriger, dafür Tickets zu bekommen.  
>
> Dann geht das eben nicht. Aber dann solltest Du auch nicht hier auf der 
> Liste auf Leute schimpfen, die mit dem Auto zum Mappen losfahren.

Wo ein wille ist, da ist ein weg.

-- 
Karl Eichwalder

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

Re: [Talk-de] INFAS Kreisgrenzen

[Michael Bemmerl]

Hallo Frederik,

Frederik Ramm schrieb:
> Hallo,

> Ich habe den Import jetzt angestossen, allerdings geht der Upload doch 
> etwas gemächlich, so dass der groesste Teil des 31.12. wohl noch damit 
> herumgeht, die Daten hochzuladen. Parallel beginne ich mit dem Umtaggen 
> der existierenden Daten. Schaun wir mal...

Kann es sein dass der Bot Schwierigkeiten mit Key-values hat, die länger
als 256 Zeichen sind? Zumindest wird z.B. bei Way #26100306 die
Beschreibung zum Reaktivieren der boundary im note-Tag abgeschnitten.
Siehe http://www.openstreetmap.org/browse/way/26100306

Grüße,
Michi



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

Re: [Talk-de] INFAS Kreisgrenzen

[Wolfgang W. Wasserburger]

> Handarbeit wird es auch an den Grenzen Deutschlands geben, wo die neuen
> Grenz-Ways in die jeweiligen Relationen der Nachbarländer eingepflegt
> werden müssen.

Na dann wird es ja an der Grenze A-D ziemlich lustig - wir importieren auch
gerade einiges - und da sind auch Grenzen dabei ;-)

lG aus Wien

Wolfgang


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

Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)

[Sebastian Hohmann]

Dimitri Junker schrieb:
>> Versteh ich nicht. Das gibt doch nur an auf welcher Seite der Radweg
>> liegt. Oder bemängelst du damit, dass man zusätzlich noch
>> cycleway.type=lane angeben muss?
> 
> 
> Bisher haben wir zum Key cycleway u.a. track und lane. Das von Dir 
> vorgeschlagene right/left ist keine Alternative dazu sondern ein Zusatz. Man 
> muß angeben können, daß der rechte Fahrradweg ein lane und der linke ein 
> track ist. Deshalb z.B.
> cycleway=left:track
> Ein
> 
>> cycleway.type=lan
> 
> 
> würde da auch nicht helfen.
> 
>> Natürlich könnte man auch optional einen Wert wie left:track definieren,
>> um gleich beide Informationen auf einmal angeben zu können.
> 
> 
> Man muß sie zusammen angeben, weil es ja 2 Fahrradwege geben kann.
> 

Also wenn es dir nur darum geht, dann ist es kein Problem. 
cycleway.type=lane setzt den Typ auf alle cycleways, egal ob man nun 
right/left oder auch both angegeben hat. Möchte man nur für eine Seite 
den Typ angeben (das macht nur bei 'both' Sinn), dann kann man dies mit 
cycleway:right.type=lane machen.

Das Ganze ist halt quasi hierarchisch aufgebaut:

both
- right
- left

Lässt man die Angabe von right/left im Schlüssel weg, wird automatisch 
'both' angenommen. cycleway.width=2.5 setzt also die Breite für 'both' 
und 'vererbt' es an 'right' und 'left'. Was zuvor mit 
cycleway=right/left/both/none angegeben wurde ist dabei egal, es setzt 
einfach die Breite für beide Seiten. Wenn auf einer Seite keiner 
vorhanden ist, wirkt es sich logischerweise eben nur auf eine Seite aus.

Gibt man keinen 'type' an, wird automatisch angenommen, dass es sich um 
einen 'track' handelt.

Willst du allerdings den Typ ohne ein extra-Tag angeben, könnte man 
natürlich auch sowas wie left:lane benutzen. Allerdings würde man dabei 
halt etwas aus dem Rahmen fallen im Vergleich zu footway=right/left/both 
das auch Teil des Proposals ist und bei dem 'lane' wohl eher selten 
vorkommt. Nimmt man weiterhin zusätzlich an, dass ein Weglassen des 
Types automatisch ein 'track' ist, hätte man eben statt 4-Hauptwerten 
plötzlich 7: right/left/both/none/right:lane/left:lane/both:lane.

Zusätzlich müsste man dann noch die bisherigen cycleway=track/lane mit 
einberechnen, die einen Radweg des jeweiligen Typs auf beiden Seiten 
definieren. Man hat dann also z.B.:

- cycleway=lane für 'lane' auf beiden Straßenseiten
- cycleway=both für 'track' auf beiden Straßenseiten
- cycleway=right:lane für 'lane' rechts
- cycleway=right für 'track' rechts
Allerdings wären andere Schreibweisen wohl auch gültig, also:
- cycleway=right:track für 'track' rechts
- cycleway=both:track für 'track' auf beiden Straßenseiten
usw.

Das kann man natürlich auf die Spitze treiben. Und da sind noch nichtmal 
footway und path mit dabei. Das kommt halt davon wenn man zum einen 
versucht bisherige Tags zu berücksichtigen und es zusätzlich auch noch 
versucht 'einfacher' zu machen indem viele Werte impliziert werden. :)

Ob man das will ist halt die Frage, das macht irgendwie alles noch 
komplizierter, sowohl für den Mapper als auch den Benutzer. Wobei der 
Mapper es natürlich auch als angenehmer weil kürzer empfinden könnte. 
Aber wiegesagt, irgendwie fällt es so aus dem Rahmen. Die Renderer 
könnte z.B. anstatt Regeln für alle Fälle zu erstellen die Wege vor dem 
Rendern in ein einheitliches Schema umschreibem, so wie sie es eben 
brauchen.

Alternativ könnte man natürlich auch ganz streng sein und sagen: Wir 
geben immer einen Typ an. Also:

- cycleway=lane für 'lane' auf beiden Straßenseiten
- cycleway=track für 'track' auf beiden Straßenseiten
- cycleway=right:lane für 'lane' rechts
- cycleway=right:track für 'track' rechts

Somit hätte man das bisherige Tagging beachtet und gleichzeitig nicht 
mehr so viele Ausnahmen. Oder man macht es halt einfach so wie in meinem 
Proposal. Was ist nun besser? Man weiß es nicht. :)

> 
>> cycleway=none/both:track/right/.. sollte dann aber auch möglich sein.
> 
> 
> Der Nutzen von none ist mir noch nicht klar, both wäre z.B. bei 
> Einbahnstraße sinnvoll als bessere Alternative zu cycleway=opposite
> 

'none' sagt einfach aus, dass sich dieser Typ nicht an der Straße 
befindet. Nach dem aktuellen Proposalstand macht das aber nur bei 
footway Sinn, da footways bei einigen highway-Typen implizit vorhanden 
sind (bei residentials zum Beispiel). Wenn auf solchen Straßen dann doch 
kein Fußweg vorhanden ist, kann man footway=none angeben.

'both' bezieht sich auf 'beide Seiten', nicht auf 'beide Richtungen'. 
Insofern ist es keine Alternative zu cycleway=opposite. Eine Alternative 
dazu wäre eher sowas wie oneway:bicycle=no, also ein Tag das die 
Einbahnstraße gezielt für Fahrräder aufhebt.

> 
>> Könnte man nicht mal schauen wo bei meinem Vorschlag die Schwachstellen
>> sind
> 
> 
> I.W. habe ich ihm ja zugestimmt.
> 

I.W.?

Gruß

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

Re: [Talk-de] Anlieger?

[Johann H. Addicks]

Dirk Stöcker schrieb:

> Ja. Du musst wenigstens einmal so tun, als ob Du eine Adresse suchst. 
> Also anhalten, sehr langsam fahren mit Kopf am Fenster oder ähnliches. 

Damit wird der gewissenhafte KFZ-Mapper kein Problem haben.
Denn gerade in in Anliegerstraßen ist es -für saubere Tracks- wichtig, 
auf der Kreuzungsmitte mal 1-2 Sekunden anzuhalten und in die 
öffentlichen Service/Erschließungswege einzufahren.
Dazu noch das sinnfrei erscheinende Ausfahren von Wendehämmern... Da 
wird niemand unterstellen, es wolle jemand "nur eine Abkürzung durchs 
Wohngebiet nehmen".

Problem sind da eher die Anwohner, die spätestens wenn man das dritte 
Mal mit auswärtigem Kennzeichen durch dieselbe Nebenstraße kommt (lässt 
sich oft ja nicht vermeiden), die Köpfe nicht nur verschämt, sondern 
offensichtlich verdrehen nach dem Eindringling.

-jha-


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

Re: [Talk-de] Ende eines Tracks

[Johann H. Addicks]

Karl Eichwalder schrieb:

>> in vielen Zügen.
> 
> Leider sind es eher wenige Züge und es werden noch weniger :-(  Zudem
> wird es immer schwieriger, dafür Tickets zu bekommen.  

Dann geht das eben nicht. Aber dann solltest Du auch nicht hier auf der 
Liste auf Leute schimpfen, die mit dem Auto zum Mappen losfahren.

-jha-


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

Re: [Talk-de] INFAS Kreisgrenzen

[Frederik Ramm]

Hallo,

Toni Erdmann wrote:
>> Wir machen den Import entweder heute abend oder, wenn wir noch über 
>> irgendein Hindernis stolpern, morgen früh. Also auf jeden Fall noch 2008 ,-)
> 
> Eine gute Nachricht zum Jahresende. Dann kann ich mit den anstoßenden
> Gemeindegrenzen weitermachen.

Ich habe den Import jetzt angestossen, allerdings geht der Upload doch 
etwas gemächlich, so dass der groesste Teil des 31.12. wohl noch damit 
herumgeht, die Daten hochzuladen. Parallel beginne ich mit dem Umtaggen 
der existierenden Daten. Schaun wir mal...

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] Anlieger?

[Johannes Huesing]

Dirk Stöcker  [Tue, Dec 30, 2008 at 10:28:57PM CET]:
> Ja. Du musst wenigstens einmal so tun, als ob Du eine Adresse suchst. 
> Also anhalten, sehr langsam fahren mit Kopf am Fenster oder ähnliches. 
> Wenn Du schnurstracks durchfährst bist Du selber schuld :-)
>

Aber vielleicht könnte man einfach aus Respekt vor denen, die da wohnen,
oder aus Einsicht darin, dass die Straße den Verkehr nicht aufnehmen
könnte, wenn jeder, dem sie nutzte, dort führe, stattdessen dort fahren,
wo es erlaubt ist?

Wäre ja vielleicht mal ein Vorsatz für's neue Jahr.
-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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

Re: [Talk-de] Seniorenheim, Pflegeheim, Hospitz

[Ulf Lamping]

Johann H. Addicks schrieb:
> Gibt's ne Seite im Wiki oder eine hilfreiche URLs für den Tagwatch?
> 

http://tagwatch.stoecker.eu/Europe/En/ignored_amenity.html

Die tags sind wohl noch nicht wirklich eindeutig, so auf den ersten Blick:

amenity=old_peoples_home (6)
amenity=nursing_home (118)
amenity=hospice (8)


Gruß, ULFL

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

[Talk-de] Kurzer Bericht vom 25C3

[Ulf Lamping]

Hi!

Nachdem der 25. Chaos Communication Congress in Berlin heute zu Ende 
gegangen ist, hier mal ein kurzer Bericht "aus OSM Sicht".

Neben den 93 Vorträgen zu Themen wie Hacking, Politik und vielen anderen 
Sachen zum Mitmachen - die alleine eine Reise wert sind ...


Gleich am Samstag fand ein einstündiger OSM Workshop statt, der den etwa 
25 Anwesenden einen Überblick über den Stand der Dinge bei OSM gegeben hat.


An den vier Tagen waren meist so 2-3 OSM'ler am OSM Tisch da, die Fragen 
beantworten konnten. Besonders häufige Fragen waren dabei:

Wie fange ich bei OSM an / ich hab angefangen und ein Problem (was 
brauche ich, JOSM Bedienung, ...)?
Wie siehts aus mit Routing auf Basis von OSM?
Wie siehts aus mit OSM auf mobilen Geräten?
Warum habt ihr keinen https Zugang ("nahezu Klartext" Passwörter zu 
übertragen ist aus Hacker Sicht halt sehr fragwürdig)?


Mein Eindruck war, daß die OSM Karten inzwischen einfach allen bekannt 
und als "gegeben" vorausgesetzt werden.

Viele würden jetzt gerne die (Handy-)Navigation auf Basis von freien 
Karten und freier Software sehen :-)


Alles in allem hat OSM in diesem Jahr ja nun wirklich gute Fortschritte 
gemacht. Wenn ich mir die aktuellen Fortschritte bei den 
Routinganwendungen anschaue, bin ich guter Hoffnung, daß bis zum 
nächsten Congress auch das Routing einfach als "gegeben" angesehen wird ;-)

Damit schließe ich und wünsche allen einen guten Rutsch und ein gesundes 
und tolles 2009!

Gruß, ULFL

P.S: Danke an Marcus Wolschon für die Reservierung des Workshop Raums 
und des Projekttisches! Ich hoffe du wolltest nicht auch sowas schreiben ;-)

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

Re: [Talk-de] Anlieger?

[Florian Lohoff]

On Tue, Dec 30, 2008 at 10:21:15PM +0100, Michael Strauß wrote:
> Ich habe mal zugeschaut, wie so was funktioniert:
> 
> Der Anfang der Straße wurde Videoüberwacht. In der Mitte hat ein
> Polizist mit Handquetsche aufgepasst, ob die einfahrenden Fahrzeuge 
> irgendwo anhalten. Kassiert wurde am Ende.
> 
> Ich glaube nicht, dass die Polizei oder Richter bei einem schnurstraks 
> durchfahrenden Fahrzeug irgendeine Ausrede akzeptiert.

Ab und zu muss man solcherlei Wegelagerei einfach als erhoehte
"Befoerderungspauschale" akzeptieren ...

Im rahmen der Rezession ist das doch auch gut - Soll der der Staat mal
was leisten ...

Es ist ja bereits angekommen das man Verbote die man nicht oder nur
schlecht durchsetzen kann nichts bringen. Deshalb werden ja zunehmend
solche Straßen bei denen der Durchgangsverkehr trotz "Anlieger Frei"
nicht abnimmt heutzutage kurzerhand mal "abgebunden". So ein Blumenkübel
auf der Straße wirkt manchmal Wunder ;)

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

[Talk-de] Seniorenheim, Pflegeheim, Hospitz

[Johann H. Addicks]

Gibt's ne Seite im Wiki oder eine hilfreiche URLs für den Tagwatch?

-jha-


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

Re: [Talk-de] Benutzung von is_in

[Fabian Schmidt]

Am 26.12.08 schrieb g.d:


Solange die Renderers nicht mitspielen (und man sofort das Ergebnis
sieht), ...
sehe ich wenig praktische Anwendung.


Wie willst Du denn is_in-Relationen brauchbar rendern, ohne die Karte zu 
ueberfrachten?


Irgendwie hätte ich gedacht, dass wir seit Hollerith diese Einzwängung 
abgeschüttelt hätten, und dass unsere Programme diskriminieren könnten 
zwischen einem "Neuburg" an der Donau und einem "Neuburg" in 
Nordrhein-Westfalen,


Die Programme koenn(t)en anhand der Entfernung die Neuburgs 
diskriminieren, es ist nur etwas aufwendiger zu bestimmen.


Aha, jetzt versteh' ich besser, weshalb der Text 'Straubenhardt' und 
auch 'Mannheim' wie 'Ludwigshafen' ab zoom 15 verschwindet : Das sind 
relations...


Nein. Aber der Ortsname ist nur bei einer Kreiskarte interessant, nicht in 
einem Stadtplan.



Grüße aus Sachsen,

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

Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p

[Tobias Knerr]

Tobias Wendorff schrieb:
> Tobias Knerr schrieb:
>> Das Plugin ist ein wenig veraltet, es erzeugt momentan noch Objekte, die
>> nicht mit dem Wikieintrag übereinstimmen. Das will ich so bald wie
>> möglich ändern.
> 
> Ich habe einen ähnlichen Ansatz verfolgt, aber aufgrund der nicht
> vorhandenen JAVA-Kenntnisse verworfen. Du setzt ja zurzeit auf ein
> kleines JOSM-Fenster, dessen Bedienung nicht mein Fall ist :-)
> 
> Wie würdest Du über eine schöne grafische Ansicht denken? Ich stelle
> mir da etwas vor, wie den Spurassistenten eines bekannten
> Navigationssystems :-)

Ich muss ehrlich gesagt zugeben, dass ich mir bei deiner Beschreibung
nicht wirklich vorstellen kann, worum es dir geht -- zumal ich den
"Spurassistenten eines bekannten Navigationssystems" nicht kenne. Willst
du auf die Größe des Fensters hinaus? Auf die Frage separate Ansicht vs.
"Detailzoom"? Qualität der grafischen Darstellung? Bedienkonzept? Reden
wir überhaupt von einem Editor oder einem Viewer?

"Schöne grafische Ansicht" klingt natürlich trotzdem vielversprechend. ;-)

Etwas verwirrt,

Tobias "Tordanik" Knerr

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

Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p

[Tobias Wendorff]

Tobias Knerr schrieb:
> Das Plugin ist ein wenig veraltet, es erzeugt momentan noch Objekte, die
> nicht mit dem Wikieintrag übereinstimmen. Das will ich so bald wie
> möglich ändern.

Ich habe einen ähnlichen Ansatz verfolgt, aber aufgrund der nicht
vorhandenen JAVA-Kenntnisse verworfen. Du setzt ja zurzeit auf ein
kleines JOSM-Fenster, dessen Bedienung nicht mein Fall ist :-)

Wie würdest Du über eine schöne grafische Ansicht denken? Ich stelle
mir da etwas vor, wie den Spurassistenten eines bekannten
Navigationssystems :-)

Könnte in den kommenden Tagen vielleicht mal ein paar Grafiken in
Corel entwerfen?

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

Re: [Talk-de] Fläche von Polygon berechnen?

[Tobias Wendorff]

Wolfgang W. Wasserburger schrieb:
> Letztlich steckt wieder mal die Proj4 dahinter ;-)

Laut Archiv hatte Proj4 damals mal ein paar Berechnungsfunktionen.
Diese wurden aber eingestellt, da die Ergebnisse zu ungenau für
den Rest von Proj4 waren :-/

Ich habe vor kurzen einen Satz TPs bekommen, gleich auch noch in
allen History-Stufen.

Die TPs wurden zuletzt von Netz77 (DHDN) in ETRS89 transformiert.
Witzigerweise weichen diese nun um bis zu 70 cm ab.

Ich frage mich, ob der Schritt der Vermessungsämter wirklich
sinnvoll ist, wenn überall solche Fehler durch die Transformation
auftreten.

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

Re: [Talk-de] Anlieger?

[Dirk Stöcker]

On Tue, 30 Dec 2008, Michael Strauß wrote:


Der Anfang der Straße wurde Videoüberwacht. In der Mitte hat ein
Polizist mit Handquetsche aufgepasst, ob die einfahrenden Fahrzeuge
irgendwo anhalten. Kassiert wurde am Ende.

Ich glaube nicht, dass die Polizei oder Richter bei einem schnurstraks
durchfahrenden Fahrzeug irgendeine Ausrede akzeptiert.


Ja. Du musst wenigstens einmal so tun, als ob Du eine Adresse suchst. Also 
anhalten, sehr langsam fahren mit Kopf am Fenster oder ähnliches. Wenn Du 
schnurstracks durchfährst bist Du selber schuld :-)


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Anlieger?

[Michael Strauß]

Am Tue, 30 Dec 2008 12:19:07 +0100
schrieb André Reichelt :

> Nein, ganz ehrlich: Ich würde es einfach drauf anlegen. Im Notfall
> kannst Du immer noch behaupten, du wurdest von wem geschickt, der Dir
> eine Hausnummer genannt hat, die es hier gar nicht gibt. Oder Du denkst
> Dir was anderes aus. Die Polizei hat keine Möglichkeit, das zu beweisen.

Ich habe mal zugeschaut, wie so was funktioniert:

Der Anfang der Straße wurde Videoüberwacht. In der Mitte hat ein
Polizist mit Handquetsche aufgepasst, ob die einfahrenden Fahrzeuge 
irgendwo anhalten. Kassiert wurde am Ende.

Ich glaube nicht, dass die Polizei oder Richter bei einem schnurstraks 
durchfahrenden Fahrzeug irgendeine Ausrede akzeptiert.

Grüße,
Michael Strauß

-- 

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

Re: [Talk-de] Linienbündel , Radwege

[Martin Simon]

Am 30. Dezember 2008 17:16 schrieb Sven Anders :

> Ich finde es wie schon in meinen letzen Postings beschrieben sehr
> problematisch, wenn man den Radweg und Fußweg nicht einzeichnen darf.

+1!

Auch wenn ich mich dieses mal bisher nicht eingemischt habe, möchte
ich das hier in aller Deutlichkeit unterschreiben;
ich werde auch weiterhin ausgeschilderte Radwege, die _nicht auf der
Fahrbahn_ verlaufen, eigenständig einzeichnen.

Es ist die einfachste, wirklichkeitsgetreueste Methode, die wir haben.
Mir ist beim mappen oder benutzen der Daten noch kein einziges Problem
damit über den Weg gelaufen - mit den vorgeschlagenen "Monstertags"
handelt man sich schon beim editieren einen Haufen davon ein.

Eine richtige Kombination auf Kfz-Fahrbahn und begleitenden Wegen mit
genauem Verlauf, zusammengefasst per Relation, kann man meinetwegen
maschinell in viele Stücke Hauptweg mit sehr vielen Monstertags
wandeln, um einen hypothetischen Router zu füttern, der damit besser
klarkommen *könnte* als mit der vollen Information.
Andersrum geht das nicht. Ich bin nicht bereit, den Verlauf
begleitender Radwege von Anfang an wegzuwerfen.

Ich glaube es war Frederik, der in einem anderen Thema sagte "wir
filtern bei OSM an der Ausgabeseite, nicht bei der Eingabe", was hier
mit breiter Zustimmung aufgenommen wurde.

Also taggt meinetwegen mit einem verschachtelten taghaufen, ohne etwas
zu gewinnen, aber hindert nicht andere, die volle Information
einzugtragen.

Vielen Dank.

-Martin

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

Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p

[Tobias Knerr]

Sebastian Hohmann schrieb:
> Tobias Knerr schrieb:
>> http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group
> 
> Ein guter Ansatz. Gehört dazu auch das lanetool-plugin for JOSM? 

Prinzipiell ja, das war mein Experiment dazu, ob ein derartiges Schema
mit geeignetem Editorsupport auch bei komplizierten Situationen
handhabbar bleibt -- ich persönlich finde ja, auch wenn ich für
produktive Nutzbarkeit noch einiges einbauen würde (etwa Selektieren per
Linksklick oder gleichzeitiges Bearbeiten mehrerer Wegstücke).

Das Plugin ist ein wenig veraltet, es erzeugt momentan noch Objekte, die
nicht mit dem Wikieintrag übereinstimmen. Das will ich so bald wie
möglich ändern.

> Allerdings würde ich nicht alle Straße damit erfassen wollen. Für 
> einfache Fälle in denen man wirklich nur angeben will, dass auf der 
> rechten Seite ein Bürgersteig ist, würde doch ein einfaches Tag reichen.

Das würde selbstverständlich reichen, die lane_group ist auch eher als
Konzept für überdurchschnittlich komplexe Straßen gedacht, mit dem man
theoretisch nach oben hin offene Möglichkeiten für die Detaillierung
hat. Für die Standardfälle tuns auch Tags -- für manches existieren sie
ja schon, die aktuellen Diskussionen um das "Advanced footway and
cycleway"-Proposal zeigen auch, dass durchaus Interesse und Potential
besteht, die tagbasierten Lösungen noch auszubauen.

Sollten irgendwann alle verbreiteten Editoren und Programme die
Erzeugung und Auswertung von lane_groups so leicht machen, dass sie
wirklich auch für 0815-Fälle die naheliegende Lösung sind, können wir
nochmal drüber reden. Damit rechne ich aber eigentlich erstmal nicht.

> Bei einer Lösung mit verschachtelten Relationen muss der Editor das auf 
> jeden Fall unterstützen, sonst geht die Übersicht schnell verloren. Ich 
> weiß nicht wie schnell sowas für alle gängigen Editoren vorhanden wäre.

Ich habe mein ursprüngliches lanetool an einem Wochenende gebastelt.
Angesichts dessen, dass ich zu Beginn den JOSM-Code noch nie gesehen
hatte, ist so etwas an sich wohl machbar. Ich kann das auch schwer
einschätzen, da es von der Motivation der Programmierer abhängt. Alles
natürlich unter der Voraussetzung, dass das Konzept überhaupt
Verbreitung findet.

Tobias "Tordanik" Knerr

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

Re: [Talk-de] Fläche von Polygon berechnen?

[Wolfgang W. Wasserburger]

> > Wenn Du's in ein PostgreSQL importierst, kannst Du dort 
> projiziert Längen und Flächen abfragen.
> > lg Wolfgang
> 
> MMh, kann PostgreSQL (mit PostGIS) nicht direkt auf dem Ellipsoiden
> rechnen?
> 
> Okay, was mache ich mir vor? Nicht mal ArcGIS 9.3 kann das :-(
> 
Letztlich steckt wieder mal die Proj4 dahinter ;-)

CU W


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

Re: [Talk-de] Fläche von Polygon berechnen?

[Tobias Wendorff]

Wolfgang W. Wasserburger schrieb:
>>>
> Wenn Du's in ein PostgreSQL importierst, kannst Du dort projiziert Längen und 
> Flächen abfragen.
> lg Wolfgang

MMh, kann PostgreSQL (mit PostGIS) nicht direkt auf dem Ellipsoiden
rechnen?

Okay, was mache ich mir vor? Nicht mal ArcGIS 9.3 kann das :-(

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

Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p

[Sebastian Hohmann]

Tobias Knerr schrieb:
> Da ich hier auf der Mailingliste stark den Eindruck habe, dass die
> Diskussionen um Linienbündel etc. auf der Stelle treten, will ich mal
> einen konkreteren Vorschlag einwerfen:
> 
> http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group
> 
> Ich habe den Ansatz gewählt, einige wesentliche hinter dem Konzept
> stehende Ziele ausdrücklich aufzulisten. Insofern würde ich mich freuen,
> wenn wir bei der Diskussion unterscheiden könnten, ob wir
> unterschiedliche Zielvorstellungen haben, oder ein anderes Konzept
> dieselben Ziele auf anderem Weg erreichen würde.
> 

Ein guter Ansatz. Gehört dazu auch das lanetool-plugin for JOSM? 
Allerdings würde ich nicht alle Straße damit erfassen wollen. Für 
einfache Fälle in denen man wirklich nur angeben will, dass auf der 
rechten Seite ein Bürgersteig ist, würde doch ein einfaches Tag reichen. 
Bei einer Lösung mit verschachtelten Relationen muss der Editor das auf 
jeden Fall unterstützen, sonst geht die Übersicht schnell verloren. Ich 
weiß nicht wie schnell sowas für alle gängigen Editoren vorhanden wäre.

Zumal der Aufwand mit den Relationen für ganz einfache Fälle sowieso 
relativ hoch wäre. Wenn es eine normale Standardstraße ist, die keine 
richtungsabhängigen Geschwindigkeitsbeschränkungen oder sowas hat, wäre 
es ja meistens mit wenigen Tags getan.

Aber für die Situationen die nicht mehr einfach mit einer handvoll Tags 
gelöst werden können, sicherlich eine gute Möglichkeit. Schön dass es 
sowohl einzeln gezeichnete als auch 'virtuelle' Wege unterstützt.

Gruß

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

Re: [Talk-de] Ende eines Tracks

[Karl Eichwalder]

Rainer Knaepper  writes:

> Btw.: Räder kann man auch mitnehmen. Auf dem Autodach,

Nun ja, ich mag das nicht.  Zu teuer, zu umständlich, zu egoistisch
gedacht.

> in vielen Zügen.

Leider sind es eher wenige Züge und es werden noch weniger :-(  Zudem
wird es immer schwieriger, dafür Tickets zu bekommen.  Ohne
Vorabreservierung geht oft gar nichts...

In dem RE am Samstag morgen um 5:10 von Nürnberg nach München ist immer
massig Platz, aber Räder scheint man nicht mitnehmen zu dürfen
(zumindest wird dieser Zug nicht angezeigt, wenn ich auf Fahrradmitnahme
klicke).

Wenn ich beispielsweise nach Berchtesgaden will, dann bedeutet das, dass
ich eine gute halbe Stunde früher abfahren muss (4:37) und dafür auch
noch eine stunde später ankomme (11:38 anstelle von 10:38).  Zugegeben,
ich könnte auch erst um 5:47 abfahren, um um 11:38 anzukommen -- aber da
müsste ich 3 mal umsteigen (anstelle von 2 mal) und in allen vier Zügen
ist Fahrradmitnahme nur "begrenzt möglich".

Wenn's dumm läuft, kann man da schnell noch 1 bis 2 Stunden verlieren.
Jedenfalls im Sommer.

-- 
Karl Eichwalder

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

Re: [Talk-de] Linienbündel , Radwege

[Wolfgang Wienke]

Hallo!
Sven Anders schrieb:
> Am Dienstag, 30. Dezember 2008 14:18 schrieb Wolfgang Wienke:
> 
>>Hallo!
>>Ich hoffe, die Fachleute haben bald ausdiskutiert und entschieden! ,-)
>>Ich bin da nur ein Neuling und verstehe nicht alle Details. Ich habe
>>aber den Eindruck, dass eine Anpassung/Klarstellung des Wikis noch nicht
>>in Sicht ist. Eigentlich möchte ich mich nur mit den Radwegen
>>beschäftigen, weiß aber zur Zeit wirklich nicht, wie ich es richtig
>>mache. Wenn nämlich nachher doch alle Arbeit umsonst ist, stelle ich
>>meine Mitarbeit lieber gleich ein.
>>Ich habe deshalb einfach mal eine Wiki-Klarstellung geschrieben und
>>hoffe, das die dann möglichst bald (bitte bitte) passend überarbeitet
>>ins Wiki gesetzt wird. Sie muss ja noch nicht ALLE Fälle umfassen,
>>sondern nur konkreter sein als das bisherige.
>>Wenn ich das einfach selbst mache, löse ich damit wahrscheinlich nur
>>einen edit-war aus.
> 
> 
> Was mache ich denn nun, wenn ich mit dem Text den du geschrieben hast 
> unzufrieden bin und nicht das Gefühl habe, das das so ins Wiki soll?
Du schreibst einfach andere Festlegungen ins wiki, die inhaltlich meinen 
Vorschlag abdecken. Die Art der Lösung ist mir egal, nur eine (EINE) 
Lösung muss her.


-- 
Mit freundlichen Gruessen

  Wolfgang Wienke

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

Re: [Talk-de] Anfängerfragen, nochmals

[Sebastian Hohmann]

Kindl München schrieb:
> *Das Problem ist:* Bei der Vorlage ist keine Höhe vorgesehen.
> 

Die Vorlagen machen nichts anderes als die entsprechenden Schlüssel und 
Werte in der Tabelle "Eigenschaften" rechts automatisch einzutragen. 
Dabei sind nur die gängigsten Dinge abgedeckt, wenn du dich ernsthaft 
mit Mapping beschäftigen willst, musst du ganz oft auch manuell Tags 
(also Schlüssel/Wert-Paare) eintragen. Manchmal geht das sogar schneller 
als über die Vorlagen.

Vielleicht helfen dir ja auch die Flash Tutorials [1], im Einsteiger 
Tutorial werden auch Tags manuell zugewiesen, allerdings nicht sehr 
ausführlich. Aber vielleicht ist ja auch sonst noch was Neues für dich 
dabei.

Gruß

[1] http://wiki.openstreetmap.org/wiki/DE:Flash_Tutorials

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

Re: [Talk-de] Anfängerfragen , nochmals

[Sebastian Hierholzer]

> Nach einiger Übung ist es meistens leichter, zusätzliche Dinge
> direkt als "Tags" zu setzen ohne dafür über die Vorlagen zu gehen.
> Einfach z.B. über "Alt+B" (oder "Hinzufügen" im Tag-Fensterchen)
> den Schlüssel und den Wert eintragen.
Ich glaub sein Problem ist viel einfacher, er sieht das Eigenschaften Fenster 
nicht.
Also Schauen ob es im rechten Bereich irgendetwas mit Eigenschaften gibt, wenn 
ja dann ist das das was du suchst, wenn nein einfach ALT + SHIFT + P und es 
sollte erscheinen.


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

Re: [Talk-de] Anfängerfragen , nochmals

[Bernd Wurst]

Hallo.

Am Dienstag, 30. Dezember 2008 schrieb Kindl München:
> *Das Problem ist:* Bei der Vorlage ist keine Höhe vorgesehen.

Vorlagen sind nicht allumfassend. Es gibt nur Vorlagen für einige verbreitete 
Dinge.

wie André schon schrieb, gibt es für diese Beschränkungen separate Vorlagen 
(da diese sonst für allerlei Straßentypen getrennt erfasst werden müssten).

Nach einiger Übung ist es meistens leichter, zusätzliche Dinge direkt als 
"Tags" zu setzen ohne dafür über die Vorlagen zu gehen. Einfach z.B. über 
"Alt+B" (oder "Hinzufügen" im Tag-Fensterchen) den Schlüssel und den Wert 
eintragen.

Die Vorlagen machen übrigens nichts anderes als jedes Feld (in das du etwas 
einträgst) mit einem fest hinterlegten Schlüssel als Tag zu setzen.

Gruß, Bernd

-- 
Die Grundsätze des Beamtenrechts können in Deutschland nur mit einer
blutigen Revolution beseitigt werden.
  -  Jürgen Rüttgers (dt. Politiker)



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] OSMOSIS Polygon File Erstellen

[Bernd Wurst]

Hallo.

Am Dienstag, 30. Dezember 2008 schrieb FrauSuhrbier:
> Gibt es eine einfache (OSM-) Anwendung Polygon Files für OSMOSIS zu
> erstellen?
> Es hat zwar einige Bespiele (wie:
> http://svn.openstreetmap.org/applications/utils/osm-extract/polygons/german
>y/), aber ich wollte für mich einen eigenen Bereich extrahieren und vertraue
> auf die Community, dass es (wahrscheinlich) schon eine mit OSM Maps
> unterlegte Anwendung dafür existiert.

Du kannst einfach ein Polygon in JOSM malen (auf einer neuen Ebene!) und das 
anstelle es hochzuladen in ener .OSM-Datei abspeichern.
Das Polygon sollte folgende Tags haben:
  polygon_id=1
  polygon_file=foobar
wobei du "foobar" durch einen Namen für die Fläche ersetzt.

Diese OSM-Datei kannst du dann mittels osm2poly.pl
  http://svn.openstreetmap.org/applications/utils/osm-
extract/polygons/osm2poly.pl
in ein Polygon-File umwandeln, das man direkt OSMOSIS geben kann.


Der Vorteil der Verwendung von JOSM ist, dass es damit möglich ist, für ein 
Polygon teile der OSM-Daten-Polygone mit zu benutzen und damit eventuell (je 
nach Anwendung) etwas genaueres zu haben als wenn man es sich grob 
zusammenklickt.

Gruß, Bernd

-- 
Skeptiker sind jene Menschen, die einfach nicht an die
friedliche Nutzung der Atombombe glauben wollen.
  -  Werner Mitsch (dt. Aphoristiker)



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] Mapping Quality - Fortschritt

[Gary68]

hallo,

auf der seite http://wiki.openstreetmap.org/wiki/Mapping_Quality könnt
ihr nun auch karten mit daten finden (programmversion 1.1). zunächst mal
hamburg, bremen, saarland, berlin und hessen sowie die oberpfalz.

die karten zeigen die radien, in denen auf nodes geprüft wird sowie
einige grundlegende daten je place. 
- nodes inside
- # residentials
- residential länge in km (gerundet)
- # amenities
- # buildings

anhand der radien können wir nun diese ggf. korrigieren. aber das
grundlegende problem bleibt zunächst bestehen, dass die orte nunmal
unterschiedlich groß sind...

die csv ausgabe wurde erweitert, nun auch mit nodeId.

die html ausgabe wird an weiteren stellen formatiert.

gleich noch eines vorweg:
- das programm ist kein (vollwertiger) renderer und
- ich bin kein künstler :-)

aber das sieht man ja auch.

ich will mir dann mal die landuse=residential ansehen, ob ich da noch
daten gewinnen kann...

ciao und schönen abend noch

gerhard
gary68



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

Re: [Talk-de] Fläche von Polygon berechnen?

[Wolfgang W. Wasserburger]

> danke für deinen input. denke ich werde den cosinus für longitude noch
> hinbekommen und dann die von frederik vorgeschlagene lib/modul nehmen.
> 
> aber erst mal sehen, was man damit anfangen kann. dazu gleich mehr in
> einer anderen mail!
> 
> ciao
> 
> gerhard
> 
> Am Dienstag, den 30.12.2008, 18:28 +0100 schrieb Bernd Wurst:
> > Hallo.
> > 
> > Am Dienstag, 30. Dezember 2008 schrieb Gary G::
> > > wozu? ganz einfach. ich spiele ja im augenblick mit dem programm
> > > mappingquality.pl (siehe wiki "Mapping Quality") und da wollte ich
> > > demnächst mal zusätzlich wohnflächen berechnen.
> > 
> > Ganz ehrlich:
> > Die Genauigkeit die du dafr haben willst, solltest du sogar 
> bekommen wenn du 
> > die Erde als Ebene approximierst.
> > 
> > Dann kannst du mit der (*räusper* vergleichsweise) einfachen Formel von
> > http://de.wikipedia.org/wiki/Polygon#Fl.C3.A4che
> > arbeiten.
> > 
> > Das was du vor hast, sollte ja alles keine großen 
> Flchenausdehnungen haben und 
> > daher der Fehler minimal sein.
> > 
> > Hat jemand ne Größenordnung, wie viel Fehler da bei einer 
> Fläche von ca. 1 x 1 
> > km zusammenkommt? Denn ich denke das könnte in etwa die übliche 
> Maximalgröße 
> > für Wohngebiete sein. Da das wesentlich weniger als eine 
> zoom-12-Kachel ist, 
> > würde ich auf der Ebene arbeiten und die Kugel völlig ignorieren.
> > 
Wenn Du's in ein PostgreSQL importierst, kannst Du dort projiziert Längen und 
Flächen abfragen.
lg Wolfgang


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

Re: [Talk-de] Fläche von Polygon berechnen?

[Gary68]

hi bernd,

danke für deinen input. denke ich werde den cosinus für longitude noch
hinbekommen und dann die von frederik vorgeschlagene lib/modul nehmen.

aber erst mal sehen, was man damit anfangen kann. dazu gleich mehr in
einer anderen mail!

ciao

gerhard

Am Dienstag, den 30.12.2008, 18:28 +0100 schrieb Bernd Wurst:
> Hallo.
> 
> Am Dienstag, 30. Dezember 2008 schrieb Gary G::
> > wozu? ganz einfach. ich spiele ja im augenblick mit dem programm
> > mappingquality.pl (siehe wiki "Mapping Quality") und da wollte ich
> > demnächst mal zusätzlich wohnflächen berechnen.
> 
> Ganz ehrlich:
> Die Genauigkeit die du dafr haben willst, solltest du sogar bekommen wenn du 
> die Erde als Ebene approximierst.
> 
> Dann kannst du mit der (*räusper* vergleichsweise) einfachen Formel von
> http://de.wikipedia.org/wiki/Polygon#Fl.C3.A4che
> arbeiten.
> 
> Das was du vor hast, sollte ja alles keine großen Flchenausdehnungen haben 
> und 
> daher der Fehler minimal sein.
> 
> Hat jemand ne Größenordnung, wie viel Fehler da bei einer Fläche von ca. 1 x 
> 1 
> km zusammenkommt? Denn ich denke das könnte in etwa die übliche Maximalgröße 
> für Wohngebiete sein. Da das wesentlich weniger als eine zoom-12-Kachel ist, 
> würde ich auf der Ebene arbeiten und die Kugel völlig ignorieren.
> 
> Gruß, Bernd
> 
> ___
> 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] Anfängerfragen, nochmals

[André Reichelt]

Kindl München schrieb:
> Kann ich im Feld für Breite einfach maxheight=2.4 eintragen, oder gibt
> es irgendwo einen Schalter der mir das Feld noch öffnet?

Nein, dazu gehen sie zusätzlich nochmal auf
Vorlagen>Straßen>Straßenbeschränkungen. Dann öffnet sich ein Feld
speziell für solche Dinge. Mit meiner Hilfe bezog ich mich nicht auf dei
Vorlagen sondern auf das manuelle Eintragen. Auf der Rechten seite in
Josm erscheint eine Tabelle. In dieser zweispaltigen Tabelle kann man
manuell Werte eintragen ohne Vorlage. Dies ist die preferierte
Eingabemethode von fortgeschrittenen Mappern.



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

Re: [Talk-de] Ende eines Tracks

[Rainer Knaepper]

Moin Karl,

>Davon ab, muss man hinter auto-autobahnmappern regelmäßig
>hinterherräumen.

Umgekehrt wird genauso ein Schuh daraus. Fahrradmapper ignorieren
anscheins ebenso oft Bedürfnisse von PKW- oder gar LKW-Fahrern.
Weshalb sonst fehlen beispielsweise allerorten Angaben für maxspeed
oder maxheight oder turning_circle usw.?

Besonders ernüchternd sind die Ergebnisse der Fahrradmapper auf dem
platten Land, da gibt es hier und da mal einen track, wenn er gerade
mal kürzer ist als die Bundesstraße, ganze Landstriche sind frei von
Straßenverbindungen, Dörfer ohne jeden Anschluß an die Welt.

Nein, ich mache keinem Radler einen Vorwurf, wenn er es scheut, eben
schnell mal 30km irgendein Gebiet anzufahren, dort 50km Nebenstraßen
zu mappen und anschließend die 30km zurückzuradeln.

Btw.: Räder kann man auch mitnehmen. Auf dem Autodach, in vielen
Zügen. Systeme können sich durchaus ergänzen.

Rainer

-- 


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

Re: [Talk-de] INFAS Kreisgrenzen

[Toni Erdmann]

Frederik Ramm schrieb:
> Hallo,
> 
> Bernd Wurst wrote:
>> Ich fand, der Import der Infas-Kreisgrenzen klang so gut durchgeplant, schon 
>> von Anfang an... :)
> 
> Hat sich ja auch Jochen ausgedacht ;-)
> 
>> Ich habe auch Verständnis dafür, wenn diese Daten eben nicht hopplahopp und 
>> verzwungen einfach importiert werden. Aber wäre es möglich, die 
>> Grenzverläufe 
>> vorab als OSM-Datei zur Verfügung zu stellen, so dass man die bestehende, 
>> ziemlich unscharfe und stellenweise auch falsche Grenze durch etwas ersetzen 
>> könnte was besser passt?
> 
> Wir machen den Import entweder heute abend oder, wenn wir noch über 
> irgendein Hindernis stolpern, morgen früh. Also auf jeden Fall noch 2008 ,-)

Eine gute Nachricht zum Jahresende. Dann kann ich mit den anstoßenden
Gemeindegrenzen weitermachen.

> Für die neu Hinzugekommenen - hier steht, worum es geht:
> http://wiki.openstreetmap.org/wiki/Import/Catalogue/Kreisgrenzen_Deutschland_2005
> 
> Der Import wird wie geplant durchgeführt. Existierende Grenzen werden 
> nicht gelöscht, sondern so umgetaggt, dass sie im Rendering nicht mehr 
> erscheinen. Es wird dann Aufgabe der Mapper vor Ort, sich davon zu 
> ueberzeugen, dass die neue Grenze auch taugt, und die alte dann vollends 
> zu entsorgen.

Dürfte kein Problem sein, für's out-door-mapping ist's eh ein wenig kühl
(hüstel, hüstel).

Gruß,
Toni


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

[Talk-de] Anfängerfragen, nochmals

[Kindl München]

Guten Tag,
vielen Dank für die prompten Antworten.

Leider haben Sie mir aber nicht wirklich weitergeholfen.
Die angegebenen Links
http://wiki.openstreetmap.org/wiki/DE:Key:access
http://wiki.openstreetmap.org/wiki/DE:Map_Features und andere
kannte ich schon, habe es mir aber natürlich nochmals durchgelesen.

Mein Grundproblem ist viel banaler. Ich will es nochmals als Beispiel
"Tunnel" angeben.

Eine Straße markiere ich, oder zeichne ich.
Ich klicke auf Vorlagen.
Ich klicke auf Straßen und wähle Ortsstraßen aus.
Hier gebe ich den Namen an und klicke Tunnel an.
Als Ebene -1 und Oberfläche geteert eingetragen
Breite entfällt.

*Das Problem ist:* Bei der Vorlage ist keine Höhe vorgesehen.

Kann ich im Feld für Breite einfach maxheight=2.4 eintragen, oder gibt es
irgendwo einen Schalter der mir das Feld noch öffnet?

Muß ich noch etwas installieren, oder bei den Einstellungen ändern?

Das gleiche gilt für Brücke und Gewichtsbeschränkung, usw.

Mir fehlt einfach ein Feld in der ich die ganzen Besonderheiten eintragen
kann.

Das zweite Problem
Ich kann bei den Straßen keine Eigenschaften sehen. Z.B.
Geschwindigkeitsbeschränkungen.
Ich habe zwar bei JOSM rechts mehrere Felder, die allerdings diese
Informationen nicht geben.

- Das Erste heisst zwar Eingeschaften/Mitgliedschaften, aber in der Regel
steht hier nichts, oder created_by und Wert JOSM.
-Darunter ein Feld Aktuelle Auswahl. Hier sind die ID und die Koordinaten.
-Darunter der Autor
-Als letztes die Relationen.

Nochmals vielen Dank für Antworten

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

Re: [Talk-de] INFAS Kreisgrenzen

[Martin Simon]

Am 30. Dezember 2008 16:07 schrieb Frederik Ramm :

> Wir machen den Import entweder heute abend oder, wenn wir noch über
> irgendein Hindernis stolpern, morgen früh. Also auf jeden Fall noch 2008 ,-)

Klasse - zumal ich durch die Kreisgrenzen anscheinend ca. 3km Bachlauf
südlich von Bad Honnef erhalte, der scheinbar als Grenze zwischen NRW
und Rheinland-Pfalz dient. :-)
Das ist sicherlich auch andernorts öfter der Fall - es lohnt sich
sicher, mal nachzuschauen!

Vielen Dank für eure Arbeit!

-Martin

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

Re: [Talk-de] Your whishlist for Debian Packages?

[Joerg Ostertag (OSM Tettnang/Germany)]

On Dienstag 30 Dezember 2008, Sebastian Niehaus wrote:
> "Joerg Ostertag (OSM Tettnang/Germany)"  
writes:
> > as most of you probably know I'm providing debian packages for the most
> > common tools needed to work with OpenStreetMap.
> > What I'd like to know is:
> >- which additional tools from the osm-svn would you like to see added
> > to the debian repository?
> >- which other debian based platforms would you like to see suported?
> >  examples would be: debian-etch, Ubuntu-xx, ...
>
> Well, I prefer debian-etch...
>
> > If you give me a preferences list, I can start with the most wanted ones
> > .
> >
> > More description on the existing debian repository can be found at:
> > http://www.gpsdrive.de/development/debian.shtml
>
> josm is great, merkaartor would be fine too. Where can I report bugs
> concerning the packages from http://www.gpsdrive.de/debian ?

Depends what it is about. But normally the osm-dev-list would be ok
"osm-dev List" 

> http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.de/30514

I was digging a little bit into this and it seems that the make distclean is 
not really triggered while building the debian package. This mixed up old and 
new packages. I changed this and a new package is on it's way.

> Thanks für your committment!

Thanks for using them; and thanks for filing usefull Bug Reports.

-
Joerg

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

Re: [Talk-de] Your whishlist for Debian Packages?

[Joerg Ostertag (OSM Tettnang/Germany)]

On Dienstag 30 Dezember 2008, Rainer Dorsch wrote:
> Am Dienstag, 30. Dezember 2008 schrieb Joerg Ostertag (OSM 
Tettnang/Germany):
> > Repository for lenny (testing)
> > /etc/apt/sources.list
> > # Gpsdrive Packages
> > deb     http://www.gpsdrive.de/debian etch main
> > deb-src http://www.gpsdrive.de/debian etch main
>
> Soll das wirklich etch (für lenny?) heißen?

Ja, denn noch gibt es von allem nur debian-testing packages (Das ist noch 
Altlast aus der Zeit als etch das debian-testing war).

Aber da bin ich grad am schrauben, damit das repository dann auch wirklich mit 
den Namen das reflektiert, was auch wirklich drin ist.

-- 
Jörg (Germany, Tettnang)

http://www.ostertag.name/

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

[Talk-de] OSMOSIS Polygon File Erstellen

[FrauSuhrbier]

Gibt es eine einfache (OSM-) Anwendung Polygon Files für OSMOSIS zu 
erstellen?
Es hat zwar einige Bespiele (wie: 
http://svn.openstreetmap.org/applications/utils/osm-extract/polygons/germany/), 
aber ich wollte für mich einen eigenen Bereich extrahieren und vertraue 
auf die Community, dass es (wahrscheinlich) schon eine mit OSM Maps 
unterlegte Anwendung dafür existiert.
Jürgen


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

Re: [Talk-de] route=train oder route=rail?

[Karl Eichwalder]

"Melchior Moos"  writes:

> Ich persönlich finde diese Nummern auch unwichtig.

Ich auch.

> Normal sterbliche haben fragen wie "wo liegt eigentlich die KBS 470?"
> doch eher selten. Die Frage kam nur auf, weil es Leute gibt, die die
> Kursbuchstrecken eben als Relationen mit den im Titel stehenden Tags
> eintragen.

In analogie zu "bus" und "subway" sollten wir "train" für zuglinien
nehmen.  Die streckennummern könnten dann meinetwegen als "rail"
gespeichert werden und sollten beim ÖPNV-layern allenfalls optional
zuschaltbar sein.

Hoffentlich gibt es bald ein update ;)

-- 
Karl Eichwalder

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

Re: [Talk-de] Canal und Riverbank

[Marc Schütz]

> > Zwinge den Renderer, die Reihenfolge
> > zu ändern.  Gib der Wasserfläche ein layer=1.
> 
> Wieso, ist denn das Wasser im breiteren Bereich über dem Wasser im Haupt-
> Kanal?
> 
> Es ist ein Fehler. Mehr nicht. Der Fehler wird behoben werden. Er besteht 
> nicht so lange, dass man sich damit arrangieren muss. Es ist echt affig,
> wegen 
> eines Fehlers in einem (!!) Renderer hier obskure Kopfstände zu machen um
> das 
> Ergebnis möglichst heute noch schöner zu bekommen.
> 
> Es wird (vermutlich) heute oder morgen jemand das Rendering so ändern,
> dass 
> erst das casing des Kanals, dann die Wasserfläche und dann der Kanal
> selbst 
> gemalt wird.

Erledigt.
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger

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

Re: [Talk-de] Your whishlist for Debian Packages?

[Joerg Ostertag (OSM Tettnang/Germany)]

On Dienstag 30 Dezember 2008, Sebastian Niehaus wrote:
> Sebastian Niehaus  writes:
> > "Joerg Ostertag (OSM Tettnang/Germany)" 
> > writes:
>
> [...]
>
> > josm is great
>
> Ich habe kürzlich einen *tierischen* Schwanz an zu installierenden
> Abhängigkeiten angezeigt bekommen:
>
> ,
>
> | crystalline:/tmp# aptitude update  && aptitude dist-upgrade
> | Treffer http://security.debian.org lenny/updates Release.gpg
> |
> |
> | [...]
> |
> | Aktueller Status: 4 Aktualisierungen [+4], 21934 Neue [+17].
> | Paketlisten werden gelesen... Fertig
> | Abhängigkeitsbaum wird aufgebaut
> | Lese Status-Informationen ein... Fertig
> | Lese erweiterte Statusinformationen
> | Initialisiere Paketstatus... Fertig
> | Lese Task-Beschreibungen... Fertig
> | Die folgenden NEUEN Pakete werden zusätzlich installiert:
> |   espeak{a} espeak-data{a} freetds-common{a} gda2-postgres{a} gdal-bin{a}
> | gpsdrive-data-maps{a} libaccess-bridge-java{a}
> | libboost-program-options1.34.1{a} libct4{a} libdbd-sqlite3-perl{a}
> | libespeak1{a} libgda2-3{a} libgda2-bin{a} libgda2-common{a}
> | libgda3-postgres{a} libspeechd2{a} libtext-query-perl{a}
> | libwww-mechanize-perl{a} mapnik-plugins{a} mapnik-utils{a}
> | openjdk-6-jre{a} openjdk-6-jre-headless{a} openjdk-6-jre-lib{a}
> | openstreetmap-map-icons{a} openstreetmap-map-icons-classic.small{a}
> | openstreetmap-mapnik-world-boundaries{a} postgis{a} postgresql-8.3{a}
> | postgresql-8.3-postgis{a} postgresql-common{a} python-mapnik{a} rhino{a}
> | ttf-arphic-uming{a} ttf-baekmuk{a} ttf-bengali-fonts{a}
> | ttf-devanagari-fonts{a} ttf-gujarati-fonts{a} ttf-indic-fonts{a}
> | ttf-kannada-fonts{a} ttf-malayalam-fonts{a} ttf-oriya-fonts{a}
> | ttf-punjabi-fonts{a} ttf-tamil-fonts{a} ttf-telugu-fonts{a}
> | tzdata-java{a}
> | Die folgenden Pakete werden aktualisiert:
> |   gpsdrive merkaartor openstreetmap-josm openstreetmap-utils
> | 4 Pakete aktualisiert, 45 zusätzlich installiert, 0 werden entfernt und 0
> | nicht aktualisiert. Muss 356MB an Archiven herunterladen. Nach dem
> | Entpacken werden 624MB zusätzlich belegt sein. Wollen Sie fortsetzen?
> | [Y/n/?]
>
> `
>
> Ich weiß nicht, wieso das alles plötzlich installiert werden soll,
> aber 624 MB Platz kann ich auf meinem Laptop nicht wirklich erübrigen.

Das hat vermutlich verschiedene Gründe:
- gpsdrive hatte eine defekte Abhängigkeitsliste, die ich vor ein paar
  Monaten gefixt habe. Damit werden die benötigten Abhängigkeiten jetzt
  wirklich gezogen.
- Ich habe umgestellt von java 1.5 auf java1.6
- Die openstreetmap-mapnik-world-boundaries alleine sind schon 270M. 
Diese
  werden aber nur für ein Mapnik Rendering benötigt.

Ich hoffe diese Tipps helfen dir weiter.

-
Joerg

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

Re: [Talk-de] Your whishlist for Debian Packages?

[Rainer Dorsch]

Am Dienstag, 30. Dezember 2008 schrieb Joerg Ostertag (OSM Tettnang/Germany):
> Repository for lenny (testing)
> /etc/apt/sources.list
> # Gpsdrive Packages
> deb     http://www.gpsdrive.de/debian etch main
> deb-src http://www.gpsdrive.de/debian etch main

Soll das wirklich etch (für lenny?) heißen?

Gruß,
Rainer

-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdor...@web.de
jabber: rdor...@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/

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

Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p

[Tobias Knerr]

Danke erstmal für dein umfangreiches Feedback. Ich wage inzwischen zu
hoffen, dass diese Linienbündel-Frage irgendwann doch mal befriedigend
gelöst werden kann.

Sven Anders schrieb:
> Am Dienstag, 30. Dezember 2008 12:43 schrieb Tobias Knerr:
>> http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group
> 
> Den Ansatz finde ich SEHR GUT. Aber ich denke wir sollten es irgendwie
> schaffen, das wir nur eine Relation brauchen, das andere verwirrt nur. 

Bei der Frage "nur eine Relation" sind wir leider schon
unterschiedlicher Meinung, was wohl auch daran liegt, dass für dich --
wie aus deinem Beispiel hervorgeht -- bei einer "voll erfassten" Straße
sämtliche Spuren als eigener Way vorliegen. In meinen Augen dürften
viele Straßen keine signifikant unterschiedlich verlaufenden Spuren
erfordern. Sehr wohl sind aber für "Vollerfassung" Dinge wie
unterschiedliche Oberflächenbeschaffenheit oder abweichende
Geschwindigkeitsbeschränkungen relevant. Die würden jedoch bei Verzicht
auf weitere Relationen zur Verwendung von Ways zwingen, weil weitere
Tags sonst nicht anzubringen wären -- mit allen Nachteilen wie Problemen
beim Verschieben u.ä. und einer überfüllteren Editor-Standardansicht.

Auch finde ich ehrlich gesagt deinen Ansatz hier nicht wirklich leichter
durchschaubar:

> Relation 100
> type=lane_group
> lane:+1=cycleway
> lane:+2=footway
> lane:-1=cycleway
> lane:-2=footway

> Relation 100
> type=lane_group
> [evtl:Optional]
> lane:+1=cycleway
> lane:+2=footway
> lane:-1=cycleway
> lane:-2=footway
> Members:
> highway ->  Way1
> highway_oposite -> Way2
> +1 ->Way3
> +2 ->Way5
> -1 -> Way4
> -2 -> Way6

Man kann bei dir eine Lane also sowohl als Way als auch als Tag einer
Relation darstellen. Bei Tag-Darstellung nimmt man nur den lane-Value
mit einem anderen Key, weiteres Tagging ist nicht möglich.
Die Keys und Rollen sind dabei leicht unterschiedlich und zwingen dazu,
die Numerierung (die ich eigentlich ohnehin eher unschön und umständlich
finde) auch dann noch zu behalten, wenn man dank geordneter Relationen
darauf verzichten hätte können -- denn sonst geht die Ordnung zwischen
Membern und Tags verloren.

Bei einer Modellierung per Relation ist die Sache doch recht klar: Eine
Spur entspricht genau einem "primitiven" OSM-Objekt: Way oder Relation.
Diese lassen sich in gleicher Weise mit Tags versehen und in gleicher
Weise in die zusammenfassende Relation einbinden.

Darüber hinaus halte ich die Auswertung in Programmen, gerade Editoren,
-- zumindest aus der beschränkten Erfahrung mit meinem Prototypen fürs
Lane-Plugin heraus -- für leichter, wenn man sich nur auf Member statt
auf alternativ Member oder Tags beschränkt. Ways und Relationen stimmen
hier in allen relevanten Eigenschaften (eigene ID, Tags) überein.
Die Programmierfreundlichkeit sollte zwar nicht primäres Kriterium sein,
ist aber nicht zu vernachlässigen, zumal sie auch darüber entscheidet,
wie leicht der für umfangreichere Erfassung  m.E. unabhängig vom Schema
nötige Editoren-Komfort eingebaut werden wird.

> Ein weiteres Problem sehe ich zur Zeit in größeren Straßen wie z.B. die 
> Amsinckstraße:
> 
> http://www.informationfreeway.org/?lat=53.544206425744335&lon=10.019533225294216&zoom=17&layers=BF000F
> 
> bzw.
> 
> http://maps.google.de/?ie=UTF8&ll=53.54412,10.020009&spn=0.000527,0.001196&t=k&z=20
> 
> Versuch das mal abzubilden! Das Problem ist das wir ja schon zwei 
> highway=prinary (für jede Richtung) haben.

Zwei-Highway-Straßen sind in der Tat ein gewisses Problem, und so etwas

> highway ->  Way1
> highway_oposite -> Way2

ist durchaus eine mögliche Lösung. Ich hätte der Einfachheit halber
(Sonderfälle...) allerdings bislang daran gedacht, jede Lane nur einem
der Highways zuzuordnen -- bei deinem Beispiel erscheint etwa der
Grünstreifen in der Mitte als plausible Trennstelle.

Geht der auswertenden Software damit Information verloren, an die ich
bislang nicht gedacht habe?

> == Was würde das für Renderer und Tools bedeuten? ==
> 
> * Beim drehen einer Straße müsste evtl. die Relation angepasst werden, aber 
> warum sollte jemand die Straßen drehen wollen

Das ist ein wichtiger Punkt, an den ich bislang nicht gedacht habe --
solche Spuren gehören in der Tat zu den richtungsabhängigen Informationen.

Tobias "Tordanik" Knerr

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

Re: [Talk-de] Anfängerfragen

[Marc Schütz]

> Frage2: Kann man irgendwo auf einem Blick sehen, ob solche Werte
> (Durchfahrtshöhe, Gewichtsbeschränkungen…) eingetragen sind?

M.W. im Moment noch nicht, aber es wäre ein Vorschlag für die Leute von der 
Geofabrik (Jochen Topf?), was sie noch in ihrem "OSM Inspektor" 
(http://tools.geofabrik.de/osmi/) unterbringen können. Man könnte dort eine 
Seite mit allem machen, was mit min_/max_ anfängt.

Grüße, Marc

-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

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

Re: [Talk-de] Canal und Riverbank

[Bernd Wurst]

Hallo.

Am Dienstag, 30. Dezember 2008 schrieb Norbert Kück:
> Zwinge den Renderer, die Reihenfolge
> zu ändern.  Gib der Wasserfläche ein layer=1.

Wieso, ist denn das Wasser im breiteren Bereich über dem Wasser im Haupt-
Kanal?

Es ist ein Fehler. Mehr nicht. Der Fehler wird behoben werden. Er besteht 
nicht so lange, dass man sich damit arrangieren muss. Es ist echt affig, wegen 
eines Fehlers in einem (!!) Renderer hier obskure Kopfstände zu machen um das 
Ergebnis möglichst heute noch schöner zu bekommen.

Es wird (vermutlich) heute oder morgen jemand das Rendering so ändern, dass 
erst das casing des Kanals, dann die Wasserfläche und dann der Kanal selbst 
gemalt wird. Dann ist alles wieder gut ohne dass für potenziell alle Ewigkeit 
an einem einzelnen Kanal ein layer getaggt wurde.

Gruß, Bernd

-- 
Eine Unterschrift enthüllt immer den Charakter eines Menschen.
Und manchmal sogar seinen Namen...



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] Fläche von Polygon berechnen?

[Bernd Wurst]

Hallo.

Am Dienstag, 30. Dezember 2008 schrieb Gary G::
> wozu? ganz einfach. ich spiele ja im augenblick mit dem programm
> mappingquality.pl (siehe wiki "Mapping Quality") und da wollte ich
> demnächst mal zusätzlich wohnflächen berechnen.

Ganz ehrlich:
Die Genauigkeit die du dafr haben willst, solltest du sogar bekommen wenn du 
die Erde als Ebene approximierst.

Dann kannst du mit der (*räusper* vergleichsweise) einfachen Formel von
http://de.wikipedia.org/wiki/Polygon#Fl.C3.A4che
arbeiten.

Das was du vor hast, sollte ja alles keine großen Flchenausdehnungen haben und 
daher der Fehler minimal sein.

Hat jemand ne Größenordnung, wie viel Fehler da bei einer Fläche von ca. 1 x 1 
km zusammenkommt? Denn ich denke das könnte in etwa die übliche Maximalgröße 
für Wohngebiete sein. Da das wesentlich weniger als eine zoom-12-Kachel ist, 
würde ich auf der Ebene arbeiten und die Kugel völlig ignorieren.

Gruß, Bernd

-- 
Die Demokratie, wie ich sie verstehe, muss dem Schwächsten die
gleichen Chancen zusichern wie dem Stärksten.  -  Mahatma Ghandi



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] INFAS Kreisgrenzen

[Bernd Wurst]

Hallo.

Am Dienstag, 30. Dezember 2008 schrieb Frederik Ramm:
> Wir machen den Import entweder heute abend oder, wenn wir noch über
> irgendein Hindernis stolpern, morgen früh. Also auf jeden Fall noch 2008
> ,-)

Klasse, vielen Dank!
Dann warte ich mal gespannt ab. :)


> Der Import wird wie geplant durchgeführt. Existierende Grenzen werden
> nicht gelöscht, sondern so umgetaggt

Ganz persönlich würde ich ja sagen, dass das sogar zu viel der Vorsicht ist 
(die bisherigen Grenzen sind bis auf wenige Ausnahmen einfach grottenschlecht 
im Vergleich). Aber klar, so fühlt sich dann sicher keiner zu sehr auf den 
Schlips getreten, wenn er vorher schon eine gute Quelle für seine Daten hatte.

Gruß, Bernd

-- 
Wohlstand ist, wenn die Menschen mehr Uhren haben als Zeit.



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] Canal und Riverbank

[Chris-Hein Lunkhusen]

André Reichelt schrieb:
> Chris-Hein Lunkhusen schrieb:
>> was hab ich denn hier für einen Fehler gemacht, dass der Kanal nicht
>> nahtlos mit der Riverbank verschmilzt?
> 
> Ich vermute, dass der Fehler in der Engine sitzt. Diese erkennt
> vermutlich nicht, dass dass die Beiden zusammen gehören und malt munter
> übereinander.

Jo, war auch meine Vermutung dass es mit dem geänderten Waterway-
Rendering zusammen hängt. Rechts, wo ich noch kein Neurendern
angestossen habe, sieht man ja noch dass der Kanal ohne
Umrandung gemalt wurde.

Chris



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

Re: [Talk-de] Mappen von verzweigten Wegen

[Peter Herison]

Peter Vitt schrieb:

>Schorschi schrieb:
>> Ich habe übrigens den layer-tag beim Bach mal weggenommen und die Brücken 
>> mit layer=1 ausgezeichnet - der layer-tag sagt nichts über die Höhe im 
>> Gelände aus, sondern nur, welches Element über welchem liegt - Brücken 
>> bekommen standardmäßig halt ein layer=1, Tunnel ein layer=-1.
>Ok, dann halt so. Ich bin bisher immer von Straßenniveau = 0
>ausgegangen, alles darunter entsprechend <0, darüber >0. Aber wenn das
>allgemein nicht Straßenniveau, sondern Erdbodenniveau ist, dann danke
>für den Hinweis.

Gar kein Niveau. Einfach nur, welcher way ist "unter" und welcher ist
"ueber".
Gar kein layer-Tag bedeutet implizit layer=0 und das ist in der Regel
Erdbodenniveau, muss aber nicht sein. Beispiel: Strassenverlauf wird
zum unterqueren einer Bahnlinie abgesenkt, verlaeuft also in einem
Graben. Uber den Graben geht eine echte Bruecke (kein Tunnel fuer die
Strasse!), dann bekommt die Eisenbahnbruecke layer=1, obwohl sie auf
Erdbodenniveau verlaeuft. Andererseits waere es auch nicht falsch der
Strasse (unter der Bruecke) layer=-1 zu verpassen und die Bruecke ohne
Layer-Tag zu mappen. Die Information, was "darueber" und was
"darunter" ist bleibt die gleiche. Ist halt nur ungewohnt und wird
bestimmt vom naechstbesten wieder umgetaggt. ;)

PS: Darueber, dass die Tags bridge=yes bzw. tunnel=yes bei einfachen
Situationen (kein Autobahndreieck mit zig ineinander verschlungenen
Bruecken / Tunneln) doch eigentlich schon ein "darueber" bzw.
"darunter" implizieren wurde hier schon oft diskutiert. Ergebnis: Es
wird immer noch bridge=yes;layer=1 getaggt... :)


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

Re: [Talk-de] Canal und Riverbank

[Norbert Kück]

Hallo,

Chris-Hein Lunkhusen schrieb:
> was hab ich denn hier für einen Fehler gemacht, dass der Kanal nicht
> nahtlos mit der Riverbank verschmilzt?
> 
> 

Scheinbar ist nichts falsch. Es gibt einen Kanal und eine Wasserfläche. 
Nun malt der Renderer in Schichten - erst die Wasserfläche und dann den 
Kanal. Dann sieht das eben so aus. Zwinge den Renderer, die Reihenfolge 
zu ändern.  Gib der Wasserfläche ein layer=1.

Gruß
nk

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

Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p

[Sven Anders]

Am Dienstag, 30. Dezember 2008 12:43 schrieb Tobias Knerr:
> Da ich hier auf der Mailingliste stark den Eindruck habe, dass die
> Diskussionen um Linienbündel etc. auf der Stelle treten, will ich mal
> einen konkreteren Vorschlag einwerfen:
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group
>
> Ich habe den Ansatz gewählt, einige wesentliche hinter dem Konzept
> stehende Ziele ausdrücklich aufzulisten. Insofern würde ich mich freuen,
> wenn wir bei der Diskussion unterscheiden könnten, ob wir
> unterschiedliche Zielvorstellungen haben, oder ein anderes Konzept
> dieselben Ziele auf anderem Weg erreichen würde.


Den Ansatz finde ich SEHR GUT. Aber ich denke wir sollten es irgendwie 
schaffen, das wir nur eine Relation brauchen, das andere verwirrt nur. 



Ein weiteres Problem sehe ich zur Zeit in größeren Straßen wie z.B. die 
Amsinckstraße:


http://www.informationfreeway.org/?lat=53.544206425744335&lon=10.019533225294216&zoom=17&layers=BF000F

bzw.

http://maps.google.de/?ie=UTF8&ll=53.54412,10.020009&spn=0.000527,0.001196&t=k&z=20

Versuch das mal abzubilden! Das Problem ist das wir ja schon zwei 
highway=prinary (für jede Richtung) haben.

Ich könnte mir aber sowas Vorstellen:

== Radwege sind in OSM nicht erfasst  ==

Way ID: 1 [3 Autospuren Stadteinwärts]
highway=primary
name=Amsinckstraße
lane=vehicle_lane
lanes=3 [Hier sind nur die Autospuren gemeint]
oneway=yes

Way ID 2  [3 Autospuren Stadtauswärts]
highway=primary
name=Amsinckstraße
lane=vehicle_lane
lanes=3 [Hier sind nur die Autospuren gemeint]
oneway=yes


Relation 100
type=lane_group
lane:+1=cycleway
lane:+2=footway
lane:-1=cycleway
lane:-2=footway
Members:
highway ->  Way1
highway_oposite -> Way2



== Voll in OSM erfaßte Straße ==

Way ID: 1 [3 Autospuren Stadteinwärts]
highway=primary
name=Amsinckstraße
lane=vehicle_lane
lanes=3 [Hier sind nur die Autospuren gemeint]
oneway=yes

Way ID 2  [3 Autospuren Stadtauswärts]
highway=primary
name=Amsinckstraße
lane=vehicle_lane
lanes=3 [Hier sind nur die Autospuren gemeint]
oneway=yes

Way ID 3 [Radweg Stadteinwärts]
lane=cycleway
name=Amsinckstraße
oneway=yes

Way ID 4[Radweg Stadtauswärts]
lane=cycleway
name=Amsinckstraße
oneway=yes

Way ID 5 [Fußweg Stadteinwärts]
lane=footway
name=Amsinckstraße
oneway=yes

Way ID 6[Fußweg Stadtauswärts]
lane=footway
name=Amsinckstraße
oneway=yes

Relation 100
type=lane_group
[evtl:Optional]
lane:+1=cycleway
lane:+2=footway
lane:-1=cycleway
lane:-2=footway
Members:
highway ->  Way1
highway_oposite -> Way2
+1 ->Way3
+2 ->Way5
-1 -> Way4
-2 -> Way6

== Was würde das für Renderer und Tools bedeuten? ==

* Beim drehen einer Straße müsste evtl. die Relation angepasst werden, aber 
warum sollte jemand die Straßen drehen wollen
* Renderer müssten um z.B. wie bei opencylcemaps.org einen blauen Rand zu 
zeichnen schon recht aufwendig die Relation untersuchen.

Gruß
Sven







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

Re: [Talk-de] Canal und Riverbank

[André Reichelt]

Chris-Hein Lunkhusen schrieb:
> was hab ich denn hier für einen Fehler gemacht, dass der Kanal nicht
> nahtlos mit der Riverbank verschmilzt?

Ich vermute, dass der Fehler in der Engine sitzt. Diese erkennt
vermutlich nicht, dass dass die Beiden zusammen gehören und malt munter
übereinander.



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

Re: [Talk-de] Mappen von verzweigten Wegen

[Tobias Wendorff]

Peter Vitt schrieb:
> Es geht darum, dass ich zwei Straßen habe, die jeweils eine zweite
> "Kante" besitzen, die nur wenige Meter lang ist. Wenn ich dort auch
> alle Tags eintrage, wird der Name extrem hässlich in diese Wege
> gerendert. Ich dachte, mit einer Relation könnte man dies umgehen.
> allerdings wird so überhaupt kein Name gerendert.

Schreib' eine Bug-Meldung an Mapnik / Osmarender - es betrifft ja
nicht die Daten ansich.

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

Re: [Talk-de] Mappen von verzweigten Wegen

[Frank Jäger]

Peter Vitt schrieb:
> LiLi,
> 
> Wie mappe ich einen verzweigten Weg? 

Hallo Peter,
man setzt an einer geeigneten Stelle neu an und bildet mehrere Ways.
Alle bekommen den gleichen Name-Tag.

Ein Anfängerfehler, den ich in meiner Region schon oft repariert habe, 
ist es, den Verlauf in einen Stichweg hinein und über die gleichen 
Punkte wieder hinaus zu führen. Die Straße überlappt sich dann selbst.

Die Editoren lassen das zwar zu, aber bei der nächsten Validierung wird 
das dann bemängelt. Man kann das in JOSM an den doppelten Pfeilspitzen 
erkennen, die ein Stück Weg zwischen zwei Punkten dann hat.

Das Reparieren ist nicht einfach. Man muss den Weg zunächst auftrennen 
und von den übereinander liegenden Teilen dann nur einen zum Löschen 
auswählen.

Zum Beispiel in einem Wohngebiet, wenn die
> Straße plötzlich noch einen Abstecher macht, um einige zurückgesetzte Häuser
> anzubinden? 

Das könnte im Einzelfall auch "highway=service" sein.

(Schmaler als die Straße? Privatweg?)

Oder wenn die Einfahrt in eine Straße von einer größeren Straße aus
> zwei Teilen (einmal von links, einmal von rechts) besteht?
..

Wenn eine Straße nur für ein kurzes Stück getrennte Fahrbahnen hat, muss 
man nicht zwangsläufig zwei Wege mappen.
Es kommt darauf an, ob die Trennung für die Verkehrsführung relevant ist.
Wenn beide Teile auf die gleiche Hauptstraße münden und die "Insel" 
dazwischen nur der Sicherheit der Fußgänger dient, dann muss man den Way 
nicht in zwei parallele Einbahnstraßen aufteilen.

> 
> mfG, Peter
> 


-- 
Frank Jäger


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

Re: [Talk-de] Mappen von verzweigten Wegen

[Peter Vitt]

Schorschi schrieb:
> Moin Peter,
>
> Antwort hast du ja schon - als verbundene Wege mit gleichen Namen; 
>   
Also ohne Relation. Danke.
> Ich habe übrigens den layer-tag beim Bach mal weggenommen und die Brücken 
> mit layer=1 ausgezeichnet - der layer-tag sagt nichts über die Höhe im 
> Gelände aus, sondern nur, welches Element über welchem liegt - Brücken 
> bekommen standardmäßig halt ein layer=1, Tunnel ein layer=-1.
>   
Ok, dann halt so. Ich bin bisher immer von Straßenniveau = 0
ausgegangen, alles darunter entsprechend <0, darüber >0. Aber wenn das
allgemein nicht Straßenniveau, sondern Erdbodenniveau ist, dann danke
für den Hinweis.
> Eine Höhe kann man dem Bach auch zuweisen (über den ele-tag), dazu braucht 
> es aber meiner Erfahrung nach bessere Daten als (m)ein einfacher 
> GPS-Datenlogger liefert ...
>   
Die liefert der OSMtracker. Allerdings übertrage ich sie selten. Kann
ich ja in Zukunft dann mal so übernehmen.
> Gruß, Schusch
>
> On Tue, 30 Dec 2008, Peter Vitt wrote
mfG, Peter


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

[Talk-de] Canal und Riverbank

[Chris-Hein Lunkhusen]

Moin,

was hab ich denn hier für einen Fehler gemacht, dass der Kanal nicht
nahtlos mit der Riverbank verschmilzt?



Grüße,
Chris


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

Re: [Talk-de] Mappen von verzweigten Wegen

[Schorschi]

Moin Peter,

Antwort hast du ja schon - als verbundene Wege mit gleichen Namen; 

Ich habe übrigens den layer-tag beim Bach mal weggenommen und die Brücken 
mit layer=1 ausgezeichnet - der layer-tag sagt nichts über die Höhe im 
Gelände aus, sondern nur, welches Element über welchem liegt - Brücken 
bekommen standardmäßig halt ein layer=1, Tunnel ein layer=-1.

Eine Höhe kann man dem Bach auch zuweisen (über den ele-tag), dazu braucht 
es aber meiner Erfahrung nach bessere Daten als (m)ein einfacher 
GPS-Datenlogger liefert ...

Gruß, Schusch

On Tue, 30 Dec 2008, Peter Vitt wrote:

> Wie mappe ich einen verzweigten Weg? Zum Beispiel in einem Wohngebiet, wenn 
> die
> Straße plötzlich noch einen Abstecher macht, um einige zurückgesetzte Häuser
> anzubinden? Oder wenn die Einfahrt in eine Straße von einer größeren Straße 
> aus
> zwei Teilen (einmal von links, einmal von rechts) besteht?___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mappen von verzweigten Wegen

[Peter Vitt]

Chris-Hein Lunkhusen schrieb:
> Peter Vitt schrieb:
>> LiLi,
>
> Liebe Liste?
Ja.
>> Wie mappe ich einen verzweigten Weg?
>
> Na, indem Du 2 Wege einzeichnest die sich berühren.
> In JOSM geeignete Hilfsmittel: Join (Punkt in Weg
> einfügen) oder Merge (2 Punkte verbinden)
Das ist mir schon klar. Wie gesagt, schaut euch bitte einmal

an.
Es geht darum, dass ich zwei Straßen habe, die jeweils eine zweite
"Kante" besitzen, die nur wenige Meter lang ist. Wenn ich dort auch
alle Tags eintrage, wird der Name extrem hässlich in diese Wege
gerendert. Ich dachte, mit einer Relation könnte man dies umgehen.
allerdings wird so überhaupt kein Name gerendert.

mfG, Peter



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

Re: [Talk-de] Linienbündel , Radwege

[Sven Anders]

Am Dienstag, 30. Dezember 2008 14:18 schrieb Wolfgang Wienke:
> Hallo!
> Ich hoffe, die Fachleute haben bald ausdiskutiert und entschieden! ,-)
> Ich bin da nur ein Neuling und verstehe nicht alle Details. Ich habe
> aber den Eindruck, dass eine Anpassung/Klarstellung des Wikis noch nicht
> in Sicht ist. Eigentlich möchte ich mich nur mit den Radwegen
> beschäftigen, weiß aber zur Zeit wirklich nicht, wie ich es richtig
> mache. Wenn nämlich nachher doch alle Arbeit umsonst ist, stelle ich
> meine Mitarbeit lieber gleich ein.
> Ich habe deshalb einfach mal eine Wiki-Klarstellung geschrieben und
> hoffe, das die dann möglichst bald (bitte bitte) passend überarbeitet
> ins Wiki gesetzt wird. Sie muss ja noch nicht ALLE Fälle umfassen,
> sondern nur konkreter sein als das bisherige.
> Wenn ich das einfach selbst mache, löse ich damit wahrscheinlich nur
> einen edit-war aus.

Was mache ich denn nun, wenn ich mit dem Text den du geschrieben hast 
unzufrieden bin und nicht das Gefühl habe, das das so ins Wiki soll?

Speziell geht es mir um:
>
> 2)
> Radweg, der von der Straße nur durch eine Kante wie eine
> Bürgersteigkante abgetrennt ist, insbesondere im innerstädtischen
> Bereich. Meist Kennzeichnung durch Zeichen 240 oder 241.

STATT:
> Der Radweg wird NICHT als selbstständiger Weg gezeichnet. 
> Das highway-Tag erhält nur den Zusatz cycleway=track.

Der Radweg kann als selbständiger Weg gezeichnet werden (siehe unter 3)
Wird er es nicht selbständig gezeichnet wird: erhält der highway  nur den 
Zusatz cycleway=track.

Ich finde es wie schon in meinen letzen Postings beschrieben sehr 
problematisch, wenn man den Radweg und Fußweg nicht einzeichnen darf.


Gruß
Sven

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

Re: [Talk-de] Mappen von verzweigten Wegen

[Tobias Wendorff]

Dimitri Junker schrieb:
>> Wie mappe ich einen verzweigten Weg?
> 
> als 2 Wege mit gleichem Namen.

Hat man dann nicht diese Superways, die vermieten werden sollen?

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

Re: [Talk-de] Mappen von verzweigten Wegen

[Chris-Hein Lunkhusen]

Peter Vitt schrieb:
> LiLi,

Liebe Liste?

> Wie mappe ich einen verzweigten Weg? 

Na, indem Du 2 Wege einzeichnest die sich berühren.
In JOSM geeignete Hilfsmittel: Join (Punkt in Weg
einfügen) oder Merge (2 Punkte verbinden).

Grüße
Chris


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

Re: [Talk-de] Mappen von verzweigten Wegen

[Dimitri Junker]

Hallo,

>Wie mappe ich einen verzweigten Weg?


als 2 Wege mit gleichem Namen.

Dimitri

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

Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)

[Dimitri Junker]

>Versteh ich nicht. Das gibt doch nur an auf welcher Seite der Radweg
>liegt. Oder bemängelst du damit, dass man zusätzlich noch
>cycleway.type=lane angeben muss?


Bisher haben wir zum Key cycleway u.a. track und lane. Das von Dir 
vorgeschlagene right/left ist keine Alternative dazu sondern ein Zusatz. Man 
muß angeben können, daß der rechte Fahrradweg ein lane und der linke ein 
track ist. Deshalb z.B.
cycleway=left:track
Ein

>cycleway.type=lan


würde da auch nicht helfen.

>Natürlich könnte man auch optional einen Wert wie left:track definieren,
>um gleich beide Informationen auf einmal angeben zu können.


Man muß sie zusammen angeben, weil es ja 2 Fahrradwege geben kann.


>cycleway=none/both:track/right/.. sollte dann aber auch möglich sein.


Der Nutzen von none ist mir noch nicht klar, both wäre z.B. bei 
Einbahnstraße sinnvoll als bessere Alternative zu cycleway=opposite

>Welche Schreibweise man intuitiv einleuchtender findet ist wohl
>subjektiv sehr unterschiedlich.


Da hätte ich gerne eine Aussage von Progrmierern ob das da einen 
gravierenden Unterschied machen würde.


>Könnte man nicht mal schauen wo bei meinem Vorschlag die Schwachstellen
>sind


I.W. habe ich ihm ja zugestimmt.

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

Re: [Talk-de] Linienbündel, Radwege

[Dimitri Junker]

>Wenn nämlich nachher doch alle Arbeit umsonst ist, stelle ich meine
>Mitarbeit lieber gleich ein.


Mach es so wie Du es für sinnvoll hälst, shreib ggf. irgendwas als note 
rein, so daß Du sie einfach wiederfindest, wenn wir dann mal einen Konsens 
gebildet haben kannst Du sie anpassen, alles was bisher nicht tagbar ist 
kannst Du entweder provisorisch in eigene Tags schreiben oder auch ins Note

>cycleway=lane:right bzw. cycleway=lane:left getaggt,


Ich wollte mal ein Proposal zu right/left machen, hab aber noch nie ein 
Proposal geschrieben. Ich vermute, daß es programiertechnisch geschickter 
ist das right/left vor den Value zu schreiben, also 
cycleway=left:lane
Aber da werde ich die unterschiedlichen Varianten zur Diskussion stellen.


>Eine solche Radspur ist standardmäßig nicht für Fußgänger zugelassen,
>sonst foot=yes.

das müßte dann um in Deiner Nomenklatur zu bleiben

cycleway=foot:yes.

sein, sonst kann man ja nicht unterscheiden ob Fußgänger auf diesem 
Fahrradweg oder auf dem daneben liegendem Bürgersteig gehen dürfen.

>Radweg, der von der Straße nur durch eine Kante wie eine
>Bürgersteigkante abgetrennt ist, insbesondere im innerstädtischen
>Bereich.


Häufig unterbrochene schmale (<1m) Grünstreifen oder Parkstreifen würde ich 
auch noch erlauben.

>Bei optisch getrenntem Rad/ Fußweg (Zeichen 241) wird segregated=yes
>ergänzt,


Wo ist segregated definiert? Ist klar, daß es sich auf den 
Fußgänger-/Fahrradweg bezieht?
sonst wieder:
cycleway=segregated:yes.


Ansonsten würde ich dafür stimmen

Dimitri

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

[Talk-de] Mappen von verzweigten Wegen

[Peter Vitt]

LiLi,

Wie mappe ich einen verzweigten Weg? Zum Beispiel in einem Wohngebiet, wenn die
Straße plötzlich noch einen Abstecher macht, um einige zurückgesetzte Häuser
anzubinden? Oder wenn die Einfahrt in eine Straße von einer größeren Straße aus
zwei Teilen (einmal von links, einmal von rechts) besteht?
Zu sehen gibt es beides im Ort Herzhausen


mfG, Peter


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

Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)

[Sebastian Hohmann]

Dimitri Junker schrieb:
> Hallo,
> 
> 
>> Leider scheinen sich dafür aber wenige zu interessieren.
> 
> 
> Mangelndes Interesse kann man mir ja nicht nachsagen, aber selbst bei mir 
> ist Dein Vorschlag noch nicht angekommen. Gibt es eigentlich eine 
> Mailingliste für Proposed_features, wo also eine Kurze Nachricht kommt: 
> neuer Vorschalg...
> 

Zum Beispiel in dieser Liste [1].

> 
>> Warum ist das mit der Straßenseite so schwer zu lösen?
> 
> 
> Ich sehe da auch kein Problem. Mit etwas Unterstützuung des Editors ist es 
> trivial.
> Man muß sich nur drauf einigen wo left und right hinsollen. Ich sehe da 3 
> Möglichkeiten:
> in den Key also
> left:cycleway=track
> in den Value:
> cycleway=left:track
> oder in ein neues Feld neben Key und Value.
> dies wäre die sauberste Lösung aber ein großer Eingriff ins Datenmodell. Am 
> einfachsten einzubinden wäre sicherlich es in den Value zu schreiben.
> 
> Was mir bei Deinem Vorschalg nicht gefällt ist:
> cycleway=right
> u.ä. right ist keine Alternative zu track, path,... sondern eine 
> Zustazinformation.
> 

Versteh ich nicht. Das gibt doch nur an auf welcher Seite der Radweg 
liegt. Oder bemängelst du damit, dass man zusätzlich noch 
cycleway.type=lane angeben muss?

Zunächst wird angegeben wo sich ein Weg befindet, left/right oder both. 
Dann können die Wege genauer beschrieben werden. Das hat den Vorteil, 
dass man einen Weg auch mappen oder rendern kann ohne die Details zu 
berücksichtigen, also nur danach ob rechts oder links einer vorhanden 
ist. Wenn man noch wissen will ob es ein lane oder track ist muss man 
eben den detaillierteren Tag benutzen.

Natürlich könnte man auch optional einen Wert wie left:track definieren, 
um gleich beide Informationen auf einmal angeben zu können. 
cycleway=none/both:track/right/.. sollte dann aber auch möglich sein.

Welche Schreibweise man intuitiv einleuchtender findet ist wohl 
subjektiv sehr unterschiedlich. Der eine mag left:cycleway=* lieber, der 
andere cycleway:left=*.

Man könnte natürlich auch die Schlüssel left/right/both definieren, die 
jweils die Wege links/rechts/auf beiden Seiten angeben. Die Frage ist 
dann wieder ob man dabei überhaupt quasi cycleway als Wert im Schlüssel 
benutzen möchte. Das wäre ja sowas Ähnliches wie highway:residential=*.

Es gibt einfach tausend Möglichkeiten. Könnte man nicht mal schauen wo 
bei meinem Vorschlag die Schwachstellen sind und dann versuchen auch 
genau die auszumerzen, anstatt immer wieder neue Vorschläge zu machen? 
Wenn andere Möglichkeiten besser sind, sollte man dadurch ja eigentlich 
darauf kommen. Ansonsten sind die verschiedenen Möglichkeiten doch nur 
Geschmackssache, weiter kommt man damit irgendwie auch nicht.

Gruß

[1] http://www.mail-archive.com/talk-de@openstreetmap.org/msg31198.html


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

Re: [Talk-de] route=train oder route=rail?

[Melchior Moos]

> Lass' Dich bitte nicht beim Abkopieren der Kursbuchnummern erwischen
> (Datenbankschutz). Die DB Netz AG hat uns eindeutig signalisiert,
> dass sie keine Kooperation will.
>
> Frag' mal den RAN, ob er die Kursbücher für uns freigeben will. Die
> sind sicherlich freundlicher :-)
>

Ich persönlich finde diese Nummern auch unwichtig. Normal sterbliche haben
fragen wie "wo liegt eigentlich die KBS 470?" doch eher selten. Die Frage
kam nur auf, weil es Leute gibt, die die Kursbuchstrecken eben als
Relationen mit den im Titel stehenden Tags eintragen.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Your whishlist for Debian Packages?

[Sebastian Niehaus]

Sebastian Niehaus  writes:

> "Joerg Ostertag (OSM Tettnang/Germany)"  writes:

[...]


> josm is great

Ich habe kürzlich einen *tierischen* Schwanz an zu installierenden
Abhängigkeiten angezeigt bekommen:

,
| crystalline:/tmp# aptitude update  && aptitude dist-upgrade
| Treffer http://security.debian.org lenny/updates Release.gpg
| 
| 
| [...]
| 
| Aktueller Status: 4 Aktualisierungen [+4], 21934 Neue [+17].
| Paketlisten werden gelesen... Fertig
| Abhängigkeitsbaum wird aufgebaut
| Lese Status-Informationen ein... Fertig
| Lese erweiterte Statusinformationen
| Initialisiere Paketstatus... Fertig
| Lese Task-Beschreibungen... Fertig
| Die folgenden NEUEN Pakete werden zusätzlich installiert:
|   espeak{a} espeak-data{a} freetds-common{a} gda2-postgres{a} gdal-bin{a} 
gpsdrive-data-maps{a} libaccess-bridge-java{a}
|   libboost-program-options1.34.1{a} libct4{a} libdbd-sqlite3-perl{a} 
libespeak1{a} libgda2-3{a} libgda2-bin{a} libgda2-common{a}
|   libgda3-postgres{a} libspeechd2{a} libtext-query-perl{a} 
libwww-mechanize-perl{a} mapnik-plugins{a} mapnik-utils{a} openjdk-6-jre{a}
|   openjdk-6-jre-headless{a} openjdk-6-jre-lib{a} openstreetmap-map-icons{a} 
openstreetmap-map-icons-classic.small{a}
|   openstreetmap-mapnik-world-boundaries{a} postgis{a} postgresql-8.3{a} 
postgresql-8.3-postgis{a} postgresql-common{a} python-mapnik{a}
|   rhino{a} ttf-arphic-uming{a} ttf-baekmuk{a} ttf-bengali-fonts{a} 
ttf-devanagari-fonts{a} ttf-gujarati-fonts{a} ttf-indic-fonts{a}
|   ttf-kannada-fonts{a} ttf-malayalam-fonts{a} ttf-oriya-fonts{a} 
ttf-punjabi-fonts{a} ttf-tamil-fonts{a} ttf-telugu-fonts{a}
|   tzdata-java{a}
| Die folgenden Pakete werden aktualisiert:
|   gpsdrive merkaartor openstreetmap-josm openstreetmap-utils
| 4 Pakete aktualisiert, 45 zusätzlich installiert, 0 werden entfernt und 0 
nicht aktualisiert.
| Muss 356MB an Archiven herunterladen. Nach dem Entpacken werden 624MB 
zusätzlich belegt sein.
| Wollen Sie fortsetzen? [Y/n/?] 
`

Ich weiß nicht, wieso das alles plötzlich installiert werden soll,
aber 624 MB Platz kann ich auf meinem Laptop nicht wirklich erübrigen.


Gruß,


Sebastian 


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

Re: [Talk-de] INFAS Kreisgrenzen

[Frederik Ramm]

Hallo,

Bernd Wurst wrote:
> Ich fand, der Import der Infas-Kreisgrenzen klang so gut durchgeplant, schon 
> von Anfang an... :)

Hat sich ja auch Jochen ausgedacht ;-)

> Ich habe auch Verständnis dafür, wenn diese Daten eben nicht hopplahopp und 
> verzwungen einfach importiert werden. Aber wäre es möglich, die Grenzverläufe 
> vorab als OSM-Datei zur Verfügung zu stellen, so dass man die bestehende, 
> ziemlich unscharfe und stellenweise auch falsche Grenze durch etwas ersetzen 
> könnte was besser passt?

Wir machen den Import entweder heute abend oder, wenn wir noch über 
irgendein Hindernis stolpern, morgen früh. Also auf jeden Fall noch 2008 ,-)

Für die neu Hinzugekommenen - hier steht, worum es geht:
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Kreisgrenzen_Deutschland_2005

Der Import wird wie geplant durchgeführt. Existierende Grenzen werden 
nicht gelöscht, sondern so umgetaggt, dass sie im Rendering nicht mehr 
erscheinen. Es wird dann Aufgabe der Mapper vor Ort, sich davon zu 
ueberzeugen, dass die neue Grenze auch taugt, und die alte dann vollends 
zu entsorgen.

Handarbeit wird es auch an den Grenzen Deutschlands geben, wo die neuen 
Grenz-Ways in die jeweiligen Relationen der Nachbarländer eingepflegt 
werden müssen.

Wir arbeiten gerade noch an ein paar Import-Sonderwünschen und 
versuchen, die Sachsen-Kreisreform möglichst gut einzubauen.

Bye
Frederik


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

Re: [Talk-de] Your whishlist for Debian Packages?

[Sebastian Niehaus]

"Joerg Ostertag (OSM Tettnang/Germany)"  writes:


> as most of you probably know I'm providing debian packages for the most 
> common 
> tools needed to work with OpenStreetMap. 
> What I'd like to know is:
>- which additional tools from the osm-svn would you like to see added to
>  the debian repository?
>- which other debian based platforms would you like to see suported?
>  examples would be: debian-etch, Ubuntu-xx, ...

Well, I prefer debian-etch...

> If you give me a preferences list, I can start with the most wanted ones 

> More description on the existing debian repository can be found at:
>   http://www.gpsdrive.de/development/debian.shtml


josm is great, merkaartor would be fine too. Where can I report bugs
concerning the packages from http://www.gpsdrive.de/debian ?


http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.de/30514

Thanks für your committment!


Sebastian 


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

Re: [Talk-de] route=train oder route=rail?

[Tobias Wendorff]

Melchior Moos schrieb:
> Im Prinzip würde ich auch sagen es spricht nichts dagegen, allerdings 
> werden momentan auch Kursbuchstrecken mit beiden Tags versehen. 
> Vielleicht könnte man einen der beiden für Kursbuchstrecken nehmen und 
> den anderen für Zuglinien... oder wir führen ein weiteres Tag ein.

Lass' Dich bitte nicht beim Abkopieren der Kursbuchnummern erwischen
(Datenbankschutz). Die DB Netz AG hat uns eindeutig signalisiert,
dass sie keine Kooperation will.

Frag' mal den RAN, ob er die Kursbücher für uns freigeben will. Die
sind sicherlich freundlicher :-)

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

Re: [Talk-de] Steigungen

[Tobias Knerr]

Andreas Labres schrieb:
> Tobias Knerr wrote:
>> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dincline
> 
> Klingt besser.
> […]
> ... außer dem mit dem Vorzeichen (was passiert, wenn Du den Weg umdrehst)? Mir
> ist auch beim vorgeschlagenen Rendering nicht klar, wo's da jetzt 
> hinaufgeht...

Steigung in Wegrichtung, bei Gefälle also ein negativer Wert. Umdrehen
erfordert Vorzeichenwechsel. Dagegen, dass ein Steigungs-Tag
richtungsabhängig ist und beim Umdrehen berücksichtigt werden muss, kann
man wohl nichts tun, da alle mir bekannten Alternativen (etwa
Himmelsrichtungen) deutlich unangenehmer zu handhaben sind.

Das Rendering finde ich auch nicht so ideal, aber das kann man eh im
Renderer entscheiden.

Tobias "Tordanik" Knerr

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

[Talk-de] Linienbündel, Radwege

[Wolfgang Wienke]

Hallo!
Ich hoffe, die Fachleute haben bald ausdiskutiert und entschieden! ,-)
Ich bin da nur ein Neuling und verstehe nicht alle Details. Ich habe
aber den Eindruck, dass eine Anpassung/Klarstellung des Wikis noch nicht 
in Sicht ist. Eigentlich möchte ich mich nur mit den Radwegen 
beschäftigen, weiß aber zur Zeit wirklich nicht, wie ich es richtig 
mache. Wenn nämlich nachher doch alle Arbeit umsonst ist, stelle ich 
meine Mitarbeit lieber gleich ein.
Ich habe deshalb einfach mal eine Wiki-Klarstellung geschrieben und 
hoffe, das die dann möglichst bald (bitte bitte) passend überarbeitet 
ins Wiki gesetzt wird. Sie muss ja noch nicht ALLE Fälle umfassen, 
sondern nur konkreter sein als das bisherige.
Wenn ich das einfach selbst mache, löse ich damit wahrscheinlich nur 
einen edit-war aus.

Änderung zu http://wiki.openstreetmap.org/wiki/DE:Bicycle/overview_ways:
(Es wären noch andere Stellen und evtl. andere Sprachen anzupassen)

Straßenbegleitende Radwege bzw. Rad/Fußwege
1)
Radweg, der mit der Straße höhengleich ist , auf der gleichen
Pflasterung verläuft und zu Straße höchstens eine optische Trennung
aufweist:
Der Radweg wird NICHT als selbstständiger Weg gezeichnet. Das
highway-Tag erhält nur den Zusatz cycleway=lane.
Liegt dieser Radweg nur auf EINER Seite der Straße vor, wird
cycleway=lane:right bzw. cycleway=lane:left getaggt, wobei sich right/
left auf die durch die Pfeile angezeigte Richtung der Straße bezieht.
Auch wenn die Straße aus 2 Richtungsspuren besteht, die jeweils mit
oneway=yes gekennzeichnet sind, ist cycleway=lane:right zu setzen. Die
Randspuren dürfen standardmäßig nur in der jeweiligen Fahrtrichtung der
Straße befahren werden, sonst cycleway=oneway:no.
Eine solche Radspur ist standardmäßig nicht für Fußgänger zugelassen,
sonst foot=yes.
Ein solcher Radweg umfasst bezüglich der gesetzlichen Regelung die
folgenden Fälle:
< bisheriger Text zu Radstreifen neben Fahrbahn, Schutzstreifen,
Straßenbegleitender anderer Radweg, Straßenbegleitender Radweg außerorts>

2)
Radweg, der von der Straße nur durch eine Kante wie eine
Bürgersteigkante abgetrennt ist, insbesondere im innerstädtischen
Bereich. Meist Kennzeichnung durch Zeichen 240 oder 241.
Der Radweg wird NICHT als selbstständiger Weg gezeichnet. Das
highway-Tag erhält nur den Zusatz cycleway=track.
Bei optisch getrenntem Rad/ Fußweg (Zeichen 241) wird segregated=yes
ergänzt, bei Zeichen 240 segregated=no. Liegt dieser Radweg nur auf
EINER Seite der Straße vor, wird cycleway=track:right bzw.
cycleway=track:left getaggt, wobei sich right/left auf die durch die
Pfeile angezeigte Richtung der Straße bezieht.
Bei unterschiedlichen Verhältnissen auf beiden Seiten der Straße wird
segregated=no/yes:right/left ergänzt.
Fußwege, die nur mit dem Zusatzzeichen 1022-10 für Radfahrer freigegeben
sind und nur mit Schrittgeschwindigkeit befahren werden dürfen, werden
auch weiterhin nicht als cycleway sondern als path gekennzeichnet und
nur mit dem Zusatz bicycle=yes ergänzt.


3)
Radweg, der von der Straße durch einen mehrere Meter breiten nicht
befahrbaren Streifen abgetrennt ist, insbesondere im außerstädtischen
Bereich. Weiterhin auch Radwege insbesondere im innerstädtischen
Bereich, die besondere Führungen unabhängig von der Straße z.B. an
größeren Kreuzungen aufweisen.
Der Radweg wird als separater Weg eingezeichnet, wobei die reale
Wegführung aufgenommen werden sollte. Als Tag wird highway=cycleway
gesetzt. Der Radweg ist standardmäßig in beide Richtungen befahrbar,
sonst oneway=yes. An Kreuzungen mit Straßen sollte auf den
Kreuzungspunkt ein Wegpunkt gesetzt werden, um ein Routing zwischen
Straße und Radweg zu ermöglichen. Weiterhin sollten alle Verbindungen
zwischen Straße und Radweg insbeondere an T-Kreuzungen eingezeichnet werden.
Der Radweg ist standardmäßig auch für Fußgänger zugelassen, sonst foot=no.


Vielleicht kann man das ganze auch durch eine Tabelle noch kürzer
fassen. Weitere Bilder fehlen noch.
Einbahnstraßen: Siehe gesonderte Regeln
-- 
Mit freundlichen Gruessen

  Wolfgang Wienke



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

Re: [Talk-de] Steigungen

[Andreas Labres]

Tobias Knerr wrote:
> Da gabs auch mal ein Proposal:
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dincline

Klingt besser.

> Außer dem Einwand, dass zwischen maximaler und durchschnittlicher
> Steigung unterschieden werden sollte, bestanden eigentlich keine
> Probleme damit

... außer dem mit dem Vorzeichen (was passiert, wenn Du den Weg umdrehst)? Mir
ist auch beim vorgeschlagenen Rendering nicht klar, wo's da jetzt hinaufgeht...

Servus, Andreas

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

Re: [Talk-de] JOSM-Latest

[Dirk Stöcker]

On Tue, 30 Dec 2008, Joerg Ostertag (OSM Tettnang/Germany) wrote:

 http://josm.openstreetmap.de/download/josm-tested.jar
>
> Was haltet ihr davon die benennung in Anlehnung an die debian releases
>   - josm-stable.jar
>   - josm-testing.jar
> zu nennen?

Ist es schon. josm-tested ist der Kompromiss, da es eben weder stable ist, 
noch testing. Es ist eben tested :-)

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

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

Re: [Talk-de] Your whishlist for Debian Packages?

[Joerg Ostertag (OSM Tettnang/Germany)]

On Montag 29 Dezember 2008, Rainer Dorsch wrote:
> Hallo Joerg,
>
> Am Sonntag, 28. Dezember 2008 schrieb Joerg Ostertag (OSM Tettnang/Germany):
> > Hi,
> >
> > as most of you probably know I'm providing debian packages for the most
> > common tools needed to work with OpenStreetMap.
> > What I'd like to know is:
> >- which additional tools from the osm-svn would you like to see added
> > to the debian repository?
> >- which other debian based platforms would you like to see suported?
> >  examples would be: debian-etch, Ubuntu-xx, ...
>
> Lenny, aber das scheint ja schon da zu sein.
>
> Da ist ja schon einiges da, das reicht mir erstmal :-)
>
> Ich habe auf Anhieb nicht die sources.list Zeile gefunden. Ist das Absicht?

Ich hab ein paar kommentarzeilen eingefügt und musste grade selber 
feststellen, dass manche Browser mir das übel nehmen und Text ausblenden. 
Jetzt sollte wieder alles zu sehen sein. 

Nur so zur Vorwarnung. Ich werde in den nächsten Tagen/Wochen das Repository 
umbauen/erweitern, so dass ich mehr Distributionen gleichzeitig unterstützen 
kann. Daher kann es zwischendurch zu unregelmäßigkeiten kommen. Ich bin aber 
auch da für jeden Tipp Dankbar.

Das Wichtigste aber hier nochmal:

Repository for lenny (testing)
/etc/apt/sources.list
# Gpsdrive Packages
deb http://www.gpsdrive.de/debian etch main
deb-src http://www.gpsdrive.de/debian etch main

Signature
 My Debian Packages are signed with: My Debian Key gpg.pub 
 Fingerprint = D40C 74CF 06DC 8460 D95E 7F56 3A83 5520 2210 9630 
check with: gpg --fingerprint 147DAD31 
 
 If you trust me, you can add my gpg key to your debian System for 
packages 
 gpg --keyserver wwwkeys.de.pgp.net --recv-keys 147DAD31 
 gpg --edit-key trust 147DAD31 
 gpg --armor --export 147DAD31 | sudo apt-key add -
-- 
Jörg (Germany, Tettnang)

http://www.ostertag.name/

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

Re: [Talk-de] Your whishlist for Debian Packages?

[Joerg Ostertag (OSM Tettnang/Germany)]

On Montag 29 Dezember 2008, Bernd Distler wrote:
> On Sun, 28 Dec 2008 21:44 +0100, "Joerg Ostertag (OSM Tettnang/Germany)"
>
>  wrote:
> > > Ich hoffe/denke mal, gpsbabel 1.3.6 (bzw. dann neuere Versionen) wäre
> > > da richtig aufgehoben. Bisher habe ich leider kein Debian-Paket dazu
> > > gefunden.
> >
> > Na ja, nicht ganz aus dem OpenStreetMap repository ;-)
> >
> > Vermutlich werd ich mich da nicht dranwagen 

Wie ist denn die SVN URL?
Falls ich mich doch entscheide, dann weiss ich wo ich schauen muss ...
Und wenn es dort im svn repository schon ein funktionierendes debian-build 
Verzeichnis gibt, steigen natürlich die chancen ;-)

> Schade :(
>
> > Aber und unter welcher Distribution denn?
> > debian (lenny,sid,etch, ...?)
> > ubuntu () ?
>
> Wenn ich die Wahl hätte: Ubuntu 8.10 :)

Welchen Namen hat das? 
dapper  feisty  gusty  hardy  intrepid  jaunty


So wie die Antworten auf meine Frage im Moment ausfallen, werd ich zuerst mal 
meine BuildUmgebung umbauen, damit ich die diversesten Debian und Ubuntu 
Versionen bauen kann. Dann werd ich mich an weitere Programme machen.

-
Joerg
-- 
Jörg (Germany, Tettnang)

http://www.ostertag.name/

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

Re: [Talk-de] Steigungen

[Tobias Knerr]

Andreas Labres schrieb:
> Ulf Lamping wrote:
>> http://wiki.openstreetmap.org/wiki/DE:Map_Features
>> Da findest du dann auch: highway=incline bzw. highway=incline_steep
> 
> Zu dem eine Frage: Wie kann eine Steigung punktförmig sein? Die fängt doch
> irgendwo an und hört woanders wieder auf... Und wo geht's rauf und wo runter?

Da gabs auch mal ein Proposal:
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dincline

Außer dem Einwand, dass zwischen maximaler und durchschnittlicher
Steigung unterschieden werden sollte, bestanden eigentlich keine
Probleme damit ("it will be rendered obsolete by SRTM contour data" ist
m.E. kein zutreffender Einwand).

Tobias "Tordanik" Knerr

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

Re: [Talk-de] Einigkeit bei Linienb?ndeldiskussion (Re:Kreuzung Radweg)

[Sebastian Hohmann]

Karl Eichwalder schrieb:
> Sebastian Hohmann  writes:
> 
>> Sven Anders schrieb:
 Dein Argument scheint zu sein, das es grafisch einfacher zu editieren ist?
>>> Eines meiner Argumente
>>> Ein anderes i(mir wichtigeres) ist das es ein bereits vorhandenes 
>>> Datenmodell 
>>> ist, und wir dafür eigentlich nichts neu Erfinden müssten.
>>>
>> Tags an die Wege hängen benötigt auch kein neues Datenmodell.
> 
> Das ist ein netter irrglaube.  Wenn du eingeführte features jetzt mit
> (anderen) tags abbildest, sind die hälfte der karten kaputt und einige
> editoren und konverter werden keine unterstützung anbieten.
> 

Warum sind irgendwelche Karten kaputt wenn ich etwas Neues mit einem 
neuen Tag einzeichne? Dann sind ja mit jedem neuen Proposal die Karten 
kaputt. Probleme gibt es doch nur wenn man schon benutzte Tags plötzlich 
entgegen der aktuellen Verwendung umdefiniert. Damit macht man die Daten 
kaputt.

Ein neuer Tag ist doch kein neues Datenmodell das eine Änderung der API 
oder sowas benötigt. Und warum sollte man glauben ein neuer Tag wird 
gleich gerendert? Bei sowas wie path hat es in Mapnik doch auch ewig und 
drei Tage gedauert.

Ich habe übrigens auch nirgends erwähnt schon bestehende Wege rigoros 
irgendwie umzuwandeln. Natürlich bezieht sich das wie bei jedem anderen 
neuen Tag auf neu eingezeichnete Dinge. Wenn bisherige Tags tatsächlich 
irgendwann mal veraltet sein sollten, DANN kann man natürlich auch die 
schon bestehenden Wege umtaggen.

Gruß

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

Re: [Talk-de] JOSM-Latest

[Joerg Ostertag (OSM Tettnang/Germany)]

On Montag 29 Dezember 2008, Dirk Stöcker wrote:
> On Mon, 29 Dec 2008, Steffen Langenbach wrote:
> >> Das stimmt nicht, die gibt es immer unter
> >>
> >> http://josm.openstreetmap.de/download/josm-tested.jar

Was haltet ihr davon die benennung in Anlehnung an die debian releases 
- josm-stable.jar
- josm-testing.jar 
zu nennen?

-- 
Jörg (Germany, Tettnang)

http://www.ostertag.name/

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

Re: [Talk-de] Fläche von Polygon berechnen?

[Gary G:]

hi frederik und auch die anderen, die so nett waren, zu antworten,

ich schrieb ja schon, dass ich die fläche nur ungefähr haben möchte. also ohne 
berge etc. auch die erde als kugel und nicht als elipsoid etc. ist ok.

ich werde also meine eigene kleine koordinatentransformation machen und die von 
frederik vorgeschlagene library verwenden, um dann die fläche zu berechnen.

wozu? ganz einfach. ich spiele ja im augenblick mit dem programm 
mappingquality.pl (siehe wiki "Mapping Quality") und da wollte ich demnächst 
mal zusätzlich wohnflächen berechnen.

ciao

gerhard
gary68

- original Nachricht 

Betreff: Re: [Talk-de] Fläche von Polygon berechnen?
Gesendet: Di, 30. Dez 2009
Von: Frederik Ramm

> Hi,
> 
> > hat jemand einen algorithmus zum berechnen der (ungefähren) fläche eines
> polygons (gegeben durch lon/lat nodes) unter der berücksichtigung, dass die
> erde keine scheibe ist? perl wäre super, anderes ebenfalls willkommen!
> 
> Daten mit Geo::Proj4 projizieren in eine für die jeweilige Gegend 
> halbwegs flächentreue Projektion und dann mit Math::Polygon die Fläche 
> ausrechnen.
> 
> Bye
> Frederik
> 
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
> 

--- original Nachricht Ende 


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

[Talk-de] Fluss mit See, Sperrgebiete im Wasser, Badestellen

[Stephan Wolff]

Mein Lieblingsfluss, die Schwentine, durchfließt etwa 10
meist größere Seen. Ich bin immer noch unschlüssig, wie man
einen Fluss mit See sinnvoll kodiert:

- als ununterbrochenen Fluss,der den See etwa mittig durchquert
- als ununterbrochenen Fluss,der den See auf kürzestem Weg durchquert
- als Flusssegmente, die am Seeufer enden und am anderen Ufer beginnen
   (führt meist zu unschönen Renderbildern)
- als Flusssegmente, die im See enden und vor dem anderen Ufer beginnen
   (etwa dort, wo die sichtbare Strömung endet oder beginnt)

Wie würde man in den letzten Fällen eine Relation für den Fluss anlegen?
Mit oder ohne die Seen?

Wie gibt man ein Sperrgebiet im Wasser (Schwimmen, Bootfahren verboten) ein?
- als Fläche auf dem See mit access = no
- als zwei Wasserflächen mit gemeinsamer Grenze, einer mit access = no
Der zweite Vorschlag ist außerhalb der Küstenlinie schwierig.

Wie kodiert ihr eine Badestelle am See? An vielen Seen (auch solchen in
Privatbesitz) sind die erlaubten Einstiegsstellen abgegrenzt und 
beschildert.
- sport=swimming im See
- sport=swimming am Uferpunkt
- sport=swimming an Land
- sport=swimming; leisure=park an Land

Viele Grüße

Stephan




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

[Talk-de] Steigungen (was: Anfängerfragen )

[Andreas Labres]

Ulf Lamping wrote:
> http://wiki.openstreetmap.org/wiki/DE:Map_Features
> Da findest du dann auch: highway=incline bzw. highway=incline_steep

Zu dem eine Frage: Wie kann eine Steigung punktförmig sein? Die fängt doch
irgendwo an und hört woanders wieder auf... Und wo geht's rauf und wo runter?

Auch zum Schilder-Taggen isses nicht so sinnvoll, weil in welcher Richtung gilt
das? Und wie weit?

Scheint nicht sonderlich durchdacht zu sein...

Servus, Andreas

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

[Talk-de] Linienbündel -- Vorschlag lane_grou p

[Tobias Knerr]

Da ich hier auf der Mailingliste stark den Eindruck habe, dass die
Diskussionen um Linienbündel etc. auf der Stelle treten, will ich mal
einen konkreteren Vorschlag einwerfen:

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

Ich habe den Ansatz gewählt, einige wesentliche hinter dem Konzept
stehende Ziele ausdrücklich aufzulisten. Insofern würde ich mich freuen,
wenn wir bei der Diskussion unterscheiden könnten, ob wir
unterschiedliche Zielvorstellungen haben, oder ein anderes Konzept
dieselben Ziele auf anderem Weg erreichen würde.

Tobias "Tordanik" Knerr

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

Re: [Talk-de] Anlieger?

[dgdg]

> Nein, ganz ehrlich: Ich würde es einfach drauf anlegen. Im Notfall
> kannst Du immer noch behaupten, du wurdest von wem geschickt, der Dir
> eine Hausnummer genannt hat, die es hier gar nicht gibt. Oder Du denkst
> Dir was anderes aus. Die Polizei hat keine Möglichkeit, das zu beweisen.

Vermutlich machen das viele so.

Ich habe auch weniger Bedenken wegen Polizei, sondern wegen genervter
Anwohner, die Autos mit auswertigen Nummernschildern aufschreiben. Auch wenn
die einem in so einem Fall überhaupt nichts nachweisen können, hat man evtl.
aber  Ärger und Papierkram.

Ähnlich ist das hier auf'm Dorf mit den Wirtschaftswegen. Wenn man da
wirklich mal angehalten würde, dann erzählt man die Story, dass man im
Auftrag des Onkels irgendein Feld oder Viehzaun begutachtet hat. Als
landwirtschaftlichen Verkehr muss man ja nicht zwangsläufig mit dem Traktor
unterwegs sein. Habe aber auch noch nie erlebt, dass hier jemand
kontrolliert worden wäre.


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

Re: [Talk-de] Anlieger?

[André Reichelt]

Chris-Hein Lunkhusen schrieb:
> Ist jemand hier schonmal in diese Situation gekommen?

Also ich persönlich wohne in einer solchen Straße. Hier fahren täglich
minimum 50 Leute mit dem Auto durch, die garantiert keine Anlieger sind.
Wir wohnen hier in der Straße 25 Jahre. Angehalten wurde in dieser Zeit
noch niemand.

Ich weiss nicht, wie es andernorts aussieht aber hier hat die Polizei
besseres zu tun als Ortsfremde Leute zu jagen, die sich verfahren haben
oder Leute, die ein paar Straßen weiter wohnen.

Und dass jemand mit einem Fahrrad aufgehalten wurde, habe ich noch nie
gehört. Warum auch? Bei Anlieger Frei geht es darum, dass man den Lärm
aus der Straße zieht. Fahrräder machen bekanntermaßen keinen Lärm.

Nein, ganz ehrlich: Ich würde es einfach drauf anlegen. Im Notfall
kannst Du immer noch behaupten, du wurdest von wem geschickt, der Dir
eine Hausnummer genannt hat, die es hier gar nicht gibt. Oder Du denkst
Dir was anderes aus. Die Polizei hat keine Möglichkeit, das zu beweisen.



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

Re: [Talk-de] Anlieger?

[Dirk Stöcker]

On Tue, 30 Dec 2008, Detlef Gerhardt wrote:


Das hat nichts mit Unwissenheit zu tun. Das Befahren ist Anliegern und
Besuchern der Anlieger gestattet. Falls jemand probieren würde den
Suchverkehr bei nicht genau bekannter Adresse von der Einfahrerlaubnis
auszuschliessen, dann muss schon ein sehr verrückter Richter da sein,
damit Du ein Bußgeld aufgebrummt bekommst.


Spricht du eigentlich aus Erfahrung (und kennst konkrete Fälle) oder ist das 
Theorie?


Mach ich schon seit 15 Jahren so. Ich muss allerdings auch dazusagen dass 
ich in den 15 Jahren und vielen Anwohnerzonen noch nie einen Polizist in 
so einer Zone gesehen habe, der die Einfahrt kontrolliert hat. Wozu auch - 
Ziel des Schildes ist es Durchgangsverkehr draußen zu halten und nicht 
irgendwelche verirrten oder einheimischen Personen vom Befahren 
abzuhalten.


Ansonsten hat mir den Tipp schon mein Fahrlehrer gegeben.

Abgefangen wird man immer nur in Baustellenbereichen und da hilft alles 
rausreden nichts. Da ist Einfahren für Nicht-Baufahrzeuge einfach verboten 
(insbesondere wenn man auf einem Motorrad unterwegs ist :-)


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Anlieger?

[Detlef Gerhardt]

> Das hat nichts mit Unwissenheit zu tun. Das Befahren ist Anliegern und 
> Besuchern der Anlieger gestattet. Falls jemand probieren würde den 
> Suchverkehr bei nicht genau bekannter Adresse von der Einfahrerlaubnis 
> auszuschliessen, dann muss schon ein sehr verrückter Richter da sein, 
> damit Du ein Bußgeld aufgebrummt bekommst.

Spricht du eigentlich aus Erfahrung (und kennst konkrete Fälle) oder ist das 
Theorie?


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

Re: [Talk-de] Anlieger?

[Dirk Stöcker]

On Tue, 30 Dec 2008, Karl Eichwalder wrote:


Polizist: "Sind Sie Anlieger?"
Ich: "Nein, aber ich will die Frau Frankenberg besuchen, die wohnte
mal hier (und tut es hoffentlich immer noch), nur leider habe ich die
genaue Adresse vergessen."

Jetzt soll Dir doch mal jemand beweisen, dass es nicht so ist :-)


Unwissenheit schützt vor strafe nicht.


Das hat nichts mit Unwissenheit zu tun. Das Befahren ist Anliegern und 
Besuchern der Anlieger gestattet. Falls jemand probieren würde den 
Suchverkehr bei nicht genau bekannter Adresse von der Einfahrerlaubnis 
auszuschliessen, dann muss schon ein sehr verrückter Richter da sein, 
damit Du ein Bußgeld aufgebrummt bekommst.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Anfängerfragen

[André Reichelt]

Kindl München schrieb:
> Frage1: Wo und wie trage ich aber hier bitte die Höhe ein beim Tunnel
> ein? Bei der Brücke kann ich auch kein Gewicht direkt eingeben. Und was
> ist mit der Geschwindigkeitsbeschränkung?

Das ist hier in der Wiki genau beschrieben:



Eine allgemeine Liste, was alles eingetragen werden kann, findest Du hier:



Beide Seiten sind deutsch. Bei der letzten findest Du außerdem jede
Menge Links (blau), die die einzelnen Sachen näher erläutern.

> Beispiel:
> 
> München, Leinthalerstraße (Das ist einer von zwei Möglichkeiten vom
> statt dem Föhringer Ring auf die A9 zu kommen, nachdem die Zufahrt
> direkt gesperrt ist. Natürlich muß etwa 1x die Woche die Polizei
> ausrücken weil auch ein Brummi seinem Navi folgt.)
> 
> Die Straße (mit baufälliger Brücke) ist aber nur für 12t zugelassen und
> Ecke Sondermeierstraße ist eine Unterführung mit Höhenbeschränkung auf
> 2,4m. Dazu gilt grundsätzlich 30km/h auf der Straße.

Hier würdest Du auf der Rechten seite in diese Tabelle folgende Werte
eintragen. Und zwar immer das Linke als Key (Schlüssel) und das Rechte
als Value (Wert):

maxweight=12 (Wert entspricht Tonnen, als Dezimaltrennzeichen . statt ,)

maxheight=2.4 (Wert entspricht Meter, wieder als Trennzeichen .)

maxspeed=30 (Entspricht km/h)

Wenn Du weitere Fragen hast, kannst Du dich auch gerne persönlich an
mich wenden.



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

Re: [Talk-de] Anfängerfragen

[Ulf Lamping]

Kindl München schrieb:
> Guten Tag.

Moin!

> Frage1: Wo und wie trage ich aber hier bitte die Höhe ein beim Tunnel 
> ein? Bei der Brücke kann ich auch kein Gewicht direkt eingeben. Und was 
> ist mit der Geschwindigkeitsbeschränkung?

Findest du unter Vorlagen/Straßen/Straßeneinschränkungen

> Genauso ergeht es mir mit anderen Dingen, die ich eintragen würde, die 
> aber in dieser Vorlage nicht sichtbar sind. Z.B. Steigung.
> 

Schau mal allgemein unter:

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

Da findest du dann auch: highway=incline bzw. highway=incline_steep

> 
> Frage2: Kann man irgendwo auf einem Blick sehen, ob solche Werte 
> (Durchfahrtshöhe, Gewichtsbeschränkungen…) eingetragen sind?
> 

Nur indem man den Weg selektiert und rechts auf die Eigenschaften schaut.

Es gibt da soviele verschiedene Möglichkeiten, da kann man nicht alle 
möglichen Eigenschaften einer Straße sinnvoll auf der Karte darstellen ...

> 
> Und natürlich allen ein Gutes Neues Jahr.
> 

Ebenso!

Gruß, ULFL

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

Re: [Talk-de] TMC (bei ORS)

[Alexander Zipf]

Hauptproblem war a.) dass wir uns in letzter Zeit nicht wirkl. drum
gekümmert haben, da ganz andere Dinge auf der Agenda standen und dass
wir zur Zeit aus regionalen Radiostadionen saugten, die TMC-maesig
nicht ganz Dtl. abgedeckt haben. Diese Daten kann man wohl intern
nutzen, aber es war b.) unklar, ob wir die anderen auch digital
weitergeben dürfen. Daher hatten wir diesmal etwas "offizieller"
angefragt und man kann auch ohne den Umweg Radion die Daten von
irgendwelchen amtlichen FTP-Server bekommen. Diesbzgl. wollten wir im
Neuen Jahr genauer nachhaken (vorher war schlicht eine Zeit). Details
ab Januar... Hauptgrund für dieses geplante Vorgehen ist, dass wir dann
hoffentlich einigermaßen rechtlich sichere Aussagen bekommen was man
mit den Daten machen darf und was nicht. Das konnte uns zu den aus dem
Radio gesaugten Daten niemand so genau sagen. Für private Nutzung im
eigenen Navi ist das sicherlich unproblematisch, aber als Web
Service!?? Da wollte ich einfach nur vorsichtig sein, und da auf
der ORS Whish-List aus meiner Sicht von Usern nicht so laut danach
gerufen wurde, haben wir das nicht vorrangig bearbeitet. 
Ich nehme an ORS wird z.Zt. noch eher von Radlern/Fussgängern bzw. zum
Validieren der Datenaufnahme genutzt? Aber wenn doch stärkeres
Interesse aus der Community da ist kümmern wir uns gerne stärker drum,
und wenn es vielleicht schon einfach mit einem Wechsel des Senders
o.ae. getan ist, wäre diese schnelle Lösung vieleicht schon eine
Option...

best 
a. zipf

Florian Lohoff schrieb:

  On Mon, Dec 29, 2008 at 12:14:33PM +0100, Alexander Zipf wrote:
  
  
Mittlerweile haben wir auch weitere Kontakte, so dass es mittelfristig 
eine Deutschlandweite TMC-Lösung für OpenRouteService geben sollte. Die 
Nutzung der Daten in so Diensten wie ORS ist kostenfrei möglich, aber 
wir können leider wohl nicht ohne weiteres unsere Datenbank (bzw. den 
Web Feature Service) mit den TMC-Daten freischalten. Wir versuchen im 
Neuen Jahr diesbzgl. nochmal nachzuhaken.
Einen Zeitplan für die ORS-Version mit Deutschland-weitem TMC kann ich 
leider auch noch nicht melden, aber wir bleiben locker dran.

  
  
Wo ist das Problem mit dem Deutschlandweitem TMC? Nur so aus neugier -
Ich habe die Weihnachtsfeiertage damit zugebracht mal im DVB Stream von
Einslive nach dem RDS zu suchen (aus dem Sat Transponder) und bin
fuendig geworden. D.h. ich bekomme im moment die RDS informationen vom
Satelliten. Der Naechste schritt ist die RDS daten zu dekodieren was
trivial sein sollte - Format ist klar - Standard offen.

Wenn das alles funktioniert fehlen vermutlich 20-30 Zeilen C um den
ganzen ARD Transponder zu dekodieren - Da sind aus allen Bundeslaendern
die Oeffentlich Rechtlichen drauf so das aus dem ganzen Bundesgebiet die
TMC Daten vorhanden sein sollten. D.h. DVB-S Budget Karte fuer
irgendwelche 50 Euro und 3% CPU auf einem Celeron 1Ghz und schon
plumpsen da die TMC Daten raus ;)

Beispiel output derzeit:

RDS000180:  fd 0e 31 31 fe 00 00 00 04 07 00 00 0a b7 a0 ff   ..11
aa bb cc cc dd ee ee ff gg hh ii ii ii ii ii jj   
   
	aa - RDS Sync byte - DVB/ISO/IEC Standard Ancillary Data
	bb - RDS Length ISO Standard Ancillary Data
	cc - Stuffing
	dd - RDS Sync (UECP Standard - Start)
	ee - Address 
	ff - Sequence number - im DVB immer 0
	gg - Length of RDS Message
	hh - RDS Message type (hier PTY)
	ii - Message
	ff - RDS Sync (UECP Standard - Stop)

So long ...

Flo
  





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

Re: [Talk-de] Fläche von Polygon berechnen?

[Peter Vitt]

Gary G: schrieb:
> hat jemand einen algorithmus zum berechnen der (ungefähren) fläche eines 
> polygons (gegeben durch lon/lat nodes) unter der berücksichtigung, dass die 
> erde keine scheibe ist? perl wäre super, anderes ebenfalls willkommen!
>
>   
Hallo Gary,
Ich glaube, es ist nicht trivial, die Fläche unter Berücksichtigung der
Erdkrümmung zu berechnen, da man dafür die genaue Beschaffenheit (Höhen
und Tiefen) der überdeckten Fläche kennen müsste. Man hätte somit
mehrere Möglichkeiten:
1) Man sieht die Erde als ideale Kugel an. - Ungenau, leicht zu berechnen
2) Man nimmt ein gebräuchliches Modell zur Beschreibung der Erde, z.B.
einen Rotationsellipsoid. Dieser müsste dann allerdings wieder genauer
beschrieben werden. - Komplizierte Theorie, mittelschwer zu rechnen,
mittelmäßig genau
3) Man verwendet die tatsächeliche Beschaffenheit, was natürlich mit dem
größten Aufwand verbunden ist. - Komplizierte Theorie, schwierig zu
berechnen, möglichst genaue Angabe (wahrscheinlich noch immer nicht die
tatsächliche Fläche, aber wohl am nächsten dran)

Für eine der drei (eventuell noch mehr, falls ich eine vergessen haben
sollte) Möglichkeiten solltest du dich allerdings aussprechen, damit man
weiß, was du suchst. Eventuell wäre auch sinnvoll zu erklären, was du
vorhast.

mfG, Peter


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

Re: [Talk-de] Fläche von Polygon berechnen?

[Dimitri Junker]

Hallo,


>hat jemand einen algorithmus zum berechnen der (ungefähren) fläche eines
>polygons (gegeben durch lon/lat nodes) unter der berücksichtigung, dass
>die erde keine scheibe ist?


Kannst Du damit was anfangen:


Dimitri

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

Re: [Talk-de] Fläche von Polygon berechnen?

[Frederik Ramm]

Hi,

> hat jemand einen algorithmus zum berechnen der (ungefähren) fläche eines 
> polygons (gegeben durch lon/lat nodes) unter der berücksichtigung, dass die 
> erde keine scheibe ist? perl wäre super, anderes ebenfalls willkommen!

Daten mit Geo::Proj4 projizieren in eine für die jeweilige Gegend 
halbwegs flächentreue Projektion und dann mit Math::Polygon die Fläche 
ausrechnen.

Bye
Frederik


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

Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)

[Dimitri Junker]

Hallo,


>Leider scheinen sich dafür aber wenige zu interessieren.


Mangelndes Interesse kann man mir ja nicht nachsagen, aber selbst bei mir 
ist Dein Vorschlag noch nicht angekommen. Gibt es eigentlich eine 
Mailingliste für Proposed_features, wo also eine Kurze Nachricht kommt: 
neuer Vorschalg...


>Warum ist das mit der Straßenseite so schwer zu lösen?


Ich sehe da auch kein Problem. Mit etwas Unterstützuung des Editors ist es 
trivial.
Man muß sich nur drauf einigen wo left und right hinsollen. Ich sehe da 3 
Möglichkeiten:
in den Key also
left:cycleway=track
in den Value:
cycleway=left:track
oder in ein neues Feld neben Key und Value.
dies wäre die sauberste Lösung aber ein großer Eingriff ins Datenmodell. Am 
einfachsten einzubinden wäre sicherlich es in den Value zu schreiben.

Was mir bei Deinem Vorschalg nicht gefällt ist:
cycleway=right
u.ä. right ist keine Alternative zu track, path,... sondern eine 
Zustazinformation.

Gruß
Dimitri

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

Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)

[Dimitri Junker]

Hallo,


>Sicher, nur diesen einfachen fall gibt es in der realität nur selten.


Also hier in Aachen besteht dieser einfache Fall fast ausschließlich.

>Das ist aber für dich kein problem; denn du hast ja bereits verkündet,
>dass dich die wirkliche kreuzungssituation nicht interessiert.

Der genaue Verlauf des Fahrradsweges interessiert mich dann wenn er mehr als 
sagen wir 10m vom 'normalen' Verlauf abweicht.


>bordsteinradwege haben zwischen kreuzungen gern verengungsstellen, wechseln 
>den belag

Ich habe noch nirgendwo gesehen, daß jemand Breiten einträgt, und wenn würde 
ich für einen Abschnitt jeweils die engste Stelle und den 
schlechtesten Belag nehmen.

>haben verschwenkungen an bushaltestellen


< Meßgenauigkeit

>haben absperrungen zwischen fahrbahn und radweg


Und wie taggst Du die bei separatem Radweg? MAchst Du dann einen Weg fence 
dazwischen? Wenn Ja OK.

>haben abweichende oneway-regelungen


cycleway=opposite

>wechseln zwischen z240, z239, und "Radfahrer absteigen"

Und wie tagst Du das?

>haben von der fahrbahn abweichende abbiegevorschriften.


bei denen gibt es bereits ein exept und man sollte meiner Meinung nach noch 
ein only hinzufügen.

>Zum teil hast du das ja auch schon erkannt, aber zugleich sagst du nun,
>dass relationen die dinge komplizierter machen.


Meine Erfahrung ist, 90% der Radwege verlaufen entweder auf der Fahrbahn 
oder unmittelbar daneben, und es trägt keiner Breiten oder Fahrbahnbelege 
ein. Diese 90% möchte ich möglichst einfach taggen. Alles andere darf dann 
komplizierter sein. Taggt man grundsätzlich Fahrradwege,.. als eigene Wege 
ist alles kompliziert.

>lern, mit den endlichen ressourcen auszukommen.


Sie reichen nicht, entweder sehen die Karten schlecht aus oder ein Router 
kann damit nichts anfangen.

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