Re: [Talk-de] Routing - Separater Radweg und andere Probleme
Moin, 2009/5/26 Mehmet Sirin > > Was mich aber so verwundert ist, dass sehr viele gegen das Vorgehen des > zusätzlichen Erstellen von Radwegen neben der Straße sind, warum?, welche > großen Nachteile existieren denn? > Die Hauptgründe sind die dadurch entstehende Unübersichtlichkeit beim editieren (durch die dadurch entstehenden Wege) sowie die Routingprobleme die sich ergeben. Als Fahrradfahrer kann man die Straßenseite ja nicht nur an Kreuzungen wechseln, sondern auch mittendrinnen. Ich bin dazu übergegangen die Fahrrad- Fußwege nur dann einzeln zu zeichnen, wenn ein einfaches wechseln der Straßenseite aufgrund von Hindernissen (Grünstreifen etc.) nicht Möglich ist. Die Möglichkeiten mit zusätzlichen Tags auch alles an die eigentliche Straße dranzuheften gibt es ja. Lediglich das rendern von einseitigen Fahrradwegen ist derzeit aufgrund von SVG Beschränkungen nicht Möglich. Meine 2. Frage: > Worauf muss ich noch achten, wenn ich einen Radrouting erstellen will, also > welche Probleme oder Szenarien könnte es noch geben? > Beim Radrouting muss besonderen Wert auf Kreuzungen gelegt werden. So kann eine einfache Kreuzung für Autofahrer für "richtiges Radrouting" viel komplizierter ausfallen. Zudem die oben schon genannten Schwierigkeiten, das man als Radfahrer auch "queerbeet" fahren kann und dies in Verkehrsberuhigten Bereichen auch durchauch annehmen sollte. Keiner fährt bis zur nächsten Kreuzung weil man in einer Wohntstraße die Straßenseite wechseln möchte ;) > Grüße von der Erde!!! > Gruß aus Erlangen Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ways_with_long_segments / Kontrol lierter Luftraum eingetrage n?
Also Informationen zu Lufträumen findet man beispielsweise hier: http://www.dfc-saar.de/ Aber es ist fraglich ob es Sinn macht das in OSM einzupflegen. Es ist sehr einfach die Karten auf dem GPS mit diesen Luftrauminformationen zu versorgen. Z.B. auch zusätzlich zu bestehenden Karten. Die Luftrauminformationen werden als Vektordaten von der Flugsicherung zur Verfügung gestellt, man kann das dann auf Garmin usw. Geräten darstellen. Flugrouten machen sicher kaum Sinn, die Diskusion gab es auch schon mal. Gruß Sven S. Am Montag, 25. Mai 2009 17:38:07 schrieb talk-de-requ...@openstreetmap.org: > Hi, > nachdem wir ja letzten die Diskussion zum Thema Flugrouten hatten sind > jetzt noch Grenzen des kontrollierten Luftraums aufgetaucht: > > http://www.openstreetmap.org/browse/way/35007658 > > Die sind nur so grossflaechig ohne nodes das natuerlich der OSM Inspektor > Meckert ;) > > Und auch schon eine Wiki Seite: > > http://wiki.openstreetmap.org/wiki/DE:Luftraum > > Macht das wirklich Sinn? > > Flo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, 25 May 2009 17:07:24 +0200, Florian Lohoff wrote: > On Mon, May 25, 2009 at 03:42:02PM +0200, marcus.wolsc...@googlemail.com > wrote: >> Also, für mich: >> Momentan wird alles in maxspeed was keine Zahl ist konsequent >> ignoriert. Der einzige Ausnahmefall sind Zahlen mit "mph" dahinter. > > Wobei der traveling salesman ja nur die maxspeed werte als hilfe > nimmt um zu bestimmt wie schnell man auf der Straße wohl vorwaert > kommen mag - d.h. gewichtung der Straßen/Routen. Nicht ganz. Die Gewichtung macht die jeweilige Metrik. Wenn sich die Metrik für die Fahrtzeit/Geschwindigkeit interessiert kann sie (muss aber nicht) die maximale erlaubte Geschwindigkeit erfragen. So eine Metrik wie "kürzeste Strecke" oder "scenic tour" z.B. interessiert die Geschwindigkeit nicht. Ausserdem wird die maximale erlaubte Geschwindigkeit immer bei der Berechnung der ETA berücksichtigt. (Wenn die gewählte Metrik Fahrtzeiten berechnen kann wird das Minimum aus dieser Fahrzeit und dem Maximum genommen, sonst das Gleiche mit einer fest vorgegebenen Zeit-basierenden Metrik.) > Mich interessiert ja eher wirklich die maximalgeschwindigkeit d.h. > speedlimit um sie beim fahren auch anzuzeigen. Lässt sich im MetricsPanel einbauen. Ist dort auch schon vorgesehen. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, 25 May 2009 16:09:25 +0200, Gary68 wrote: > also ich würde es nicht explizit taggen, sondern anhand von > grenzpolygonen in einem präprozessor dem routing algorithmus zuführen. > > man kann ja feststellen, ob eine straße innerorts oder außerorts ist. in > deutschland oder in england. das ist ein klein wenig aufwändig, läuft > aber automatisch und muss nur zur datenaufbereitung gemacht werden. > nicht für jedes routing. a) Bitte mal ausrechnen was das für eine Datenmange z.B. für eine Europa-Karte ist. b) Auch daran denken, dass die Karte auf dem Navi wärend der Fahrt aktualisiert werden kann. Dabei können nicht nur Orte hinzukommen oder wachsen sondern auch Strassen sich aus dem Ort heraus verschieben und Orte kleiner werden oder verschwinden. Vorverarbeitung kann vieles, wenn man damit leben will mit einer mehrere Monate alten Karte zu fahren. Wer aber die Vorteile der Kombination von OSM als Karte und Handy-Datenflats ausnutzen will, der kann es sich nicht so leicht machen. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags für Radfahrer
Stephan Wolff schrieb: > Ein Feldweg mit Verbot für Fahrzeuge aller Art, "landwirtschaftlicher > Verkehr frei" ohne "Radfahrer frei", in den aber neu aufgestellte > Fahradwegweiser auf beiden Seiten hineinzeigen: bicycle=no, > bicycle=permissive oder bicycle=inconsistent? Und wenn die Stadt sich Mühe gibt, dann kommen solche Monster dabei heraus: http://www.addicks.net/gallery/osm/P5180069 -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Am Montag, 25. Mai 2009 12:56:09 schrieb Christian von Rotenhan: > Am 25.05.2009 11:38 Uhr, schrieb Holger Blum: > > Merkwürdig ist eben nur, dass der hinweg klaglos und schnell berechnet > wird (sind ja nur ca 50 km) und beim Rückweg diese Abstürze auftreten. > Ich kann in den Straßen die ich befahre mit JOSM und mit potlach nichts > verdächtiges finden... Hallo, ich habe das gleiche Problem mit einem Colorado 300. Es muss (auch) an der Garmin-SW liegen. Meistens sagt er Datenfehler, dann kann man immerhin noch Wegepunkte zwischensetzen, aber manchmal stürzt er ab und kann nur mit Kaltstart wiederbelebt werden, was mit dem Verlust aller nicht gesicherten eigenen Daten verbunden ist. Abhilfe ist eigentlich immer, zusätzliche Wegepunkte einzufügen. Ich vermute, dass das Navi einfach zu viele Alternativen findet. Für längere Fahrten sollte man wohl eine Karte ohne Fußwege etc benutzen, um das Datenvolumen kleiner zu halten. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Access-Tags für Radfahrer
Moin, für Radfahrer gelten zwar formal die üblichen Verkehrsregeln und Beschilderungen, aber diese sind oft lückenhaft, widersprüchlich oder praxisfern. Oft muss man intuitiv entscheiden, ob ein Weg fahrradgeeignet ist oder nicht. Allerdings ist es schwierig, das in OSM-Tags umzusetzen. Entsprechend enttäuschend verliefen meine Versuche mit Fahrradroutung auf meinem eTrex Vista mit Computerteddys Karten. Die Einstellung Fußgängerrouting brachte bessere Resultate. Wie wollen wir grundsätzlich vorgehen: die Beschilderung möglichst exakt wiedergeben und es dem Routern/Auswerteprogrammen überlassen, diese sinnvoll zu interpretieren, oder die Eignung zum Radfahren nach eigener Anschauung eingeben? Einige Beispiele: Eine fahrradgeeignete Strecke mit Radwegweisern trägt 100m vor der Einmündung ein Verbotsschild für Radfahrer mit einem Zusatzschild "Radfahrer absteigen". Der Weg führt dort recht steil bergab. In Gegenrichtung ist radfahren erlaubt, aber wegen der Steigung recht schwierig. Welche Tags gibt man dort ein, so dass der Router die schöne Strecke nicht meidet: "bicycle:forward=no", "speed:bicycle= walk" oder nur "note=Radfahrer absteigen"? Nach einem tödlichen Fahrradunfall auf einer Kanalhochbrücke sind in Kiel einige Brücken wegen zu niedriger Geländer für Radfahrer gesperrt. Einige sind als Fußwege andere als kombinierte Rad- und Fußwege mit dem Zusatz "Radfahrer absteigen" gekennzeichnet. Ein Fahrradrouter sollte trotzdem keinen großen Umweg planen um wenige Sekunden Schiebestrecke zu vermeiden. Viele Einbahnstraßen sind in Gegenrichtung für Radfahrer freigegeben. Allerdings haben alle Straßen an der Einmündung Abbiegeverbote zur Einbahnstraße ohne Zusatz "Radfahrer frei". Formal müsste man das Rad vermutlich um die Ecke schieben. Ein Feldweg mit Verbot für Fahrzeuge aller Art, "landwirtschaftlicher Verkehr frei" ohne "Radfahrer frei", in den aber neu aufgestellte Fahradwegweiser auf beiden Seiten hineinzeigen: bicycle=no, bicycle=permissive oder bicycle=inconsistent? Ein Weg, der an einem Ende als Fußweg am anderen Ende aber aber gar nicht beschildert ist Ein gepflegter, nur knapp 2m breiter Kiesweg im Ortsbereich ohne Beschilderung (vom Bauchgefühl ein Fussweg, den man vorsichtig mit dem Rad befahren kann): path, footway, footway mit bicycle=yes oder cycleway? Ein Waldweg (kein Trampelpfad, aber für mehrspurige Fahrzeuge ungeeignet) ohne Beschilderung: path, footway, footway mit bicycle=yes oder cycleway? Ein für Renn- und Tourenräder ungeeigneter Waldweg ohne Verbotsschilder: path, path mit bicycle=no oder footway Treppen auf Radstrecken (vor kurzem in einem anderen Thread), etc. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Routing - Separater Radweg und andere Probleme
Moin, nach einigem Lesen alter Diskussionen über das Erstellen eines von der Straße abgetrennten Radweges (etwa durch simplen Bordstein), bin ich noch immer nicht fähig mich zu entscheiden. Soll ich nun Radwege entlang von Straßen möglichst als eigenständige Wege (highway=cycleway) erfassen, oder sollen diese einfach nur als zusätzliches Attribut an die Straße geheftet werden (bspw. highway=secondary + cycleway=track) ? Bei straßenbegleitenden Radwegen, die nur durch eine Markierung von der Fahrbahn getrennt sind, ist es ja eindeutig mit cycleway=lane. Aber bei dem anderen Fall? Spontan würde ich mich für den Separaten entscheiden, aufgrund der Vorteile wie: -Radfahrer kann problemlos in eine Einbahnstraße abbiegen -Radfahrer hat andere Fahr/-Abbiegeregeln als Autofahrer, bspw. an Kreuzungen (naja eher uninteressant für Radroutenplaner?) -Zusätzliche Tags (Oberfläche, Breite..) für Fahrradweg verfügbar, die man so in der einfachen Form hätte nicht an die Straße (wenn Fahrradweg als Tag an highway=secondary/...) anbringen können. -Angabe des Fahrradweg-Typs; angeben was es genau ist(Gemeinsamer Fuß/-Radweg, getrennt,..) ? -weitere?? Was mich aber so verwundert ist, dass sehr viele gegen das Vorgehen des zusätzlichen Erstellen von Radwegen neben der Straße sind, warum?, welche großen Nachteile existieren denn? Meine 2. Frage: Worauf muss ich noch achten, wenn ich einen Radrouting erstellen will, also welche Probleme oder Szenarien könnte es noch geben? (mein Gott, sind hier viele ? drin..) Grüße von der Erde!!! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Moin Neue Version seit einigen Stunden für z15-z17 online mit nun leicht brauner Füllung, unterschiedlich stark je nach tracktype und zoom plus leichte Transparanz am Rand... Martin Koppenhoefer wrote: > Am 25. Mai 2009 18:33 schrieb Heiko Jacobs : >> Kann man theoretisch schon, klappt praktisch aber nicht wirklich... >> Besser nicht, wenn's anders geht... > > damit könnte man die gestrichelte Doppellinie erzeugen ohne ein 3. > weisses "Innencasing" zu benötigen, d.h. mit dem ersten Casing in > transparent würde es gehen. Ja. nennt sich mask-class in den Osmarender-styles, geht darin offenbar für Tunnel, aber bisher nur dafür. Ein weiteres Mal begegnete es mir bei der Suche nach einem unerklärbaren Fehler vor längerer Zeit. Da hatte es schon wer anderes für eine andere Anwendung auch verwenden wollen, erfolglos, hatte unerwünschte Seiteneffekte. Und auch ich spielte schon erfolglos 2x mit diesem Feature. Ist mir ehrlich gesagt zu viel fruchtlose Arbeit, die da versandet... Das gewünschte soll evtl. der nächste SVG-Standard können. Ich stöberte darin mal rum und entdeckte dort solche Strichmuster quer zu den bisherigen Strichlierungen als Nice-to-have oder so erwähnt.. MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umwelt&verkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
Am Monday 25 May 2009 schrieb Martin Koppenhoefer: > Am 25. Mai 2009 16:01 schrieb Falk Zscheile : > > Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese > > Variante? Beispielsweise im Zusammenhang mit der Auswertung durch die > > Renderer? > > wie angedeutet wird das praktisch von niemandem ausgewertet, man > generiert also zumindest derzeit unbrauchbare Daten, daher empfehle > ich das eher nicht (auch wenn es offiziell ist). > naja, fuer manchen dinge ist das schon sinnvoll so. da aber leider der alte weg mit zwei tags nicht mehr geht, muss man es wohl so machen... zumindest auf meiner TODO-liste steht die unterstuetzung schon seit geraumer zeit ;-) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
Am Monday 25 May 2009 schrieb Martin Koppenhoefer: > Hoffentlich seid Ihr nicht alle von der bisherigen Maxspeed-Debatte > abgeschreckt, aber eine kleine Frage hätte ich nochmal: im Laufe der > Diskussion hatte ich gesagt, dass man die Länder, in denen die Straßen > liegen, per Polygon durch Vorverarbeitung klären sollte. Ich bin mir > allerdings nicht ganz sicher, ob das wirklich Stand der Technik ist > (ist ja auch in anderem Zusammenhand relevant). Auf der Maxspeed-Seite > wird ausführlich beschrieben, man sollte z.B. nicht "walk" sondern > "maxspeed=UK:walk" oder "maxspeed=DE:living_street" verwenden. Ist das > wirklich notwendig? Oder reicht doch schon ein schlichtes "walk" ohne > Länderkürzel? Dasselbe gilt natürlich auf für "town" und "country". > rein technisch ist die polygon-methode zwar sicherlich machbar, aber ich wuerde das tag mit laenderkuerzel bevorzugen. das mag zwar redundant sein, aber weh tut die zusatzinfo auch nicht. desweiteren laesst sich das ganze wesentlich einfacher auswerten, finde ich... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Selbstbezug in Relation
Hallo, ich bin heute über eine Relation gestolpert, die sich selbst als Mitglied enthielt: 56873. Erst nach vielen missglückten Hochladeversuchen, die unter anderem eine Änderung an dieser Relation enthielten, bei denen JOSM einfach nichts mehr tat, habe ich diese Relation als Übeltäter ausmachen können. Mit JOSM (tested) konnte ich dann diesen Selbstbezug auflösen, JOSM (latest) lief sich immer mit 100% CPU-Last fest. Lange Rede, kurzer Sinn: Ich denke solche Endlosschleifen sind eher nicht gewollt, zumindest fällt mir kein Szenario ein, wo das sinnvoll wäre. Besteht die Möglichkeit, solche Fehler abzufangen, bevor sie in die Datenbank kommen, entweder über die API oder Plugins in den Editoren? Zumindest würde ich mir eine Warnung wünschen, daß solche Konstrukte zu Problemen führen können. Grüße, Carsten signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Am 25. Mai 2009 18:33 schrieb Heiko Jacobs : > Kann man theoretisch schon, klappt praktisch aber nicht wirklich... > Besser nicht, wenn's anders geht... damit könnte man die gestrichelte Doppellinie erzeugen ohne ein 3. weisses "Innencasing" zu benötigen, d.h. mit dem ersten Casing in transparent würde es gehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte für Österreich
Hi! Sven Geggus schrieb: > Nop wrote: > Mir ist aufgefallen, dass die Gletscher nicht da sind, die solltest Du aber > IMO schon einzeichnen. > > http://www.openstreetmap.org/?zoom=14&lat=47.09225&lon=12.29377 > http://topo.geofabrik.de/?zoom=14&lat=47.09225&lon=12.29377 Gute Idee. Sind aufgenommen. bye nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] boundary.pl v2.0 beta
hi, habe eben die erste v2 beta veröffentlicht: http://wiki.openstreetmap.org/wiki/Boundaries.pl code über meine wiki seite - diverse verbesserungen der funktionen der v1 - zusätzlich die möglichkeit, die hirarchie der boundaries auszugeben (is_in) das speicherproblem bei größeren dateien kommt wohl von den polygonen - mal sehen... ciao gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrbahnen und bicycle=no
Am Montag 25 Mai 2009 11:29:54 schrieb Markus Schaub: > Es muss ja noch nicht mal so sein, dass der Radweg dann irgendwo in einen > Park o. ä. verschwenkt. Wenn man sich zu einer Hausnummer auf der linken > Straßenseite routen lässt, dann wird der Router einen erstmal auf den > Radweg auf der rechten Seite schicken, an der Hausnummer vorbeifahren und > an der nächsten Kreuzung dann wieder auf dem Radweg zurück. Sollte man das > bemerken und direkt vom Radweg auf die andere Straßenseite wollen, ist > einem dann evtl. der Weg durch Hecken, Bäume, Zäune etc. versperrt. Wenn man sich an der Stelle auskennt wird man das Routing nicht benutzen oder ignorieren. Wenn man sich an der Stelle nicht auskennt passiert das sowieso, mit oder ohne Navi. Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auflisten aller Elementtypen...
prinzip ja - aber ! erst einmal vielen - werde ich mir ansehen. gruß Jan :-) ekkeh...@gmx.de schrieb: > Hi! > >> hat einer etwas in der schublade liegen mit dem man die vorkommenden >> pois ermitteln kann in einer OSM-datei - vielleicht mit vorgabe des >> klassenfilters > > Bin mir zwar nicht ganz sicher, was Du genau willst, aber vielleicht kann Dir > der OSM Composer weiterhelfen. Der kann: > - eine Statistik ausspucken wie oft welcher tag verwendet wurde > - bestimmte OSM Elemente nach halbwegs genauen Regeln ausfiltern und > rausschreiben. > > > bye > Nop > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auflisten aller Elementtypen...
Hi! > hat einer etwas in der schublade liegen mit dem man die vorkommenden > pois ermitteln kann in einer OSM-datei - vielleicht mit vorgabe des > klassenfilters Bin mir zwar nicht ganz sicher, was Du genau willst, aber vielleicht kann Dir der OSM Composer weiterhelfen. Der kann: - eine Statistik ausspucken wie oft welcher tag verwendet wurde - bestimmte OSM Elemente nach halbwegs genauen Regeln ausfiltern und rausschreiben. bye Nop -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Martin Koppenhoefer wrote: >> Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie >> es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... > > ja, mind. für 15 ist es m.E. klar, dass eine Behandlung ähnlich Z14 > besser aussähe (eine Linie statt 2), bei 16 und 17 bin ich mir nicht > so sicher, wobei da der weisse Hintergrund ein bisschen stört, aber > vielleicht kommt man dem ja auch anders bei. Hast Du es schonmal ohne > casing versucht? Es war vorher OHNE das weiße casing: man sah den tracktype nicht mehr, das war ja überhaupt der Anlass, dass ich das reinbastelte... ;-) Ich werde gleich mal was umbasteln in z15-z17 > Das Problem ist wohl, dass man nur hinzufügen (also > überdecken) kann, nicht weglöschen (also so was wie ne Boolsche > Subtraktion). Kann man theoretisch schon, klappt praktisch aber nicht wirklich... Besser nicht, wenn's anders geht... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umwelt&verkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
Falk Zscheile schrieb: >> Der Notlösungen sind >> mit 2 bekannt: Trennung mit Semikolon. >> amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) > > Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese > Variante? Ja: Es ist schwerer auszuwerten. Außerdem: Spätestens, wenn du einem der Dinge noch Attribute geben willst, funktioniert dein System nicht mehr. Genauso wenig kannst du z.B. mit den kürzlich vorgeschlagenen Etagen-Relationen das Restaurant in den ersten Stock setzen. Darum: Nimm zwei getrennte Nodes, ggf. innerhalb des selben building. Damit ist zwar die Information "befindet sich im selben Gebäude" schwerer zugänglich, aber die wichtigere Basisinformation leichter zugänglich. Und was ist wohl der wahrscheinlichere Anwendungsfall für eine 0815-Anwendung: "Gib mir eine Liste der Gebäude, die sowohl eine Toilette als auch eine Dusche enthalten" oder "Wo gehts zur nächsten Toilette"? > Je detaillierter man zukünftig arbeiten wird, desto häufiger wird man > Gebäude haben, die mehrere Eigenschaften besitzen, die sich nicht ohne > Tricks kombinieren lassen. Das Gebäude hat nicht mehrere Eigenschaften, sondern enthält mehrere (mehr oder weniger getrennte) Einrichtungen. Und so würde ich das auch mappen. Schon verschwinden alle potentiellen Probleme mit Zusatzattributen und bei Auswertungen. Dieser Gedanke, das im gleichen Gebäude liegende oder am selben Laternenpfahl hängende Einrichtungen sich einen Node teilen müssten, macht nur alles unnötig kompliziert. "Hängt am selben Pfahl" ist eine in der Praxis unwesentliche Information, für die man nicht das Tagging verkomplizieren sollte. Wenns wirklich interessiert, kann man ja eine Relation "same_pole" machen. ;-) Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ways_with_long_segments / Kontrollierter Luftraum eingetragen?
Hi, nachdem wir ja letzten die Diskussion zum Thema Flugrouten hatten sind jetzt noch Grenzen des kontrollierten Luftraums aufgetaucht: http://www.openstreetmap.org/browse/way/35007658 Die sind nur so grossflaechig ohne nodes das natuerlich der OSM Inspektor Meckert ;) Und auch schon eine Wiki Seite: http://wiki.openstreetmap.org/wiki/DE:Luftraum Macht das wirklich Sinn? Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte für Österreich
Nop wrote: > Die Reit- und Wanderkarte (http://topo.geofabrik.de/) wurde erweitert > und deckt jetzt die Länder Deutschland und Österreich komplett ab. Super! Fehlt eigeltich nur noch die Schweiz :) Mir ist aufgefallen, dass die Gletscher nicht da sind, die solltest Du aber IMO schon einzeichnen. http://www.openstreetmap.org/?zoom=14&lat=47.09225&lon=12.29377 http://topo.geofabrik.de/?zoom=14&lat=47.09225&lon=12.29377 Gruss Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, May 25, 2009 at 03:42:02PM +0200, marcus.wolsc...@googlemail.com wrote: > Also, für mich: > Momentan wird alles in maxspeed was keine Zahl ist konsequent > ignoriert. Der einzige Ausnahmefall sind Zahlen mit "mph" dahinter. Wobei der traveling salesman ja nur die maxspeed werte als hilfe nimmt um zu bestimmt wie schnell man auf der Straße wohl vorwaert kommen mag - d.h. gewichtung der Straßen/Routen. Mich interessiert ja eher wirklich die maximalgeschwindigkeit d.h. speedlimit um sie beim fahren auch anzuzeigen. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, May 25, 2009 at 03:07:34PM +0200, Martin Koppenhoefer wrote: > Hoffentlich seid Ihr nicht alle von der bisherigen Maxspeed-Debatte > abgeschreckt, aber eine kleine Frage hätte ich nochmal: im Laufe der > Diskussion hatte ich gesagt, dass man die Länder, in denen die Straßen > liegen, per Polygon durch Vorverarbeitung klären sollte. Ich bin mir > allerdings nicht ganz sicher, ob das wirklich Stand der Technik ist > (ist ja auch in anderem Zusammenhand relevant). Auf der Maxspeed-Seite > wird ausführlich beschrieben, man sollte z.B. nicht "walk" sondern > "maxspeed=UK:walk" oder "maxspeed=DE:living_street" verwenden. Ist das > wirklich notwendig? Oder reicht doch schon ein schlichtes "walk" ohne > Länderkürzel? Dasselbe gilt natürlich auf für "town" und "country". de:living_street ergibt sich als einziges maxspeed tag aus highway=living_street und muss nicht gesetzt werden. Ansonsten sind nicht numerische maxspeeds im moment nicht wirklich in benutzung bzw werden nicht ausgewertet ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Auflisten aller Elementtypen...
hi ! hat einer etwas in der schublade liegen mit dem man die vorkommenden pois ermitteln kann in einer OSM-datei - vielleicht mit vorgabe des klassenfilters gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hausnummern für Garmin
Moin ! hat einer von Euch schon einmal mir den Hausnummern und den zugehörigen Verbindungslinien für den Garmin experimentiert. Wie habt Ihr das umgesetzt (Overlay ?!?!) und wie sind die Erfahrungen? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
Am 25. Mai 2009 16:01 schrieb Falk Zscheile : > Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese > Variante? Beispielsweise im Zusammenhang mit der Auswertung durch die > Renderer? wie angedeutet wird das praktisch von niemandem ausgewertet, man generiert also zumindest derzeit unbrauchbare Daten, daher empfehle ich das eher nicht (auch wenn es offiziell ist). > Je detaillierter man zukünftig arbeiten wird, desto häufiger wird man > Gebäude haben, die mehrere Eigenschaften besitzen, die sich nicht ohne > Tricks kombinieren lassen. meine Erfahrung ist eher, dass man die Kombinationen weniger braucht, wenn man detaillierter arbeitet (Ausnahmen gibt es wohl trotzdem). Ein Gebäude nur mit einem Node darzustellen ist nur eine Interimslösung, wenn eine Bank z.B. einen Geldautomaten hat, kann man den POI für atm dorthinsetzen, wo der atm steht, und die Bank dorthin, wo der Eingang ist (oder der Mittelpunkt der Bank, abgesehen davon, dass hier schon atm=yes verwendet wird). Denkbar wäre so eine Art "collected-building"-relation, die die einzelnen Polygone (für EInheiten innerhalb desselben Gebäudes und evtl. auch für versch. Stockwerke) und Nodes wieder zu einem Gesamtgebäude zusammenfasst. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
Am 25. Mai 2009 16:09 schrieb Gary68 : > also ich würde es nicht explizit taggen, sondern anhand von > grenzpolygonen in einem präprozessor dem routing algorithmus zuführen. > > man kann ja feststellen, ob eine straße innerorts oder außerorts ist. in > deutschland oder in england. das ist ein klein wenig aufwändig, läuft > aber automatisch und muss nur zur datenaufbereitung gemacht werden. > nicht für jedes routing. aber doch nur, wenn sämtl. Ortschilder oder ein entspr. Tag am Weg oder ein Innerorts-Polygon explizit gemappt wurden, ansonsten kann man das nur grob abschätzen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
also ich würde es nicht explizit taggen, sondern anhand von grenzpolygonen in einem präprozessor dem routing algorithmus zuführen. man kann ja feststellen, ob eine straße innerorts oder außerorts ist. in deutschland oder in england. das ist ein klein wenig aufwändig, läuft aber automatisch und muss nur zur datenaufbereitung gemacht werden. nicht für jedes routing. ps: arbeite gerade an boundary.pl wo ich erste erfahrungen mit hirarchien sammeln werde! http://wiki.openstreetmap.org/wiki/Boundaries.pl PPS: denkbar wäre auch ein bot, der das auf osm daten direkt macht. periodischer lauf. dann würde jeder way ein oder mehrere flags oder attribute bekommen, die dann jeder router ohne preprocessing verwenden könnte. my 2cts ciao gerhard On Mon, 2009-05-25 at 15:57 +0200, marcus.wolsc...@googlemail.com wrote: > On Mon, 25 May 2009 15:52:03 +0200, Martin Koppenhoefer > wrote: > > Am 25. Mai 2009 15:42 schrieb : > >> On Mon, 25 May 2009 15:07:34 +0200, Martin Koppenhoefer > > > >> Für die Maxspeed-Werte gibt es eine Default-Implementierung welche > >> versucht zu erkennen ob man innerhalb oder ausserhalb einer Ortschaft > >> ist und dann abhängig vom highway-Tag eine maximale Geschwindigkeit > >> wählt. > > > > anhand von was erkennst Du in der Default-Logik, ob Du innerhalb oder > > ausserhalb bist? Wäre das explizite Mappen von impliziten > > Gegebenheiten (also innerhalb, ausserhalb) hier nicht sehr hilfreich? > > Von Ländern oder Orten? > > Ort: > Es gibt 2 mögliche Adress-Datenbanken (Plugins wie alles andere in TS > halt). > Diese kennen entweder das Polygon eines Ortes oder Mittelpunkt > und angenommenen Radius. > Eine Unterscheidung zwischen Orts-Polygon für Adress-Suche und > für Verkehrs-Regeln findet (noch) nicht statt. > > Eine Suche ob ein als Ortschaft getaggter Weg/Node in einem > bestimmten Umkreis vorhanden ist wären viel, viel zu aufwendig > nur um wärend der Auswertung einer Metrik in der Routen-Berechnung > die maximale erlaubte Geschwindigkeit für ein Wegstück, was am > Ende warscheinlich eh nicht Teil der Router wird zu ermitteln. > > Marcus > > ___ > 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] amenity=shower/toilets und JOSM
On Mon, 25 May 2009, Falk Zscheile wrote: Der Notlösungen sind mit 2 bekannt: Trennung mit Semikolon. amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese Variante? Beispielsweise im Zusammenhang mit der Auswertung durch die Renderer? Bei tourism=hotel und amenity=restaurant ist es ja auch mehr oder weniger entwicklungsgeschichtlicher Zufall, dass es hier zu keiner unzulässigen Kombination kam. Auch ein hotel könnte ich mir sehr gut als amenity vorstellen. Eigentlich ist das Semikolon wohl der offizielle Weg. Aber außer TagWatch wertet das keiner aus. Da kann es noch so offiziell sein, wenn es keiner nutzt hilft das nicht. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
Am 25. Mai 2009 15:47 schrieb Martin Koppenhoefer : > Am 25. Mai 2009 13:51 schrieb Falk Zscheile : >> auf Campingplätzen sind die Sanitärgebäude oft eine Kombination aus >> amenity=toilets und amenity=shower. Unter JOSM kann ich beides nicht >> gleichzeitig in einer node abbilden. Ist dieses Verhalten gewollt? > wieso nur unter JOSM? Ist das nicht allgemein unmöglich, 2 tags mit > demselben namen zu setzen, mind. seit API 0.6? Das wusste ich nicht. Deshalb habe ich es nur auf den Fall bezogen, für den ich mir sicher war. > Der Notlösungen sind > mit 2 bekannt: Trennung mit Semikolon. > amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese Variante? Beispielsweise im Zusammenhang mit der Auswertung durch die Renderer? Bei tourism=hotel und amenity=restaurant ist es ja auch mehr oder weniger entwicklungsgeschichtlicher Zufall, dass es hier zu keiner unzulässigen Kombination kam. Auch ein hotel könnte ich mir sehr gut als amenity vorstellen. Je detaillierter man zukünftig arbeiten wird, desto häufiger wird man Gebäude haben, die mehrere Eigenschaften besitzen, die sich nicht ohne Tricks kombinieren lassen. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, 25 May 2009 15:52:03 +0200, Martin Koppenhoefer wrote: > Am 25. Mai 2009 15:42 schrieb : >> On Mon, 25 May 2009 15:07:34 +0200, Martin Koppenhoefer > >> Für die Maxspeed-Werte gibt es eine Default-Implementierung welche >> versucht zu erkennen ob man innerhalb oder ausserhalb einer Ortschaft >> ist und dann abhängig vom highway-Tag eine maximale Geschwindigkeit >> wählt. > > anhand von was erkennst Du in der Default-Logik, ob Du innerhalb oder > ausserhalb bist? Wäre das explizite Mappen von impliziten > Gegebenheiten (also innerhalb, ausserhalb) hier nicht sehr hilfreich? Von Ländern oder Orten? Ort: Es gibt 2 mögliche Adress-Datenbanken (Plugins wie alles andere in TS halt). Diese kennen entweder das Polygon eines Ortes oder Mittelpunkt und angenommenen Radius. Eine Unterscheidung zwischen Orts-Polygon für Adress-Suche und für Verkehrs-Regeln findet (noch) nicht statt. Eine Suche ob ein als Ortschaft getaggter Weg/Node in einem bestimmten Umkreis vorhanden ist wären viel, viel zu aufwendig nur um wärend der Auswertung einer Metrik in der Routen-Berechnung die maximale erlaubte Geschwindigkeit für ein Wegstück, was am Ende warscheinlich eh nicht Teil der Router wird zu ermitteln. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
Am 25. Mai 2009 15:42 schrieb : > On Mon, 25 May 2009 15:07:34 +0200, Martin Koppenhoefer > Für die Maxspeed-Werte gibt es eine Default-Implementierung welche > versucht zu erkennen ob man innerhalb oder ausserhalb einer Ortschaft > ist und dann abhängig vom highway-Tag eine maximale Geschwindigkeit > wählt. anhand von was erkennst Du in der Default-Logik, ob Du innerhalb oder ausserhalb bist? Wäre das explizite Mappen von impliziten Gegebenheiten (also innerhalb, ausserhalb) hier nicht sehr hilfreich? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
Am 25. Mai 2009 13:51 schrieb Falk Zscheile : > Moin, > > auf Campingplätzen sind die Sanitärgebäude oft eine Kombination aus > amenity=toilets und amenity=shower. Unter JOSM kann ich beides nicht > gleichzeitig in einer node abbilden. Ist dieses Verhalten gewollt? > Gibt es ein eigenes tag für Sanitärgebäude? > Gruß, Falk wieso nur unter JOSM? Ist das nicht allgemein unmöglich, 2 tags mit demselben namen zu setzen, mind. seit API 0.6? Der Notlösungen sind mit 2 bekannt: Trennung mit Semikolon. amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) oder setzen von 2 Nodes: einen mit Toilets, einen mit Shower. (ist praktisch problemlos). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, 25 May 2009 15:07:34 +0200, Martin Koppenhoefer wrote: > Hoffentlich seid Ihr nicht alle von der bisherigen Maxspeed-Debatte > abgeschreckt, aber eine kleine Frage hätte ich nochmal: im Laufe der > Diskussion hatte ich gesagt, dass man die Länder, in denen die Straßen > liegen, per Polygon durch Vorverarbeitung klären sollte. Ich bin mir > allerdings nicht ganz sicher, ob das wirklich Stand der Technik ist > (ist ja auch in anderem Zusammenhand relevant). Auf der Maxspeed-Seite > wird ausführlich beschrieben, man sollte z.B. nicht "walk" sondern > "maxspeed=UK:walk" oder "maxspeed=DE:living_street" verwenden. Ist das > wirklich notwendig? Oder reicht doch schon ein schlichtes "walk" ohne > Länderkürzel? Dasselbe gilt natürlich auf für "town" und "country". > > Gruß Martin > Hallo Martin, so eine Frage wäre wohl auf der "routing" oder zumindest der "dev" Mailing-Liste besser aufgehoben. Zumal du hier nur die deutschsprachigen Entwickler und von denen auch nur einen Teil erreichst. Also, für mich: Momentan wird alles in maxspeed was keine Zahl ist konsequent ignoriert. Der einzige Ausnahmefall sind Zahlen mit "mph" dahinter. Für nationale Verkehrsregeln und damit auch die Default-Werte für Maxspeed sind bei mir die Klassen http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=TrafficRuleManager und http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=Country zuständig. Diese versuchen für tausende angefragte Strassen pro Sekunde jeweils möglichst schnell zu bestimmen in welchem Land sie vollständig oder teilweise liegen. Die Auswertung des Grenzpolygons ist dabei der letzte Rückfall-Kandidat und die aufwendigste Methode. Eine Vorverarbeitung findet für maxspeed nich statt. Du kannst jederzeit "edit in JOSM" clicken und was du bekommst auch hochladen ohne lauter computer-generierte Tags mit in die DB zu pusten. (Die ich lokal ja auch speichen müsste und die Karte ist schon viel zu gross auf der Platte.) Für die Maxspeed-Werte gibt es eine Default-Implementierung welche versucht zu erkennen ob man innerhalb oder ausserhalb einer Ortschaft ist und dann abhängig vom highway-Tag eine maximale Geschwindigkeit wählt. Die einzelnen Länder können dabei diese Default-Logik nutzen oder eine eigene (für Sonderfälle) besitzen. (z.B. abhängig von lit=yes/true/1 oder von dem Wert eines "lanes"-tags) Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Am 25. Mai 2009 11:17 schrieb Heiko Jacobs : > Martin Koppenhoefer wrote: >> Als Alternative fällt mir nur ein, wie in den höheren >> Zoomstufen eine einzige braune Linie für den Track zu rendern (alles >> insgesamt schmaler, z.B. weisse Linie, 40% Alpha, 0.8px, darüber >> braune Linie 0.6px und keine 3. weisse Linie mehr). > > Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie > es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... ja, mind. für 15 ist es m.E. klar, dass eine Behandlung ähnlich Z14 besser aussähe (eine Linie statt 2), bei 16 und 17 bin ich mir nicht so sicher, wobei da der weisse Hintergrund ein bisschen stört, aber vielleicht kommt man dem ja auch anders bei. Hast Du es schonmal ohne casing versucht? Das Problem ist wohl, dass man nur hinzufügen (also überdecken) kann, nicht weglöschen (also so was wie ne Boolsche Subtraktion). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] an die Routing- und sonstigen Entwickler
Hoffentlich seid Ihr nicht alle von der bisherigen Maxspeed-Debatte abgeschreckt, aber eine kleine Frage hätte ich nochmal: im Laufe der Diskussion hatte ich gesagt, dass man die Länder, in denen die Straßen liegen, per Polygon durch Vorverarbeitung klären sollte. Ich bin mir allerdings nicht ganz sicher, ob das wirklich Stand der Technik ist (ist ja auch in anderem Zusammenhand relevant). Auf der Maxspeed-Seite wird ausführlich beschrieben, man sollte z.B. nicht "walk" sondern "maxspeed=UK:walk" oder "maxspeed=DE:living_street" verwenden. Ist das wirklich notwendig? Oder reicht doch schon ein schlichtes "walk" ohne Länderkürzel? Dasselbe gilt natürlich auf für "town" und "country". Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
"Marc Schütz" wrote: >> Für z12-z14 bin ich zum "Mapnik-Stil" übergegangen, da man da anders >> gar nix mehr erkannt hat und nix zu optimieren ging... > > Diesen Stil finde ich generell ziemlich gut; die Tracks und auch > die Residentials sind bei niedrigem Zoom viel besser zu erkennen. Wenn ich genug Zeit dafür habe, werde ich das wohl für z11 abwärts weiter entwickeln. > Was meiner Meinung nach nicht ganz so schön ist sind die Fuß- und Radwege > (besonders letztere): Ja, da ist mein eigenes Empfinden für's Optimum auch noch nicht voll erreicht... > Das sieht alles aus wie ein hellgrüner Brei, > deswegen vermute ich, dass es an der grellen Farbe liegt. Ich hatte die Farben aus denen der flächigen Pastellfarben der Wege weiter entwickelt, nur mit mehr Sättigung im IHS-(HSV)-System, aber das ist es wohl noch nicht so ganz... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umwelt&verkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Moin Stephan > meiner Meinung nach ist die Karte durch deine Änderungen deutlich > übersichtlicher geworden. Danke, finde ich ja auch ;-) > Für z15 und z16 wirken die Tracks noch etwas > überbetont und könnten schmaler sein. Bei z17 sieht es wieder gut aus. Bin schon ein wenig am experimentieren, aber sicher nicht zu einem Ergebnis heute, da eigentlich anderes zu tun... >> Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie >> es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... > > In höheren Zoomstufen bevorzuge ich die flächenhafte Zeichnung der Wege > von Osmarender. Ich ja eigentlich auch... > Da wir schon über das Kartendesign in osmarender sprechen: Die > Darstellung der Bahnlinien finde ich unglücklich. Im Ausschnitt > http://www.openstreetmap.org/?lat=54.334&lon=10.2105&zoom=14&layers=0B00FTF > erkennt man sie Museumsbahnstrecke sofort, bei den normalen Bahnstrecken > muss man genau schauen, welche Straßen durch Querstriche zu Gleisen > werden. Mapnik stellt Bahnstrecken geschickter dar. Steht eh schon als einer der nächsten Punkte auf meiner ToDo-Liste ;-) Darf es eine Mapnik-ähnliche Darstellung sein? Die kenne ich auch von deutschen Karten. Wie weit ist die international verbreitet gegenüber der jetzigen? MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umwelt&verkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Hallo Heiko, meiner Meinung nach ist die Karte durch deine Änderungen deutlich übersichtlicher geworden. Für z15 und z16 wirken die Tracks noch etwas überbetont und könnten schmaler sein. Bei z17 sieht es wieder gut aus. >> Als Alternative fällt mir nur ein, wie in den höheren >> Zoomstufen eine einzige braune Linie für den Track zu rendern > > Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie > es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... In höheren Zoomstufen bevorzuge ich die flächenhafte Zeichnung der Wege von Osmarender. Bei z=13-z14 erkennt man kleine Wege auf der Mapnikkarte einfacher, dafür wirkt sie unruhiger. Da wir schon über das Kartendesign in osmarender sprechen: Die Darstellung der Bahnlinien finde ich unglücklich. Im Ausschnitt http://www.openstreetmap.org/?lat=54.334&lon=10.2105&zoom=14&layers=0B00FTF erkennt man sie Museumsbahnstrecke sofort, bei den normalen Bahnstrecken muss man genau schauen, welche Straßen durch Querstriche zu Gleisen werden. Mapnik stellt Bahnstrecken geschickter dar. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] amenity=shower/toilets und JOSM
Moin, auf Campingplätzen sind die Sanitärgebäude oft eine Kombination aus amenity=toilets und amenity=shower. Unter JOSM kann ich beides nicht gleichzeitig in einer node abbilden. Ist dieses Verhalten gewollt? Gibt es ein eigenes tag für Sanitärgebäude? Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: Schlüssel-Klartext über den Eigenschaften
Moin ! wenn ich mich richtig erinnere, dann war der Klartext Tags bisher immer UNTER den Key-Value-Einträgen. Jetzt sind diese darüber und müssen immer nach oben geschoben werden. Unten fand ich das besser ! Seht ihr das genauso und sollte das nicht wieder geändert werden !? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Am 25.05.2009 11:38 Uhr, schrieb Holger Blum: Christian von Rotenhan schrieb: Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Das passiert bei meinem Vista HCx leider auch recht häufig, bevorzugt bei längeren Strecken, und liegt wohl am zu kleinen Arbeitsspeicher des Geräts. Ich habe verschiedene Karten ausprobiert (Computerteddy, All-in-one, selbst mit mkgmap erstellte), bei allen tritt das Problem auf. Vielleicht beherrscht mkgmap ja auch noch nicht alle Eigenheiten des Garmin-Datenformats, so dass dadurch noch Fehler entstehen können? Selbst Versuche kurz vor der Haustür ( Schweinfurt - Raßdörferstr.) noch den Rest Routen zu lassen scheitern Das habe ich auch schon gehabt, ist aber die Ausnahme. Ich lasse das Navi oft mitlaufen wenn ich kurze Strecken in bekanntem Gebiet unterwegs bin um einen Eindruck von der Routingqualität zu bekommen, da klappt es normalerweise recht gut. Aber dafür brauche ich eben kein Navi :-/ Ich hoffe ja, dass "Plan B" von Openmoko ein taugliches Opensource-Navi wird, dann gäbe es wohl einige Probleme weniger. Viele Grüße, Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Merkwürdig ist eben nur, dass der hinweg klaglos und schnell berechnet wird (sind ja nur ca 50 km) und beim Rückweg diese Abstürze auftreten. Ich kann in den Straßen die ich befahre mit JOSM und mit potlach nichts verdächtiges finden... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Holger Blum wrote: > Ich hoffe ja, dass "Plan B" von Openmoko ein taugliches Opensource-Navi > wird, dann gäbe es wohl einige Probleme weniger. Tja, der wasserdichte Linux PDA mit GPS-chip. Gibts leider noch nicht. Würd ja auch schon reichen, wenn jemand sowas auf vorhandene Navi-Hardware portieren würde. Die Outdoor Garmins sind AFAIK leider nicht Linuxbasiert. Sven -- "We just typed make" (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Christian von Rotenhan schrieb: > Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen > mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von > dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, > dann wird diese Route berechnet bis 100% und dann erfolgt ein > totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben > lässt (Das Berechnen Bild hängt sich bei 100% auf) Das passiert bei meinem Vista HCx leider auch recht häufig, bevorzugt bei längeren Strecken, und liegt wohl am zu kleinen Arbeitsspeicher des Geräts. Ich habe verschiedene Karten ausprobiert (Computerteddy, All-in-one, selbst mit mkgmap erstellte), bei allen tritt das Problem auf. Vielleicht beherrscht mkgmap ja auch noch nicht alle Eigenheiten des Garmin-Datenformats, so dass dadurch noch Fehler entstehen können? > Selbst Versuche kurz vor der Haustür ( Schweinfurt - Raßdörferstr.) noch > den Rest Routen zu lassen scheitern Das habe ich auch schon gehabt, ist aber die Ausnahme. Ich lasse das Navi oft mitlaufen wenn ich kurze Strecken in bekanntem Gebiet unterwegs bin um einen Eindruck von der Routingqualität zu bekommen, da klappt es normalerweise recht gut. Aber dafür brauche ich eben kein Navi :-/ Ich hoffe ja, dass "Plan B" von Openmoko ein taugliches Opensource-Navi wird, dann gäbe es wohl einige Probleme weniger. Viele Grüße, Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrbahnen und bicycle=no
Joerg Fischer schrieb: > Am Freitag 22 Mai 2009 14:43:33 schrieb Martin Koppenhoefer: > > > er weiss ja, wohin Du fahren willst. Das kannst Du beim Mappen des > > Wegs nicht vorhersagen. Wenn der Radweg dorthin führt, wo Du nicht > > hinradeln willst (z.B. willst Du links abbiegen, oder Du willst auf > > Ok, das ist ein Argument, das ich an relevanten Stellen beachte. Wenn ich in > mich gehe hab ich das in hiesiger Umgebung *so* auch noch nicht gesehen. > (Also, dass ein Radweg straßenbegleitend anfängt und dann unvermittelt und > ohne eine weitere Möglichkeit zurück auf die Straße zu kommen abbiegt.) Es muss ja noch nicht mal so sein, dass der Radweg dann irgendwo in einen Park o. ä. verschwenkt. Wenn man sich zu einer Hausnummer auf der linken Straßenseite routen lässt, dann wird der Router einen erstmal auf den Radweg auf der rechten Seite schicken, an der Hausnummer vorbeifahren und an der nächsten Kreuzung dann wieder auf dem Radweg zurück. Sollte man das bemerken und direkt vom Radweg auf die andere Straßenseite wollen, ist einem dann evtl. der Weg durch Hecken, Bäume, Zäune etc. versperrt. Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Am 25.05.2009 11:24 Uhr, schrieb Sven Geggus: Christian von Rotenhan wrote: Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Ein bekanntes Problem, das manchmal bei längeren Routen auftritt. Christoph, der die all-in-one Graminkarte macht ist in Urlaub und kann vielleicht mehr dazu sagen. Hast Du mal pobiert zu Hause einen Wegpunkt zu setzen und Dich zu diesem Wegpunkt routen zu lassen? Das mit den Adressen ist ja bekanntlich noch etwas holprig. Sven Tja, genau das hab ich gemacht, In der Regel vermeide ich die Adressen suche und navigiere nur Wegpunkte an ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Christian von Rotenhan wrote: > Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen > mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von > dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, > dann wird diese Route berechnet bis 100% und dann erfolgt ein > totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben > lässt (Das Berechnen Bild hängt sich bei 100% auf) Ein bekanntes Problem, das manchmal bei längeren Routen auftritt. Christoph, der die all-in-one Graminkarte macht ist in Urlaub und kann vielleicht mehr dazu sagen. Hast Du mal pobiert zu Hause einen Wegpunkt zu setzen und Dich zu diesem Wegpunkt routen zu lassen? Das mit den Adressen ist ja bekanntlich noch etwas holprig. Sven -- "We just typed make" (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Martin Koppenhoefer wrote: > Als Alternative fällt mir nur ein, wie in den höheren > Zoomstufen eine einzige braune Linie für den Track zu rendern (alles > insgesamt schmaler, z.B. weisse Linie, 40% Alpha, 0.8px, darüber > braune Linie 0.6px und keine 3. weisse Linie mehr). Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umwelt&verkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Sven Geggus wrote: > Heiko Jacobs wrote: >> Sei waren früher mal innen weiß. Dann hat jemand dran rumgeschraubt >> und sie hatten innen einen hellstbraunen oder hellstgrünen (bei surface= >> grass) Strich. > > Das war ne Änderung von jemandem hier auf der Liste. Da das besser > ausgesehen hatte als vorher hatte ich das seinerzeit eingecheckt. An der Diskussion war ich damals glaub sogar mit beteiligt. Ich meine, ich hätte damals schon wegen der Nichterkennbarkeit des tracktyps rumgenölt ;-) Geholfen hat das bzgl. tracktype-Unterscheidbarkeit aber nicht viel... Mag an meinem Laptop-LCD liegen... Aber das Problem hätte ich dan sicher nicht alleine... Da die tracks den Leuten offenbar nun zu weiß sind, könnte ich das alte hellstbraun ja wieder ausgraben und zusätzlich einbauen und/oder Transparenzen, schaun mer mal, wie's wirkt. Aber vielleicht erst in paar Tagen, wollte eigentlich wegen anderer wegen OSM schon aufgeschobener Terminsachen mal einen OSM-suchtfreien Tag versuchen ;-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umwelt&verkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
> Für z12-z14 bin ich zum "Mapnik-Stil" übergegangen, da man da anders > gar nix mehr erkannt hat und nix zu optimieren ging... Diesen Stil finde ich generell ziemlich gut; die Tracks und auch die Residentials sind bei niedrigem Zoom viel besser zu erkennen. Was meiner Meinung nach nicht ganz so schön ist sind die Fuß- und Radwege (besonders letztere): http://www.openstreetmap.org/?lat=49.895&lon=10.9201&zoom=14&layers=0B00FTF Das sieht alles aus wie ein hellgrüner Brei, man muss sich schon sehr konzentrieren, um die einzelnen Wege auseinanderhalten zu können. Wenn man rauszoomt, wirds noch schlimmer. Bei den Feldwegen (z.B. weiter nördlich in dem großen Kleingartengebiet vor Hallstadt) kommt mir das nicht so schlimm vor, deswegen vermute ich, dass es an der grellen Farbe liegt. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] All-in-One Deutschland - mit Garmin eTrex
Hallo, ich lese inzwischen regelmäßig mit, manches ist mir etwas hoch, aber als Hobby Mapper muss ich ja auch nicht alles wissen. Ich teste aber gerne immer wieder die Routigfunktion auf meinem Garmin eTrex legend Cx und da ist All-in-One Karte eigentlich super, aber... Jetzt hab ich aber mit der All-in-One Karte auf meinem Garmin eTrex ein Problem. Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Selbst Versuche kurz vor der Haustür ( Schweinfurt - Raßdörferstr.) noch den Rest Routen zu lassen scheitern Bei anderen Strecken ist mir das in den Osterferien in NRW auch schon mal passiert, dann hatte ich eine neuere Karte da ging's. Die Karte die ich jetzt verwende ist vom 22.05 hat jemand einen Tipp was da los ist? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Hi >die erste weiße Linie müsste die transparente sein, d.h. die >Transparenz muss sich nirgends durcharbeiten. Das könnte vielleicht schon helfen. Die optische Überbewertung der schlechteren Tracktypes vor dunklem Hintergrund kommt m.E. im wesentlichen durch den höheren Weißanteil im Rand. -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] All-in-One Deutschland - mit Garmin eTrex
Hallo, ich lese inzwischen regelmäßig mit, manches ist mir etwas hoch, aber als Hobby Mapper muss ich ja auch nicht alles wissen. Ich teste aber gerne immer wieder die Routigfunktion auf meinem Garmin eTrex legend Cx und da ist All-in-One Karte eigentlich super, aber... Jetzt hab ich aber mit der All-in-One Karte auf meinem Garmin eTrex ein Problem. Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Selbst Versuche kurz vor der Haustür ( Schweinfurt - Raßdörferstr.) noch den Rest Routen zu lassen scheitern Bei anderen Strecken ist mir das in den Osterferien in NRW auch schon mal passiert, dann hatte ich eine neuere Karte da ging's. Die Karte die ich jetzt verwende ist vom 22.05 hat jemand einen Tipp was da los ist? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Heiko Jacobs wrote: > Sei waren früher mal innen weiß. Dann hat jemand dran rumgeschraubt > und sie hatten innen einen hellstbraunen oder hellstgrünen (bei surface= > grass) Strich. Das war ne Änderung von jemandem hier auf der Liste. Da das besser ausgesehen hatte als vorher hatte ich das seinerzeit eingecheckt. Sven -- "We don't know the OS that God uses, but the Vatican uses Linux" (Sister Judith Zoebelein, Vatican Webmaster) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
