from:"Felix Hartmann"

Ich hab grad ziemlich einen Schock bekommen, wie ich bemerkt hab, das 
Gondeln, Sessellifte und Schlepper in Österreich und Deutschland 
scheinbar nie man an das Wegenetz direkt angeschlossen sind.


Vor gut ein zwei Jahren war das noch ziemlich anders. Hat da 
irgendjemand systematisch die Wege gelöscht? Teils sind dagegen Pisten 
direkt verbunden!


Andere öffentliche Verkehrsmittel, haben wir schließlich auch verbunden 
mit dem Wege/Staßennetz (etwa Fähren, Autoverladung, Ubahnen, usw.).




Ein Routing unter Einbezug der Gondeln, Sesselliften und Co. ist so 
unmöglich. Dazu kommt noch, dass kaum eine Gondel direkt mit einer Piste 
verbunden ist, auch im Winter (Sessellifte dagegen schon), so dass man 
doch schon Wege in OSM haben sollte.


Frage ist daher, wie schaffen wir es Gondeln und Sessellifte so an das 
Wegenetz zu verbinden, das nicht wieder Vandalen dies löschen. Oder 
braucht es eine eigene Wegart für Wege vom öffentlichen Wegenetz zu 
Verkehrsmitteln des ÖPNV und Co?


highway=service  access=no  foot=permissive ??
highway=footway ??
highway=path ??

--
keep on biking and discovering new trails

Felix
openmtbmap.org  www.velomap.org



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

Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz



On 23.08.2012 13:59, Rainer Kluge wrote:

Hallo,
Am 23.08.2012 12:02, schrieb Felix Hartmann:
Andere öffentliche Verkehrsmittel, haben wir schließlich auch 
verbunden mit dem

Wege/Staßennetz (etwa Fähren, Autoverladung, Ubahnen, usw.).


Was spricht dagegen, Seilbahnen genau so zu handhaben wie 
schienengebundene Bahnen, d.h. mit einer Plattform aerialway=platform, 
die mit dem Straßennetz verbunden ist?


Dazu kommt noch, dass kaum eine Gondel direkt mit einer Piste 
verbunden ist,
auch im Winter (Sessellifte dagegen schon), so dass man doch schon 
Wege in OSM

haben sollte.


Willst du die einzelnen Gondeln mappen? Ich vermute du meinst die 
Seilbahn, also die Trägermasten, das Kabel und die Berg- und Talstation.

Logisch. Einzelne Gondeln sind ja mobil, und daher eh nicht mappbar.


Frage ist daher, wie schaffen wir es Gondeln und Sessellifte so an 
das Wegenetz

zu verbinden, das nicht wieder Vandalen dies löschen.


Wenn es man mit aerialway=platform, dann stellt es sich für das 
Routing wie ein Bahnhof oder eine Straßenbahnhaltestelle dar. Und 
gegen Vandalen hilft nur Aufmerksamkeit.


Dagegen spricht nichts (solange die platform dann auch mit dem 
Seil/bzw Trasse verbunden wird ) , nur dass dieser Tag einfach weder 
existiert, noch dokumentiert ist - siehe etwa: 
http://tagwatch.stoecker.eu/Colombia/Fr/tagstats_aerialway_platform.html



So ein Tag kann gerne eingeführt werden, und hab ich in der ersten Mail 
ja auch vorgeschlagen. Der Status Quo, dass es scheinbar einige User 
gibt, die da konsequent footway und service gelöscht haben, ist 
schließlich nicht tragbar. Dazu fragt sich dann auch, von wo nach wo 
zeichnet man aerialway=platform. Will man damit nur den Einstiegsbereich 
taggen, oder zählt der Weg im Gebäude zum Einstiegsbereich auch schon 
als platform?

Gruß
Rainer



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


--
keep on biking and discovering new trails

Felix
openmtbmap.org  www.velomap.org





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

Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz



On 23.08.2012 14:38, Andreas Labres wrote:

On 23.08.12 14:22, Felix Hartmann wrote:

Dagegen spricht nichts (solange die platform dann auch mit dem Seil/bzw
Trasse verbunden wird )

PMJI, aber das ist IMO ein Denkfehler... Bei Bahn/Straßenbahn wird die
Plattform auch nicht mit dem Gleis verbunden. Das muß der Router sich ggf.
schon zusammensuchen, dass er von der stop_position auf dem Gleis zur platform
eine gedankliche Verbindung macht.
gedankliche Verbindungen ... im Bereich von railways und ÖPNV Routing, 
kann ich ja noch irgendwie einsehen, dass man dies vom Router verlangen 
soll, da es die Hauptaufgabe des Routers ist. Da es bei Bergbahnen, nun 
aber nicht um klassischen ÖPNV geht, wäre die Konsequenz hieraus, OSM 
wird für 99% aller Anwendungen, im Punkt, Einbeziehung von Bergbahnen 
ins Routing, untauglich bleiben/werden.


Es gibt einfach noch keine Algorythmen die vernünftiges Flächenrouting 
beherschen, und selbst wenn diese existieren, wird es 
unverhältnismäßigen Aufwand bedeuten.

IMO muß man da einen Kompromiss machen: solange die Talstation (oder
Bergstation oder was immer) als ein einziger Punkt gemappt wird, sollte auch
ein Gehweg oder eine Piste in diesem Punkt enden. Macht man Micromapping, dann
kann man z.B. den Weg von Gondelschienen (für ausgehakte Gondeln) mappen
(wahrscheinlich mit einer stop_position; vielleicht auch mit eigenen
Schienen-Tags) und getrennt davon die Plattform.

Servus, Andreas


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


--
keep on biking and discovering new trails

Felix
openmtbmap.org  www.velomap.org





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

Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz

Das seh ich ganz anders, da gehören die Wege im Haus einfach dazu, und 
ich frag mich wer solche In Hause Wege halt etwa gelöscht hat, da ich 
diese schon recht oft angelegt hab.

On 23.08.2012 14:49, Andreas Labres wrote:

ReHi!

Wenn Du z.B. bei Seegrube oder Patscherkofel schaust, da ist immer das Gebäude
gemappt, sprich da endet der Bahn- oder Gondel-Way im Gebäude. Da kannst Du nur
ein Öffi-Routing machen, indem man annimmt, daß man auf der Hungerburg
(http://osm.org/go/0IUSihE3w--) von der Hungerburgbahn zur Seilbahn umsteigen
kann. Da jetzt ein inhouse-Routing und vielleicht Fußwege von Gebäudeeingang
zur Straße einzeichnen wäre wohl zu viel verlangt, oder...

Also ich würde an Deiner Stelle diese Seilbahnendpunkte müssen mit Wegen
verknüpft sein Idee eigentlich schnell wieder vergessen.

/al

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


--
keep on biking and discovering new trails

Felix
openmtbmap.org  www.velomap.org





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

Re: [Talk-de] was bedeutet bicycle:backward?

2012-07-03 Diskussionsfäden Felix Hartmann


On 28.06.2012 13:07, Tobias Knerr wrote:

Am 28.06.2012 10:52, schrieb Martin Koppenhoefer:

Wie oben angegeben: bezieht sich bicycle:backward auf die Richtung des
ways oder die Richtung der Einbahnstraße?

Auf die Richtung des Ways.


Spielt vor allem dann eine
Rolle, wenn der tag oneway=-1 ist.

Achtung: Zumindest nach den Auswerte-Regeln, wie sie im zugehörigen
Proposal definiert wurden, kann man Einschränkungen nur durch andere
Tags überschreiben, die denselben Grundschlüssel verwenden: Eine
Ausnahme von maxspeed muss mit maxspeed:... anfangen, eine von maxweight
mit maxweight:..., und eine für oneway eben mit oneway:...!

Eine Ausnahme von der Einbahnstraßen-Regelung für Radfahrer muss nach
diesem Schema also oneway:bicycle verwenden, um bei der Auswertung
überhaupt berücksichtigt zu werden.

Wer/wo hat den bitteschön bicycle:backward definitert?

Es gibt ja schon cycleway:opposite=yes/no/both/lane/track (was wiederrum 
auch nichts über die Fahrtrichtung gegen Einbahn aussagt, sondern im 
Prinzip nur wo es Möglichkeiten zum Fahrradfahren gibt).

Es braucht keinen zusätzlichen Tag Wildwuchs...

oneway:bicycle=no/yes (meinetwegen auch oneway:bicycle=-1/reverse) ist 
das korrekte Tag.


Tobias

___
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] Freeride Trail : wie taggen ?

2012-05-14 Diskussionsfäden Felix Hartmann




On 11.05.2012 15:03, Chris66 wrote:

Am 11.05.2012 14:27, schrieb Alech OSM:


Natürlich  ist ein Freeride Strecke für MTB  ein „highway=path“ ,

Naja path ist erstmal ein Weg primär für Fussgänger/Radfahrer/Reiter.

Also nicht vergessen die  mtb:xyz Tags hinzuzufügen. So dass Router die
Möglichkeit haben diese Wege fürs Routing herunter zu gewichten.

Bzgl. der speziellen Hindernisse und Sprungschanzen hat sich noch nichts
durchgesetzt IMHO.

mtb:barrier = xyz fänd ich nicht schlecht.
wenn schon mtb:obstacle ... weil es nun mal keine Barrieren sind, 
sondern Features und die englisch zum Mountainbiken unter obstacles 
zusammengefasst werden.


Wenn du das wirklich machen willst, leg mtb:obstacle im wiki an, 
verlinke es auf der mountainbike Übersichtsseite, und stell mal die 
Haupttypen an obstacles mit Pic rein.


Chris


___
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] online tool: track selector für tracks ohne tracktype

2012-05-07 Diskussionsfäden Felix Hartmann

Ich sehe tracktype als eindeutig schlechter wie smoothness an, wenn es 
um Radeln geht.



Surface ist im Prinzip zwar nett, in der Praxis liegt man da aber bei 
5-10% komplett daneben, sprich surface werten man nur dann aus, wenn 
kein smoothness oder tracktype vorliegt, bzw für tracktype 5.



tracktype 4/5 sind leider in den Tagginggewohnheiten sehr 
unterschiedlich, sprich beim auswerten weiß ich nicht was sich dahinter 
verbirgt. Ab tracktype 4/5 braucht man zusätzliche Attribute wie 
mtb:scale -- muss unterscheiden ob footway/path/track, oder das 
vermaledeite (weil häufig nicht verstandene) sac_scale oder eben auch 
surface.



Wenn es um Wege geht die tracktype 3-5 sind, und nicht mit mtb:scale 
getagged sind, dann macht smoothness einfach viel mehr Sinn.



Einen track selector halte ich daher für ziemlichen Stuss, weil eben 
häufig aus gutem Grund kein Tracktype angegeben ist (weil es nicht 
differenziert genug ist). Selbst bei grade1/2 gibt es ja genug Probs. 
Sprich sinnvoller wäre ein smoothness selector


On 07.05.2012 13:48, Sven Geggus wrote:

Adrian Stabiszewskimynewslet...@nitegate.de  wrote:


Danke fürs Feedback. Persönlich sehe ich surface als viel zu detailliert an,
so dass ich mit tracktype ein Minimum an Information haben möchte, das aber
gut zu verwenden ist.

Dto. Als Radfahrer interressieren mich (mal abgesehen von
surface=cobblestone) lediglich tracktype1, tracktype2 und notfalls
tracktype3, der Rest ist nichts für normale Radler und für Mountainbike gibt
es mtb:scale.


Die Idee ist, die Erfassung der tracktypes zu vervollständigen, da wir bei
geschätzten 90% liegen.

Jepp, finde ich Klasse. Ich könnte Dir anbieten eventuell mit mapnik ein
Overlay zu rendern.


Außerdem sehe ich den tracktype aus der
Radfahrerperspektive und hier brauche ich einfach nur die Info:
Rennrad-tauglich (grade1), Trekkingrad-tauglich(grade1-3) und MTB
(grade1-5).

dto.

Sven




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

Re: [Talk-de] online tool: track selector für tracks ohne tracktype

2012-05-07 Diskussionsfäden Felix Hartmann

cobblestone ist wirklich ziemlich genau vorstellbar - auch wenn es da 
große Unterschiede gibt.


Aber surfaces wie sand, earth, sind total nutzlos. Sand kann etwa von 
Strand (unfahrbar mit Rad) zu sandigem Boden fast alles sein.



Aber bleiben wir mal lieber bei der Liste der Häufigkeiten Absteigend.

1: Paved ::: nutzlos wenn smoothness oder tracktype angegeben ist
2. Unpaved ::: kann quasi alles bedeuten

3. Asphalt ::: das ist recht gut einschätzbar. Aber gibt auch noch ganz 
gute Unterschiede


4. Gravel ::: ist normalerweise grade2/3 -- recht gut einschätzbar.

5. Ground ::: nicht einschätzbar

6. Grass::: kann mal wieder fast alles bedeuten (von 50cm hoher Wiese 
bis super Fussballrasen)


7. Dirf ::: ROFL

8 Paving Stones ::: recht gut einschätzbar

9: Concrete ::: recht gut einschätzbar

10: Cobblestone. recht gut eischätzbar


So jetzt rechnen wir mal zusammen unter allen relevanten typen sind grad 
mal so 33% einschätzbar. Wie man da von einem sinnvollen Tag sprechen 
kann ergibt sich mir leider überhaupt nicht. Ja zusätzlich ist surface 
super. Aber alleine meistens sinnlos


Siehe: http://taginfo.openstreetmap.org/keys/?key=surface#values


Wenn also mal wieder von den so toll auswertbaren surface values 
gesprochen wird, dann bitte beachten wie häufig die vorkommen


On 07.05.2012 16:40, aighes wrote:

Am 07.05.2012 16:19, schrieb Felix Hartmann:
Surface ist im Prinzip zwar nett, in der Praxis liegt man da aber bei 
5-10% komplett daneben, sprich surface werten man nur dann aus, wenn 
kein smoothness oder tracktype vorliegt, bzw für tracktype 5.

Wie meinst du das mit dem daneben liegen?

Wenn da surface=asphalt getaggt ist, sollte dem doch auch so sein. 
Ähnlich bei cobblestone, concrete und wie die ganzen anderen values 
lauten. Sicherlich gibt es da auch den einen oder anderen Fehler in 
den Daten, aber den hat man doch bei tracktype auch. Dazu muss man ja 
nur den thread hier zu lesen, wo da die Interpretationsgrenzen liegen.


smoothness ist unabhängig von surface und tracktype auch sinnvoll, 
aber keiner der beiden macht eine Aussage über smoothness laut 
wiki-Definition aus.


Henning




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

Re: [Talk-de] online tool: track selector für tracks ohne tracktype

2012-05-07 Diskussionsfäden Felix Hartmann




On 07.05.2012 17:50, aighes wrote:

Am 07.05.2012 17:15, schrieb Felix Hartmann:

Aber bleiben wir mal lieber bei der Liste der Häufigkeiten Absteigend.

1: Paved ::: nutzlos wenn smoothness oder tracktype angegeben ist
Sagt immerhin aus, dass ich da bei Dauerregen lang kann, ohne im 
Schlamm zu versinken, etc.
Nein. Absolut nicht. Werte wie Gravel oder Earth sagen nichts über die 
Beschaffenheit von Wasserablaufrinnen in einem wenig befestigten Weg 
aus. Nur bei Asphalt oder anderen guten Werten kann man davon ausgehen. 
Aber auch hier kann seitlich Dreck draufgespült werden. Ich kann es 
vielleicht zu 70-80% annehmen, aber besser nicht.

2. Unpaved ::: kann quasi alles bedeuten
Sagt halt aus, dass der Weg nicht befestigt ist. Je nach 
Interessengebiet kann das entscheidend sein oder nicht.


Beide haben aber eine Aussage. Ob die nun fürs Radrouting sinnvoll 
erscheint, muss jeder selber wissen. Auf Karten der betroffenen 
Regionen (wo noch nicht alle Verbindungsstraßen asphaltiert sind) wird 
jedenfalls unterschieden zwischen befestigte Straße und unbefestigte 
Straße. Wenn diese Unterscheidung sinnlos wäre, würde man sie in den 
Karten wohl kaum unterscheiden.


Henning


Ja sie hat schon eine Bedeutung, aber viel aussagen tuts trotzdem nicht, 
denn die Überlappung ist viel zu groß. (was ist paved, was ist unpaved). 
Sinnvoll mit einem Zweck auswerten kann man es kaum. Sprich, existiert 
auch nir irgend ein anderer tag wie etwa smoothness, tracktype, usw, 
dann ist die surface in dem Fall komplett egal.


Es ist nicht so dass ich Surface komplett als Unsinn empfinde, aber der 
größte für mich gute Nutzen wäre etwa beim Routen/Tourenplanen eine 
Statistik für die komplette Strecke mit Anteil, Erde, Anteil Gras, 
Anteil Asphalt usw anzuzeigen. Das wird man halbwegs gut hinbekommen 
(wobei die diversen neuen extrem spezifischen Werte natürlich viel 
ARbeit zum einpflegen bedeuten).



Auf einer amtlichen, koherenten Karte, ist der Sinn zwischen unpaved und 
paved ganz anders. Da weiß man welche Kriterien mit hoher Genauigkeit 
zur Unterscheidung genutzt wurden. Bei OSM wissen wir es überhaupt 
nicht, selbst regional sind die Unterschiede oft schon groß. Ausserdem 
fällt es schwer (weil nirgendswo definiert) die zahlreichen surface 
values in paved/unpaved aufzuteilen. Gibt zu viele die weder noch sind.



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

Re: [Talk-de] Auszeichnung fuer Bikepark gesucht

2012-03-23 Diskussionsfäden Felix Hartmann


On 22.03.2012 10:17, aighes wrote:

Am 22.03.2012 10:08, schrieb Schorschi:

es wäre prima, wenn jemand aus der Bike- oder MTB-Fraktion noch mal
seine Meinung abgibt.

Ich hab jetzt mal folgendes genutzt:

leisure=track
mtb:type=bikepark
sport=cycling

und die folgenden habe ich auch noch angehängt, das ist aber eher
Informations-Dopplung oder?
Wenn leisure=track auch als Linie definiert ist, würde ich das 
area=yes setzen, ansonsten nicht. Wichtig fände ich noch die 
Oberfläche zu erfassen. Ist das nun eine Schlammbahn, oder eher 
sowas Halfpipe-ähnliches oder gar eine Strecke fürs Bahnradfahren. Das 
lässt das das sport=cycling noch offen. Kenne mich in der Szene aber 
zu wenig aus, als das ich hier Fachbegriffe für eine nähere 
Beschreibung abgeben könnte.


Henning

Also primär kann man natürlich beides mappen, die area und die Wege an 
sich. Hier muss man jetzt halt etwas aufpassen ob wir BMX zu Mtbike 
zählen oder nicht. Ich würde mal sagen ja, allerdings  sollte das oben 
beschriebene eher mtb:type=dirtjump oder mtb:type=bmx heißen. Ein 
Dirtjumppark / BMX Strecke ist für mich kein Bikepark. Bei einem großen 
Bikepark ist es IMHO auch sinniger, wenn man nur die Trails an sich 
mapped, wir wollen ja nicht etwa das komplette Gebiet Portes du Soleil 
als Bikepark taggen - oder da um die ganzen Lifte rumherun Flächen 
ziehen. Skigebiete werden ja auch nicht als area gemapped, sondern die 
Pisten an sich.


Bei einer kleinen BMX Strecke, Dirtjump park, wo sich alles schnell 
ändert (einmal die Wochen fahrens mit dem Caterpillar durch, und ändern 
alles) macht dies dagegen evtl schon Sinn. Weil die einzelnen 
Obstacles/Trails zu mappen nicht sinnvoll ist a) weil es sich zu schnell 
ändert b) weil man es für die Orientierung nicht braucht - die 
Übersichtlichkeit ist weil klein eh gegeben.



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

Re: [Talk-de] Garmin-Karte mit Skipisten?

2012-03-06 Diskussionsfäden Felix Hartmann




On 05.03.2012 18:43, Bodo Meissner wrote:

On Mon, Mar 05, 2012 at 09:30:28AM +0100, Felix Hartmann wrote:

Pisten anhand schwierigkeit habe ich etwa in der Openmtbmap.org bzw
VeloMap integriert...

Das ist schon fast, wie ich es mir vorgestellt hätte.


piste:ref werde ich zum nächsten Update auch integrieren, hab den
Key noch gar nicht gekannt

Super, danke.
Es gibt auch noch piste:name, aber das wäre für mich weniger wichtig.
(Keine Ahnung, warum für die Pisten nicht einfach ref und name verwendet 
wird.)
Ich hab mir schon gedacht dass piste:name auch existiert, und hab es 
daher gleich auch für den Namen gesetzt, allerdings nur wenn kein name 
existiert. Primär ist die Karte halt doch für den Sommersport gedacht, 
und manche Pisten(teile) haben halt mehrere Nutzungen.

Es hängt vielleicht vom Skigebiet ab, ob zur Orientierung die Nummern oder 
Namen besser geeignet sind. (Ich hatte bisher an den Pisten nur Schilder mit 
Nummern.)
Ich würde mir das so wünschen, daß die Pisten-Nummern direkt sichtbar sind und 
die Namen als Zusatzinformation angezeigt werden, wenn man mit dem Pfeil auf 
die Piste zeigt. Wenn keine Nummer definiert ist, könnte möglicherweise der 
Name direkt angezeigt werden.
Es gibt keine Möglichkeit zwischen Pop Up Name und angezeigtem Name zu 
unterscheiden im Garmin Format.


Mir ist aber auf meinem GPSMAP76CSx aufgefallen, daß die Pisten mit dem Pfeil 
nicht selektierbar sind. Bei mir wurde immer nur eine Bezeichnung für den 
Hintergrund angezeigt. (Bei Höhenlinien wird in einem Mini-Popup die Höhe 
angezeigt, wenn der Pfeil darauf steht.)
Sind die Pisten für das Gerät andere Objekte als Wege oder Höhenlinien?
Nur Pisten die als Polygone angelegt sind (sehr selten) sollten nicht 
anklickbar sein.



Viele Grüße
Bodo



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

Re: [Talk-de] Garmin-Karte mit Skipisten?

2012-03-05 Diskussionsfäden Felix Hartmann

Pisten anhand schwierigkeit habe ich etwa in der Openmtbmap.org bzw 
VeloMap integriert...


piste:ref werde ich zum nächsten Update auch integrieren, hab den Key 
noch gar nicht gekannt


On 02.03.2012 20:26, Bodo Meissner wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo alle,

gibt es eine fertige Garmin-Karte auf der Skipisten dargestellt werden?
Oder hat jemand schon eine geeignete Konfiguration, um eine solche Karte selbst 
zu generieren?

Ich würde gern den Schwierigkeitsgrad (piste:difficulty) und die Nummer 
(piste:ref) erkennen.


Viele Grüße
Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk9RHskACgkQnMz9fgzDSqc3oACcD7f7lCkFTOz7W3sVHxDZEkKf
SHYAniFjCXpVRwvJ5YGuJIR9ogawW8TD
=VtHB
-END PGP SIGNATURE-

___
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] Geofabrik OSM-extract downloads langsam seit gut einer Woche

2012-01-05 Diskussionsfäden Felix Hartmann




On 05.01.2012 11:33, Frederik Ramm wrote:

Hi,


Ich hab jetzt mal (reboot tut gut) den Rechner neu gestartet und
ausserdem eine Anfrage an den Provider geschickt. Vielleicht war denen
ja der Traffic zu viel ;)


Es sieht aus, als ob die Stoerung tatsaechlich mutwillig vom alten 
Provider verursacht wurde. Ich bin jetzt mit dem Downloadserver zu 
Hetzner umgezogen und habe den DNS schon umgestellt. Die OSM-Auszuege 
sollten alle schon da sein, die Shapes brauchen noch einen Moment. 
Wenn jemandem was seltsames auffaellt, bitte sagen.


Na dann hoffe ich mal das 10TB im Monat für Downloads vom Server 
ausreichen, weil ab dann wird AFAIK ja ziemlich krass der Speed 
runtergefahren bei Hetzner... (und pro TB zahlen wird ziemlich teuer)

Außer sie haben ein Spezialangebot fürs hosten von OSM Extracts gemacht


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

[Talk-de] Geofabrik OSM-extract downloads langsam seit gut einer Woche

2012-01-04 Diskussionsfäden Felix Hartmann

Weiß jemand warum die so langsam geworden sind? Gibt es irgendwelche 
Consumer Apps die evtl sich dort bedienen? Derzeit schwankt der Speed 
zwischen 50-200KB.
Oder funktioniert das spiegeln der beliebtesten Länder auf gdwg derzeit 
nicht und ist der Speed daher so eingebrochen (da bin ich mir ziemlich 
sicher dass es nicht funktioniert)?



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

Re: [Talk-de] Geofabrik OSM-extract downloads langsam seit gut einer Woche

2012-01-04 Diskussionsfäden Felix Hartmann


Vielen Dank für die Rückmeldung...

Hoffe mal, dass wenn Deutschland und Europa Spiegeln wieder funktioniert 
(Frankreich wäre, da inzwischen größer wie Deutschland - und doch recht 
beliebt evtl auch gut zu spiegeln) der Speed hoffentlich wieder 
brauchbar ist (und nicht 10 Stunden warten bis Frankreich mit Glück 
gedownloaded) die Downlaods wieder in akzeptabler Geschwindigkeit 
verfügbar sind.



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

Re: [Talk-de] ODBL Status Garmin Karten

2011-12-15 Diskussionsfäden Felix Hartmann

Hallo Simon, der Alternative Style verstößt eindeutig gegen meine 
Lizenzbestimmungen. Bitte Les die dir nochmal durch. Du kannst ihn gerne 
benutzen, aber das verlinken und nennen meines Styles möchte ich bitte 
beachtet haben...


On 15.12.2011 14:29, Simon Poole wrote:


Wie isch schon angekündigt habe, habe ich einen Satz von Garmin Karten 
online gestellt die auf Frederiks Daten für seinen OSMI viewer beruhen.


Ich habe jetzt noch weitere Regionen hinzugefügt und auch noch einen 
zweiten Kartenstil gemacht. Mindestens die europäischen Karten werde 
ich versuchen täglich zu erneuern.


Die Karten können von http://odbl.poole.ch/garmin/ bezogen werden.

Simon


___
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] ODBL Status Garmin Karten

2011-12-15 Diskussionsfäden Felix Hartmann

ups sorry grad gecheckt dass es nur ein Overlay über einer meinen Karten 
ist Wäre trotzdem nett wenn du bei Screenshots meiner Karten auch 
dazuschreibt, dass sie von mir sind (ist sonst zumindest ein Verstoß 
gegen meine Lizenzbedingungen, wobei ich jetzt bezüglich FairUse nicht 
weiß ob es wriklich eine Verletzung der CCBYSA2.0 ist...)
Dachte zuerst es handelt sich um eine komplette Karte und nicht nur ein 
Overlay...


On 15.12.2011 17:07, Felix Hartmann wrote:
Hallo Simon, der Alternative Style verstößt eindeutig gegen meine 
Lizenzbestimmungen. Bitte Les die dir nochmal durch. Du kannst ihn 
gerne benutzen, aber das verlinken und nennen meines Styles möchte ich 
bitte beachtet haben...


On 15.12.2011 14:29, Simon Poole wrote:


Wie isch schon angekündigt habe, habe ich einen Satz von Garmin 
Karten online gestellt die auf Frederiks Daten für seinen OSMI viewer 
beruhen.


Ich habe jetzt noch weitere Regionen hinzugefügt und auch noch einen 
zweiten Kartenstil gemacht. Mindestens die europäischen Karten werde 
ich versuchen täglich zu erneuern.


Die Karten können von http://odbl.poole.ch/garmin/ bezogen werden.

Simon


___
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] GPS Tracks vereinfacht hochladen?

2011-12-14 Diskussionsfäden Felix Hartmann

Wenn dein GPS Device intelligent loggen kann, dann mach es. Ein Punkt 
pro Sekunde ist meist vom Ergebnis deutlich schlechter wie ein 
intelligentes vermeiden zu vielen Punkte - vor allem da dein Device dann 
da die internen Qualitätsdaten noch vorhanden sind, Outlier 
rausschmeißen kann. Ausserdem braucht es auf einer Geraden nicht einen 
Punkt pro Sekunde, in Kurven wären evtl aber sogar 2 Punkte pro Sekunde 
besser (gibt aber nur sehr wenige PNA/PDA die ein kleineres Intervall 
als 1s aufnehmen können).


Genauso macht natürlich auch 1 Punkt / Meter keinen Sinn.

Gerade wer ein Garmin hat (weil weit verbreitet) errreicht mit 
Aufzeichnungsintervall automatisch / Datendichte am höchsten deutlich 
bessere Ergebnisse wie bei 1point/sec oder 1point/m.



Dazu macht es auch Sinn am Anfang die ersten Punkte zu löschen - da es 
dauert bis der GPS Fix halbwegs stabil wird (Almanachdaten) , und 
natürlich auch vor dem hochladen den Track anschauen um evtl große 
Fehlerstellen (etwa Punktwolken oder großes Zickzack, oder noch 
schlimmer - eine Gerade zum Punkt des letzten ausschalten über lange 
Distanz) zu entfernen.


On 13.12.2011 18:07, Manuel Reimer wrote:

Hallo,

ich logge generell einen Punkt pro Sekunde. Bisher lade ich das 
Resultat auch so bei OSM hoch.


Gerade habe ich gesehen, dass gpsbabel auch Tracks vereinfachen kann.

Sollte man Tracks vor dem Hochladen so bearbeiten oder werden 
unveränderte Tracks lieber gesehen? Ist es sogar sinnvoll die Tracks 
zu vereinfachen, um Speicherplatz zu sparen?


Gruß

Manuel


___
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] mkgmap und der --delete-tags-file Parameter

2011-08-08 Diskussionsfäden Felix Hartmann


On 07.08.2011 22:30, Joerg Fischer wrote:

Chris66 wrote:


ich mach das so, dass ich die Option --link-pois-to-ways nutze und im
polygon-file shop=* auf Gebäude umsetze:

shop=* [0x13 resolution 24]

Und das funktioniert _wenn Du vorher die Gebäude via
--delete-tags-file gelöscht hast_? Das versteh ich gerade nicht...

Tschaui, Jörg

AFAIK ist delete-tags-file kaputt, und funktioniert nicht! Man müsste es 
allerdings mal überprüfen (etwa highway tag löschen, und schauen ob 
trotzdem highways in der Karte auftauchen)



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

Re: [Talk-de] Bahnstrecke vs. Gleis

2011-05-25 Diskussionsfäden Felix Hartmann




On 25.05.2011 12:07, Garry wrote:

Am 24.05.2011 17:40, schrieb Torsten Leistikow:

Garry schrieb am 24.05.2011 17:09:
In die eine Richtung ist es eine Detailverbesserung, in die andere 
würde

sicher nicht nur ich es als Vandalismus
ansehen...
In beiden Richtungen wird Information zerstoert, die von 
unterschiedlichen
Auswertungen genutzt werden. Letztendlich werden die meisten 
Kartenansichten
durch das detailliertere Mapping schlechter und nicht besser, so dass 
die

Sichtweise des Vandalismus alles andere als eindeutig ist.
Da wir nicht für den Renderer taggen können wir auch keinen 
Vandalismus an den Kartenansichten

tätigen ;-)

Du hast da katastrophal was falsch verstanden. Der Satz wir taggen nicht 
für die Renderer bedeutet. Wir taggen nicht so, dass Fehler vom Renderer 
verschleiert werden, bzw wir taggen nicht für spezielle Renderer.


Wir sollten aber sehr wohl so taggen, dass man mit für den Renderer 
zumutbarem Aufwand eine korrekte Karte rendern kann. Daher braucht es 
eben Lösungen, um für Zoomstufen mit weniger Details, auch noch korrekte 
Daten aus OSM herausfiltern zu können.
OSM ist kein Gemälde in Weltgrößesondern noch immer primär eine 
Datenbank (und wenn eine Datenbank nicht logisch aufgebaut ist, dann ist 
sie Schrott, ganz einfach)



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

Re: [Talk-de] Bahnstrecke vs. Gleis

2011-05-24 Diskussionsfäden Felix Hartmann




On 24.05.2011 10:07, Wolfgang wrote:

Hallo,
Am Montag 23 Mai 2011 19:16:16 schrieb Bjørn Bäuchle:


Oder soll man die Trasse taggen? Dafür könnte man dann vlt
landuse=railway_corridor benutzen. Fang gerne an damit, und wenn sich
das durchsetzt, spricht ja nichts dagegen, dass die Renderer bei
Zoomlevels  13 (oder was auch immer) eben railway_corridor benutzen
statt railway=*.


landuse=railway

gibt es schon länger im Wiki und wird bereits benutzt und gerendert.

Gruß, Wolfgang



Das wird aber als Fläche und nicht als Linie eingezeichnet, und ist 
daher erst recht für niedrige Zoomstufen untauglich. Evtl wäre 
railway=railway_corridor als Mittellinie nicht schlecht. Und da gehören 
dann auch Relationen dran, sowie die Bedeutung der Strecke. (weil usage 
ja Bullshit ist, gelinde gesagt, für eine allgemeine Karten)



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

Re: [Talk-de] Bahnstrecke vs. Gleis

2011-05-23 Diskussionsfäden Felix Hartmann




On 23.05.2011 12:43, M∡rtin Koppenhoefer wrote:

Am 23. Mai 2011 02:26 schrieb Felix Hartmannextremecar...@gmail.com:

Ich bin mir sicher, dass es einfacher wäre, die abstrakteren Level
up-to-date zu halten. Fakt ist derzeit kann man aus OSM Daten keine
vernünftige Weltkarte rendern. Auf Rasterbasis mag das noch irgendwie gehen,
aber als Vektorkarte ganz sicher nicht.


stelle ich mir ziemlich einfach vor: einzelne Layer als Raster rechnen
und danach in Vektoren umwandeln und zusammensetzen.

Gruß Martin

Viel Spaß mit dem Schrott der dabei entsteht.


Das Problem ist dass Matching von ähnlichen Sachen halt nie 100% korrekt 
funktionieren kann. Dafür gibt es ja auch Relationen. Sprich man 
bräuchte eine Relation die alle Gleise zusammenfasst. Dann könnte man es 
vernünftig rendern.
Ein Rasterkartenrenderer wird übrigens auch viel Zeit verschenken, nur 
wenn halt 5 Gleise übereinander liegen, sieht man nur eins, somit ist 
für den Betrachter egal.





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

Re: [Talk-de] Bahnstrecke vs. Gleis

2011-05-22 Diskussionsfäden Felix Hartmann




On 22.05.2011 22:47, Bjørn Bäuchle wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Thorsten,

Am 22.05.2011 19:01, schrieb Torsten Leistikow:

Ich habe ja auch nichts gegen die Detail-Erfassung, aber warum konnte
dafuer nicht ein neues Tag genommen werden? Ein Gleis ist nun mal was
anderes als eine komplette Bahnstrecke. Beim Detailmapping von
Wohngebieten benutzt man ja auch building=* fuer die Gebauede und
traegt nicht einfache viele kleine landuse=residential ein.

ich bin in Frankfurt eifrig dabeigewesen, Eisenbahnen gleisgenau zu
mappen. Wenn ich dich richtig verstehe, hast du da auch nichts dagegen,
richtig? Aber dann mach doch einen Vorschlag, wie man sonst die
Einzelgleise taggen soll, wenn railway=* für dich nicht akzeptabel ist!?
Ich hielt das für sinnvoll, denn getrennte Fahrstreifen auf der Straße
sind ja auch beide highway=*, dabei sind - um dein Argument zu nehmen -
Fahrspuren was anderes als eine komplette Autobahn. Als ich damit
angefangen habe, das zu mappen, habe ich auch nirgendwo gelesen, dass es
damit ein Problem geben könnte.

Also, wie ist dein Proposal?
Das Ganze ist bei Autobahnen ja auch schon ein Fehler. Bei 
Billigrendereren die aus Vektordaten Rasterkarten (etwa png) erzeugen 
wie Mapnik, ist das ganze egal. Aber alle Renderer die Vektordateien 
benutzen um diese möglichst real-time darzustellen, ist es einfach nicht 
vernünftig. Egal ob jetzt Fahrspuren, separate Bürgersteige, etc.


Die professionelle Variante wäre, die Mitte zu kennzeichnen, und auf die 
Mitte alle für Autorouting relevanten Infos einzutragen. Separate 
Spuren, Gleise, etc. sollten nur für die Darstellung in niedrigen 
Zoomstufen benutzt werden.


Ein Mittelweg, wäre etwa ein Mittelgleis zu definieren, welches separat 
getagged wird damit es klar ist, dass dies für Routing/Rendering in 
hohen Zoomstufen benutzt wird.


Warum sind Einzelgleise auch wirklich falsch? -- Weil etwa eine 
Zugverbindung nicht alle Gleise benutzt, sondern wie genereller Verkehr, 
nur bestimmte Gleise der Bahnstrecke (Bahnstrecke gleich die 
Zusammenfassung aller Einzelgleise). Sprich nur weil man Sachen einzeln 
mappt, wird es nicht korrekter. Karten sind Abstrakte der Wirklichkeit. 
Eine Karte ist kein Foto. Also ist eine einzelne Bahnspur genauso 
inkorrekt wie alle Gleise separat. Im Idealfall sollte man beides haben.


Und usage=main hat nichts mit der Bedeutung zu tun, das wurde nur häufig 
falsch beschrieben (und darüber hab ich mich im Wiki auch schon 
ordentlich geärgert). Usage ist nur was für Eisenbahnfreaks, für alle 
anderen, bräuchte es ein Tag um Hauptverbindungen von Nebenverbindungen 
zu unterscheiden, weil dies in Ansicht der Bahnfreaks, nichts mit Haupt 
und Nebenstrecken zu tun hat. usage=main, kannst auch an die nicht 
elektrifizierte Bimmelbahn nach Hintertupfing anhängen. Man kann aber 
trotzdem sagen, dass die Bahnfreaks hier recht haben, weil usage sich 
ihrer Meinung eben auf das Gleis und nicht die Bahnstrecke bezieht. Die 
Bedeutung müsste man im Prinzip in der Relation angeben, und das nicht 
per usage, sondern mit einem neuen Tag.



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

Re: [Talk-de] Bahnstrecke vs. Gleis

2011-05-22 Diskussionsfäden Felix Hartmann





-- Weil etwa eine Zugverbindung nicht alle Gleise benutzt, sondern 
wie genereller Verkehr, nur bestimmte Gleise der Bahnstrecke 
(Bahnstrecke gleich die Zusammenfassung aller Einzelgleise). Sprich 
nur weil man Sachen einzeln mappt, wird es nicht korrekter. Karten 
sind Abstrakte der Wirklichkeit.


Voellig richtig, und wenn wir hier eine Karte im Illustrator malen 
wuerden, waere das was anderes. Aber die Abstraktion soll bitte der 
Renderer vornehmen und nicht der Mapper. Ich moechte naemlich 
irgendwann schon gern ein Draisinen-Routing haben, bei dem mir der 
Router genau sagt, ob ich das linke oder rechte Gleis fahren soll ;)


Das Problem des Masstabs haben wir uebrigens bei Bahnhoefen auch 
schon; wenn ich jetzt die Kursbuchstrecke Basel-Hamburg als Relation 
eintrage, bin ich gezwungen, die an ein ganz bestimmtes Gleis zu 
haften und an einen ganz bestimmten Bahnsteig in jedem Bahnhof, obwohl 
das natuerlich meistens eine operative Entscheidung ist und nicht in 
Stein gemeisselt. Es muesste also tatsaechlich die Moeglichkeit geben, 
eine Trasse und einen Bahnhof auf einem abstrakteren Niveau 
anzusprechen als ein konkretes Gleis.


Manchmal denke ich, wir sollten solche Relationen erst dann 
einfuehren, wenn mindestens zwei verbreitete Editoren damit auch gut 
umgehen koennen. Wir haben im Moment eine Situation, wo sehr viele, 
meist auch logisch irgendwie sinnvolle, Relationen angelegt werden, 
aber ich fuerchte, immer weniger Leute blicken da durch.


Ich bin mir sicher, dass es einfacher wäre, die abstrakteren Level 
up-to-date zu halten. Fakt ist derzeit kann man aus OSM Daten keine 
vernünftige Weltkarte rendern. Auf Rasterbasis mag das noch irgendwie 
gehen, aber als Vektorkarte ganz sicher nicht. Dabei könnte man so eine 
Weltkarte, als Einzelperson, wohl locker innerhalb von 2-3 Wochen von 
Yahoo Bildern / OSM Grundlayer erstellen. Dazu noch 1-2 Zwischenlayer, 
und es würde die ganze Sache viel einfacher machen. Auch weil es 
bestimmte Konflikte über Detailgenauigkeit lösen würde (wer jeden Baum 
einzeln taggen möchte, der könnte das dann ohne Schaden machen, wo die 
absolute Genauigkeit da bleibt, ist dann halt fraglich). Und es würde 
viele der Relationen deutlich vereinfachen.


Man könnte sogar überlegen, ob es nicht Sinn macht, die Datenbank viel 
stärker aufzubröseln. Damit man sich nur noch die Sachen holt die man 
braucht. Das ein Topf wo ich alles reinschmeiße Modell, funktioniert 
einfach immer schlechter. Etwa je genauer Straßen gemapped werde, in 
desto mehr Einzelteile werden sie zerlegt, aber fast immer ohne eine 
Straßenrelation zu erstellen (ist ja irgendwie auch dumm, dass es sowas 
braucht). Und desto mehr Einzelteile, die man maximal in 90% der Fälle 
korrekt logisch verbinden kann, desto schlechter wird das Routing.


Und es gibt derzeit keinen Editor, der wirklich gut mit Relationen 
umgehen kann (sprich, der halbwegs intelligen erkennt, wenn jemand eine 
Relation doppelt einträgt, oder der intelligent die Relation anzeigt, so 
dass der User sieht dass sie schon existiert). Solange man nicht bei 
klicken auf Fahrradroute, alle Fahrradrouten im Editorausschnitt 
hervorgehen sieht (aber restliche Relationen unsichtbar bleiben), wird 
es auch nicht klappen. Damit unser derzeitiges immer detaillierter 
werdendes Mapping irgendwie funktioniert, bräuchte es viel mehr 
Userbasierte Presets. Sprich das komplette Kartenrendering und 
Editorpresetlayout verändert sich, wenn ich anklicke taggen als 
Wanderer oder taggen als Autofahrer. Das ist zwar umsetzbar, aber 
richtig viel Arbeit. Und solange die Editoren in ihren 
Vektordarstellungen nicht 1-2 Generationen besser werden (bezogen auf 
Presets für die Darstellung wie auch technische Möglichkeiten der 
Darstellung, wird es auch nicht Userfreundlich.



OSM ist so groß geworden, dass es einfach eine Fragmentierung braucht 
(klar braucht das viel Input/Zeit um eine Interoperabilität der 
Fragmente zu gewährleisten). Wenn dies nicht passiert, wird OSM einfach 
an Bedeutung verlieren, weil Spezialgruppen ihre Interessen nicht mehr 
umsetzen können (und das ist das was OSM wirklich ausmacht, weil nur 
freie Kartendaten gibt es eh mehr und mehr) ohne andere Gruppen vor den 
Kopf zu stoßen.
Highway:area=* wäre etwa ein Fall, der ganz einfach in eine separaten 
Datenbankteil gehört.


Wenn hier nichts passiert, werden andere Userbasierte Kartendatenbanken 
interessanter werden und es würde sich alles zersplittern (womit aber 
die größte Stärke von OSM, die Verkreuzung verschiedenster sonst so 
nicht registrierter Daten, abhanden käme).



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

Re: [Talk-de] Cycleways - oftmals falsch getaggt




Schön wäre es wohl, schnell eine Lösung für das Multilane-Problem zu
finden und in den Editors Relationen noch benutzerfreundlicher (Newbies)
zu machen. Nebenbei könnten wir ja noch das Area-Problem lösen.;)

Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu erfassen, und 
dann alle Lanes (egal ob jetzt Bordstein oder Fahrradweg) mit relativer 
Entfernung dazu. Bei Kreuzungen dann angeben, welche Lane zu welcher 
Lane der kreuzenden Straße eine Verbindungsmöglichkeit hat.


Dann könnte man auch easy pro Lane die Breite angeben, bzw Zustand und 
hätte keine Probleme beim herauszoomen (sprich beim rauszoomen, kann ich 
sehr schnell ausrechnen, ab wann Linien überlagert werden, und brauche 
sie nicht doppelt zu zeichnen - sprich enorme Performancesteigerung etwa 
beim rendern von Straßen am GPS oder anderen Systemen die Vektorkarten 
benutzen).



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

Re: [Talk-de] Cycleways - oftmals falsch getaggt




On 05.05.2011 16:54, M∡rtin Koppenhoefer wrote:

Am 5. Mai 2011 16:29 schrieb Felix Hartmannextremecar...@gmail.com:

Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu erfassen, und dann
alle Lanes (egal ob jetzt Bordstein oder Fahrradweg) mit relativer
Entfernung dazu. Bei Kreuzungen dann angeben, welche Lane zu welcher Lane
der kreuzenden Straße eine Verbindungsmöglichkeit hat.


Das reicht für vieles nicht aus, wir wollen ja nicht nur routen mit den Daten...

Gruß Martin

Wofür soll es denn nicht ausreichen??? Beispiele benötigt.

Im Katasterplan von Wien, werden Straßen so eingezeichnet (AFAIK) 
seitdem er vektorisiert wurde, bzw dort wo er vektorisiert erfasst wurde.



Das es vom Modell her nicht unbedingt einfach ist, ist klar, aber darum 
können sich Editorenpresets kümmern.



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

Re: [Talk-de] Cycleways - oftmals falsch getaggt




On 05.05.2011 18:29, M∡rtin Koppenhoefer wrote:

Am 5. Mai 2011 18:20 schrieb Felix Hartmannextremecar...@gmail.com:

On 05.05.2011 16:54, M∡rtin Koppenhoefer wrote:

Am 5. Mai 2011 16:29 schrieb Felix Hartmannextremecar...@gmail.com:

Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu erfassen, und dann
alle Lanes (egal ob jetzt Bordstein oder Fahrradweg) mit relativer
Entfernung dazu. Bei Kreuzungen dann angeben, welche Lane zu welcher Lane
der kreuzenden Straße eine Verbindungsmöglichkeit hat.

Das reicht für vieles nicht aus, wir wollen ja nicht nur routen mit den
Daten...

Wofür soll es denn nicht ausreichen??? Beispiele benötigt.


Beispiele braucht man da keine: es reicht nicht, um die Form
abzubilden, ist wohl klar, oder?



Doch es reicht um die Form abzubilden. Es braucht nur die enstprechenden 
Tags dafür. Straßen, Krezungen, und Bordsteine haben es an sich vom 
Menschen am Reißbrett geplant zu sein, und daher mit Vektoren leicht 
beschreibbar zu sein. Das ganze funktioniert natürlich nicht vernünftig 
in der Natur, wo man wohl wirklich auf Wege als Flächen für eine 
sinnvolle genaue Abdeckung der Lage ausweichen müsste (macht zum Glück 
keiner, weil es keinen sinnvollen Nutzen hat).



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

Re: [Talk-de] Cycleways - oftmals falsch getaggt




On 05.05.2011 20:00, M∡rtin Koppenhoefer wrote:

Am 5. Mai 2011 19:05 schrieb Felix Hartmannextremecar...@gmail.com:

Doch es reicht um die Form abzubilden. Es braucht nur die enstprechenden
Tags dafür. Straßen, Krezungen, und Bordsteine haben es an sich vom Menschen
am Reißbrett geplant zu sein, und daher mit Vektoren leicht beschreibbar zu
sein.


wenn Du aber mehrere Vektoren in einem zusammenfasst ist es klar, dass
nicht alle Informationen enthalten sein können.

Du brauchst nicht mehrere Vektoren in einem zusammenfassen. Es reicht 
aus die relative Lage zu bestimmen. Ausserdem reicht es normalerweise 
aus, anzugeben, Spur X verläuft mit Breite von x Metern im Abstand von Y 
Metern zur Mittellinie. Bei Krezungen gibt man dann genau an, welche 
Spur, auf welche Spur der kreuzenden Straße trift. So kann man das 
leidige Problem lösen, dass man mit alle Möglichkeiten separat 
einzeichnen hat (das funktioniert bei komplizierten Krezungen nicht, 
haben wir etwa schon beim Wiener OSM Treffen durchgesprochen, sprich die 
Spuren dort wo sie sind einzeichnen, ist NICHT ausreichend um komplexe 
Krezungen korrekt abzubilden).


Klar braucht es dafür ein sehr spezialisiertes Taggingsystem, und 
Editoren die es umsetzen. Das wird locker ein paar Monate 
Entwicklungszeit brauchen, damit es einfacher und besser ist, wie das 
derzeitige Chaos.


Etwa diese Krezung hier: 
http://www.openstreetmap.org/?lat=48.248268lon=16.388447zoom=18layers=M
Ist derzeit einfach nicht auch nur halbwegs korrekt eintragbar, mit 
unserem derzeitigen Datenmodell (weder ist das Autorouting korrekt, noch 
die Anzeige). Dabei ist die noch gar nicht so komplex (und Fuß und 
Radwege sind gar nicht eingetragen). Wobei erschwerend natürlich noch 
dazu kommt, dass es sich hier um eine Krezung auf einer Brücke handelt. 
(und das falscheste ist, es gibt hier nicht zwei separate Brücken, 
sondern nur eine auf der beide Fahrtrichtungen verlaufen - aber die 
Brücke ist nicht als Relation eingetragen - was sie eigentlich müsse, 
aber fast nirgends korrekt ausgewertet wird).


Dafür bräuchte es einfach ein Fahrspurensystem in OSM.


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

Re: [Talk-de] Cycleways - oftmals falsch getaggt




Unterscheidung, von daher ist ein in Deutschland nicht angebracht.
Sie unterscheiden sich durch die An- bzw. Abwesenheit der Straße.
Mit dem Argument unterscheiden sich Wanderwege mit immer wieder 
lockerem
Sandboden und geteerte Wanderwege durch den Belag und sollten dann 
nicht
beide mit dem gleichen highway-Wert getagged werden; der Unterschied 
für
Radfahrer ist sicherlich größer als der zwischen Bürgersteig und 
Fußweg für

(erwachsene) Fußgänger - überzeugt mich irgendwie nicht besonders.

ich glaube, wir verstehen unterschiedliche Dinge unter Typologie. Für
mich ist ein Wanderweg ein Typ (Feinunterteilungen lasse ich hier mal
aussen vor, sind alles Beispiele). Eine Straße auch. Eine mehrspurige
Straße mit baulich getrennten Richtungsfahrbahnen auch. Ein
Gehweg/Trottoir/Bürgersteig ist für mich Teil der Straße, im Gegensatz
zu einem eigenständigen Fußweg. Das meinte ich.

Da bist du Architekt und ich Fußgänger ;)
Ein Gehweg ist Teil des Gesamtbauwerks Straße, aber spätestens bei 
einer stark befahrenen Straße hab ich davon nichts gewonnen: Durch die 
praktische Einschränkung, dass ich die Straßenseite nicht ohne Gefahr 
für Leib und Leben wechseln kann, wird der Bürgersteig effektiv zu 
einem eigenständigen Weg.
Und du verlierst durch den eigenständigen Weg, die Information, dass der 
Weg entlang einer stark befahrenen Straße geht, außer du legst nun für 
jeden Bordstein, eine Relation zur Straße.


Troittors wie auch Fahrbanspuren, sind nichts eigentständiges, sondern 
gehören zur Straße. Um die relative Lagegenauigkeit vernünftig zu 
mappen, fehlt derzeit einfach noch ein Konzept. Die aber separat zu 
mappen, bringt nur Probleme (auch für das von dir erwähnte 
Fußgänger-Navi. Das wird sich denken, toll hier ist ein Trottoir, der 
geht lange geradeaus schön zum Ziel, aber weiß nicht, dass der 
Bürgersteig voll in den Abgasen hängt, und bei jeder Querstraße Ampeln 
sind, die die Geschwindigkeit mindern (bzw fehlen uns halt 
Möglichkeiten, Grüne Wellen zu taggen - im Bezug zur 
Fortbewegungsgeschwindigkeit (ohne ist es für Fußgänger, Radler, usw, 
nicht machbar, da sich die Geschwindigkeiten relativ viel stärker 
unterscheiden wie bei Autofahrern).


Gruß
Peter

___
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] Cycleways - oftmals falsch getaggt




On 04.05.2011 14:24, Georg Feddern wrote:

Moin,

Felix Hartmann schrieb:
Und du verlierst durch den eigenständigen Weg, die Information, dass 
der Weg entlang einer stark befahrenen Straße geht, außer du legst 
nun für jeden Bordstein, eine Relation zur Straße.




nun, diese Eigenschaft ließe sich an dem getrennt gemappten Weg 
einfacher per Tag signaliseren (sic! sidewalk=yes) als alle anderen 
Eigenschaften des Trottoirs am Subtag der Straße.
sidewalk:primary=yes  so würde es ansatzweise gehen, aber mir fehlen 
noch viel mehr Infos, siehe weiter unten.


Die aber separat zu mappen, bringt nur Probleme (auch für das von dir 
erwähnte Fußgänger-Navi. Das wird sich denken, toll hier ist ein 
Trottoir, der geht lange geradeaus schön zum Ziel, aber weiß nicht, 
dass der Bürgersteig voll in den Abgasen hängt,


siehe oben

und bei jeder Querstraße Ampeln sind, die die Geschwindigkeit mindern 
(bzw fehlen uns halt Möglichkeiten, Grüne Wellen zu taggen - im 
Bezug zur Fortbewegungsgeschwindigkeit (ohne ist es für Fußgänger, 
Radler, usw, nicht machbar, da sich die Geschwindigkeiten relativ 
viel stärker unterscheiden wie bei Autofahrern).


Ein eigenständig gemapptes Trottoir enthält genauso viele Querstraßen 
bzw. Ampeln (Crossing-Informationen) wie die Straße, die das Subtag 
tragen würde - vorausgesetzt, das Subtag der Straße enthält überhaupt 
die Seiten-Information, sonst gaukelt es ggf. zuviele Querstraßen vor 
- nämlich die, die auf der anderen Seite einseitig sind.
falsch, die Fallen rauß, es gibt ja Turn Restrictions. Die sind leicht 
auszuwerten. Dazu fehlen alle Daten über die Straße selber (was für eine 
Straße, speed limit der Straße, und und und).
Das Grüne-Welle-Problem ist eh grundsätzlich schon ein Daten-Problem, 
aber ansonsten unabhängig vom Mapping-Stil.
Es wird hierdurch noch schlimmer. Weil ich anhand der Straßendaten 
berechnen kann, wie es sich für einen Fahrradfahrer ausgeht (etwa 
maxspeed=30, da schaffe ich es als sportlicher Radler easy im Verkehr 
mitzuschwimmen, bzw sogar schneller zu sein.
Ist der Fahrradweg getrennt, so fehlen mir hier die relevanten 
Informationen über die Straße selber (und noch komplizierter, über 
Relationen welche auf der Straße liegen).



Das separate Mappen von Fahrradwegen am Trottoir, macht derzeit 
genausoviel Sinn wie das separate mappen von Fahrspuren. Nächmlich gar 
keinen Sinn. Uns fehlt hierfür ganz einfach ein vernünftiges Datenmodell.




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

Re: [Talk-de] Cycleways - oftmals falsch getaggt




On 04.05.2011 16:01, Peter Wendorff wrote:

Am 04.05.2011 12:58, schrieb Felix Hartmann:



Unterscheidung, von daher ist ein in Deutschland nicht angebracht.
Sie unterscheiden sich durch die An- bzw. Abwesenheit der Straße.
Mit dem Argument unterscheiden sich Wanderwege mit immer wieder 
lockerem
Sandboden und geteerte Wanderwege durch den Belag und sollten dann 
nicht
beide mit dem gleichen highway-Wert getagged werden; der 
Unterschied für
Radfahrer ist sicherlich größer als der zwischen Bürgersteig und 
Fußweg für

(erwachsene) Fußgänger - überzeugt mich irgendwie nicht besonders.

ich glaube, wir verstehen unterschiedliche Dinge unter Typologie. Für
mich ist ein Wanderweg ein Typ (Feinunterteilungen lasse ich hier mal
aussen vor, sind alles Beispiele). Eine Straße auch. Eine mehrspurige
Straße mit baulich getrennten Richtungsfahrbahnen auch. Ein
Gehweg/Trottoir/Bürgersteig ist für mich Teil der Straße, im Gegensatz
zu einem eigenständigen Fußweg. Das meinte ich.

Da bist du Architekt und ich Fußgänger ;)
Ein Gehweg ist Teil des Gesamtbauwerks Straße, aber spätestens bei 
einer stark befahrenen Straße hab ich davon nichts gewonnen: Durch 
die praktische Einschränkung, dass ich die Straßenseite nicht ohne 
Gefahr für Leib und Leben wechseln kann, wird der Bürgersteig 
effektiv zu einem eigenständigen Weg.
Und du verlierst durch den eigenständigen Weg, die Information, dass 
der Weg entlang einer stark befahrenen Straße geht, außer du legst 
nun für jeden Bordstein, eine Relation zur Straße.
Die Information, an welcher Straße der Weg liegt, verliere ich direkt, 
ja. Durch doppelte Benennung mit dem gleichen Namen ist die Zuordnung 
aber relativ einfach. (Dass das kein besonders gutes Gegenargument zu 
deinem Argument ist, ist mir klar)
Troittors wie auch Fahrbanspuren, sind nichts eigentständiges, 
sondern gehören zur Straße. 
Warum werden dann Fahrbahnspuren, sobald es Abbiegespuren sind, immer 
wieder als eigenständige osm-ways gemapped?

http://osm.org/go/0GlK5rDBy--
http://osm.org/go/0GlK4ZbIK--
http://osm.org/go/0I@V9Lu@u-- hier ist die ganze Straße als zwei Wege 
eingetragen, aber nur durch doppelte durchgezogene Linie voneinander 
getrennt.


Ja sobald es abbiegespuren sind, aber das ist für Autorouting noch 
deutlich zu wenig. Eine virtuelle Kreuzungsansicht die korrekt ist, 
kannst so nicht erstellen. Das ist halt auch nur ein provisorischer 
Workaround zu echtem Fahrspurmapping (etwa inkl. Breite jeder Fahrspur, 
Gewichtslimits, verschiedenen maxspeeds / Richtgeschwindigkeiten, etc...
Da fehlen 99% von dem was Navteq etwa auf vielbefahrenen Straßen an 
Infos hat.

Weitere Beispiele lassen sich bestimmt finden.
Das ist also durchaus jetzt schon gängig, um das Routing zu verbessern 
etc.


Eine strikte Auslegung der Regeln, die in Bezug auf Bürgersteige 
aufgestellt werden, würde dies aber generell verbieten; etwas, das ich 
nirgendwo dokumentiert sehe bisher, und wo auch niemand bisher jemals 
drauf eingegangen ist.
Dummerweise bin ich ja gar nicht gegen das explizite Eintragen von 
Bürgersteigen, also sehe ich auch keinen Grund, die Praxis bei 
Auto-Fahrspuren zu kritisieren.
Um die relative Lagegenauigkeit vernünftig zu mappen, fehlt derzeit 
einfach noch ein Konzept. 

...wenn man nicht das separate Mapping benutzt.

Das ist kein Konezpt, dass ist einfach nur eine schrottige Alternative.
Die aber separat zu mappen, bringt nur Probleme (auch für das von dir 
erwähnte Fußgänger-Navi.

Mal sehen, was du da so für Probleme siehst:
Das wird sich denken, toll hier ist ein Trottoir, der geht lange 
geradeaus schön zum Ziel,

richtig.

aber weiß nicht, dass der Bürgersteig voll in den Abgasen hängt,
Für eine diesbezügliche Beurteilung muss die Umgebung sowieso mit 
interpretiert werden.
Was hilft es, Abgase ausschließen zu können, wenn die Mülldeponie 
stattdessen stinkt?
Solange du das also nicht auch noch an den Fußweg pappen willst 
(Achtung, Mülldeponie in der Nähe!), hast du damit nichts zusätzlich 
verloren.
Wenn die Umgebung analysiert wird, dann wird die Straße genauso 
gefunden wie alles andere auch.
Umgebung analysieren funktioniert nicht. Da gibt es genug Beispiele hier 
in der mailingliste. Umgebung wird erst dann analysierbar, wenn sie 
durch Relationen einen Bezug bekommt (aber dass würde das 
Relationssystem sprengen, wenn man alles was bezug hat, überall dranpappt.


Außerdem sagt sidewalk=yes ja genau das: da ist eine Straße nebenan.

Aber nicht was für eine Straße.

und bei jeder Querstraße Ampeln sind,

...die als highway=crossing eingetragen sein sollten.
Wie erkennst du denn die Ampeln an Querstraßen, wenn du nur 
sidewalk=yes am Fußweg setzt?
Ampeln erkenne ich so auch nicht. Hier wurde nur halbgedacht. Damit 
Ampeln wirklich korrekt sind, bräuchte es Standort und Relationen zu den 
Spuren für die sie gelten. Das ist hier aber nicht.

Ich denke, hier geht deine Argumentation etwas durcheinander.
die die Geschwindigkeit mindern (bzw fehlen uns halt Möglichkeiten, 
Grüne

Re: [Talk-de] Cycleways - oftmals falsch getaggt




On 04.05.2011 16:20, Peter Wendorff wrote:

Am 04.05.2011 15:45, schrieb Felix Hartmann:
und bei jeder Querstraße Ampeln sind, die die Geschwindigkeit 
mindern (bzw fehlen uns halt Möglichkeiten, Grüne Wellen zu 
taggen - im Bezug zur Fortbewegungsgeschwindigkeit (ohne ist es für 
Fußgänger, Radler, usw, nicht machbar, da sich die 
Geschwindigkeiten relativ viel stärker unterscheiden wie bei 
Autofahrern).
Ein eigenständig gemapptes Trottoir enthält genauso viele 
Querstraßen bzw. Ampeln (Crossing-Informationen) wie die Straße, die 
das Subtag tragen würde - vorausgesetzt, das Subtag der Straße 
enthält überhaupt die Seiten-Information, sonst gaukelt es ggf. 
zuviele Querstraßen vor - nämlich die, die auf der anderen Seite 
einseitig sind.
falsch, die Fallen rauß, es gibt ja Turn Restrictions. Die sind 
leicht auszuwerten. Dazu fehlen alle Daten über die Straße selber 
(was für eine Straße, speed limit der Straße, und und und).

Was haben jetzt Turn-Restrictions mit Fußgängerrouting zu tun?
Die Daten der Straße wären für die Einschätzung des Bürgersteigs 
halbwegs sinnvoll, ja; aber nicht besonders dringend, solange nicht 
gequert wird.
Das sehe ich anders. Ich finde diese Daten 10mal wichtiger wie kerb=yes 
oder die relative Lage (absolut bringen wird dadurch ja meist eine 
Verschlechterung der Genauigkeit)
Klar laufe ich lieber an einer Straße in der 30er-Zone entlang als an 
einer Stadtautobahn bei Höchstgeschwindigkeit 70 - aber notwendig ist 
diese Info nicht unbedingt.

finde ich schon.
Das Grüne-Welle-Problem ist eh grundsätzlich schon ein 
Daten-Problem, aber ansonsten unabhängig vom Mapping-Stil.
Es wird hierdurch noch schlimmer. Weil ich anhand der Straßendaten 
berechnen kann, wie es sich für einen Fahrradfahrer ausgeht (etwa 
maxspeed=30, da schaffe ich es als sportlicher Radler easy im Verkehr 
mitzuschwimmen, bzw sogar schneller zu sein.

Das kannst du auch weiterhin.
Ist der Fahrradweg getrennt, so fehlen mir hier die relevanten 
Informationen über die Straße selber (und noch komplizierter, über 
Relationen welche auf der Straße liegen).
Ist der Fahrradweg getrennt, so sollte er entsprechend auch eine 
Höchstgeschwindigkeit tragen, wenn diese hier zur Anwendung kommt.
Abgesehen davon ist es auch weiterhin Sache der Routing-Konfiguration, 
ob Straßen mit Höchstgeschwindigkeit 30 fürs Radrouting mit 
berücksichtigt werden sollen oder nicht.
Die Informationen, die auf den Radweg zutreffen, sollen natürlich am 
Radweg getagged werden. Ob das aber zutrifft oder nicht, ist damit 
erstmals explizit tagbar, während bisher die Unterscheidung eben nicht 
möglich ist, außer vielleicht über maxspeed:bicycle=*


Wenn Du aber über den Verlust von Informationen redest, dann bring ich 
jetzt den Rennradfahrer, der den doofen gepflasterten Radweg nicht mag 
und deshalb die Straße lieber ganz meidet, sobald der Radweg mit 
StVO-Z 237, 240 oder 241 gekennzeichnet ist, weil er dann den Radweg 
benutzen MUSS.
Grade als Rennradfahrer, ist es mir wichtig die Abhängigkeit von der 
Straße möglichst exakt zu wissen. Aber in AT brauch ich am Rennradel eh 
nicht den beschissenen Radweg am Randstein benutzen.


Die hier WICHTIGE Information über unterschiedliche Beläge von Radweg 
und Fahrbahn gehen aber üblicherweise verloren (oder willst du jetzt 
solche Tag-Monster wie sidewalk:left:surface. aufbauen?).
wüsste nicht was an sidewalk:left:surface=blablabla auszusetzen ist, 
genauso wenig wie an sidewalk:left:width= usw. Tagging Monster sind 
es nur, solange die Editoren es nicht vernünftig unterstützen.


Das separate Mappen von Fahrradwegen am Trottoir, macht derzeit 
genausoviel Sinn wie das separate mappen von Fahrspuren. Nächmlich 
gar keinen Sinn. Uns fehlt hierfür ganz einfach ein vernünftiges 
Datenmodell.

Dass das Datenmodell dafür nicht ideal ist, dem stimme ich zu.
Wann aber ändert sich ein Datenmodell?
Wenn der Bedarf da und der Druck groß genug ist.

Mir ist bisher kein sinnvolles Datenmodell eingefallen, das 
mehrspurige Straßenprofile sowie Querungen unterstützen könnte, dabei 
aber für den Mapper handhabbar bleibt.


Das Mapping imer wieder totzudiskutieren, weil kein Datenmodell genau 
passt, ist aber der falsche Weg.
Das sehe ich anders, lieber gar nicht als falsch. Und genau der Weg wird 
mit dem separaten Mapping gepushed. Es braucht einfach eine klare 
Separation von visueller Gestaltung, und zugrundeliegenden Daten. Auch 
das Datenmodell an sich, muss halt verbessert werden, aber wenn wir 
dauernd lieber informationen halbrichtig eintragen, wird da kein Druck 
entstehen, Editoren vernünftig aufzubauen, um Fahrspuren gut eintragbar 
zu machen, ohne Informationen zu verlieren. Dazu kann man dann ja noch 
separat rein für die Anzeige ein visual:highway:sidewalk:cycleway 
einzeichnen, für jene die meinen das zu brauchen (Verdrängung - macht es 
nicht grade einfach).


Vorschläge sind immer willkommen.
Wenn sie Änderungen an der OSM-Datenbank erfordern, dann ist das eben so.
Vernünftige

Re: [Talk-de] Cycleways - oftmals falsch getaggt




On 04.05.2011 16:33, Peter Wendorff wrote:

Am 04.05.2011 16:13, schrieb Felix Hartmann:
Was hilft es, Abgase ausschließen zu können, wenn die Mülldeponie 
stattdessen stinkt?
Solange du das also nicht auch noch an den Fußweg pappen willst 
(Achtung, Mülldeponie in der Nähe!), hast du damit nichts 
zusätzlich verloren.
Wenn die Umgebung analysiert wird, dann wird die Straße genauso 
gefunden wie alles andere auch.
Für eine diesbezügliche Beurteilung muss die Umgebung sowieso mit 
interpretiert werden.
Umgebung analysieren funktioniert nicht. 

Glaub ich nicht ;)
Da gibt es genug Beispiele hier in der mailingliste. 

Welche? Ich will ja lernen ;)
Hab jetzt keine Lust zu suchen, aber das notorisch in nur 90% aller 
Fälle korrekte Nominatim, ist doch die beste Begründung. Es funktioniert 
nicht zuverlässig.
Umgebung wird erst dann analysierbar, wenn sie durch Relationen einen 
Bezug bekommt (aber dass würde das Relationssystem sprengen, wenn man 
alles was bezug hat, überall dranpappt.
Ich gebe zu, dass Nominatim da recht viel Rechenzeit reinsteckt, aber 
die Zuordnung von Häusern zu Straßen funktioniert - und das ist eine 
reine Umgebungsanalyse in den allermeisten Fällen.

Ich sehe keinen Grund, warum das in anderen Fällen nicht gehen sollte.

Außerdem sagt sidewalk=yes ja genau das: da ist eine Straße nebenan.

Aber nicht was für eine Straße.

Ja und?
Wie viele Straßen sind denn üblicherweise nebenan?
Nimm großzügig kalkuliert eine Straßenbreite von 14 Metern an (das 
reicht für eine zweispurige innerorts-Bundesstraße einschließlich 
Randstreifen), dann reicht ein Puffer zur Seite von 9 Metern aus, um 
die richtige Straße zu finden.
Innerhalb dieses Puffers zwei Straßen zu finden, und dann die falsche 
zu treffen, wenn man tatsächlich mehrere findet und die nächste davon 
auswählt, halte ich für ein seltenes Phänomen.
Dann müsste man Bäume, Mauern, Haushöhen, usw mit reinrechnen, das ist 
nur ein Kampf, der nie korrekt sein wird.

und bei jeder Querstraße Ampeln sind,

...die als highway=crossing eingetragen sein sollten.
Wie erkennst du denn die Ampeln an Querstraßen, wenn du nur 
sidewalk=yes am Fußweg setzt?
Ampeln erkenne ich so auch nicht. Hier wurde nur halbgedacht. Damit 
Ampeln wirklich korrekt sind, bräuchte es Standort und Relationen zu 
den Spuren für die sie gelten. Das ist hier aber nicht.
Wieso das? Wir sind bei Fußgängerrouting und Querungen. Die sind per 
highway=crossing eingetragen, und zwar nicht auf dem Kreuzungspunkt 
der beiden Straßen, sondern abseits davon da, wo die Fußgängerampel 
steht (meist ca 3-5 meter vom Straßenrand(!) entfernt).
Aus einer Kfz-Ampel eine Fußgängerampel zu schließen geht sowieso oft 
schief.


Das Ampel-Tagging für Autos ist nicht perfekt, da gebe ich dir recht; 
es hat mich allerdings bisher auch nur am Rande interessiert.
Dass die für nur einige Spuren gelten üblicherweise ist richtig, aber 
irrelevant, solange die Spuren nicht eingetragen sind.
Jip, und genau daher sollten wir es auch bei Wegen am Gehsteig genauso 
handlen, nicht separat eintragen.

Ich denke, hier geht deine Argumentation etwas durcheinander.
die die Geschwindigkeit mindern (bzw fehlen uns halt Möglichkeiten, 
Grüne Wellen zu taggen - im Bezug zur 
Fortbewegungsgeschwindigkeit (ohne ist es für Fußgänger, Radler, 
usw, nicht machbar, da sich die Geschwindigkeiten relativ viel 
stärker unterscheiden wie bei Autofahrern).
Aber ist das ein Problem, das man löst, indem man Bürgersteige als 
Tags an der Straße mapped?
Nein, nicht vollständig, aber schon besser wie wenn die Sachen 
separat gemapped sind.

Wieso?
Schließt du aus der grünen Welle der Autos auf eine grüne Welle für 
Fußgänger und Radfahrer?

Sorry, aber das ist unrealistisch.
Nein, das geht sogar ganz gut - solange Grüne Wellen nur geschätzt 
werden. Klar ist man langsamer, aber halbwegs einschätzen kann es eine 
Routingengine trotzdem - und wenn die Ampelschaltungen mal korrekt 
eingetragen sind, dann würde es sogar hervorragend gehen, basierend auf 
momentaner Geschwindigkeit.


Gruß
Peter


___
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] [mkgmap-dev] continue statement and order of drawn ways?

2011-05-03 Diskussionsfäden Felix Hartmann




On 04.05.2011 00:05, Henning Scholland wrote:

Am 03.05.2011 23:37, schrieb Felix Hartmann:


On 03.05.2011 23:27, Minko wrote:
Yes, that is also a good alternative, 0x01 as a transparent line and 
on top either

0x10f01 or 0x10f02


you cannot make a line transparent by omitting it from the typfile, but
go ahead and do your tries.

Yes, but you can use a transparent png-file ;)

Henning

And then you have streetnames shown, but no street If you remove the 
streetnames on 0x01, you remove streetnames on the broken Oregon, edge 
800, gpsmaps 62 series, for all maps (until hard reset)


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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3





Genau das sage ich ja. Daher will ich keine odbl. Ausserdem gehts wie 
gesagt gar nicht um Garmin, sondern um Vektorkarten im allgemeinen. 
Und hier versagt die odbl kläglich, weil nicht klar ist was eine 
Datenbank ist, bzw was Vektorkarten sind. 


Ich hab doch aber gerade auf ca. 100 Zeilen dargestellt, dass es 
eigentlich gar keine Rolle spielt?


Naja, ich finde es keine Lösung, wenn die Lizenz zu ihrem größten 
Unterscheidungspunkt, derivated database oder produced work, keine 
klaren Regeln hat, was was ist. Und die Regel der Ersteller bestimmt es 
selber, hat für mich mit Datenfreiheit nichts zu tun. Da ist die 
Freiheit einfach den Bach runtergeflossen...



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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3




On 30.04.2011 10:48, Simon Poole wrote:
Die Regel ist eigentlich klar: Produced Work ausser es wurde zum 
Zwecke gemacht die Bestimmungen in der ODbL zur Datenbank zu umgehen. 
Da das bei einer Garminkarte eigentlich nicht so ist (sprich Geometrie 
hat man, den Rest eigentlich nur grob, insofern es sich überhaupt auf 
Garmin Werte abbilden lässt) - Produced Work.



Das ist aber keine glückliche Definition und lässt Unmengen an Spielraum zu.

Etwa ich exportiere Key X aus OSM Datenbank, um ihn für meine Anwendung 
zu benutzen. Dann ist das der Auffassung nach eindeutig Produced Work.


Da ich aber für eine Garmin Karte nicht nur Key X exporiere, sondern 
sallop gesagt A-F, aber ohne D., habe ich schon eine recht umfangreiche 
Datenbank. Ausserdem erstelle ich ja etwa für die Addresssuche auch eine 
wirkliche neue Datenbank aus OSM Daten.

-- Aber du sagst eindeutig Produced Work.

Gut dann ist eh alles Produced Work, wenn der Zweck den ich festlege 
(kann ja sein dass die User einen ganz anderen Zweck sehen wollen) keine 
Umgehung der Datenbank ist.



Ohne fixe Regeln die keinen Spielraum lassen, ist dass doch Schwachsinn 
von hinten bis vorne.



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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3


On 30.04.2011 15:51, Henning Scholland wrote:

Am 30.04.2011 14:11, schrieb M∡rtin Koppenhoefer:

Am 30. April 2011 13:41 schrieb Henning Schollando...@aighes.de:
WIe bereits in der anderen Mail angedeutet kann man mit etwas 
Bilderkennung

und Rechenpower auch aus einem jpg die Daten wieder auslesen.


ach echt? Hast Du ein Programm dafuer oder eine Referenz? Ich bin
bisher immer davon ausgegangen, dass das nicht moeglich sei. Habe mich
selbst im Studium schon mit Vektorisierungsversuchen von
Raster-Katasterplaenen rumgeschlagen (600 dpi s/w, 1:5000) und kann
Dir berichten, dass da nie was brauchbares rauskam. Nie. Ich glaube
das nicht, dass das geht, will es aber auch nicht komplett
ausschliessen. Gleich gut kann es aber natuerlich nicht werden, da
die meisten Attribute (bozogen auf die Anzahl verschiedener Attribute)
und tags im Rendering ja gar nicht drin sind.
Es gab im Zuge der Bing-Bildbereitstellung erste Ansätze, aus den 
Satbildern Straßenverläufen zu folgen. Umgesetzt als josm-Plugin. Wie 
der derzeitige Stand ist, weiß ich nicht. Aber ganz unbrauchbar war 
das damals gezeigte Ergebnis nicht. Eine Online-Demo gibts hier 
http://maps.qualitystreetmap.org/bingtracing/
Wenn das mit Sat-Bildern schon so gut funktioniert, dann dürfte es 
mit einem einfach gehaltenen Style durchaus möglich sein, zumindest 
Straßen zu extrahieren.


Henning



Topo Hispania -- eine Garminvektorkarte erstellt aus den amtlichen 
(NCBY) veröffentlichten Rasterkarten. Es geht also sehr wohl. Auch wenn 
es natürlich besser ist, die zugrunde liegenden Daten zu haben. Die 
Sache mit Datenbank vs Produced Work, hinkt einfach von hinten bis vorne.



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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3




On 30.04.2011 15:59, Henning Scholland wrote:

Am 30.04.2011 14:52, schrieb Frederik Ramm:
Das ist von der Logik her nicht ganz leicht zu begreifen, weil man 
immer denkt: Wenn die DVD erstmal ihr Share-Alike verloren hat, dann 
kann das ja nicht wieder zurueckkommen. Kann es aber doch. Das ist so 
aehnlich, wie wenn ich Dir ein Rezept fuer Milcheis aufschreibe und 
versichere, dass mein Text PD ist, und dann stellt sich heraus, dass 
jemand anders - moeglicherweise komplett ohne mein Wissen - ein 
Patent auf diese Art der Milcheis-Herstellung hat. Dann kannst Du 
auch nicht darauf pochen, dass Du doch hier einen 100% PD-Zettel 
hast, auf dem das draufsteht.
Vollkommen richtig. Der Patentinhaber wird Ulf auf Schadensersatz 
verklagen und Ulf, sagt, wieso soll ich das zahlen. Der Frederik  hat 
mir doch das Ding als PD verkauft und verklagt dich auf 
Schadensersatz. Also bist du der dumme.
Vorallem, wenn man bedenkt, dass es hier nicht um Milchreis geht, 
sondern um OSM-Daten und dass man als Autor sich schon mit der Lizenz 
auseinander gesetzt haben muss, wenn man die Daten nicht unter ODbL 
stellt, ergo sich nicht rausreden kann und sagen kann, man hätte davon 
nichts gewusst.


Henning

Was dann einfach im Grunde so ausschaut. Entweder odbl oder unfrei. Aber 
von einer freien Karte aus freien Daten ist man halt weit weg. Schöne 
neue odbl Welt



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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3




On 30.04.2011 16:57, Bodo Meissner wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 30.04.2011 01:22, schrieb Felix Hartmann:


Das würde mit CCBYSA und dem DRM verbot durchs Share Alike halt anders aussehen.

Glaube ich nicht.
Ich könnte das übersehen haben, weil die vollständigen Lizenztexte ziemlich 
unübersichtlich sind.
Wo genau steht bei CCBYSA das DRM-Verbot?

Wenn ich dem Käufer erlaube, die Karte unter CCBYSA weiterzugeben, die Daten 
aber nur auf einem bestimmten Gerät nutzbar sind, habe ich dann formal die 
Lizenz eingehalten?



Soweit ich weiß, steht in der CCBYSA 3.0 (auf die man ja ohne 
Userbefragung wechseln könnte) drinne, das Maßnahmen die die weitergabe 
Einschränken nicht zulässig sind. Daher ist DRM nicht erlaubt.



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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3




On 29.04.2011 12:32, Ulf Lamping wrote:

Am 21.04.2011 09:59, schrieb Frederik Ramm:

Hallo Kai,

On 04/21/11 04:23, Kai Krueger wrote:

Mit ODbL muss ich nun mir ueberlegen ist es ein Produced Work oder
nicht?


Wenn es eine Datenbank ist, ist es eine Datenbank, und ansonsten ist es
ein Produced Work. Es gibt in der Tat ein paar Dinge, bei denen das
nicht so klar ist (z.B. Garmin-Vektorkarte), aber in den allermeisten
Faellen ist es klar.


Gerade die allermeisten OSM Anwendungsfälle sind aktuell Garminkarten, 
der Satz beinhaltet dadurch eine gewisse Komik ;-)



Das wichtige ist doch, dass Künstler nun die Daten nehmen können wie sie 
wollen. Weil die mussten bisher ja ihre Kunstwerke und CCBYSA 2.0 
stellen, also quasi Kommunismus. :-P Da dürfen solche kleinen 
Spezialfälle wie ob eine Vektorkarte aus OSM Daten nun ein produced Work 
ist oder eine database nicht im Weg stehen. :-D
Ausserdem wird von Befürwortern ja derzeit schon angenommen, CCBYSA 
existiere nicht mehr:



/Die Reit- und Wanderkarte ist als Onlinekarte gedacht. Der direkte 
Download von Kacheln ist nur begrenzt möglich, um den Onlinebetrieb 
nicht auszubremsen. Für alle, die gerne größere Bereiche herunterladen 
wollen, z.B. um sie auf ein Smartphone zu übertragen, gibt es die 
Möglichkeit, die Karte zu abonnieren. /


/Abonnenten erhalten Zugang zu einer speziellen Download-URL, die eine 
Anmeldung erfordert. Dieser Zugang ist so ausgelegt daß er den 
Onlinebetrieb möglichst wenig stört. Die Kartenkacheln für das 
Abonnement werden mindestens alle 2 Wochen aktualisiert. *Sie dürfen aus 
lizenzrechtlichen Gründen nur für den Eigengebrauch verwendet und nicht 
weiter veröffentlicht werden*. Abonnenten können beliebige Bereiche in 
der Karte bis zum Zoomlevel 16 (ca. 1:5000) und bis zu 2 Millionen 
Kacheln im Monat herunterladen. Von der Größenordnung her sollte das 
reichen um ganz Deutschland monatlich abholen zu können. /


Quelle:http://www.wanderreitkarte.de/shop_abo_de.php


Also auf, damit dass kein Einzelfall bleiben muss, sondern Regel wird, 
helft alle kräftig mit und spammt die odbl Ablehner zu. An die CCBYSA 
2.0 halten sich die odbler ja eh schon länger nicht mehr.:-*

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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3




On 29.04.2011 19:32, Frederik Ramm wrote:

Hallo,

Felix Hartmann wrote:
Also auf, damit dass kein Einzelfall bleiben muss, sondern Regel 
wird, helft alle kräftig mit und spammt die odbl Ablehner zu. An die 
CCBYSA 2.0 halten sich die odbler ja eh schon länger nicht mehr.:-*


Ich hatte Dich immer so verstanden, als ob es Dir eigentlich sogar 
lieb waere, wenn Du deine eigenen aus OSM abgeleiteten Werke unter 
einer Noncommercial-Lizenz vertreiben koenntest, und dass Du nur mit 
einem Zaehneknirschen hingenommen hast, dass das nicht moeglich war. 
Da muesstest Du die ODbL doch eigentlich begruessen?


Falsch, ich hab nur meine ganzen Skripte unter NC, damit sie genauf für 
sowas nicht hergenommen werden dürfen. Im Prinzip sind meine 
Skripte/Files eh nicht legal benutzbar, da NC inkompatibel mit CCBYSA 
ohne NC.
Ich bin dafür, dass Datenbank UND Endprodukte Share Alike sein müssen. 
Dann würde man sich auch die komplette Debatte Datenbank vs Produkt 
sparen, weil es irrelevant wäre.


Für mich ist es auch illegal, einen Server anzubieten, wie oben 
geschrieben, wo man OSM verbreitet, aber Usern sagt Share Alike nicht 
erlaubt. Aber ich würde das so interpretieren, wie dass da eben Share 
Alike Vorrang hat, sprich der Seiteninhaben ist halt der der die 
Probleme hat, weil die CCBYSA 2.0 halt aussagt, dass wenn man Sachen 
vermischt, das Endprodukt auch Share Alike ist, und damit Nop's Text 
ungültig und jeder kann machen was er will mit den Daten - solange er 
sich an CCBYSA 2.0 hält. Das geht aber eigentlich schon bei der 
Onlinekarte los, wenn der User keine Möglichkeit hat, die Höhenlinien 
auszublenden per ermessbarem Aufwand (das heißt sicherlich nicht 
irgendwas umzuprogrammieren um den Layer zu löschen), dann ist der 
Hinweis auf eine andere Lizenz des Layers eh hinfällig, und das ganze 
ein CCBYSA 2.0 Produkt.



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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3




On 29.04.2011 20:42, Frederik Ramm wrote:

Hi,

Henning Scholland wrote:
Kann man es denn irgendwo Schwarz auf Weiß lesen, dass eine 
Garmin-Karte keine Datenbank im Sinne der Lizenz ist?


Nein - weder, dass sie keine ist, noch dass sie eine ist. Ich hatte ja 
gesagt, dass das noch so ein etwas unklarer Punkt ist. Das Problem mit 
einer Garminkarte ist, dass sie von der Technik her nach saemtlichen 
Regeln der Kunst eben gerade eine Datenbank ist (waere es ein offenes 
Format, so wuerden Garminkarten z.B. als sqlite-Files ausgeliefert 
werden oder sowas). Andererseits ist sie in der Anwendung - das legt 
schon der Name Karte nahe - eben keine Datenbank.


Die OSMF will da gemeinsam mit der Community Regeln festlegen. Im 
Augenblick sieht die Regel so aus:


http://wiki.openstreetmap.org/wiki/Open_Data_License/Produced_Work_-_Guideline 



If it was intended for the extraction of the original data, then it 
is a database and not a Produced Work. Otherwise it is a Produced Work.


Das ist leider nicht besonders hilfreich. Ich denke, der Fall 
Garmin-Karte muss da noch genauer diskutiert werden. Ich neige 
eigentlich eher zu der Interpretation, das eine Garmin-Karte keine 
Datenbank im Sinne der ODbL ist.
Es geht hier aber um viel mehr, als nur Garmin Karten. Wenn es keine 
Datenbank ist, bedeutet dass, auf allen GPS/Smartphones etc. können 
kostenpflichtige, und nicht weiterbreitbare Vektorkarten angeboten 
werden. Sprich für die User wird es großteils (Ausnahme Garmin - weil 
hier ja das Format geknackt ist) - keine kostenlosen Karten geben. Es 
geht um ALLE Anwendungen wo offline eine Karte aus Vektordaten 
gespeichert ist. (und in Zukunft, wird es sicherlich auch kommen, dass 
die Karten nicht mehr von Mapnik, sondern zu großen Teilen lokal am 
Computer gerendert werden, womit auch die Anzeige von Karten am PC nicht 
geregelt sein wird -- OSM ist eine Vektorkarte, und das zu einer 
Rasterkarte zu verwursten, ist IMHO einfach nur ein Beschränkung und 
liegt an mangelnder Software)


Wenn es aber eine Datenbank ist, bedeutet dies, Anbieter die ein Share 
Alike der Karten verhindern wollen, dürfen dies auch (bisher ist etwa 
DRM dazu verboten, weil es das Share Alike verhindert, es geht derzeit 
schon durch die Hintertür, wie Karten kann man offen verbreiten, aber 
die Software ließt sie nur wenn ein proprietärer Schlüssel dies erlaubt).


Damit sagt die ODBL zum Großteil aller Anwendugnsfällte, derzeit einfach 
gar nichts aus.



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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3




On 29.04.2011 22:34, Simon Poole wrote:

Am 29.04.2011 21:57, schrieb Felix Hartmann:
Es geht hier aber um viel mehr, als nur Garmin Karten. Wenn es keine 
Datenbank ist, bedeutet dass, auf allen GPS/Smartphones etc. können 
kostenpflichtige, und nicht weiterbreitbare Vektorkarten angeboten 
werden. Sprich für die User wird es großteils (Ausnahme Garmin - weil 
hier ja das Format geknackt ist) - keine kostenlosen Karten geben. 


Deine Logik scheint mir nicht ganz schlüssig. Wenn das Format geknackt 
ist, dann kann jeder mit den entsprechenden Tools Karten für das 
entsprechende Gerät produzieren (siehe Garmin). Ist das Format nicht 
geknackt gibt es, mit oder ohne OSM, mit ODbL oder CC-by-SA, so oder 
so keine vom Hersteller unabhängigen Karten.


Ich sehe für OSM keinen Vorteil darin den Benutzern solcher Geräte 
künstlich den Zugang zu OSM-Daten zu erschweren, ausser man verfolgt 
was, schlussendlich, ideologische Ziele ohne Bezug zum Projekt sind.


Simon


Das sehe ich anders. Mit CCBYSA gibt es für die Hersteller eine 
Motivation ein offenes Format für die Karten zu 
ermöglichen/implementieren. Man kann ja nicht davon ausgehen, dass ein 
geschlossenes Format reverse engineered wird (gut das Garmin Format ist 
nicht geschlossen, sondern einfach nicht dokumentiert, es ist durch 
keinerlei DRM oder Encryption geschützt - daher kann man auch nur 
bedingt von geschlossen reden).


Es muss ja nicht jeder Hersteller so bekloppt sein wie die Asiaten (Name 
kann sich eh jeder denken), welche ihr GPS mit einer Mapnik Karten in 
Zoomstufe 15 rausgeben, und alles andere als 15 ist nicht möglich (oder 
wars 16??).
Ein Outdoorfähiges PNA mit offener Software zu moderatem Preis wird so 
schnell nicht kommen.


Bei odbl, (siehe nächsten Post von Frederik) kann es sich der Hersteller 
einfach machen. Er bietet eine odbl Datenbank zum kostenpflichtigen 
Download an (offen - wird eh niemanden interessieren), und daneben halt 
seine Karten kostenpflichtig. Genau das würde aber mit CCBYSA 2.0 nicht 
gehen! (zumindest nicht ohne große Umwege wie Karten kostenlos und 
offen, aber zur Benutzung kostenpflichtige Schlüssel).



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

Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3




On 29.04.2011 23:31, Frederik Ramm wrote:

Hallo,

Felix Hartmann wrote:
Das ist leider nicht besonders hilfreich. Ich denke, der Fall 
Garmin-Karte muss da noch genauer diskutiert werden. Ich neige 
eigentlich eher zu der Interpretation, das eine Garmin-Karte keine 
Datenbank im Sinne der ODbL ist.


Es geht hier aber um viel mehr, als nur Garmin Karten. Wenn es keine 
Datenbank ist, bedeutet dass, auf allen GPS/Smartphones etc. können 
kostenpflichtige, und nicht weiterbreitbare Vektorkarten angeboten 
werden.


Hm, das ist aber nach meiner Interpretation nicht davon abhaengig, ob 
es sich um eine Datenbank handelt oder nicht. Denn selbst wenn es eine 
Datenbank ist, dann erlaubt die ODbL dennoch, dass der Hersteller 
diese Datenbank in einer speziellen, technisch geschuetzten Version 
vertreibt (z.B. ein verschluesseltes Kartenformat fuer mobile 
Geraete), wenn er parallel die Daten auch in einem frei lesbaren 
Format anbietet (siehe Abschnitt 4.7.b der ODbL).


Das bedeutet, dass die ODbL nicht als Hebel taugt, um den Hersteller 
zu zwingen, sein Datenformat offenzulegen oder seine compilierten 
Karten jedem zur freien Nutzung zu ueberlassen; der Hersteller muss 
lediglich die zugrundeliegenden *Daten* freigeben (genauso wie auch 
bei einem Produced Work).
Richtig, unter odbl kann jeder machen was er will, außer halt die Daten 
zu vermischen ohne Veröffentlichung. Unter CCBYSA geht das nicht!


Auch hier wieder die Motivation: OSM ist ein Datenprojekt; wir haben 
uns nicht auf die Fahnen geschrieben, die Welt von der Geissel 
proprietaerer Hardware/Software zu befreien. Wenn sich ein Nutzer aus 
freien Stuecken fuer ein GPS-Geraet entscheidet, dessen Hersteller das 
Kartenformat geheimhaelt und womoeglich sogar kryptographisch 
abgesicherte OSM-Datenupdates fuer 99,90 Euro verkauft, dann ist das 
zwar keine Entscheidung, die *ich* treffen wuerde, aber moeglich ist 
es. (Wenn der Hersteller damit wuerbe, dass seine OSM-Daten 
verbessert seien, dann koennte man von ihm diese verbesserten Daten 
unter ODbL fordern - aber nicht notwendigerweise in einem auf das 
Geraet spielbaren Format!)


Das würde mit CCBYSA und dem DRM verbot durchs Share Alike halt anders 
aussehen. Aber gut, du scheinst halt gerne als Geisel zu leben.
Sprich für die User wird es großteils (Ausnahme Garmin - weil hier ja 
das Format geknackt ist) - keine kostenlosen Karten geben. Es geht um 
ALLE Anwendungen wo offline eine Karte aus Vektordaten gespeichert ist.


Ehrlich gesagt, habe ich wenig Mitgefuehl mit freiwilligen Nutzern 
geschlossener Plattformen. Es ist ja nun nicht so schwer, sich ein 
Geraet zu kaufen, auf dem man z.B. MoNav installieren kann oder so.


Wenn es denn bezahlbare und gute Geräte gäbe. Aber unter 600€ ist 
derzeit nichts zu bekommen (etwa Maggelan Mobile Mapper 6 - und Windows 
Mobile ist ja auch nicht gerade dass Allheilmittel)
Damit sagt die ODBL zum Großteil aller Anwendugnsfällte, derzeit 
einfach gar nichts aus.


Es stimmt zwar, dass derzeit unklar ist, ob eine Garminkarte eine 
Datenbank sein soll oder ein abgeleitetes Werk; allerdings ist es fuer 
Deine Argumentation nicht relevant, da die Folgen gleich sind:


Falls Garminkarte = Produced Work:

* Werk selbst kann unter nahezu beliebiger Lizenz stehen, z.B. kostet 
50 Euro, kopieren verboten
* zugrundeliegende Datenbank muss aber auf Anfrage rausgegeben werden 
unter ODbL


Falls Garminkarte = Derived Database:

* Datenbank selbst muss unter ODbL rausgegeben werden, darf aber in 
einem speziellen Format codiert/compiliert/verschluesselt sein, wenn

* man die Datenbank zugleich in einem lesbaren Format verfuegbar macht

Beide Faelle ermoeglichen es also einem auf ein geschlossenes System 
bedachten Hersteller, OSM-Karten fuer seine Geraete herauszugeben, die 
man nicht kopieren darf/kann.


Genau das sage ich ja. Daher will ich keine odbl. Ausserdem gehts wie 
gesagt gar nicht um Garmin, sondern um Vektorkarten im allgemeinen. Und 
hier versagt die odbl kläglich, weil nicht klar ist was eine Datenbank 
ist, bzw was Vektorkarten sind. Und dass ist einfach für mich nur 
lächerlich, und ein klarer Grund warum odbl nicht akezptierbar ist 
(neben dem fehlenden Share Alike der Produced Works).



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

Re: [Talk-de] railway=* usage




On 18.04.2011 13:54, Heiko Jacobs wrote:

Am 18.04.2011 11:47, schrieb M∡rtin Koppenhoefer:

Andererseits ist das wohl ein Spezialtag der Pufferküsser, wo man
evtl. davon ausgehen kann, dass das nur von Leuten verwendet wird, die
die rechtliche Definition kennen. Ob das so ist, könnte man z.B. durch
Befragen der mapper herausfinden, die den tag verwendet haben.


Bei mir ist's bspw. so, als ich das in KA drangehängt habe.

Im übrigen, was ich noch vergaß:

Die reale Verkehrsbedeutung abseits der amtlichen Einteilung in Haupt-
und Nebenbahn kann man anders viel besser erfassen als über usage.
Linien als Relationen zu taggen, setzt sich ja immer mehr durch.
An diese noch tags zu hängen, die die Art des Verkehrs spezifizieren
(Bummelzug, Regional-Express, IC oder ICE, ...) oder dessen Dichte,
halte ich für zielführender. Oder anders:


Gibt es dazu irgendwelche Docs?

Weil es macht jetzt ja wenig Sinn, wenn jedes Land hier seinen eigenen 
Müll zusammenschreibt. Man will ja nicht ICE, TGV, Shinkansee, etc... 
und alle Zugtypen kennen müssen um entscheiden zu können was es ist. Ob 
so ein Tag per Relation vorkommt, oder an der Schiene selber ist 
eigentlich egal. Wobei am besten wäre es, wenn man klar definiert dass 
man Relationen benutzt, und die Relation immer nur auf EIN (möglichst 
mittiges) Gleis legt (falls die Gleise seperat gemapped werden). So 
könnte man am besten die Karten für niedrige Zoomstufen aufbereiten.
Aber es braucht eine klare Dokumentation bezüglich der Verkehrsbedeutung 
von Zugrelationen! Weil etwa nur weil 10 Relationen auf einem Gleis 
hängen, bedeutet das ja nicht, dass die Verbindung überregionale 
Bedeutung hat.



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

Re: [Talk-de] railway=* usage




On 18.04.2011 17:56, M∡rtin Koppenhoefer wrote:

Am 18. April 2011 17:35 schrieb Felix Hartmannextremecar...@gmail.com:

Wobei
am besten wäre es, wenn man klar definiert dass man Relationen benutzt, und
die Relation immer nur auf EIN (möglichst mittiges) Gleis legt (falls die
Gleise seperat gemapped werden). So könnte man am besten die Karten für
niedrige Zoomstufen aufbereiten.


m.E. sollte man idealerweise jeweils das ans jeweilige Gleis taggen,
was es ist. D.h. wenn eine Hochgeschwindigkeitsstrecke 2-gleisig
ausgebaut ist, und beide Gleise gemappt sind, würde ich auch an beiden
Gleisen die Info haben wollen.

Was einfacher auszuwerten ist bzw. bei bestimmten Renderregeln und
Rohdaten als Eingang am besten aussieht sollte dabei sekundär sein.

Das sehe ich anders. Dann bräuchte es eben halt auch die Information, 
dass man ein Gleis wegschmeißen kann. Das Problem von Fahrspuren, usw 
ist dass Verdrängung nur bei Rasterkarten, aber nicht bei Vektorkarten 
funktioniert. Und OSM ist nunmal eine Vektorkarte. 2Gleise gehen ja 
noch, Aber bei 20 Gleisen im Bahnhof, wo pappst da die Relation 
drann An jedem Gleis ist genauso falsch wie an einem Gleis.



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

Re: [Talk-de] railway=* usage




On 18.04.2011 18:00, Heiko Jacobs wrote:

Am 18.04.2011 17:35, schrieb Felix Hartmann:

On 18.04.2011 13:54, Heiko Jacobs wrote:

Die reale Verkehrsbedeutung abseits der amtlichen Einteilung in Haupt-
und Nebenbahn kann man anders viel besser erfassen als über usage.
Linien als Relationen zu taggen, setzt sich ja immer mehr durch.
An diese noch tags zu hängen, die die Art des Verkehrs spezifizieren
(Bummelzug, Regional-Express, IC oder ICE, ...) oder dessen Dichte,
halte ich für zielführender. Oder anders:


Gibt es dazu irgendwelche Docs?


Nein, in sowas wie
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
kommt die Angebotsdichte und -art bisher praktisch nicht vor


Weil es macht jetzt ja wenig Sinn, wenn jedes Land hier seinen

 eigenen Müll zusammenschreibt. Man will ja nicht ICE, TGV, Shinkansee,
 etc... und alle Zugtypen kennen müssen um

entscheiden zu können was es ist.


Ob das international klappt ...
Wir kriegen ja noch nicht mal sauber die nationalen Straßenklassen
überall sauber gleich hin, weil sie halt jedes Land ein wenig
anders definiert ...


Ob so ein Tag per Relation vorkommt,
oder an der Schiene selber ist eigentlich egal. Wobei am besten
wäre es, wenn man klar definiert dass man
Relationen benutzt, und die Relation immer nur auf
 EIN (möglichst mittiges) Gleis legt (falls die Gleise seperat 
gemapped werden).


Mittig geht nur bei einleisig ;-)
Geht genauso bei zweigleisig und tracks=2. Das ganze ist aber ein 
prinzipielles OSM Problem. Im Grunde müsste man beides separat in der 
Datenbank aufnehmen (und so ist es auch in professionellen Datenbanken, 
bzw hängen da die Infos sonst so drann, dass man weiß was man 
wegschmeißen kann). Alles andere ist bei Vektorkarten einfach unoptimal.


Oder wir hätten in einer forward Relation die auf einem Gleis liegt, 
gleich die Info dass noch eine backward relation auf einem anderen Gleis 
liegt, aber die backward keine grundsätzlich unterschiedlichen 
Streckenverläufe hat, und somit fallengelassen werden kann.

Ansonsten gibt's formal nur zweigleisig ohne Mitte für Relationen.
Und wenn außerhalb on Bahnhöfen mehr als zwei Gleise liegen,
sind es in .de schon formal zwei verschiedene Strecken!

Im Nahverkehr (Bus und Straßenbahn) wird schon gerne je Richtung
eine eigene Relation gemappt, die kann man dann gleistreu legen.
Im Eisenbahnverkehr hat sich das noch nicht durchgesetzt


So könnte man am besten die Karten für niedrige Zoomstufen aufbereiten.
Aber es braucht eine klare Dokumentation bezüglich der Verkehrsbedeutung
von Zugrelationen! Weil etwa nur weil 10 Relationen auf einem
Gleis hängen, bedeutet das ja nicht, dass
die Verbindung überregionale Bedeutung hat.


Richtig.
Definitionen aufstellen und darüber diskutieren müssen wir aber erst 
noch ...


Gruß Mueck


___
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] railway=* usage

BTW. Es gibt ein European Agreement on Main International Railway Lines 
(AGC) Das wäre ein guter Anhaltspunkt (wenngleich etwas von der 
falschen Zugangsseite, da hier auf die Infrastruktur, und nicht die 
tatsächliche Benutzung abgezielt wird - aber prinzipiell wird ja nichts 
auf 300km/h ausgebaut für Züge, und dann für Schnellbahnverkehr 
verwendet...). Das Dokument wurde sogar erstmals 1985 ausgearbeitet.



Hier auf deutsch: 
http://www.transportrecht.de/transportrecht_content/1271941086.pdf

On 18.04.2011 13:54, Heiko Jacobs wrote:

Am 18.04.2011 11:47, schrieb M∡rtin Koppenhoefer:

Andererseits ist das wohl ein Spezialtag der Pufferküsser, wo man
evtl. davon ausgehen kann, dass das nur von Leuten verwendet wird, die
die rechtliche Definition kennen. Ob das so ist, könnte man z.B. durch
Befragen der mapper herausfinden, die den tag verwendet haben.


Bei mir ist's bspw. so, als ich das in KA drangehängt habe.

Im übrigen, was ich noch vergaß:

Die reale Verkehrsbedeutung abseits der amtlichen Einteilung in Haupt-
und Nebenbahn kann man anders viel besser erfassen als über usage.
Linien als Relationen zu taggen, setzt sich ja immer mehr durch.
An diese noch tags zu hängen, die die Art des Verkehrs spezifizieren
(Bummelzug, Regional-Express, IC oder ICE, ...) oder dessen Dichte,
halte ich für zielführender. Oder anders:

In zwei Forumsdiskussionen aus letzter Zeit habe ich dazu die Idee
eingeworfen, die Fahrplankarten (u.a. von meinem VCD) nachzubilden
statt wie dort angestoßen Fahrpläne zu erfassen.
http://forum.openstreetmap.org/viewtopic.php?id=11874
http://forum.openstreetmap.org/viewtopic.php?pid=146321#p146321

Gruß Mueck


___
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] railway=* usage




On 18.04.2011 18:36, M∡rtin Koppenhoefer wrote:

Am 18. April 2011 18:18 schrieb Felix Hartmannextremecar...@gmail.com:

Das sehe ich anders. Dann bräuchte es eben halt auch die Information, dass
man ein Gleis wegschmeißen kann. Das Problem von Fahrspuren, usw ist dass
Verdrängung nur bei Rasterkarten, aber nicht bei Vektorkarten funktioniert.
Und OSM ist nunmal eine Vektorkarte.


OSM ist eine Datenbank.



2Gleise gehen ja noch, Aber bei 20
Gleisen im Bahnhof, wo pappst da die Relation drann An jedem Gleis ist
genauso falsch wie an einem Gleis.


wenn es so ist, dass der Zug wirklich je nach aktueller Situation auf
verschiedenen Gleisen fährt, muss man sich was ausdenken bzw. etwas
weniger genau mappen, klar. Gleise wegschmeissen kommt für die
Datenbank aber nicht in Frage, das kannst Du schön bei Dir lokal
machen...

Es geht nicht drum, dass die Gleise weggeschmissen werden. Sondern das 
in den Daten steht, was man weglassen kann weil es ab einer bestimmten 
Auflösung nicht mehr unterscheidbar ist / gewollt ist dies zu 
unterscheiden. Und das funktioniert nunmal nicht automatisch. (wer was 
anderes Behauptet soll es beweisen und vorzeigen). Dasselbe Problem wird 
kommen, wenn wir in OSM irgendwann flächendeckend Fahrspuren mappen. 
Dann brauchen wir trotzdem eine einfache Straße als Grundlage, und nicht 
nur nur Fahrspuren.


Sprich eine einfache Strecke, und Detailgleisinformationen. Man kann 
aber weder aus der einfachen Strecke noch aus den 
Detailgleisinformationen automatisch das andere errechnen. Derzeit ist 
es aber so, dass man eigentlich aus OSM eine Vektorkarte nicht für 
Mapnik Zoomlevel 13 bauen kann, ohne in das Problem unlösbarer 
Detailselektion zu kommen.



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

Re: [Talk-de] railway=* usage




On 18.04.2011 20:25, M∡rtin Koppenhoefer wrote:

Am 18. April 2011 18:44 schrieb Felix Hartmannextremecar...@gmail.com:

Es geht nicht drum, dass die Gleise weggeschmissen werden. Sondern das in
den Daten steht, was man weglassen kann weil es ab einer bestimmten
Auflösung nicht mehr unterscheidbar ist / gewollt ist dies zu unterscheiden.
Und das funktioniert nunmal nicht automatisch. (wer was anderes Behauptet
soll es beweisen und vorzeigen).


puffer um das Gleis legen und analysieren, ob andere Gleise darin vorkommen.
Nah her mit dem Code. Bisher hat kein einziges Programm was OSM daten 
anylisiert dies umgesetzt AFAIK. Es würde evtl ja sogar halbwegs gehen, 
aber vernünftiger und korrekter ist es korrekt zu erfassen (ob das jetzt 
separat oder als zusatz tag ist, ist im Grunde egal).


  Dasselbe Problem wird kommen, wenn wir in

OSM irgendwann flächendeckend Fahrspuren mappen. Dann brauchen wir trotzdem
eine einfache Straße als Grundlage, und nicht nur nur Fahrspuren.


glaube ich nicht. Einfacher wäre es aber wohl, daher wird man es wohl so machen.



Sprich eine einfache Strecke, und Detailgleisinformationen. Man kann aber
weder aus der einfachen Strecke noch aus den Detailgleisinformationen
automatisch das andere errechnen.


doch, Detail reduzieren geht immer, automatisch hinzufügen halte ich
aber auch für extrem extrem extrem schwierig ;-)

Gruß Martin



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

Re: [Talk-de] railway=* usage




Der Grund, warum man (ich) das bisher nicht braucht, ist dass sich das
beim Rendern von lowzoom sowieso von selbst löst (Überlagerung durch
die Überhöhung). Klar, man rendert auch viel, was man eigentlich nicht
sieht (könnte Rechenzeit und Strom sparen). Je nachdem, wie lange Du
den Datensatz behalten willst, um so umständlicheres Prozessing kannst
Du Dir erlauben (und um so eher spart man auch wirklich unterm
Strich).
Das ist eindeutig Falsch. Nur bei Rasterkarten ist es derzeit egal. Aber 
alle Karten die real-time gerendert werden (und irgendwann wird man auch 
bei Mapnik und anderen Renderern draufkommen, dass es zumindest im 
Nahbereich praktischer ist, wenn realtime am PC des Kartenbetrachters 
gerendert wird) dann ist es extrem blöd, wenn man 10 Gleise rendern 
muss, die sich eh überlappen. Das vorher auszufiltern ist aber mehr oder 
weniger unmöglich ohne Fehler zu bekommen.


Wenn OSM keine reine Amateur und Zweitlösung sein will, muss man den 
Lowzoombereich radikal umbauen. Das geht im Prinzip über tags, 
praktischer in einer eigenen, bzw per Tags getrennten, Datenbank.


Dass es derzeit schrott ist, sieht man ja bei allen Renderern aus OSM 
Daten. Will ich einen Überblick haben, benutze ich zu 100% nicht OSM, 
weil es einfach nichtmal mit Rasterkarten möglich ist, was gscheites aus 
der Datenbank für etwa eine Deutschland A3 Karte rausextrahierbar ist. 
Dabei wäre die Datenerfassung dafür trivial, hätte man ein vernünftiges 
Taggingsystem.

Weshalb ich meinen Einwand vorgebracht habe: die Abwägung
Detaillierung zu einfacherer Auswertbarkeit sollte in gewissem Rahmen
zu Gunsten der Detaillierung getroffen werden, und hier ist es m,E.
eindeutig (das ist doch einer der Hauptgründe, überhaupt parallele
Gleise zu mappen).

Gruß Martin



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

[Talk-de] railway=* usage

2011-04-16 Diskussionsfäden Felix Hartmann

Irgendwie kommen mehr und mehr User drauf, die meinen usage=main würde 
auch etwa für Schnellbahnstrecken (etwa die kaum benutzte Ostlinie in 
Wien) gelten. Ich hab das im Wiki mal geändert, wäre aber eigentlich für 
eine bessere Aufteilung wie nur usage=main // usage=branch. Ich denke

usage=main (ICE/IC/IR Züge befahren die Gleise)
usage=secondary (Eilzüge, Regionalzüge)
usage=branch (Schnellbahnen, Zubringerbahnen)

würde deutlich mehr Sinn machen.

siehe.
http://wiki.openstreetmap.org/wiki/DE:Key:usage


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

Re: [Talk-de] railway=* usage

2011-04-16 Diskussionsfäden Felix Hartmann




On 16.04.2011 17:44, Heiko Jacobs wrote:

Am 16.04.2011 15:29, schrieb Felix Hartmann:
Irgendwie kommen mehr und mehr User drauf, die meinen usage=main 
würde auch etwa für Schnellbahnstrecken (etwa die kaum benutzte 
Ostlinie in Wien) gelten. Ich hab das im Wiki mal
geändert, wäre aber eigentlich für eine bessere Aufteilung wie nur 
usage=main // usage=branch. Ich denke

usage=main (ICE/IC/IR Züge befahren die Gleise)
usage=secondary (Eilzüge, Regionalzüge)
usage=branch (Schnellbahnen, Zubringerbahnen)

würde deutlich mehr Sinn machen.

siehe.
http://wiki.openstreetmap.org/wiki/DE:Key:usage


Zumindestens für Deutschland ist die Unterscheidung Hauptbahn / Nebenbahn
in der EBO geregelt:
http://bundesrecht.juris.de/ebo/__1.html
... und hat übehraupt nix damit zu tun, was für Züge auf der Strecke 
fahren.


Ich vermute mal stark, dass das in AT ähnlich ist ...

Gruß Mueck



Das mag so beschrieben sein, hat aber mit Openstreetmap usage wenig zu 
tun. Wenn das so sein soll, dann sollte hier auch geschrieben werden 
dass es nur um Gesetzliche Regeln geht, dazu schmeißen wir industrial, 
tourism und Co rauß, und nutzen halt priority stattdessen vernünftig. 
Genauso ist ja auch primary/secondary/tertiary und Co nicht von der 
offiziellen Klassifikation abhängig, sondern hängt von der tatsächlichen 
Verkehrswichtig ab. Das zu verwursten ist aber Schwachsinn.


Entweder wir haben hier einen Schlüssel für bundesrechtliches Gesetze, 
oder wir legen die tatsächliche Wichtigkeit fest. Ich sehe nicht dass 
usage bisher rechtlich interpretiert wurde..



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

Re: [Talk-de] Status Fahrradwege-Tags

2011-03-03 Diskussionsfäden Felix Hartmann

Also ich sehe auch absolut keinen Bedarf für einen bicycle:trekking oder 
was auch immer Tag.


Der Grund warum es mtb:scale sowie mtb:scale:uphill gibt, ist das 
Mtbiken einfach keiner anderen Fortbewegungsart direkt entspricht, und 
es eben Wege gibt, wo ein Wanderer nur auf allen 4en runterkommt, ein 
technsich versierter Mtbiker aber einfach ein paar Sachen obispringt. 
Andersrum gibts genug Fälle wo man egal mit welcher Technik am MTB nicht 
weiterkommt, der Fußgänger aber kein Problem hat. Ich bin allerdings 
auch schon mit einem Trekkingbike Wege mit mtb:scale=1 gefahren und 
würde für fast alle ausgeschilderten MTB-Strecken behaupten, dass man da 
mit einem Trekkingbike besser bedient ist wie mit einem MTB. Eine 
normale Steintreppe fahre ich auch mit einem Trekkingbike runter - 
obwohl da ein Großteil der Leute die ein MTB haben, absteigen. Daher bin 
ich immer froh wenn incline=up/down angegeben ist.


Surface als Key sagt in Wirklichkeit so gut wie gar nichts aus. Eine 
Straße mit riesigen Schlaglöchern, Wurzeln, oder Steinbrocken im Weg 
weil sie wegen Steinschlag nicht mehr benutzt wird, wäre für mich noch 
immer surface=asphalt, weil ja 80-90% der Oberfläche noch aus Asphalt 
bestehen. Surface=wood kann irgendwas bedeuten (von guter Holzbrücke 
hin zu ein paar Planken die über eine morastige Landschaft geworfen 
sind). Surface=gravel kann vom normalen Schotterweg hin zu einem kaum 
mehr begehbaren Trail in den Alpen gehen, da dort Schotter gestreut 
wurde, damit der Boden nicht weiter erodiert. Für mich macht surface 
daher nur in Verbindung mit smoothness - oder zur Not mit tracktype 
Sinn. Surface=paved kann ich sowieso nichts mit anfangen. Ein 
Klettersteig ist doch auch surface=paved, weil er ganz eindeutig 
befestigt ist.


Tracktype ist für Rennradfahrer oder Inlineskater nicht differenziert 
genug. Auf Inlinern brauche ich aber keinen eigenen Tag, smothness ist 
hier perfekt ausreichend da tracktype=grade1 eben mal besser, mal 
schlechter zum entlangrollen ist. Als klassischer Trekkingradler oder 
Donauradwegradfahrer reichen mir smoothness und tracktype allemal. Viel 
größere Probleme bereitet mir hier Verkehr, Ampeln, Stopschilder, 
parkende Autos, depperte Hunde, spielende Kinder, uneinsichtige Kurven, 
usw. --- da ich am Trekking oder Rennrad halt gerne 25-35km/h ohne 
abbremsen und evtl auch am schnellsten Weg fahren möchte. Diese ganzen 
Gefahrenfaktoren für mich als Radler der nicht bremsen will, wird man 
kaum objektiv beschreiben können, dafür gibt es zum Glück aber noch 
class:bicycle womit ich ausdrücken kann wie gut sich ein Weg zum 
radfahren oder rennradfahren eignet. *Class:bicycle welches 
überraschenderweise stark benutzt wird, obwohl es kaum erwähnt wird. 
Dass könnte deine Bedingungen erfüllen.*


Bicycle=yes sehe ich generell nur bei highway=pedestrian oder 
highway=trunk Sinnvoll an. Da ich annehme dass ich hier generell nicht 
fahren darf. Highway=footway  bicycle=yes ist dagegen eh der 
Normalfall, da footway einfach per se nicht bedeutet, dass nur Fußgänger 
erlaubt sind. Bicycle=no  highway=footway / highway=path ist dagegen 
leider häufig eben falsch verwendet, weil Leute annehmen hier können 
keine Fahrradfahrer fahren, anstelle von hier ist explizit 
ausgeschildert dass Fahrradfahrer nicht lang dürfen.


Wo dagegen wirklich noch eine Lücke klafft, sind Einradfahrer. Und damit 
meine ich jene Einradfahrer die das ganze auch im deutschen Sprachraum 
als Unicycle bezeichnen, und harte Alpentrails damit befahren. Im 
Grundsatz reicht für die auch die mtb:scale. Allerdings gibt es halt 
Stellen wo die mtb:scale für einen Unicyclist die Schwierigkeit 
übertreibt, da am Unicycle eine Spitzkehre kein Problem ist. 
Andererseits teils falsch, weil ja ein einfacher Sprung von 5-10m 
Länge mit einem Unicycle nicht machbar ist, da die Geschwindigkeit die 
ein Mtbiker hat, nicht aufgebaut werden kann.

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

Re: [Talk-de] highway=residential und area=yes ?

2011-03-03 Diskussionsfäden Felix Hartmann

Das ganze sollte area:highway=residential heißen, anstelle 
higwhay=residential  area=yes.


Ist nicht komplizierter, und würde für weniger Fehler sorgen. Und vor 
allem wäre dann jedem klar, dass Routing auf area:highway nicht stattfindet.



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

Re: [Talk-de] Wo aktuelle Garmin Karten für DE?

2011-02-14 Diskussionsfäden Felix Hartmann




On 14.02.2011 18:35, Andreas Tille wrote:


Ich halte eine Information an leicht zu findender Stelle für angemessen,
wenn ein Dienst der früher mal zur Verfügung stand für längere (  2
Wochen) Zeit / unvorherbar lange Zeit nicht mehr zur Verfügung steht.
Ein Mangel an Information schadet dem Projekt, weil Neulinge eventuell
abgeschreckt werden.  Meine Mail diente dazu herauszufinden, ob ich nur
eine offensichtliche Information verpaßt habe oder ob sie wirklich
fehlt.


Du bist schon irgendwie blind, oder?

Seit 8. Feber gepublished. Hatte vorher auch schon in Comments über die 
Situation geschrieben, dass Domainbox scheinbar nicht mehr in der Lage 
war den Traffic zu sponsern.

http://openmtbmap.org/updates/enopenmtbmap-download-server-background-deopenmtbmap-download-server-nicht-erreichbar/

bzw am 12.2:
http://openmtbmap.org/updates/enmaps-online-yehaa-fully-working-address-search-de-karten-bald-wieder-online-und-erstmals-mit-voll-funktionierender-addressuche/


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

Re: [Talk-de] cycleway=track vs. cycleway=opposite_track

2011-02-04 Diskussionsfäden Felix Hartmann




On 04.02.2011 20:44, Steffen Wolf wrote:

M∡rtin Koppenhoefer schrieb:


Wenn Dir die Information wichtig ist, dass es ein Fahrradweg in der
Nähe einer Straße ist, dann kann man das auch anders in den Daten
unterbringen.

beispielsweise, indem man das cycleway=track an den Fahrradweg selbst
hängt (zusätzlich).

Ach. Ich hab das immer als Fehler angesehen, etwa als haette der
Fahrradweg einen seitlichen Fahrradweg-Track. Ist das tatsaechlich so
gedacht? Steht das irgendwo?

stw
Nein und auch aus gutem Grund. Weil dann fehlen weiterhin die ganzen 
Attribute der Straße. Zwei typische Beispiele:

highway=tertiary
maxspeed=50
cycleway=track
lanes=2
oneway=yes

Hier möchte ich in 99% aller Fälle nicht mit dem Rad langfahren. Hoher 
Verkehr (auch wenn tertiary) in einer großen Stadt


highway=secondary
source:maxspeed=rural
maxspeed=100
cycleway=track

Ist wahrscheinlich eine wenige befahrene Landstraße, hier fahre ich 
gerne mit dem Rad.
Wenn wir also schon seperat die Wege einzeichnen (ist mir ein Graus), 
dann gehören auch ALLE Attribute mit einem speziellen Schlüssel auf den 
Fahrradweg nebenan, sonst kann man nicht entscheiden was er taugt. Oder 
wir sagen einfach highway=cycleway ist fürs Fahrradfahren grundsätzlich 
wenig geeignet außer class:bicycle ist gesetzt.



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

Re: [Talk-de] cycleway=track vs. cycleway=opposite_track

2011-02-03 Diskussionsfäden Felix Hartmann




On 03.02.2011 20:10, M∡rtin Koppenhoefer wrote:

Am 2. Februar 2011 22:32 schrieb Pascal Neispascal.n...@gmail.com:

bin vor ein paar Tagen auf ein Fahrrad-Routing-Problem
mit Ways die ein cycleway=track-Tag besitzen aufmerksam
gemacht worden. (danke Sven :) )

Folgendes Problem: Darf ein Way der als cycleway=track
und auch als Einbahnstraße getaggt ist in verkehrter
Richtung mit dem Fahrrad befahren werden ? Laut der
Tag-Beschreibung im Wiki[1] eher nein! Ansonsten müsste
er als cycleway=opposite_track gemappt sein.


wie viele lanes hat denn der cycleway? Wenn er für beide Richtungen
gelten soll, sollte er wohl cyleway:lanes=2 (0 mal) und
cycleway:oneway=no (kommt immerhin 13 mal vor) oder so was haben. Am
besten man mappt diese ways konsistent mit unseren allgemeinen
Mapping-regeln separat, sind ja baulich getrennte Fahrbahnen.

Gruß Martin
Nein, das ist für jegliche Auswertung das blödeste. Im Prinzipiellen 
will man als Fahrradfahrer der schnell fahren möchte, alle cyleway=track 
vermeiden. Ist es nun highway=cycleway kann man als Router nichts mehr 
damit anfangen, da man nicht weiß ob so ein Weg gut oder Schlecht 
fahrbar ist.

___
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] cycleway=track vs. cycleway=opposite_track

2011-02-02 Diskussionsfäden Felix Hartmann


Im Prinzip nein. Allerdings ist es nicht korrekt durchdacht.
Besser cycleway=track (gleich in die Richtungen gebaut und befahrbar wie 
die Straße), left (auf linker Seite), right, both
und dazu bicycle:oneway=no bzw bicycle:oneway=yes um vom oneway=yes // 
oneway=no abweichende Regelungen der Befahrbarkeit darzustellen. Evtl 
könnte ja sogar der Fall sein, dass Fahrräder auf der falschen Seite 
(bezogen auf rechts- oder linksverkehr) mit der Einbahn fahren dürfen. 
cycleway=opposite ist nur halb zu Ende gedacht - es deckt einfach keine 
ungewöhnlichen Situationen ab.


On 02.02.2011 22:32, Pascal Neis wrote:

Hi,
bin vor ein paar Tagen auf ein Fahrrad-Routing-Problem
mit Ways die ein cycleway=track-Tag besitzen aufmerksam
gemacht worden. (danke Sven :) )

Folgendes Problem: Darf ein Way der als cycleway=track
und auch als Einbahnstraße getaggt ist in verkehrter
Richtung mit dem Fahrrad befahren werden ? Laut der
Tag-Beschreibung im Wiki[1] eher nein! Ansonsten müsste
er als cycleway=opposite_track gemappt sein.

Laut Tagwatch gibt es um einige mehr cycleway=track
als cycleway=opposite_track vgl.[2]. Sollte aber dennoch
ein Way mit cycleway=track mit dem Fahrrad in falscher
Richtung befahrbar sein ? In Heidelberg machen das alle
Radfahrer so ... :)

dankeviele gruesse
pascal

[1] http://wiki.openstreetmap.org/wiki/DE:Key:cycleway?uselang=de
[2] http://tagwatch.stoecker.eu/Germany/De/keystats_cycleway.html


___
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] AIO fehlt völlig

2011-01-07 Diskussionsfäden Felix Hartmann




On 07.01.2011 09:45, Christoph Wagner wrote:

Am 07.01.2011 02:00, schrieb Felix Hartmann:


Oder anders: Ich will nicht soviel RAM, aber da eben alle Kacheln auf einmal 
eingelesen werden, wird zurzeit halt etwa Kachelgröße mal 1.2 an verfügbarem 
Ram benötigt. Und wenn der Rechner hier zu swappen anfängt, dann braucht es 
derzeit ewig. Ich bin kein Programmierer, daher kann ich das nicht ändern. Bin 
eh schon froh wenn ich solche Files halbwegs lesen kann.


Ich sag mal ganz lax das ist dann ein Problem von mkgmap. Ich meine Mapsource 
schafft das mit dem Index ja auch irgendwie ohne dass man da nen riesen 
Superrechner braucht.
Ich bin da aber eigentlich zuversichtlich, dass das irgendwann noch gefixt wird 
- gerade wenn der cGPSmapper code verfügbar ist.
Für den AIOTM bedeutet das halt, dass der User nen Haken setzen kann, ob er nen 
Index will oder nicht. Alternativ kann er das ganze ja immernoch mit Mapsource 
laden und dann damit den Index backen oder so.

Bin da eigentlich recht entspannt.

Grüße
Christoph

Nein, das ist kein Problem von mkgmap an sich. Sondern halt ganz einfach 
ist das was hier mit mkgmap gemacht werden soll, nicht der Einsatzzweck 
von mkgmap. Mkgmap ist darauf optimiert schnell zu sein, nicht auf 
irgendwelchen lahmen Rechnern zu funktionieren. Mapsource muss den Index 
ja nur lesen - logisch dass dabei, nicht viel RAM gebraucht wird. 
Mapsource kann keinen Index erstellen! Wie schon geschrieben, wenn 
mkgmap den Index auf Rechnern ohne viel RAM schreiben soll, dann braucht 
es mindestens doppelt so lange.


Cpreview funktioniert so weit ich weiß nicht mit mkgmap erstellten 
Karten. Andere Alternativen gibt es nicht.


Mapsource/Basecamp wird weiterhin benötigt, um den Index in das für das 
GPS richtige Format umzuwandeln (nicht neu erstellen) - da ja derzeit 
nur die Struktur bekannt ist, die Mapsource erwartet, nicht das GPS. 
Hoffentlich kann mkgmap in Zukunft den Index auch im GPS Format 
schreiben - ich hab da allerdings eher wenig Hoffnung.



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

Re: [Talk-de] AIO fehlt völlig

2011-01-07 Diskussionsfäden Felix Hartmann




On 07.01.2011 15:03, Sven Geggus wrote:

Felix Hartmannextremecar...@gmail.com  wrote:


Sehe ich nur sehr begrenzt so. Einerseits gibt es gerade bei den anderen
Typen große Unterschiede in der Benutzung, anderseits hat eh jeder ein
anderes Design.

Ich bin ja was Garminkarten betrifft nur Anwender und nur zufällig als
devserver Admin ein wenig in den Buildprozess der AIO involviert.

Ich nenne Dir ein konkretes Beispiel.

Mir gefällt das fahrradspezifische Routing Deiner Velomap nicht so
sehr gefällt mir das graphische Layout (unter anderem wegen komplett
fehlendem Nachmode - der tagmode blendet nachts).

Beid er AIO gefällt mir das KFZ zentrierte Routing nicht aber das
Layout gefällt mir ganz gut.

Nun würde ich mir gerne eine AIO Velo Supermap bauen und da beginnen
nun die Probleme.  Ohne halbwegs vereinheitlichtes Mapping der
Straßentypen steht der Aufwand hier nämlich in keinem Verhältnis zum
Nutzen.

In der Praxis ist es nun tatsächlich so, dass ich wahlweise die AIO
oder die Velomap laufen habe und mich das fehlende Feature des Gpsmap
zwischen komplett verschiedenen karten umschalten zu können zunehmend
bervt.

Gruss

Sven

Was dir gefällt ist in dem Fall egal. Ich schaffe es nicht einmal für 
die openmtbmap und die velomap die Typen synchron zu halten im Lines 
file. Das Garmin Format ist hier einfach zu eingeschränkt, also ist das 
was du willst Utopie, wenn man komplexere Maps baut (ich hab etwa für 
jede Zoomstufe unterschiedlich dicke Straßentypen - sowas vervielfacht 
natürlich den Bedarf an Typen, und führt Optionen bezüglich ein TYP.file 
fits all ad absurdum und macht sie unmöglich. Gäbe es beliebig viele 
Typen und diese nicht funktionsbezogen (gibt es aber nicht) dann wäre 
dein Wunsch machbar,


Deine beiden beispiele sind ohne kommata unlesbar, bzw mit der double 
negation verstehe ich nicht was du meinst.


Ausserdem kann man auf jedem GPS von Garmin zwischen den Karten 
herschalten, indem man nicht benötigte Karten deaktiviert. Ich benutze 
neben der openmtbmap (und teils velomap) immer eine 2009er City 
Navigator - alleine schon wegen der Addresssuche - obwohl diese außer im 
PKW immer deaktiviert ist. Ab und zu auch noch andere Karten zum testen, 
bzw Höhenlinien mal integriert oder seperat.



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

Re: [Talk-de] AIO fehlt völlig




Was man eigentlich auch mal versuchen sollte anzugehen wäre die OSM
Typen halbwegs einheitlich auf Garmintypen zu mappen.  Derzeit kann
man nämlich aufgrund dieser uneinheitlichen Umsetzung kaum sinnvoll
Typfiles anderer Garminkarten mir der AIO verwenden und umgekehrt.



Du verstehst hier irgendwas nicht. Es ist komplett egal wer was wie 
verwendet. Es braucht eh jede Karte ihr eigenes Typfile. Sonst müsste 
man eine komplett einheitliche Darstellung haben, da nicht genug Typen 
(speziell routingfähige) vorhanden sind, um alle möglichen Darstellungen 
zu integrieren. Ein .TYP-file welches für verschiedene, bzw alle, Karten 
funktionieren soll geht nicht. Man kann beliebig viele (okay 20 bei 
älteren GPS) verschiedene Karten jeweils mit eigenem Typfile am GPS 
benutzen.


Das einzige was man entfernen sollte, eigentlich gleich aus mkgmap, ist 
der switch/road-name-pois/, da dies zig GPS zum abstürzen beim benutzen 
der Suchfunktion bringt, bzw die Suche extrem verlangsamt. Und da die 
Suche für alle Karten egal ob aktiviert oder deaktiviert funktioniert, 
schieben dann viele User Abstürze auf die aktive Karte, selbst wenn eine 
inaktive Karte am Absturz Schuld ist (bzw an unbrauchbarer POI 
Suchfunktion).

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

Re: [Talk-de] AIO fehlt völlig

Hmm, ich gebe zu es wäre mir persönlich am liebsten, wenn sich um die
Styleerstellung komplett jemand anderes kümmert.
Die Typen kann man von mir aus mappen wie man will. Es gibt da leider bei
manchen Garmintypen auf manchen Geräten Probleme (komische Rauten oder weiß der
Geier...)
Ich hab eigentlich keinen Bock und auch nicht die Kraft das alles selbst zu
debuggen und immer die optimalen Typen zu finden.
Das ist auch von dem Rest des Systems übrigens völlig unabhängig zu bebasteln.

Ich würd mich lieber um die Infrastruktur der Kartenerzeugung kümmern statt Anfragen von wegen
dies und jenes wird nicht angezeigt oder diese farbe gefällt mir aber nicht
etc. zu bearbeiten.
Es wäre optimal, wenn sich ein AiO-Styleverantwortlicher finden könnte.
Vorraussetzungen wären mkgmapstyle- und typfiles bearbeiten zu können. Schön
wäre noch mit git klarzukommen (ich weiß das ist erstmal ne Hürde, aber man
kommt rein - ehrlich!)

Wäre es nicht sinnvoll auf SVN zu wechseln??
GIT ist für so ein kleines Projekt (Anzahl Codezeilen und Changes)
absolut übertrieben.

SVN ist deutlich leichter installierbar und für neue User leichter zu
verstehen. (kein Unterschied zwischen Push und Commit, und kein Zwang zu
einem Keyfile). Klar versteht man irgendwann GIT, aber 3-4 Stunden
Einarbeitungszeit braucht es einfach, und SVN kapiert man innerhalb von
10min (ausserdem sind die meisten anderen OSM Projekte wie etwa JOSM und
mkgmap auch via SVN angeboten).

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

Re: [Talk-de] AIO fehlt völlig




On 06.01.2011 16:05, Sven Geggus wrote:

Felix Hartmannextremecar...@gmail.com  wrote:


Du verstehst hier irgendwas nicht. Es ist komplett egal wer was wie
verwendet. Es braucht eh jede Karte ihr eigenes Typfile. Sonst müsste
man eine komplett einheitliche Darstellung haben, da nicht genug Typen
(speziell routingfähige) vorhanden sind, um alle möglichen Darstellungen
zu integrieren. Ein .TYP-file welches für verschiedene, bzw alle, Karten
funktionieren soll geht nicht. Man kann beliebig viele (okay 20 bei
älteren GPS) verschiedene Karten jeweils mit eigenem Typfile am GPS
benutzen.

Eine Handvoll routingfähige Typen manuell zu ändern ist wenig
Aufwand. Für den ganzen Rest (insbesondere für POI und Flächen) wäre
aus Anwendersicht ein einheitliches Mapping absolut wünschenswert.

Sehe ich nur sehr begrenzt so. Einerseits gibt es gerade bei den anderen 
Typen große Unterschiede in der Benutzung, anderseits hat eh jeder ein 
anderes Design. Daher ist es solange es von Garmin/GPS/Mapsource 
identisch behandelt wird, absolut keine Relevanz was wie zugeordnet ist.



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

Re: [Talk-de] AIO fehlt völlig




On 06.01.2011 18:51, Christoph Wagner wrote:

Am 06.01.2011 17:59, schrieb fla...@googlemail.com:


Wer Java installiert hat hat alles was er braucht. 1Ghz und 512MB Ram
sollten reichen.

Na wenn ich Felix richtig verstanden habe, braucht es etwas mehr RAM, wenn man 
mit mkgmap den Adressindex erzeugen will - auch beim simplen Kacheln 
zusammenkleben.

Eben, mit 512MB RAM (frei verfügbar, weil wenns an swappen geht kanns 
Stunden brauchen), bekommt man gerade mal den Adressindex für die Hälfte 
von Deutschland berechnet. Für DE brauchts schon 1GB verfügbarer RAM. 
DACH braucht schon ein x64 System unter Windows (max ~1300 RAM die ein 
einzelner Prozess belegen darf). Wirklich blöd ist es halt, wenn jemand 
mit 2GB RAM, davon 1.4GB verfügbar, und 2GB Swap, etwa für Europa einen 
Adressindex berechnen möchte. Hier wird mkgmap mit pech 48h brauchen, 
und der User geht von einem Absturz aus.


Ohne Adressindex reichen 512MB, dagegen wirklich für die ganze Welt aus. 
Da ist es mehr oder weniger egal wie der PC aussieht.



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

Re: [Talk-de] AIO fehlt völlig




On 06.01.2011 23:37, fla...@googlemail.com wrote:

Klar, derzeit ist es nur bedingt brauchbar. Aber der komplette Code der
benötigt wird, ist hier online:
http://sourceforge.net/projects/cgpsmapper/

Da dies Sourcecode erst seit gut zwei Wochen online ist, wurde er bisher
noch nicht genutzt um es in mkgmap zu implementieren. Steve hat dies
angekündigt. Primär scheinen in mkgmap einige Indexes im mdr falsch
sortiert, bzw fehlen noch.
Da cgpsmapper einen korrekt funktionierenden Index schreiben kann, wird es
wohl bei mkgmap nicht mehr lange dauern. Entweder Steve oder jemand anders
wird es schon schaffen noch die Änderungen zu implementieren.

(damit steht dann primär noch das kaputte Intertilerouting zu korrigieren in
mgkmap, sowie eine bessere transliteration von Sonderzeichen / anderen
Alphabeten).



alles bekannt, aber jetzt werde dich bitte mal konkret was du mit dem
vielem Ram für einen Index
rechnen wilst ? Bitte um Codebeispiele was du machst.

Dirk



Ich mach damit gar nichts, aber soweit ich erkennen kann, lädt mkgmap 
zur Indexerstellung alle Tiles auf einmal in den RAM.

Siehe: uk\me\parabola\mkgmap\combiners\mdrbuilder.java

Wahrscheinlich müsste man hier nur umprogrammieren, dass ein temporärer 
Speicher auf der Festplatte erstellt wird, statt alles im RAM zu machen. 
Das Problem ist halt, dass die Straßen zu den Cities gematcht werden 
müssen, da wir ja blöderweise bei OSM nicht dazuschreiben (wie in jeder 
professionellen Geodatenbank) zu welcher Stadt/Gemeinde/Land eine Straße 
gehört. Also muss mkgmap den Cityrecord durchgehen, und die nächste 
Stadt ist eben nicht zwingend in derselben Kachel, wo die Straße sich 
befindet. Also müsste man, wenn man nicht alle Kacheln auf einmal laden 
will, halt Etappenweise vorgehen mit Überschneidungen - was halt 
komplizierter ist, als alles in eine Datenbank vor der Indexerstellung 
zu schmeißen.


Oder in Etappe 1, eine Datenbank der Cities erstellen und hier Kachel 
für Kachel in den Ram laden, und dann in einer zweiten Etappe die 
Straßen dagegen Matchen, dabei aber die Kacheln neu in den Ram laden, 
statt aus Step 1 noch drinnenzubehalten. Am einfachsten wäre wohl, wenn 
der User angibt wieviel RAM zur Verfügung steht, dann durch 20 geteilt 
wird, und dass die maximale Anzahl der Kacheln ist, die in einem Rutsch 
geladen wird. Wenn nicht müsste man den Index in zwei statt in einem 
Schritt erstellen (also etwa doppelte Erstellungszeit, wenn genug Ram 
frei gewesen wäre).


Oder anders: Ich will nicht soviel RAM, aber da eben alle Kacheln auf 
einmal eingelesen werden, wird zurzeit halt etwa Kachelgröße mal 1.2 an 
verfügbarem Ram benötigt. Und wenn der Rechner hier zu swappen anfängt, 
dann braucht es derzeit ewig. Ich bin kein Programmierer, daher kann ich 
das nicht ändern. Bin eh schon froh wenn ich solche Files halbwegs lesen 
kann.



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

Re: [Talk-de] Tag zum Schutz vor Lizenz-Datenverlust

2010-12-17 Diskussionsfäden Felix Hartmann



Ich denke, es ist tatsaechlich nicht boese, die nicht-relizensierten 
Sachen neu zu erfassen, sondern notwendig.




Wenn so argumentiert wird, denke ich auch nicht, dass es boese ist, odbl 
ja Sachen neu zu erfassen, und unter CCBYSA 2.0 exklusiv neu 
einzustellen - nein nicht nur boese sondern notwendig!


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

Re: [Talk-de] Tag zum Schutz vor Lizenz-Datenverlust

2010-12-17 Diskussionsfäden Felix Hartmann




On 17.12.2010 22:15, Frederik Ramm wrote:

Hallo,

Felix Hartmann wrote:
Ich denke, es ist tatsaechlich nicht boese, die 
nicht-relizensierten Sachen neu zu erfassen, sondern notwendig.


Wenn so argumentiert wird, denke ich auch nicht, dass es boese ist, 
odbl ja Sachen neu zu erfassen, und unter CCBYSA 2.0 exklusiv neu 
einzustellen - nein nicht nur boese sondern notwendig!


Die nicht-relizensierten Sachen muessen neu erfasst werden - 
*spaetestens* nach dem Lizenzwechsel, denn dann sind sie weg. Selbst 
wenn sie vorher schon neu erfasst werden, entsteht dadurch kein 
Schaden, da sie in jedem Fall zukunftssicher sind (auch dann, wenn 
eine Lizenzwechsel nicht stattfindet, koennen sie bestehen bleiben) - 
es kommt also in keinem Fall zu einem Informationsverlust.


Umgekehrt kommt es sehr wohl zu einem Informationsverlust. Wenn sowas 
im Rahmen der normalen Editiertaetigkeit passiert (hm, dieser Way ist 
ungenau, ich loesch den mal und mach ihn neu), dann muss man das 
akzeptieren (bis zum 31.3.2011...); wenn jemand das, um den 
Lizenzwechsel zu sabotieren, systematisch tut (ich loesche hier mal 
dieses ODbL-Dorf und erfasse es unter CC-BY-SA neu, denen in London 
werd ich's nicht so einfach machen...), dann ist das Vandalismus, und 
ich wuerde der Person mit Freuden den Account sperren.


Bye
Frederik

Natürlich ensteht Schaden, zumindest wenn etwa von Luftbildern 
abgezeichnet wird, weil dann darf man nicht einfach die Tags kopieren. 
Wenn man per GPS neu aufnimmt, auch dann kann es sein dass man den Weg 
dann anders tagged, und es gibt auch einen Informationsverlust - bzw 
wenn jemand die Tags kopiert, begeht er Lizenzbruch.

Daher ist es für mich genauso Vandalismus.


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

Re: [Talk-de] Tag zum Schutz vor Lizenz-Datenverlust

2010-12-17 Diskussionsfäden Felix Hartmann




On 17.12.2010 20:48, Ulf Möller wrote:

Am 17.12.2010 20:18, schrieb Felix Hartmann:


Wenn so argumentiert wird, denke ich auch nicht, dass es boese ist, odbl
ja Sachen neu zu erfassen, und unter CCBYSA 2.0 exklusiv neu
einzustellen - nein nicht nur boese sondern notwendig!


Das ist nicht notwendig, weil bis zur endgültigen Umstellung alle 
Daten unter CCBYSA veröffentlicht werden.



Falsch, weil man kann eben nicht einfach so einen Weg neuzeichnen. Woher 
bekommt man die Tags? Wenn Tags verloren gehen, oder widerrechtlich 
kopiert werden, ist das auch entweder Vandalismus, oder eben Lizenzbruch.



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

[Talk-de] Topographie im Gerbirge ... Werte fuer Kämme, Gräben, Geröllhalden, etc.

2010-12-01 Diskussionsfäden Felix Hartmann

Dank Bing Bildern kann man (zumindest in Teilen) in den Alpen nun ja 
ziemlich genau Informationen zur Topographie eintragen. Wichtig fände 
ich dass es eine Übersichtsseite im Wiki gibt, wo genau detailliert all 
diese Sachen zusammengefasst werden. Gibt es da schon was?


Was mir etwa fehlt zurzeit - bzw noch nicht gefunden:
Bergkämme
Mittellinie von Gräben (in Topographsichen Karten meist schwarz punktiert)
Detaillierung von Geröllfeldern (feines Geröll, Schrofen, etc..)
Detaillierte Felszeichnungen wie in Alpenvereinskarten - also nicht nur 
einfach plump eine Gegend als Felsen ausweisen, sondern Detailliert 
Einschnitte, Felsbänder und anderes einzuzeichnen.




Dazu dann Auflistung bestehender Werte wie scrub, etc.. (evtl noch 
detailliertere Unterscheidungen für Latschen, bzw Unterschiede zwischen 
Geltschern (ein Gletscher fließt) und permanenten Schneefeldern), usw.



Sprich einfach eine Seite wo alle die Informationen reinkommen, die 
derzeit im Gegensatz zu guten 1:25k Rasterkarten noch fehlen



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

Re: [Talk-de] Unzählige Wege mit sac_scale bzw trail _visibility die komplett falsch eingetragen ist.

2010-11-21 Diskussionsfäden Felix Hartmann


Hallo,
Am Donnerstag 18 November 2010 14:55:25 schrieb M∡rtin Koppenhoefer:


halte ich für sinnvoll. Insgesamt ist zu viel Übersetzung in den
Presets m.E. eher schädlich, weil sie davon abhält, sich mit der
Bedeutung des tags auseinander zu setzen. Ich halte auch nichts von
Bundesstraße oder Kreisstraße als Übersetzung von primary oder
tertiary...


+1

Gruß, Wolfgang

___
So ich hab mal Beispielbilder bei Trail_visibility angefügt - wobei das 
halt schwer ist. Weil eben eigentlich schon bei trail_visibility=bad auf 
einem Photo kein Weg mehr erkennbar ist. Evtl hat hier ja noch jemand 
Photos die gut passen.


Ausserdem hab ich die Begriffe alpin und Bergschuh erklärt, weil sonst 
irgendwie logisch ist, dass zahlreiche Mapper die Skala falsch deuten 
(und ergo jeder zweite T4 Weg derzeit alles andere als alpin ist...).
Ausserdem hab ich noch Notizen hinzugefügt, um zu erklären dass die 
Sac_scale primär für Bergregionen gedacht und geeignet ist. (Jungle, 
Moor, Wüste usw. bergen ganz andere, mit der sac_scale nicht abbildbare 
Gefahren - hierfür braucht es eben andere Gefahren).


(Vorgestern hab ich übrigens die Klettersteigskala ala Hüsler im 
proposal auf englisch übersetzt und eingefügt).


Jetzt fehlt uns aber noch die Hochtourenskala des SAC - sonst haben wir 
zig T5 und T6 Wege (wenn sie mal existieren) bei denen die Anforderungen 
unklar sind. Die SAC Wanderskala ist etwa für Gletscher und 
Permaeisregionen absolut ungeeignet. Die Haute Route kann man etwa mit 
der sac_scale kaum sinnvoll beschreiben.



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

Re: [Talk-de] Unzählige Wege mit sac_scale bzw trail _visibility die komplett falsch eingetragen ist.

2010-11-21 Diskussionsfäden Felix Hartmann




On 21.11.2010 22:54, M∡rtin Koppenhoefer wrote:

Am 21. November 2010 22:41 schrieb Ulf Lampingulf.lamp...@googlemail.com:

Am 21.11.2010 20:13, schrieb Felix Hartmann:

So ich hab mal Beispielbilder bei Trail_visibility angefügt - wobei das
halt schwer ist. Weil eben eigentlich schon bei trail_visibility=bad auf
einem Photo kein Weg mehr erkennbar ist. Evtl hat hier ja noch jemand
Photos die gut passen.

Also die aktuellen Bilder bitte erstmal wieder rausnehmen. Die verwirren
jetzt wirklich wesentlich mehr als das sie nützen!


verstehe ich nicht, ich finde die Bilder ganz anschaulich, danke Felix.

Gruß Martin
Ich bin sofort dafür dass sie jemand austauscht. Da ich sie nicht falsch 
finde, würde ich sie bis es bessere Bilder gibt, lieber drinnen lassen.


2. (reply 1 mail weiter vorne) --- Ob Bergschuh so exakt definiert 
werden muss bin ich mir unsicher. Alpin würde ich aber auf jeden Fall 
weiter drinnenlassen. Ich hab letzte Woche gute 30 T4 Wege den sac_scale 
gelöscht weil diese ganz klar nicht T4 waren. (evtl T2, eher T1). Teils 
war T4 angegeben, und tracktype=grade3 (und in BEV Karten als dicke rote 
Linie),, also wahrscheinlich mit Mühe T1. Ein paar der Tagger hab 
ich auch gleich angeschrieben und um Info gefragt warum T4??



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

Re: [Talk-de] Unzählige Wege mit sac_scale bzw trail _visibility die komplett falsch eingetragen ist.

2010-11-21 Diskussionsfäden Felix Hartmann




On 21.11.2010 23:52, Ulf Lamping wrote:

Am 21.11.2010 23:00, schrieb Felix Hartmann:

Ich bin sofort dafür dass sie jemand austauscht. Da ich sie nicht falsch
finde, würde ich sie bis es bessere Bilder gibt, lieber drinnen lassen.


Ich bin schon mal ein bisschen durch die Gegend gewandert und mich 
haben die Bilder auf den ersten Blick mehr verwirrt als mir geholfen. 
Das geht anderen dann bestimmt auch so - also kein guter Ansatz ;-)


Bilder halten sich meist recht lange, weil die Leute sich nicht trauen 
die auszutauschen. Fehlende Bilder werden meist relativ schnell 
ergänzt. Deshalb sollten die Bilder gerade bei so schwierigen Themen 
die Sache gut veranschaulichen. Wenn das nicht der Fall ist, lieber 
erstmal wieder raus.


Vorschlag:
Jeweils die unteren Bilder bei excellent und good rausnehmen, die 
jeweils oberen drinlassen (das untere bei good geht für mich z.B. 
komplett daneben, da kann ich keinen Pfad erkennen).
Das untere bei Good, ist halt eine schwierige Situation für ein 
Einzelbild. Die Orientierung real ist glasklar. Aber weil es über ein 
Geröllfeld geht, wo halt im Frühling immer wieder was runtergeht, ist 
kein Weg vorhanden. Aber es geht ja um Orientierung, und die ist einfach 
-- man muss nur hoch zu der Stelle wo es nach rechts weggeht. Das es 
dort einen Weg im Felsen gibt, erkennt man als bergefahrene Person 
selbst auf dem Bild (weil nirgendswo anders wie dort, kann ein Weg 
sein...).


Die Stelle ist eine klassische Situation von kein Weg, aber sehr leichte 
Orientierung. Solche Stellen sind oberhalb der Baumgrenze recht häufig. 
Für mich ein perfektes Beispiel der Bezeichnung: Next marker always 
visible, but sometimes has to be searched for
Marker ist hier der Felseinschnitt, den man erkennen muss (has to be 
searched for). (P.S. den Einschnitt rechts rauf, hab ich als anderes 
Bild bei der via_ferrata_scale=0 als Beispiel eingefügt).


Das Bild bei no rausnehmen, ich kann da recht klar einen Pfad erkennen.
Schau und so kann man sich täuschen. Da gehen ab und zu ein paar Tiere 
runter, und noch seltener Menschen. Das was du da als Weg 
interpretierst, sind einfach nur Stellen wo Geröll durchgerutscht ist 
bei der Schneeschmelze.
Das ist aber das Problem was man hier hat. Wie stelle ich einen wirklich 
kaum erkennbaren Weg auf einem Photo dar?
Evtl nur Bilder bis bad, und dazu schreiben, dass bei noch schlechterer 
trail visibility ein Weg auf einem Photo unmöglich erkennbar ist?


Bei trail_visibility=no, ist es ja meist weglos. Und gute Orientierung 
ist gefragt (ich muss auf der Karte erkennen, ob da weiter unten 
Felsabbrüche kommen - das ist von dem Standpunkt aus nicht erkennbar, 
weiters ist bei schlechtem Wetter hier Null Kontrast - andererseits ist 
es ein sehr schneller Abstieg...).



Vielleicht für no:
http://commons.wikimedia.org/wiki/File:WaldlichtungLieserpfad.JPG

So eine Stelle ist für mein Verständnis, intermediate oder bad. Die 
Orientierung ist dort egal bei welchem Wetter nie schwer. Und genau das 
ist der Grund, warum ich gerne Bilder bei den Beispielen haben möchte. 
Weil sonst ist die Beschreibung extrem vom Orientierungsvermögen 
abhängig.  Nur Nachts bei Nebel könnte man sich hier verirren (da bin 
ich im Hochgebirge aber schon länst aufgeschmissen). Ich bin häufiger 
weglos unterwegs im Sommer, und im Winter eine jener Personen die mit am 
besten irgendwo in einer Steilwand eine fahrbare Strecke findet und sich 
dann auch nicht verfährt obwohl es bergab alles anders ausschaut wie 
beim scouten wenn man eine Steilwand frontal anschaut. Jemand der 
Erfahrung in den Bergen hat, sieht viel leichter Wege wie jemand der 
keine hat. Wir haben hier aber eine breite Skala, und daher müssen wir 
objektiv (und die derzeitige Beschreibung ist dies leider keineswegs) 
festlegen wie sie zu deuten ist. Ansonsten bleibt einem nur die 
Sicherheit, dass bei excellent und good der Weg einfach zu finden ist, 
bei allen anderen Werten es quasi nichtsaussagend ist, weil unklar ist 
wie es getagged gehört (das blödeste wäre, wenn jemand meint weil ihm 
nicht klar ist ob der Weg wo er ist nun Route X ist, oder Route Y, 
obwohl der Weg breit ausgetreten ist, wäre die Orientierung schwer.


Für die Erkennbarkeit von Routen, bräuchte es einen seperaten Key (wobei 
dieses Problem eigentlich nur Personen trifft, die ohne GPS sich mit 
Karte orientieren. OSM User aber großteils mit GPS unterwegs sind, und 
die Orientierungsschwierigkeit hierzu eigentlich auch ganz klare 
Aussagen bräuchte. GPS sind inzwischen einfach genauso wichtig für die 
Orientierung wie Karten geworden. Und hier fehlt es halt in der Skala. 
Denn falls es wo egal ist, wenn ich 20m neben dem Weg laufe oder ob ich 
wo abstürzen kann, dass gehört sehrwohl auch bei trail_visibility 
beachtet. Und selbst die Beachtung anderer Keys hilft hier wenig. Weil 
nehmen wir mal an, dass wir sac_scale=T5 haben. Dass sagt aber nichts 
aus, ob ich 10m neben dem Weg sofort draufgehe, oder ob es dort nicht 
vielleicht

Re: [Talk-de] Unzählige Wege mit sac_scale bzw tra il_visibility die komplett falsch eingetragen ist.




On 18.11.2010 08:15, Fichtennadel wrote:

2010/11/17 Felix Hartmannextremecar...@gmail.com:

sac_scale generell + trail_visibility

+1
Stimmt, ist mir auch schon aufgefallen. Die Wikiseiten könnten etwas
besser beschreiben und weniger bergerprobten eine besser
Einschätzung ermöglichen. Da hast Du recht.


Noch dazu gibt es in Österreich und DE kaum T5 und T6 Wege die markiert sind
(hier würde man eher angeschimpft werden, warum man abseits von Wegen
unterwegs ist wenn man Sachen besteigt, die sich als T5 oder T6 
klassifizieren...).

-1
Preintalersteig Rax. II-, ein bisserl markiert. --  sac_scale:
difficult_alpine_hiking, trail_visibility: bad
(http://www.openstreetmap.org/browse/way/56313986). Und dazu stehe
ich. Ist auch in der ÖK so eingetragen und in der Führerliteratur so
beschrieben.
Man muss nicht einer der Huberbuam und im Wallis zu sein, um T5+T6 zu
gehen und zu taggen.
Ja natürlich nicht. Aber selbst in Bergeerlebnis Schneeberg - Rax von 
Csaba Szépfalusi / Karel Kriz steht hierzu:
... /Markierte Klettertouren sind eine Spezialität des östlichen 
Alpenrands. Auf der Hohen Wand und auf der Rax gibt es eine ganze Reihe 
von Anstiegen, die mit Punkten versehen, und damit leichter auffindbar 
sind. Der Preintalersteig gehört auch in diese Reihe, mit der 
Besonderheit dass er sogar in den Karten eingezeichnet ist, was bei 
Klettertouren an sich unüblich ist.

/
Ich würde den Preintalersteig jedoch nur mit T5 bewerten. 
Kletter-Schwierigkeit ist nur Stellenweise II, und als Anforderung wird 
er generell als längere alpine Klettertour beschrieben, mit einigen 
ausgesetzten Stellen.


Klar es gibt viele solcher Steige auch außerhalb des Wallis. Aber wärend 
diese in der Schweiz doch recht häufig in Karten zu finden sind, ist das 
im Ostalpenraum eine Rarität. In Österreich sind abseits von wahnsinning 
häufig begangenen Hochtouren, Routen im T4 bis T6 Bereich eigentlich 
nicht in Karten eingezeichnet (vor allem nicht in Kompass oder BEV 
Karten, die bei Touristen weniger verbreiteten Alpenvereinskarten sind 
da noch etwas ausführlicher). Dass sie lokale Namen haben, bzw erkennbar 
sind oder existieren, und teils auch markiert, das streite ich ja gar 
nicht ab.

T5 und T6 dagegen, werden sehr gerne für Klettersteige verwendet - Das ist
kompletter Schwachsinn. Da die sac_scale ausdrücklich nicht für
Klettersteige geschrieben wurde. Für Klettersteige gibt es eigene
Klassifikationen.

Ist eine offene Diskussion, siehe
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/via_ferrata#sac_scale
Meiner Ansicht nach ist ein leichter(!) Klettersteig auch ein Pfad und
verdient daher eine sac_scale. Ich kann da auch ohne Klettersteigset
hoch -  highway=path. Ein anderer nimmt das set -
highway=via_ferrata. Beides trifft zu.

Finde ich nicht, da eben vom SAC eindeutig definiert wurde:

In Wirklichkeit ist eine Alpinwanderung im oberen 
Schwierigkeitsbereich (T5, T6) in aller Regel bedeutend anspruchsvoller 
als beispielsweise eine Hochtour mit der Bewerung L. Ein wesentlicher 
Unterschied zur leichten Hochtour liegt darin, dass auf einer T5 oder T6 
Route *selten bis nie mit Seil oder sonstigen Hilfsmitteln gesichert 
werden kann* und das entsprechende Gelände absolut beherscht werden 
muss,


(http://alpen.sac-cas.ch/html_d/archiv/2002/200204/ad_2002_04_18.pdf)


Es geht also nicht darum ob man einen Klettersteig auch ungesichert 
begehen kann, sondern darum ob der Weg künstlich dafür ausgelegt wurde 
(daher ja auch der Name Eisenweg für Klettersteig) oder ob er noch im 
natürlichen Zustand ist.
Wobei mich die inflationären Sonntagswanderwege die als T4 bezeichnet 
werden, viel mehr stören. Meiner Ansicht muss daher vor allem in JOSM 
statt dem Namen eben einfach nur T1-T6 auswählbar sein - Nur so sind die 
User gezwungen sich die Sac_scale zumindest einmal durchzulesen - bei 
50% der Wege scheint mir, dass die Bewerter dies nie gemacht haben. Bei 
der mtb:scale klappt es im Gegensatz daher ziemlich gut und die 
Abweichungen sind minimal und im subjektiven Bereich angesiedelt. Als 
Wanderer ist daher wenn vorhanden, obwohl nicht dafür gedacht, bei OSM 
die mtb:scale fast aussagekräftiger.




-- mit einem Bot alle T5 und T6 von Klettersteigen (sind ja zum Glück meist
noch seperat ausgewiesen) löschen?

-100
Aber ganz sicher nicht! Wenn ich einen Pfad so eintrage, habe ich mir
was dabei gedacht. Bots die die Arbeit anderer zerstören sind ne
Frechheit. Genauso wie User, die von mir abgegangenen und getaggten
Wanderwegen von der Couch im Ruhrpott aus Tags wegnehmen.

Wenn die Beschreibung der sac_scale im Wiki nicht passt, dann muss man
dort ansetzen. Aber solange bei demanding_alpine_hiking Oft weglos,
einzelne einfache Kletterstellen bis II. in der Beschreibung steht,
passt das auch auf A-B Klettersteige. Und da das auch in der
offiziellen Beschreibung des SAC
(http://alpen.sac-cas.ch/html_d/archiv/2002/200204/ad_2002_04_18.pdf)
steht, bin ich der Meinung, dass das so passt.

lG,
  Georg

Re: [Talk-de] ?Unzählige Wege mit sac_scale bzw tr ail_visibility die komplett falsch eingetragen?ist.




On 18.11.2010 09:24, Sven Geggus wrote:

Andreas Tilleandr...@an3as.eu  wrote:


Für mich ist die Konsequenz, daß ich persönlich sac_scale im Harz gar
nicht verwende, denn letztlich wird auf allen path und track gewandert
und nirgends wäre etwas anderes als hiking wirklich sinnvoll.

Das ist definitiv so und ein Problem der SAC scale. Für Mittelgebirge
weitgehend ungeeignet.

Sven

Sehe ich nicht so. Im Mittelgebirge gibt es einfach kaum technisch 
schwer begehbare Wege. Die Schwierigkeit liegt hier eher an anderen 
Faktoren wie:


Kondition (Streckenlänge).
Mühsamkeit (etwa viele Äste im Weg, oder Weg verschlammt und man sinkt 
tief ein nach Regenfällen)
und anderen Faktoren die aber nichts mit technischer Schwierigkeit zu 
tun haben und primär erst durch Streckenlänge, nicht jedoch durch 
Anforderung an Gleichgewicht, Trittsicherheit und erkennen alpiner 
Gefahren (Steinschlag, Gletscherspalten..) aufkommen.


Für typische Mittelgebirgswanderwege, liegt die Anforderung an der 
geplanten Route als gesamtes, nicht jedoch an der technischen 
Schwierigkeit einzelner Wegstücke. Ergo lässt sich die Anforderung einer 
Tour auch nicht anhand der technischen Schwierigkeit der begangenen Wege 
definieren. Da man als Kartenzeichner, jedoch nicht die Route des 
Begeher kennt, sind die Anforderungen nicht in der Karte 
klassifizierbar. Es ist also nicht die SAC Skala ungeeignet, sondern sie 
wird ganz einfach nicht benötigt, auch jede andere Skala für technische 
Schwierigkeit würde nicht besser funktionieren.


Viel interessanter im Mittelgebirge wären also Werte, die nicht den Weg, 
sondern das drumherum näher beschreiben. Etwa Frequenz (wie viele 
Menschen trifft man hier an), Aussicht, Sehenswürdigkeiten, Vegetation 
(also etwa schöne Blumen, schmackhafte Pilze, etc.), Auslauf für Tiere, usw.



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

Re: [Talk-de] Unzählige Wege mit sac_scale bzw tra il_visibility die komplett falsch eingetragen ist.




On 18.11.2010 10:54, Ulf Lamping wrote:

Am 17.11.2010 23:12, schrieb Felix Hartmann:

Mir fällt immer wieder auf, dass sehr viele User bei sac_scale bzw
trail_visibility einfach nur Schrott eintragen.
IMHO liegt das an den Werten und wie sie beschrieben sind, bzw noch
schlimmer dass sie eben im JOSM Preset übersetzt sind, aber sich viele
User scheinbar noch nie die Mühe gemacht haben, nachzulesen, was ein
Wert bedeutet.

So bekommen gut markierte und ausgebaute Wege im Gebirge (aber nicht
alpinen Gelände, wobei alpin ein Begriff ist mit dem eben 90% der
Flachländer nichts anfangen können, für die ist schon ein Hügel alpin)
oft etwa sac_scale=alpine_hiking  trail_visibility=bad als
Beschreibung. Obwohl man so einen Weg mit Stöckelschuhen gehen 
könnte


Irgendwie hast du eine ziemlich schräge Ausdrucksweise: für die ist 
schon ein Hügel alpin, kompletter Schwachsinn, wie wild auf jeden 
Weg klatscht und anscheinend auch schräge Sichtweise der 
uninformierte Leser. Könntest du dir angewöhnen dich etwas 
zivilisierter auszudrücken?


Geh bitte davon aus, das der Mensch der bei OSM Sachen einträgt eben 
*kein* Profi ist und daher die Informationen nicht in seiner 
Handbibliothek zuhause nachlesen kann und im Zweifel auch nicht erst 
eine große Recherche im Web starten wird.
Und genau aus dem Grund, sollten eben keine Beschreibungen vorkommen in 
Editoren, die jemand ohne jegliche Einarbeitung in das Thema, einfach 
nach Gefühl benutzt. Und klar, die Skala ist für jemanden der noch nie 
im Hochgebirge war, nicht benutzbar.
Das ist aber bei vielen Sachen so, wer sich womit nicht auskennt, sollte 
es auch nicht verwenden.


Wenn etwas bei OSM nicht gut funktioniert, sollte man sich Gedanken 
darüber machen warum. Man sollte aber auch seine eigene Sichtweise 
hinterfragen, ob das was man erwartet von anderen aktuell überhaupt 
erfüllbar ist.



Bei trail_visibility ist es eigentlich noch schlimmer. Hier geht es
nicht drum ob man die rot-weiß-rote oder gelbe Markierung der
Wanderroute findet, sondern ob der Weg an sich erkennbar ist. Leider
wird dies von sehr vielen Benutzern verwechselt, und so bekommen breit
ausgetretene Pfade eine visibility von bad attestiert, obwohl man da mit
50km/h mit seinem MTBike ohne Risiko den Weg zu verlieren rumbrettern
könnte (sprich nicht einen Falschen weg zu fahren, sondern ohne Risiko
dass man generell vom Weg abkommt in wegloses Gelände). Leider ist das
Wiki hier auch etwas verwirrend, da dem uninformierten Leser der
Unterschied zwischen einer Wegmarkierung (wo ist der Weg, etwa auf einem
Gletscher, oder in einem Geröllfeld, oder weil so selten benutzt) und
einer Routenmarkierung scheinbar nicht klar ist.


Sorry, diese Aussage kann ich so nicht nachvollziehen.

Die Wiki-Seite sagt explizit etwas über die Markierung des Weges aus, 
z.B. bei good: Die nächste Markierung ist ständig sichtbar, 
allerdings manchmal etwas schwer zu finden..


Diese Beschreibung steht seit 2008 so im Wiki, ich würde dich daher 
bitten diese nicht ohne allgemeine Rücksprache zu verändern.
Für mich würde hier etwa Sinn machen. /Falls Weg nicht klar erkennbar, 
ist die nächste Wegmarkerierung ständig sichtbar (bei gutem Wetter), 
allerdings manchmal etwas schwer zu finden/.



T5 und T6 dagegen, werden sehr gerne für Klettersteige verwendet - Das
ist kompletter Schwachsinn. Da die sac_scale ausdrücklich nicht für
Klettersteige geschrieben wurde. Für Klettersteige gibt es eigene
Klassifikationen.


Solange es in OSM für Klettersteige nichts anderes gibt, ist es ganz 
einfach *kein* Schwachsinn. Wenn du willst das Leute für Klettersteige 
was anderes verwenden, wirst du dafür sorgen müssen das sie die 
Möglichkeit dazu haben. Ansonsten werden sie das nehmen was sie kennen.


Es wäre doch z.B. sinnvoll auf der Wikiseite zu sac_scale einen 
neutralen Hinweis einzufügen, daß Klettersteige eine eigene 
Klassifizierung haben und daher normallerweise nicht mit sac_scale 
getaggt werden. Ein Hinweis auf das via_ferrata Proposal wäre sicher 
auch nicht schlecht um dem geneigten Leser Alternativen aufzuzeigen ...



Generell fallen sicherlich 90% der Wege in T1 oder T2, nur wer mit
Openstreetmap unterwegs ist, wird nach einem Wander/MTB-Tag zurückkommen
und prahlen wieviel T4 oder T5 er heute schon wieder abgegangen 
ist :-(


Unterstellungen helfen hier nicht weiter ;-)


Noch dazu gibt es in Österreich und DE kaum T5 und T6 Wege die markiert
sind (hier würde man eher angeschimpft werden, warum man abseits von
Wegen unterwegs ist wenn man Sachen besteigt, die sich als T5 oder T6
klassifizieren...). T5 und T6 sind halt eher im wirklichen Hochgebirge
zu finden, und das gibt es in DE und AT kaum. Ich hab heute grade wieder
ein paar Wurzelwege die im Flachland an einem Seeufer langgehen und mit
T4 klassifiziert sind gefunden.


Nicht so schön.

Aber auch hier: Solange es fürs Flachland und die Mittelgebirge keine 
geeigneten Klassifizierungen gibt (oder diese den Leuten unbekannt 
bleibt), werden die

Re: [Talk-de] Unzählige Wege mit sac_scale bzw tra il_visibility die komplett falsch eingetragen ist.




On 18.11.2010 08:56, Andreas Tille wrote:

On Wed, Nov 17, 2010 at 11:12:35PM +0100, Felix Hartmann wrote:

Mir fällt immer wieder auf, dass sehr viele User bei sac_scale bzw
trail_visibility einfach nur Schrott eintragen.
IMHO liegt das an den Werten und wie sie beschrieben sind, bzw noch
schlimmer dass sie eben im JOSM Preset übersetzt sind, aber sich viele
User scheinbar noch nie die Mühe gemacht haben, nachzulesen, was ein
Wert bedeutet.

Hinsichtlich sac_sacle sehe ich das ähnlich.  Ich bin vorwiegend im Harz
unterwegs und habe dort noch keinen Weg gefunden, den ich nicht mit ein
paar soliden Wandersandalen langlaufen könnte, auch wenn es manchmal
etwas über Stock und Stein geht.  Damit könnte man sagen, um Harz gibt's
eigentlich nur sac_scale=hiking und damit ist das Tag eigentlich
redundant und kann entfallen.  Daß die sac_scale Beschreibung auch an
highway=track verwendent werden können soll, halte ich erst recht für
Unsinn: Wenn ein Track etwas ist, wo man mit zweispurigen Fahrzeugen
durchkommt, dann sollte da niemals was anderes als sac_scale=hiking
stehen und ist somit redundant.


Also im generellen ja, aber ich finde schon dass es hier Ausnahmen gibt. 
Es gibt im Gebirge teils alte Karrenwege, (Beispiel -Törlweg Rax - siehe 
mehrere Bilder hier: http://www.sonnabend.at/toerlweg_ottohaus.htm) wo 
früher (bestimmt 60-70 Jahre lang) mit Eseln und Pferden zweispurige 
Karren hinaufgezogen wurden. An Schlüsselpassagen wurde mit Seilwinden 
geholfen. Dieser Weg ist derzeit als path getagged, aber von der Breite 
und historischen Bedeutung/Erbauung her wäre es eigentlich noch ein 
track, obwohl es eben kaum mehr danach aussschaut da nach Bau der 
Raxseilbahn die Bedeutung als Transportstraße wegfiel. Das ein track 
also sac_scale=mountain_hiking entspricht, ist durchaus möglich - wenn 
auch eine Ausnahme.  Neben dem Bildauschnitt geht es recht steil 
(30-45°) hinab, Eine geringe Absturzgefahr besteht also - womit 
mountain_hiking gerechtfertigt ist.




In schlecht entwickelten Ländern, ist dies aber deutlich häufiger 
anzutreffen. Da gibt es Straßen wo man sein Geländefahrzeug nur mit 
Seilwinden durch Flüsse zieht, oder über Abhänge/Abbrüche drüber 
bekommt. Die Anforderung Teilweise steil. Absturzgefahr möglich ist ja 
nicht so schwer zu erfüllen. Auch wenn ein Track durch ein Unwetter etwa 
weggespült wurde, kann durchaus mountain_hiking zutreffen, wenn nicht 
sogar Kletterfähigkeiten erforderlich werden.



Noch seltener, aber auch möglich wäre sogar demanding_mountain_hiking. 
Ein Beispiel dafür wäre etwa der sogenannte Maschinengraben auf der Rax. 
Hier wurden Anfang des 20. Jahrhunderts große Maschinen bzw Material 
durch einen bis zu 45° Steilen weglosen Graben 400HM den Berg hinauf 
befördert mit Seilwinden. Wenn jetzt jemand diesen Graben als 
highway=track  disused=yes eintragen würde, dann wäre es gar nicht mal 
falsch. Obwohl hier 2m Hohe Abbrüche zu überklettern sind, bzw im Winter 
viele Lawinen durchgehen. Das solche Fälle absolute ausnahmen sind ist 
schon klar.



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

[Talk-de] Unzählige Wege mit sac_scale bzw tra il_visibility die komplett falsch eingetragen ist.

2010-11-17 Diskussionsfäden Felix Hartmann

Mir fällt immer wieder auf, dass sehr viele User bei sac_scale bzw 
trail_visibility einfach nur Schrott eintragen.
IMHO liegt das an den Werten und wie sie beschrieben sind, bzw noch 
schlimmer dass sie eben im JOSM Preset übersetzt sind, aber sich viele 
User scheinbar noch nie die Mühe gemacht haben, nachzulesen, was ein 
Wert bedeutet.


So bekommen gut markierte und ausgebaute Wege im Gebirge (aber nicht 
alpinen Gelände, wobei alpin ein Begriff ist mit dem eben 90% der 
Flachländer nichts anfangen können, für die ist schon ein Hügel alpin) 
oft etwa sac_scale=alpine_hiking  trail_visibility=bad als 
Beschreibung. Obwohl man so einen Weg mit Stöckelschuhen gehen könnte



Es fällt übrigens auf, dass der am häufigsten falsch verwendete Wert 
alpine_hiking ist. Sprich soweit es mir erscheint, denken sich viele 
einfach: Alpinwandern ist einfacher als anspruchsvolles Bergwandern - 
ohne dass ihnen irgendwie klar ist, dass es hier nicht um den 
umgangssprachlichen Begriff geht, sondern um eine Klassifikation, die 
man sich durchlesen muss, und am besten auch noch anhand korrekt 
klassifizierter Beispiele klarmachen muss, bevor man die Werte wie wild 
auf jeden Weg klatscht.



Bei trail_visibility ist es eigentlich noch schlimmer. Hier geht es 
nicht drum ob man die rot-weiß-rote oder gelbe Markierung der 
Wanderroute findet, sondern ob der Weg an sich erkennbar ist. Leider 
wird dies von sehr vielen Benutzern verwechselt, und so bekommen breit 
ausgetretene Pfade eine visibility von bad attestiert, obwohl man da mit 
50km/h mit seinem MTBike ohne Risiko den Weg zu verlieren rumbrettern 
könnte (sprich nicht einen Falschen weg zu fahren, sondern  ohne Risiko 
dass man generell vom Weg abkommt in wegloses Gelände). Leider ist das 
Wiki hier auch etwas verwirrend, da dem uninformierten Leser der 
Unterschied zwischen einer Wegmarkierung (wo ist der Weg, etwa auf einem 
Gletscher, oder in einem Geröllfeld, oder weil so selten benutzt) und 
einer Routenmarkierung scheinbar nicht klar ist.


T5 und T6 dagegen, werden sehr gerne für Klettersteige verwendet - Das 
ist kompletter Schwachsinn. Da die sac_scale ausdrücklich nicht für 
Klettersteige geschrieben wurde. Für Klettersteige gibt es eigene 
Klassifikationen.


Generell fallen sicherlich 90% der Wege in T1 oder T2, nur wer mit 
Openstreetmap unterwegs ist, wird nach einem Wander/MTB-Tag zurückkommen 
und prahlen wieviel T4 oder T5 er heute schon wieder abgegangen ist :-(
Noch dazu gibt es in Österreich und DE kaum T5 und T6 Wege die markiert 
sind (hier würde man eher angeschimpft werden, warum man abseits von 
Wegen unterwegs ist wenn man Sachen besteigt, die sich als T5 oder T6 
klassifizieren...). T5 und T6 sind halt eher im wirklichen Hochgebirge 
zu finden, und das gibt es in DE und AT kaum. Ich hab heute grade wieder 
ein paar Wurzelwege die im Flachland an einem Seeufer langgehen und mit 
T4 klassifiziert sind gefunden.




Was kann man für eine bessere Klassifizierung tun?
-- Größere und bessere Bilder für T4 bis T6? Die jetzigen Bilder kann 
man auch anders deuten...

-- Erklärungen davon was alpin bedeutet?
-- Klarstellung der Unterscheidung von Routen und Wegmarkierung?
-- Aus JOSM und anderen Editoren die mündlichen Werte raushaun (das ist 
meiner meinung nach am wichtigsten) und nur T1 bis T6 drinnenlassen? -- 
Dies würde die ganzen Flachlandtiroler (dazu zähle ich auch 
Bergbewohner, die mit Alpinismus nichts am Hut haben) davon abhalten 
inflationär mit T3 bis T6 rumzuschmeißen?
-- mit einem Bot alle T5 und T6 von Klettersteigen (sind ja zum Glück 
meist noch seperat ausgewiesen) löschen?



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

Re: [Talk-de] Neues von Taginfo

2010-11-14 Diskussionsfäden Felix Hartmann

Wär es eigentlich möglich, nicht nur die Anzahl der keys darzustellen, 
sondern bei Linien, auch noch die Anzahl der KM? Oder wäre das deutlich 
mehr (Rechen-)Aufwand?


Bzw bei Flächen (wenn Länge der Linien nicht schwer implementierbar ist) 
auch noch die Fläche insgesamt (wobei ich dies weniger wichtig finde ich 
wie bei Linien - da klar ist, dass etwa landuse Polygone selbst wenn sie 
seltener benutzt werden wie man_made, einfach mehr Fläche belegen).



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

Re: [Talk-de] Prrobleme mit der Anzeige von Karten in MapSource 6.16.3

2010-11-14 Diskussionsfäden Felix Hartmann


On 14.11.2010 15:32, Bodo Meissner wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 14.11.2010 01:21, schrieb NopMap:


Ich habe von Leuten gehört, die Schwierigkeiten
mit Mapsource 6.16.x haben

Ich zitiere aus Beiträgen in der Mailingliste map_auth...@yahoogroups.com :


The changes list of the new 6.16.3 Mapsource version released last week shows 
the following line:
Made MapSource more robust when encountering invalid map products.
Has anybody identified how this change affects third party maps, both personal 
and commercial?

Behaviour  depends on MAP ID.
If Map id  is more or equal 2200 it will search for a new file in the hard
drive,  in order to authenticate map as belonging to Garmin.
Maps not authenticated are not displayed. So, change your Map ID to less
then 2200.

But as for this measure there is always a counter one, there are already
mapsource patched versions circulating in the Net...

Mapsource erwartet wohl für Karten mit Map-ID= 2200 eine zusätzliche Datei zur 
Freischaltung.
Auch in der o.g. Mailingliste hat der Autor von cgpsmapper geschrieben, daß 
Garmin in Zukunft einen anderen Freischalt-Mechanismus benutzt, der auf 
Kryptographie basiert, und nachträgliche Manipulationen der Karten verhindern 
will.
Also ist das vermutlich eine Maßnahme von Garmin gegen die Möglichkeit, die 
kommerziellen Garmin-Karten so zu ändern, daß keine Freischaltung mehr 
erforderlich ist.


Bode
Das ist falsch. Zumindest für Karten im .img (also nicht gmap 
Schwachsinn) Format. mkgmap Karten mit mapid 2200 funktionieren 
einwandfrei. Wenn eine Karte in 6.16.3 nicht angzeigt wird, aber schon 
in vorherigen Versionen, dann ist dort eindeutig geschlampt worden.


Das einzige Problem sind Karten mit Unlock Codes und 2200. Das kann 
aber nur auf cgpsmapper zutreffen, da mkgmap den Switch nicht setzt - 
den Mapsource für gelockte Karten erwartet.


(und da dieser Switch sowas von offensichtlich ist, wird sich Garmin 
hoffentlich in Zukunft eine bessere Implementierung zum Schutz ihrer 
Karten entwickeln, weil es halt viel zu einfach ist, eine Karte so zu 
verändern, dass Mapsource/GPS nicht nach einem Unlockkey/Zusatzdatei 
sucht - weil die Karte als nicht gelocked erkannt wird - der größte 
Profiteur wenn Garmin Karten nicht mehr so superleicht zu 
knacken/bekommen wären, wär in Europa ganz eindeutig Openstreetmap)




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

Re: [Talk-de] Neues von Taginfo

2010-11-14 Diskussionsfäden Felix Hartmann


On 14.11.2010 18:14, Jochen Topf wrote:

On Sun, Nov 14, 2010 at 05:15:30PM +0100, Felix Hartmann wrote:

Wär es eigentlich möglich, nicht nur die Anzahl der keys darzustellen,
sondern bei Linien, auch noch die Anzahl der KM? Oder wäre das deutlich
mehr (Rechen-)Aufwand?

Bzw bei Flächen (wenn Länge der Linien nicht schwer implementierbar ist)
auch noch die Fläche insgesamt (wobei ich dies weniger wichtig finde ich
wie bei Linien - da klar ist, dass etwa landuse Polygone selbst wenn sie
seltener benutzt werden wie man_made, einfach mehr Fläche belegen).

Das ist erheblich mehr Aufwand, weil ich dazu die Geometrien zusammenbauen
müßte. Das wird es sobald nicht geben.

Okay schade. Hatte ich mir schon gedacht (aber Fragen kost ja nix...). 
Hatte gehofft dass zumindest die Länge von Linien noch einfach wäre.

Jochen




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

Re: [Talk-de] Schlechtest Wertung für OSM im Kartenver gleich

2010-10-24 Diskussionsfäden Felix Hartmann

Ohne hier irgendjemand persoenlich attackieren zu wollen, frag ich mich 
schon, warum Frederik sich so vehemenent dafuer einsetzt, ein 
beschissenes Rendering zu verteidigen. Fuer mich kann da eigentlich nur 
der Schluss kommen, dass Geofabrik hier selber bessere Karten 
vermarkten/verkaufen moechte.


Ich denke dass ein Großteil der OSM Mapper, zur Uebersicht googlemaps 
oder andere Dienste benutzt, ganz einfach weil Mapnik abgesehen von sehr 
nahen Zoomstufen (ab 16) einfach schlecht ist. Was ehrlicherweise aber 
nicht nur an Mapnik selber liegt. Der Grund ist auch einfach, dass die 
Regel wir mappen nicht fuer die Renderer, hier einfach nicht funktioniert.


Denn solange es keinen Schluessel fuer regionale, nationale, 
internationale Bedeutung gibt, so lange kann ein Renderer einfach auch 
nicht wissen, wie wichtig eine Stadt ist, denn nur aus der 
Einwohnerzahl, geht dies halt nicht hervor. Sonst hat man etwa in 
Deutschland oder Benelux eine Stadt neben der anderen, in Oesterreich 
sieht man in derselben Zoomstufe, dann statt Wien, Graz, Inssbruck aber 
nur Wien - obwohl Graz oder Innsbruck fuer den Kartenausschnitt in 
derselben Zoomstufe, eine hoehere Bedeutung haben, wie etwa Mainz neben 
Frankfurt.


Auch ist es quasi unmoeglich, vernuenftige Gelaendedarstellung weit 
herausgezoomt zu erhalten, da dem renderer nicht klar sein kann wie groß 
etwa ein See, Gletscher, Wald,  ist, wenn sich dieser aus hunderten 
Einzelteilen zusammensetzt. Stellt man nun alle Seen ab Groeße X dar, so 
fehlen einem entweder große Seen, oder die Karte ist uebersaeht von 
kleinen Tuempeln. Keine kommerzielle Datenbasis bzw Karte kommt hier 
ohne haendische Faktoren aus (ob bei der Erstellung, oder bei der 
Datenbasis).



Andererseits, waere eine haendisch korrigierte Openstreetmap 
Darstellung, nicht sinnvoll. Weil wenn man mal nach Wochen Arbeit diese 
erstellt hat, sind die Daten schon wieder veraltet.


Solange die Karte nur Straßen darstellen soll, gibt es das Problem ja 
gar nicht. Da Straßen ja großteils logisch geplant sind, und ihre 
Wichtigkeit feststeht (Autobahn groeßer Schnellstraße, usw,...) bzw 
leicht messbar ist (wieviele Autos fahren pro Tag, Woche,  auf 
Straße X) und eine Darstellung nach ihrer Wichtigkeit somit klar ist.


Woher soll aber ein Renderer Wissen, dass in Wien der Stephansdom schon 
sehr frueh sichtbar sein soll, andere Kirchen aber nicht (selbst wenn 
diese gleich groß sein sollten, und sich sonst in der Datenbasis auch 
nicht unterschieden)? Er kann es ganz einfach nicht wissen, und damit 
auch nicht korrekt darstellen!


Wie koennte man dies loesen?

a)
Am besten indem fuer saemtliche OSM Features ein Schluessel wie etwa 
Priority=+/-1,2,3 angegeben wuerde. Dieser sollte dann zum Einsatz 
kommen, wenn man durch logisches versuchen der Zoomstufe zu finden (auf 
weltweiter Basis, damit man nicht pro Land, Region, Stadt einen eigenen 
Kartenstil braucht) hier sonst Fehler machen wuerde.


Alle Waldteile, die zum Schwarzwald gehoeren, koennte man etwa mit einem 
Priority`+2 taggen, dass waere deutlich einfacher wie zu versuchen alle 
Waldteile einer Relation hinzuzufuegen, und gleichzeitig dann vom 
Renderer zu verlangen, dass er diese zusammenfuegt, dann die Flaeche 
errechnet, Loecher loescht weil zu kleine Loecher nur verwirren 
(nicht immer hilft die Realitaet in der Kartendarstellung der 
Orientierung) und zu einem richtigen Ergebnis der regionalen Bedeutung 
zu kommen.


b)
Man koennte ganz einfach vom Modell, der Kartendaten ohne Zoomstufen 
abgehen, und OSM Layerbasiert aufbauen. Waere komplizierter und nicht 
besser (aber gibt genug Kartendatenbanken die komplett unabhaengige 
Datenlayer haben) - da ein Editor ja auch die Layer dynamisch aufbauen 
koennte, wenn die regionale Bedeutung der Objekte per Schluessel 
getagged ist.


c)
Die Renderer erstellen fuer jedes Land, lange und aufwendige Listen der 
wichtigen Objekte (dies macht etwa Nop - der das Thema hier ja gestartet 
hat) um so etwa wichtige Fluesse nach ihrer Bedeutung in den Zoomlevels 
richtig darzustellen. Dies ist eindeutig die schlechteste Loesung, weil 
wenn man es so angeht, dann gibt man zu, dass man ohne lokales Wissen 
aus OSM keine gescheite Karte bauen kann.


d)
wir schieben die Schuld an sauschlechten Karten weiter auf die Renderer, 
und sagen so wie Frederik, dass gute Karten nicht der Sinn von 
Openstreetmap.org sind. Koennen ja andere kommerziell ausbeuten, dass 
die Openstreetmap Community hier ganz einfach versagt. Bzw wir 
beschließen dass Openstreetmap nicht dafuer geeignet ist, auf Karten 
dargestellt zu werden, und nur noch fuer Use Cases wie Navigation oder 
andere Werke basierend auf OSM Daten da ist.



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

Re: [Talk-de] Schlechtest Wertung für OSM im Kartenver gleich

2010-10-24 Diskussionsfäden Felix Hartmann


On 24.10.2010 20:39, Johannes Huesing wrote:

Felix Hartmannextremecar...@gmail.com  [Sun, Oct 24, 2010 at 06:42:35PM CEST]:
[...]

Denn solange es keinen Schluessel fuer regionale, nationale,
internationale Bedeutung gibt, so lange kann ein Renderer einfach
auch nicht wissen, wie wichtig eine Stadt ist, denn nur aus der
Einwohnerzahl, geht dies halt nicht hervor.

Ich habe vor langer Zeit mal dargelegt, wie man mit der Einwohnerzahl
und den Geokoordinaten das Problem ganz gut in den Griff kriegen kann.

http://wiki.openstreetmap.org/wiki/DE:Anzeige_von_St%C3%A4dten#Dominanz

[...]
Das Problem ist, ja klar kann man dies fuer Staedte/Orte ausrechnen, 
aber sicherlich eben nicht fuer jedes Kartenobjekt.

a)
Am besten indem fuer saemtliche OSM Features ein Schluessel wie etwa
Priority=+/-1,2,3 angegeben wuerde.

Da glaube ich, dass das Kirchturmdenken hier die Prioritätswerte
nach oben hin nivellieren wird.

[...]
Ja, wahrscheinlich werden die meisten Leute nur positive Werte benutzen, 
ist aber auch egal. Fuer eingen Großteil aller eingezeichneten Objekte, 
wird es keine Prioritaet brauchen, aber meist kommt man mit 10% Einsatz, 
bei 90% des optimalen Wertes heraus (oder 20/80, was auch egal ist).

dann gibt man zu,
dass man ohne lokales Wissen ... keine gescheite Karte bauen
kann.


Das würde ich (mit meiner etwas eigenwilligen auszugsweisen
Zitierweise) auch so sehen.
Und genau dies sollte eben nicht so sein. Sprich Openstreetmap sollte so 
gut sein, dass man auch ohne lokales Wissen eine Karte bauen kann, die 
gut ist (sie braucht ja nicht perfekt zu sein) - zurzeit ist jede OSM 
Karte ohne lokales Wissen einfach maximal ausreichend hinnehmbar von der 
Qualitaet. Nur bei Einsatzzwecken die im vorhinein von den 
traditionellen Kartendaten ueberhaupt nicht beachtet wurden, kann OSM 
punkten. So traurig es ist, wenn sich hier nichts an der Datenstruktur 
aendert (im Sinne von zusaetzliche Tags) - wird sich dies auch in 
Zukunft nicht aendern.




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

Re: [Talk-de] Xplova G3 GPS mit OSM-Onboard-Navigation


 On 14.09.2010 04:35, Johann H. Addicks wrote:

Am 14.09.2010 00:52, schrieb Felix Hartmann:


Das ganze ist soweit ich erkennen kann offboard. Am GPS sieht man nur
Rasterkarten (und selbst hier ist fraglich wie haeufig und fuer welche
Gegenden man die updaten kann).


Mangels UMTS oder anderer Luftschnittstelle muss das schon schon 
onboard sein, wie soll das sonst Turn-by-Turn machen?


Und mit lokal gespeicherten Rastermaps wird auch niemand Routing 
hinbekommen.
Sprich: Die Mapnik-Bilder in den Screenshots werden einfach Montagen 
sein.

Oder da läuft wirklich ein lokaler Mapnik drin...

-jha-
Die schreiben dort was von Online Routenportal. Sprich man muss sich die 
Route vorher online erstellen, und hat dann Turn-by-Turn Navigation 
solange man die Route nicht verlaesst. Halt extreme Minimalstloesung.


Ich glaube  nicht dass die Mapnik Bilder Montage sind. Wenn dem so ist, 
dann braeuchte es fuer On-Board Turn-by-Turn gleich zwei Karten. Einmal 
eine Vektordatenbasis zum routen, und zweitens die Mapnik Bilder (die 
richtig viel Speicherplatz brauchen) zum anschauen.
Das entwickeln einer outdortauglichen Vektorkarte halte ich jetzt 
einfach mal als unmoeglich fuer Xplova und deren Marktverstaendnis 
(siehe G5)



___
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] Xplova G3 GPS mit OSM-Onboard-Navigation


 On 14.09.2010 04:35, Johann H. Addicks wrote:

Am 14.09.2010 00:52, schrieb Felix Hartmann:


Das ganze ist soweit ich erkennen kann offboard. Am GPS sieht man nur
Rasterkarten (und selbst hier ist fraglich wie haeufig und fuer welche
Gegenden man die updaten kann).


Mangels UMTS oder anderer Luftschnittstelle muss das schon schon 
onboard sein, wie soll das sonst Turn-by-Turn machen?


Und mit lokal gespeicherten Rastermaps wird auch niemand Routing 
hinbekommen.
Sprich: Die Mapnik-Bilder in den Screenshots werden einfach Montagen 
sein.

Oder da läuft wirklich ein lokaler Mapnik drin...

-jha-

Ich hab mir mal die Betriebsanleitung durchgelesen. Das bestaetigt mich 
nur, dass es kein onboard autorouting gibt - da es hier einfach nicht 
erwaehnt wird (okay bezieht sich aufs brydon, aber das hat ja ziemlich 
sicher dieselbe Hardware).
Dazu fehlen (zumindest in der Betriebsanleitung) zig essentielle Dinge 
die man einfach von einem GPS erwartet. Sie Screenshots zeigen fast alle 
Mapnik Karten in der Betriebsanleitung, eine Vektorkarte konnte ich auf 
keinem einzigen Bild erkennen.
Das ganze ist eigentlich nur ein Fahrradtacho mit Karten und 
Trackanzeige, sowie der Moeglichkeit POIs zu suchen.


Betriebsanleitung auf englisch ist hier:
http://corp.brytonsport.com/download/Rider%2050%20UM-EN-0628.pdf

gibt auch eine auf Deutsch, aber ich wuerde bei solch Firmen immer das 
original bevorzugen.


Karten zur Auswahl scheinen Mapnik Standard bzw OpenCycleMap zu sein. 
Dazu noch Daten von Eurovelo (keine Ahnung was fuer welche und in 
welchen Laendern).
Zu Updates oder Stand der Karten wird sich ausgeschwiegen. Mehr dazu in 
dem Manual:

http://corp.brytonsport.com/download/Bryton%20Bridge_UM-0908.pdf

Gut moeglich dass wir hier das erste GPS sehen, wo fuer OSM 
Kartenupdates Geld verlangt wird (denn die Karten kann man nur per DVD 
uploaden, eine Onlineschnittstelle wird nicht genannt) - auch fragt sich 
welche Zoomstufen verfuegbar sind. Da ganz Europa auf 2DVDs ausgeliefert 
wird, sind die Zoomstufen wohl eher spaerlich. Die Schweiz etwa hat laut 
einem Screenshot 165.66MB - das kann sich bei einer Rasterkarte nicht 
fuer hochaufgeloeste Zoomstufen ausgehen.



Dass die Kartendaten unter CCBYSA2.0 stehen, wird uebrigens nirgendswo 
auch nur in einer Fußnote erwaehnt. Auch sonst wird nicht erklaert was 
hinter Openstreetmap oder OpenCycleMap (wird ohne Domain angegeben) 
stehen soll.




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

Re: [Talk-de] Grenzen der Ausschnitte


 On 14.09.2010 12:23, Frederik Ramm wrote:

Hallo,

Elmar Burke wrote:
auch ich muss mich erst mal bei dir bedanken, Frederik, ohne deine 
Extrakte würde manches Experiment scheitern! Aber mir ist 
aufgefallen, dass wenn ich zwei aneinander grenzende Regionen in 
Osmosis zusammenfüge (in meinem Fall Regierungsbezirk Düsseldorf und 
die Niederlande) ist an der Grenze ein Spalt, so zu sagen ein 
Informationsvakuum. Wäre es daher möglich, die Extrakte um ~ 250m zu 
vergrößern oder einen Extrakt vom Niederrhein (von Nijmegen bis 
Düsseldorf) zur Verfügung zu stellen? Das würde uns in Kleve sehr 
nützlich sein ;-)


Ich hab das schon lang auf meiner Liste, alle Ausschnittsgrenzen mal 
zu ueberarbeiten, so dass sie


(a) die Grenzlinie, auf die sie sich beziehen, auf jeden Fall 
vollstaendig enthalten;


(b) dabei zugleich nur so wenig wie moeglich ueber diese Grenzlinie 
hinausgehen;


(c) dabei zugleich so wenig Punkte haben wie moeglich (daher kommt es 
nicht in Frage, die Grenzlinie selbst als Ausschnittsgrenze zu nehmen).
d) dabei sollte aufgepasst werden, dass nicht Ozeane bloed 
durchgeschnitten werden. Besonders tueckisch ist da etwa die NL/DE 
Grenze im Norden. Hier muesste man fasst jede Seite 5-6km Ueberlappen 
lassen, damit nicht See--Land--See entsteht (und das Land aber wegen 
abschneiden fehlt), und die Algorhytmen meinen dass somit der Ozean 
uebers Land geht, und damit große Landesteile ueberschwemmt. 
Hinzukommt hier ja eh noch, dass die Grenze nicht wirklich 
ausjuridiziert ist. Wird halt sonst extrem kompliziert fuer einen 
Renderer zu wissen auf welcher Seite der Ozeanlinie der Ozean liegt (da 
einfach nur zuwenig Stuecke der Ozeanlinie im Extrakt liegen).


Das wuerde die Probleme derer, die Auschnitte kombinieren, weitgehend 
loesen (grenzueberschreitende Wege waeren allerdings immer noch in 
beiden Ausschnitten halb drin).


Bislang bin ich da noch nicht dazu gekommen, idealerweise wolle ich 
das so machen, dass diese Grenzen automatisch aus OSM geholt werden 
(und wenn mal eine kaputt geht, soll halt die vom letzten Tag 
weiterverwendet werden).


Bye
Frederik


___
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] Alpen...