Re: [Talk-de] Im Bau befindliche Brücke
Am 03.09.10 07:35, schrieb bkmap: Tags wie construction:awarding_authority wären dann leicht möglich Wer/was soll das sein? Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVkarte - Situation verbessern?
Am 02.09.10 23:11, schrieb C. Brause: Am 30.08.2010 21:17, schrieb Hanno Böck: Hi, Ich halte die ÖPNV-Karte ja gerade für eines der Killerfeatures von OSM (zumindest eines von denen die ich selber sehr oft benutze). Leider scheint es ja grad öfters Probleme zu geben. Deshalb, da ich auch nicht weiss wer dafür zuständig ist: - Woran hakt es? - Wird Hilfe gebraucht um die Situation zu verbessern? - Braucht es bessere Hardware? Ich würde gern dazu beitragen, dass das zuverlässiger tut. Da winkt einer mit Hardware und keiner reagiert... Ich kann da leider auch nichts zu sagen. Melde sich jemand, bevor er sichs anders überlegt! ;-) Darf der arme Melchior Moos nicht auch mal Urlaub machen? Er wird sich mit Sicherheit hier oder beim edlen Spender melden. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Perl Relation Analyzer
Am 02.09.10 17:57, schrieb Rainer Kluge: Da der Relation Analyzer auf http://betaplace.emaitie.de/webapps.relation-analyzer/ offenbar ständig überlastet ist, habe ich mir auf die Schnelle ein Perl-Skript gebastelt, welches mir im wesentlichen die selbe Funktionalität bietet: Zusammenfassen der Wege zu zusammenhängenden Segmenten, Hinweise auf grobe Fehler, Erzeugen eines GPX-Files. Bevor ich das Skript weiter perfektioniere, wollte ich hier mal nachfragen, ob es ein vergleichbares Skript schon irgendwo zum Herunterladen gibt, wenn ja, wo? Ich bastel auch gerade an einer offline-Lösung zur Erzeugung von zusammenhängenden gpx-files. Leider kann ich programmiertechnisch nur mit Visual Basic unter Windows dienen :-( Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Perl Relation Analyzer
Am 02.09.10 19:21, schrieb Gary68: "Relation check" im Wiki Kann der auch gpx-Ausgabe? Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] htc-Smartphone mit osm
Stephan Knauss wrote: > schöne Zusammenfassung. Willst du das nicht ins Wiki reinkopieren? > Wäre schade wenn das in den Mailarchiven untergeht. Der überwiegende Teil ist schon länger im Wiki. Dort habe ich meine Tipps nämlich her. :-) Zumindest der Teil mit den harten, nachprüfbaren Fakten. Meine persönliche Meinung, Vergleich und Wertung ist IMHO im Wiki nicht gut aufgehoben. Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
Am 02.09.2010 10:59, schrieb M∡rtin Koppenhoefer: > steht doch oben: > construction=motorway bzw. residential ok. Und was ist nun mit Objekten, die keine Straßen sind? Das war mein Einwurf weiter oben: >>> Eine Sportstätte wird erschlossen und gebaut - mein Tagging für alle >>> Bestandteile inclusive Parkplätze und Zufahrtswege: access=no, >>> construction=yes construction:period und vielleicht ergänende Tags wie construction:awarding_authority wären dann leicht möglich und auch für jedes Objekt benutzbar, sogar in einer Relation. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche OSM-Technik-HowTos
Am 02.09.2010 22:10, schrieb Benjamin John: Am 01.09.2010 22:39, schrieb Benjamin John: Ich glaube ich bin einen Schritt weiter, die zeitliche Differenz zwischen dem Download-File und dem was ich der state.txt eingetragen habe war wohl zu kurz gewählt (ca. 12 Std) Nach meinen heutigen Versuchen denke ich, daß ich das Problem erkannt habe: nach der Erstladen der sachsen.osm.bz2 habe ich den Startzeitpunkt für den Download der state.txt wohl zu klein gewählt, nämlich die im Wiki erwähnten zwölf Stunden. Das sollte eigentlich nix ändern. Der Zeitpunkt gibt an, welche OSC Dateien Osmosis herunterlädt und mittels osm2pgsql auf den bestehenden Datenbestand anwendet. Das Alter des Datenbestandes spielt dabei keine Rolle. Das Datum im State-File kann sowohl weit vor dem Datenbestand liegen (es werden in diesem Fall Datensätze zum alten Stand zurückgesetzt) als auch weit hinter dem Datenbestand (in diesem Fall werden Datensatzänderungen übersprungen). Allerdings darf man die nicht am Dateidatum festmachen. Die Datei hat regelmäßig eine Erstellungszeit von 10:xx (wobei ich nicht mal weiß, welche Zeitzone hier zum tragen kommt) aber der jüngste Eintrag in der Datei ist vom Vortag 19:xxZ (zumindest so ungefähr). Das macht also eine Lücke von ca. drei Stunden, die wohl offensichtlich nie mit den diffs gefüllt werden kann, wenn die Erstellung eines nodes, ways, ... in diesen Zeitraum fällt. Das würde sich von selbst lösen, sobald die entsprechenden nodes erneut verändert werden. Da die Datenbank keine Historie speichert, würden die neuen Werte einfach übernommen. Ich weiß nun nicht, ob die Differenz beim planet-file anders ist, aber im Fall der kleine Dateien kann man wohl das mindestens bei "Hierzu sollte vom Veröffentlichungsdatum des Planet-Dumps noch mindestens ein halber Tag abgezogen werden" nicht genug betonen Gerne kannst du die Angabe auf "einen Tag" ändern. Der halbe Tag ist ein reiner Schätz-Wert. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVkarte - Situation verbessern?
Am 30.08.2010 21:17, schrieb Hanno Böck: Hi, Ich halte die ÖPNV-Karte ja gerade für eines der Killerfeatures von OSM (zumindest eines von denen die ich selber sehr oft benutze). Leider scheint es ja grad öfters Probleme zu geben. Deshalb, da ich auch nicht weiss wer dafür zuständig ist: - Woran hakt es? - Wird Hilfe gebraucht um die Situation zu verbessern? - Braucht es bessere Hardware? Ich würde gern dazu beitragen, dass das zuverlässiger tut. Da winkt einer mit Hardware und keiner reagiert... Ich kann da leider auch nichts zu sagen. Melde sich jemand, bevor er sichs anders überlegt! ;-) LG Christian ___ 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] Projekt DE des Monats - Tankstellen
Am 01.09.2010 12:51, schrieb Garry:
Am 01.09.2010 09:10, schrieb Jan Tappenbeck:
fuel_electricity ("Steckdose")
* nodes: 30
* ways: 1
Diese aber bitte vollkommen getrennt von einer normalen Tankstelle!
Sonst werden die Tankstellen-POIs auf allen bestehenden Anwendungen die
nicht nach der Sorte unterscheiden (derzeit wohl die meisten) wertlos wenn
jede Tank-Steckdose als Tankstelle auftaucht.
Auch denke ich dass Ladestation an der normalen Tankstelle ehr die
Ausnahme bleiben wird.
Da reicht doch schon als Unterscheidung, zu gucken, ob eine Tankstelle
(ausschließlich) fuel:electricity=yes dran hat. Wenn nicht, ist es
vermutlich eine "normale, herkömmliche" Tankstelle. Wer trägt schon eine
Ladesäule lediglich als Tankstelle ohne Zusatz ein?
Für alle herkömmlichen Tankstellenanwendungen also:
amenity=fuel (& fuel:electricity) => Tanke
amenity=fuel & fuel:electricity=yes ohne weiteres fuel:xy=yes => keine Tanke
Ich hatte das Thema an anderer Stelle auch schon angesprochen, weil ich
das auch zumindest Kritisch sehe.
Könnte man auf der Tankstellen-Karte zumindest Markieren, ob überhaupt
fuel:xy=yes gesetzt wurde. Das könnte dem Problem durch mehr Daten
entgegenwirken. Ich würde zumindest mal gucken, was so angeboten ist,
hab aber keine Lust extra per Hand jede Tanke zur prüfen, ob da was fehlt.
LG
Christian
P.S.: Ich finde die Monatsidee super! Vielleicht ja irgenwann mit
vorheriger Abstimmung, was Thema des Monats ist. (Finde Tankstellen aber
schonmal gut!)
Garry
___
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] Deutsche OSM-Technik-HowTos
Am 01.09.2010 22:39, schrieb Benjamin John: > Ich glaube ich bin einen Schritt weiter, die zeitliche Differenz > zwischen dem Download-File und dem was ich der state.txt eingetragen > habe war wohl zu kurz gewählt (ca. 12 Std) Nach meinen heutigen Versuchen denke ich, daß ich das Problem erkannt habe: nach der Erstladen der sachsen.osm.bz2 habe ich den Startzeitpunkt für den Download der state.txt wohl zu klein gewählt, nämlich die im Wiki erwähnten zwölf Stunden. Allerdings darf man die nicht am Dateidatum festmachen. Die Datei hat regelmäßig eine Erstellungszeit von 10:xx (wobei ich nicht mal weiß, welche Zeitzone hier zum tragen kommt) aber der jüngste Eintrag in der Datei ist vom Vortag 19:xxZ (zumindest so ungefähr). Das macht also eine Lücke von ca. drei Stunden, die wohl offensichtlich nie mit den diffs gefüllt werden kann, wenn die Erstellung eines nodes, ways, ... in diesen Zeitraum fällt. Ich weiß nun nicht, ob die Differenz beim planet-file anders ist, aber im Fall der kleine Dateien kann man wohl das mindestens bei "Hierzu sollte vom Veröffentlichungsdatum des Planet-Dumps noch mindestens ein halber Tag abgezogen werden" nicht genug betonen Benajmin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO steht wieder still
On 02.09.2010 21:30, Frederik Ramm wrote: Hallo, Weil ich keine Lust hab, dass wenn ich damit aufhoere - sprich beim Split odbl/CCBYSA jemand die Karte weiterbenutzt - jemand den Style fuer Daten der odbl Datenbank verwendet. Ganz einfach. Evtl mache ich dass selber, oder aber die Velomap gibt es dann nur noch fuer CCBYSA basierte Kartendaten. Non-Commercial moechte ich prinzipiell aber nicht verbieten. Immerhin stecken da Monate an Arbeit drinnen - und die zu 99.9% nur von mir. Ich verstehe das nicht ganz, vermutlich, weil ich mich mit Garminkarten im Detail nicht auseinandergesetzt habe. Es gibt drei denkbare Faelle: 1. Der Style geht direkt in die erzeugte Karte ein (die Karte ist ein abgeleitetes Werk von, unter anderem, dem Style). 2. Der Style ist eigenstaendig und wird mit auf das Garmin-Geraet draufkopiert. 3. Der Style ist ein Algorithmus, der bei der Herstellung der Karte gebraucht wird, aber 1./2. treffen nicht zu. Wenn der Style CC-BY-SA ist, so kann die Karte derzeit in den Faellen 1-3 veroeffentlicht werden. Nach einem Wechsel zur ODbL kann die Karte nur noch in den Faellen 2-3 veroeffentlicht werden. Wenn der Style CC-BY-SA-NC ist, so kann die Karte derzeit nur in den Faellen 2-3 veroeffentlicht werden. Nach einem Wechsel zur ODbL kann die Karte ebenfalls in den Faellen 2-3 veroeffentlicht werden (da die Garminkarte eine Datenbank ist). Ich sehe also in keinem Fall, dass der Wechsel der Styles von CC-BY-SA auf CC-BY-SA-NC irgendeine Aenderung *nach* einem Wechsel zur ODbL bewirkt - egal ob die Styles NC sind oder nicht, in den Faellen 2-3 gehts und in Fall 1 gehts nicht. Der Wechsel zu einer NC-Lizenz hat lediglich eine Wirkung, solange OSM noch unter CC-BY-SA ist, denn dann macht der Wechsel zu NC den vorher moeglichen Fall 1 unmoeglich. Eventuell ist Felix sich nicht darueber im Klaren, dass eine Garmin-Karte nach ODbL eine Datenbank ist und daher zwingend unter ODbL lizensiert werden muss. Bye Frederik 2. Trifft nicht zu. 1. oder 3. wobei dass wohl Ansichtssache ist. Sollte es so sein, dass der Style dazu verwendet werden kann (ohne explizite Erlaubnis wie im Falle des Dev-Servers) fuer kommerzielle Karten verwendet zu werden, obwohl er unter NC steht, werde ich die Entwicklung unter Open-Source einstellen. Sollte der von mir beabsichtigte Grundsatz, Style darf ohne explizite Erlaubnis nur fuer NC Kartengenerierung verwendet werden also nicht zutreffen, dann werde ich die OpenSource Entwicklung einstellen, und an ausgewaehlten Personen per NDA den Style zur Verfuegung stellen, mehr aber nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO steht wieder still
Hallo, Weil ich keine Lust hab, dass wenn ich damit aufhoere - sprich beim Split odbl/CCBYSA jemand die Karte weiterbenutzt - jemand den Style fuer Daten der odbl Datenbank verwendet. Ganz einfach. Evtl mache ich dass selber, oder aber die Velomap gibt es dann nur noch fuer CCBYSA basierte Kartendaten. Non-Commercial moechte ich prinzipiell aber nicht verbieten. Immerhin stecken da Monate an Arbeit drinnen - und die zu 99.9% nur von mir. Ich verstehe das nicht ganz, vermutlich, weil ich mich mit Garminkarten im Detail nicht auseinandergesetzt habe. Es gibt drei denkbare Faelle: 1. Der Style geht direkt in die erzeugte Karte ein (die Karte ist ein abgeleitetes Werk von, unter anderem, dem Style). 2. Der Style ist eigenstaendig und wird mit auf das Garmin-Geraet draufkopiert. 3. Der Style ist ein Algorithmus, der bei der Herstellung der Karte gebraucht wird, aber 1./2. treffen nicht zu. Wenn der Style CC-BY-SA ist, so kann die Karte derzeit in den Faellen 1-3 veroeffentlicht werden. Nach einem Wechsel zur ODbL kann die Karte nur noch in den Faellen 2-3 veroeffentlicht werden. Wenn der Style CC-BY-SA-NC ist, so kann die Karte derzeit nur in den Faellen 2-3 veroeffentlicht werden. Nach einem Wechsel zur ODbL kann die Karte ebenfalls in den Faellen 2-3 veroeffentlicht werden (da die Garminkarte eine Datenbank ist). Ich sehe also in keinem Fall, dass der Wechsel der Styles von CC-BY-SA auf CC-BY-SA-NC irgendeine Aenderung *nach* einem Wechsel zur ODbL bewirkt - egal ob die Styles NC sind oder nicht, in den Faellen 2-3 gehts und in Fall 1 gehts nicht. Der Wechsel zu einer NC-Lizenz hat lediglich eine Wirkung, solange OSM noch unter CC-BY-SA ist, denn dann macht der Wechsel zu NC den vorher moeglichen Fall 1 unmoeglich. Eventuell ist Felix sich nicht darueber im Klaren, dass eine Garmin-Karte nach ODbL eine Datenbank ist und daher zwingend unter ODbL lizensiert werden muss. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO steht wieder still
On 02.09.2010 12:00, Sven Geggus wrote: Felix Hartmann wrote: Die Karten sind ja weitherhin CCBYSA 2.0 und dass soll auch so bleiben. Die Style-Files sehe ich in Bezug auf odbl jedoch nicht mehr ein, als CCBYSA wie bisher zu veroeffentlichen. Was hat das mit der odbl zu tun? Die Alternative waere fuer mich nur Closed-Source, und das wollte ich mit CCBYNCSA 3.0 eben vermeiden. Da es sich bei beidem um diskriminierende Lizenzen handelt kollidiert das mit der FOSSGIS Satzung. Der devserver steht zur Förderung nicht freier Software nicht zur Verfügung. Wenn nicht, bin ich weg. CCBYSA 2.0 ist fuer mich keine Alternative (mehr). Wenn dem so ist, muss der Name VeloMap entfernt werden, und die Styles koennen mit altem Stand als CCBYSA 2.0 weiterlaufen, viel Sinn wuerde dass allerdings nicht machen. Jetzt mach mal halblang. Solange du kein [tm] auf den namen velomap hast können wir die nenen wie man will. Ich habe jetzt leider nur noch zwei Möglichkeiten: 1. Wir stellen die Produktion der velomap auf dem devserver ein weil zu deren Erzeugung neuerdings non-free komponenten ein gesetzt werden müssen 2. Wir starten einen fork der velomap wenn sich ein Maintainer findet Eine Frage hätte ich noch. Warum jetzt plötzlich Non-commercial? Weil ich keine Lust hab, dass wenn ich damit aufhoere - sprich beim Split odbl/CCBYSA jemand die Karte weiterbenutzt - jemand den Style fuer Daten der odbl Datenbank verwendet. Ganz einfach. Evtl mache ich dass selber, oder aber die Velomap gibt es dann nur noch fuer CCBYSA basierte Kartendaten. Non-Commercial moechte ich prinzipiell aber nicht verbieten. Immerhin stecken da Monate an Arbeit drinnen - und die zu 99.9% nur von mir. Wie gesagt, solange die Karte am Dev-Server gerendert wird, sehe ich den kompletten Output inkl. Typfile als CCBYSA 2.0 by velomap.org - Map Data CCBYSA 2.0 by openstreetmap.org & Contributors an (obwohl das Typfile im Prinzip ja unabhaengig von der Karte ist, und somit auch unter Lizenz X stehen koennte). Ich werde die Lizenz nicht wieder auf CCBYSA 2.0 zuruecksetzen (darunter war mein style-file vorher veroeffentlicht). Wenn dies also so auf dem Dev-Server nicht geht, dann muesst ihr wohl die Erstellung wieder aus den Skripten rausnehmen. Es sind aber keine non-free Komponenten, sondern einfach Non-Commercial Komponenten. Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap-Daten für Navigationssy steme der Automobilhersteller?
Am 02.09.2010 10:00, schrieb Florian Lohoff: (Wer würde heute ein Navi haben wollen ohne funktionsfähiges Hausnummern-Routing? Das gab's bei den Kommerziellen beim Wechsel von TomTom1 auf TomTom2, das muss ca. 2003 gewesen sein.) Mich wuerde mal interessieren wieviel Prozent der Straßen in den Kommerziellen Daten Hausnummern haben - Denn alle werden das nicht sein. Das kann man mit dem Google-Geocoder wunderbar ausprobieren. Der ist zwar -wegen des zugrundeliegenden Teleatlas-Materials nicht immer total toll, aber schlimmer als "auf Sichtweite", also +/-50m patzt auch der nicht. Hast Du Beispiele, wo es Probleme gibt? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
On 02.09.2010 19:41, Carsten Gerlach wrote: Hallo zusammen, Am Mittwoch 01 September 2010 schrieb Andreas Tille: ich habe gestern eine Brücke entdeckt, die momentan Rekonstruiert wird und somit für einige Zeit nicht nutzbar ist. Wow, es ist schon erstaunlich welch aufbrausende Diskussion durch solch einfache Frage ausgelöst wird. Ob man nun die eine oder die andere Variante bevorzugt, ein "access=no" passt in beiden Fällen und wird bestimmt auch von den Routern berücksichtigt. Damit sollten ja eigentlich "Säuberungsaktionen" und "Sperrandrohungen" überflüssig sein. Manchmal wünsche ich mir, daß die Leute lieber mal eine andere Sichtweise einfach so stehen lassen, als sich hier in Endlosdiskussionen zu verlieren. Das Beispiel erinnerte mich an die Zeit, wo man Kindern in der Schule zum Rechtshänder erziehen wollte. Zum Glück hat man das irgendwann überwunden und sich auf wesentlicheres konzentriert. Mal schauen, wann das auch in der OSM-Welt ankommt. +1 Gruß, Carsten ___ 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] Im Bau befindliche Brücke
Hallo zusammen, Am Mittwoch 01 September 2010 schrieb Andreas Tille: > ich habe gestern eine Brücke entdeckt, die momentan Rekonstruiert wird und > somit für einige Zeit nicht nutzbar ist. Wow, es ist schon erstaunlich welch aufbrausende Diskussion durch solch einfache Frage ausgelöst wird. Ob man nun die eine oder die andere Variante bevorzugt, ein "access=no" passt in beiden Fällen und wird bestimmt auch von den Routern berücksichtigt. Damit sollten ja eigentlich "Säuberungsaktionen" und "Sperrandrohungen" überflüssig sein. Manchmal wünsche ich mir, daß die Leute lieber mal eine andere Sichtweise einfach so stehen lassen, als sich hier in Endlosdiskussionen zu verlieren. Das Beispiel erinnerte mich an die Zeit, wo man Kindern in der Schule zum Rechtshänder erziehen wollte. Zum Glück hat man das irgendwann überwunden und sich auf wesentlicheres konzentriert. Mal schauen, wann das auch in der OSM-Welt ankommt. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Perl Relation Analyzer
"Relation check" im Wiki On Thu, 2010-09-02 at 17:57 +0200, Rainer Kluge wrote: > Hallo, > > Da der Relation Analyzer auf > http://betaplace.emaitie.de/webapps.relation-analyzer/ offenbar ständig > überlastet ist, habe ich mir auf die Schnelle ein Perl-Skript gebastelt, > welches > mir im wesentlichen die selbe Funktionalität bietet: Zusammenfassen der Wege > zu > zusammenhängenden Segmenten, Hinweise auf grobe Fehler, Erzeugen eines > GPX-Files. > > Bevor ich das Skript weiter perfektioniere, wollte ich hier mal nachfragen, ob > es ein vergleichbares Skript schon irgendwo zum Herunterladen gibt, wenn ja, > wo? > > Grüße > Rainer > > > ___ > 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 - Layer kombinieren
Du könntest das viele da draußen (die diese Liste nicht lesen) aber nicht .. Bin dafür das wir jemand suchen der uns sowas in Java schreibt. Dann könnte man auch nur ein paar Kacheln updaten und müßte nicht immer 2gb runterladen .. ( OK einmal im Monat muss man ggf en Kachelzuschnitt anpassen ) aber dann kann man die 2 Gb ja per Torrent verteilen .. Dirk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Perl Relation Analyzer
Mhh .. wenn man das Skript per svn freigeben könnte . kann man es auf einige Server spielen ... Am 2. September 2010 17:57 schrieb Rainer Kluge : > Hallo, > > Da der Relation Analyzer auf > http://betaplace.emaitie.de/webapps.relation-analyzer/ offenbar ständig > überlastet ist, habe ich mir auf die Schnelle ein Perl-Skript gebastelt, > welches > mir im wesentlichen die selbe Funktionalität bietet: Zusammenfassen der Wege > zu > zusammenhängenden Segmenten, Hinweise auf grobe Fehler, Erzeugen eines > GPX-Files. > > Bevor ich das Skript weiter perfektioniere, wollte ich hier mal nachfragen, ob > es ein vergleichbares Skript schon irgendwo zum Herunterladen gibt, wenn ja, > wo? > > Grüße > Rainer > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > -- Wikipedia -- http://tools.wikimedia.de/~flacus/IWLC/ OSM -- http://osm.flacus.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Layer kombinieren
fla...@googlemail.com wrote: > Nur das es da Probleme geben könnte .. den die maximale Anzahl der > Kacheln ist ja im Gerät begrenzt. Auf was beziehst Du dich denn jetzt? Korrektes quoting würde helfen :( > Da alle User am besten EU.Karten haben wollen, muss die Anzahl der Kacheln > mit der Anzahl der Ebenen multipliziert werden .. und dann noch kleiner > als 2025 sein. Wenn das ein Problem ist, dann hab ich keine Not damit einfach den Maxspeed Layer rauszuwerfen und vielleicht auch noch keepright. Wie Christoph breits geschrieben hat ist es ja einfach mehrere gmapsupp.img zu einem ganzen zu kombinieren. Gruss Sven -- Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das Verbindungsgebrüll. (aus einer Ebay fishing Mail) /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
[Talk-de] Perl Relation Analyzer
Hallo, Da der Relation Analyzer auf http://betaplace.emaitie.de/webapps.relation-analyzer/ offenbar ständig überlastet ist, habe ich mir auf die Schnelle ein Perl-Skript gebastelt, welches mir im wesentlichen die selbe Funktionalität bietet: Zusammenfassen der Wege zu zusammenhängenden Segmenten, Hinweise auf grobe Fehler, Erzeugen eines GPX-Files. Bevor ich das Skript weiter perfektioniere, wollte ich hier mal nachfragen, ob es ein vergleichbares Skript schon irgendwo zum Herunterladen gibt, wenn ja, wo? Grüße Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Layer kombinieren
Nur das es da Probleme geben könnte .. den die maximale Anzahl der Kacheln ist ja im Gerät begrenzt. Da alle User am besten EU.Karten haben wollen, muss die Anzahl der Kacheln mit der Anzahl der Ebenen multipliziert werden .. und dann noch kleiner als 2025 sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Peter Wendorff schrieb am 02.09.2010 09:46: > Mir ist durchaus bewusst, dass die Navigation nicht die erforderliche > Genauigkeit bieten kann. > Um so wichtiger ist aber die Modellierung korrekter Topologie. > Auch einem Blinden Fußgänger kann ich die Anweisung geben, den Fußweg > entlangzugehen. Solange keine Rückfrage kommt "ich hab mist gebaut" kann > das System davon ausgehen, dass der Fußgänger auf dem Fußweg geblieben > ist, und entsprechend auch ungenaue GPS-Signale korrigieren. Nichts > anderes machen Kfz-GPS, wenn sie das GPS-Signal auf der Straße > einfangen, obwohl es teilweise danebenliegt. Um so schaedlicher ist aber ein uebermaessiger Detailreichtum der Daten. Was du hier zu bauen versucht ist ein klassischer Verstoss gegen das http://de.wikipedia.org/wiki/Nyquist-Shannon-Abtasttheorem. Wenn du mit zu ungenauen Position auf zu detaillierten Wegnetzen navigieren willst, dann wird das fuerchterlich daneben gehen, weil du immer wieder zu falschen Entscheidungen kommst, wo du gerade bist. praktisch ausgedrueckt bedeutet das, dass deine Navigation nicht wird erkennen koennen, auf welcher Strassenseite du dich befindest. Deshalb wird sie zwangslaeufig immer wieder falsche Komandos geben, um die Strasse zu wechseln. > Ungenaue GPS-Signale sind aber kein Argument für ungenaue Karten - im > Gegenteil: Bei grob modellierten Kartendaten UND ungenauem GPS-Signal > steigt die Wahrscheinlichkeit, dass Fehler sich aufsummieren - und das > Endergebnis noch schlechter ist. So eine Folgerung gilt nur fuer kontinuierliche Systeme. Bei diskreten Systemen, womit wir es hier ja zu tun haben, koennen und werden zu viele Details durchaus zu einer Verschlechterung fuehren. > Ich hoffe nicht, aber ich hoffe auch, dass die OpenStreetMap Potential > nach oben hat - und nicht einfach durch Relevanzdiskussionen gestoppt > wird, die künstliche Beschränkungen auferlegen. Ich hoffe, bei deiner Bachelorarbeit versuchst du nicht die naturgegebenen Beschraenkungen der Mathematik zu verletzen. Da kannst du sicher sein, dass die Mathematik gewinnen wird. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gpx-daten rückverfolgen
Jan Tappenbeck wrote: wenn man sich die gpx-daten (Rohdaten vom osm-Server!) in josm einlädt - kann man irgendwie ermitteln aus welchem track die stammen ?? Also im Merkaartor geht das zumindest ganz einfach. Die Dateinamen stehen dort links in der Layer-Liste und man kann jede GPX-Datei getrennt ein- und ausschalten. Geht aber alles nur, wenn die beteiligten die GPX-Daten als "Identifizierbar" hochgeladen haben, was man wo immer möglich tun sollte. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] gpx-daten rückverfolgen
HI ! wenn man sich die gpx-daten (Rohdaten vom osm-Server!) in josm einlädt - kann man irgendwie ermitteln aus welchem track die stammen ?? gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wiki-Seite
Habe noch eine Wiki-Seite dazu eingerichtet ein Anfang erst einmal http://wiki.openstreetmap.org/wiki/DE:Project_of_the_month/2010/september Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Layer kombinieren
Christoph Wagner wrote: > Du nimmst dir die entsprechenden gmapsupps her und machst eine gmapsupp draus. > Dazu gibt es unzählige Möglichkeiten. Die OpenSourceVariante geht mit mkgmap: > > java -jar mkgmap.jar --gmapsupp gmapsupp_velomap.img gmapsupp_osb.img > > und fertig. OK, das ist ja einfach. Meine Wunschkarte sieht ja eigentlich nochmal anders aus: 1. AIO Karte 2. Fahrradoptimiertes routing aus der Velomap 3. Im AIO Stil zuschaltbarer Overlay mit Radfernwegen. Wie wäre denn da der Workflow? Wenn ich das richtig sehe müßte ich lediglich für Punkt 3 einen eigenen Style basteln - korrekt? Gruss Sven -- "Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch." (Anselm Lingnau in de.comp.os.unix.discussion) /me ist gig...@ircnet, http://sven.gegg.us/ im WWW ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO steht wieder still
Darüber habe ich auch mal am Rande mit Christoph gesprochen ... Ich hab da Ideen, aber ich denke eher das man das in Zukunft so machen könnte das man da Request über trusted -Server verteilen kann .. aber so ganz hab ich noch kein klares Bild im Kopf Dirk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap-Daten für Navigationssy steme der Automobilhersteller?
Am Donnerstag 02 September 2010, 09:58:42 schrieb Florian Lohoff: > On Wed, Sep 01, 2010 at 12:52:01PM +0200, Garry wrote: > > Ich denke schon mal dass es ein Problem ist dass die Automobilhersteller > > auf eine (Iso...)-Zertifizierung Ihrer > > Lieferanten bestehen. OSM hat nicht mal ein konsistentes Datenmodell auf > > das man sich verlassen kann - nicht mal > > eine Versionierung so dass sich jedes Tag zu jedem beliebigen Zeitpunkt > > ändern kann. > > Du glaubst also das Navted und Teleatlast eine ISO-900X zertifizierung haben? > > Und so wie ich die ISO-900X Geschichten verstanden habe geht es lediglich > um dokumentation d.h. Prozessbeschreibung und eben Dokumentation. Und > DA ist OSM allem ueberlegen. Solange man keinen Wisch vorweisen kann ist das in einmem solchen Fall eh wurscht. Da können Daten und Dokumentation noch so toll sein, ohne Zertifikat kommst nirgends rein, wenn die eines sehen wollen. flo -- Als Napoleon war Ich ein Genie! Als Nero ein Idiot. Als Woko bin Ich ein Idiotisches Genie. Oder bin Ich doch ein genialer Idiot.[WoKo in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
2010/9/2 Garry > Am 01.09.2010 20:33, schrieb Robert S.: > >> >> >>> >>> >>> access = no >>> construction = yes >>> construction:period = Frühjahr 2009 bis Herbst 2010 >>> highway = tertiary >>> >> > Das übliche tagging ist allerdings: >> >>> highway = construction >> >>> construction = tertiary >> >>> >> >> construction=yes sehe ich zumindest eher als Zusatztag unter dem Motto >> "Hier >> >>> wird (längerfristig) gebaut, man kann aber noch durchkommen." >> >> > Das Thema war noch lange nicht ausdiskutiert. > Stimmt, ich erinnere mich. Du hattest vehement gegen das von mir genannte Tagging opponiert, weil die von dir genutzte Software in dem Bereich schlecht programmiert war. Und weil dir klar war, dass mit dem von dir bevorzugtem Tagging viele andere Programme Probleme hätten, hast du solche Dinge vorgeschlagen wie: "Die Wege nicht mit dem Rest der Karte verbinden, damit da nicht drübergeroutet wird!" Die Vorteile von highway = construction hatten wir ja auch schon mal angesprochen: Jede Auswertung, die sich nicht für in Bau befindliche Stecken interessiert (also z.B. alle Router) brauchen hier nur den highway Tag auswerten und können dann alles mit highway = construction ignorieren, während diese Programme bei dem von dir bevorzugtem Tagging an ALLEN Wegen noch nach construction = yes suchen müssen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
Andreas Tille schrieb: > ich habe gestern eine Brücke entdeckt, die momentan Rekonstruiert wird > und somit für einige Zeit nicht nutzbar ist. Ich setz mal noch einen drauf: Hier gibt es zwei mir bekannte Fussgaengerbruecken, die wohl dauerhaft gesperrt bleiben. Bei denen ist nur noch ein Metallgeruest und gar keine begehbare Flaeche mehr vorhanden. http://openstreetmap.org/browse/way/37632798 http://openstreetmap.org/browse/way/75525920 Letztere ist bei Mapnik lustig dargestellt. access=no wird anscheinend einfach so ins Nichts gemalt. Ich empfehle zumindest: access=no bridge=yes Bei Bedarf und Kenntnis halt noch: highway=construction + construction=footway (oder was auch immer) surface= width= handrail= smoothness= wenn abzusehen ist, wie's wird Und die Blockaden nicht vergessen: barrier=fence z.B. auf den Zugangsknoten. stw -- Die Ausdehnung der Unbesiegbarkeit der Dummheit auf die der Götter selbst entspricht eher der modernen, nihilistischen, als der klassischen Interpretation der allgemeinen Verwirrtheit der Welt und ihrer Protagonisten. [Roland Franzius in desd] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO steht wieder still
Felix Hartmann wrote: > Die Karten sind ja weitherhin CCBYSA 2.0 und dass soll auch so bleiben. > Die Style-Files sehe ich in Bezug auf odbl jedoch nicht mehr ein, als > CCBYSA wie bisher zu veroeffentlichen. Was hat das mit der odbl zu tun? > Die Alternative waere fuer mich nur Closed-Source, und das wollte ich mit > CCBYNCSA 3.0 eben vermeiden. Da es sich bei beidem um diskriminierende Lizenzen handelt kollidiert das mit der FOSSGIS Satzung. Der devserver steht zur Förderung nicht freier Software nicht zur Verfügung. > Wenn nicht, bin ich weg. CCBYSA 2.0 ist fuer mich keine Alternative > (mehr). Wenn dem so ist, muss der Name VeloMap entfernt werden, und die > Styles koennen mit altem Stand als CCBYSA 2.0 weiterlaufen, viel Sinn > wuerde dass allerdings nicht machen. Jetzt mach mal halblang. Solange du kein [tm] auf den namen velomap hast können wir die nenen wie man will. Ich habe jetzt leider nur noch zwei Möglichkeiten: 1. Wir stellen die Produktion der velomap auf dem devserver ein weil zu deren Erzeugung neuerdings non-free komponenten ein gesetzt werden müssen 2. Wir starten einen fork der velomap wenn sich ein Maintainer findet Eine Frage hätte ich noch. Warum jetzt plötzlich Non-commercial? Gruss Sven -- Der "normale Bürger" ist nicht an der TU Dresden und schreibt auch nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion) /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] Im Bau befindliche Brücke
On 02.09.2010 10:51, Peter Wendorff wrote: On 02.09.2010 10:26, Norbert Wenzel wrote: On 02.09.2010 10:13, Peter Wendorff wrote: Bei highway=construction - wie kann ich dann unterscheiden, welcher Straßentyp hier gebaut wird? On 01.09.2010 19:20, Carsten Gerlach wrote: > access = no > construction = yes > construction:period = Frühjahr 2009 bis Herbst 2010 > highway = tertiary Deshalb mein expliziter Bezug auf die von einigen bevorzugte Variante mit highway=construction. Dass das über construction=yes funktioniert, ist klar. Oh sorry, da hätt ich jetzt mal genauer lesen sollen was ich zitier. Gemeint war eigentlich folgender Beitrag: On 01.09.2010 20:33, Robert S. wrote: > highway = construction > construction = tertiary Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap-Daten für Navigationssy steme der Automobilhersteller?
Hallo,
Am Mittwoch 01 September 2010 12:15:59 schrieb Garry:
>
> OSM ist noch "etwas" davon entfernt um von einem "guten Navi" sprechen
> zu können wenn ausschliesslich OSM
> darauf läuft. Dafür sind einfach noch die Lücken zu gross und auch gut
> gemappte Gegenden zu unterschiedlich in der Umsetzung.
ich weiß nicht, in welcher Gegend du dich bewegst, aber ich benutze OSM-Karten
seit ca 1 Jahr nahezu ausschließlich und hatte noch keine ernst zu nehmenden
Probleme.
Einschränkungen gibt es bei der Adress-Suche, und die Anzeige der erlaubten
Geschwindigkeit funktioniert nicht. Das wird noch. Alles andere geht, solange
man sich in D, A oder DK aufhält. Und wenn man aussteigt, haben die
kommerziellen Karten sowieso schon verloren. Da hat unsere Karte Lücken, die
anderen Karten aber gar keine bis völlig unzuverlässige Daten.
Wenn in Hinterposemuckel der Dorfangerhinterweg fehlt - so what. Wenn ich Zeit
habe, ergänze ich ihn sofort. Die Hauptstraßen bis herunter zu tertiary sind
nahezu perfekt vorhanden. Das gilt so allmählich auch für MeckPom. Routing
funktioniert und innovativ ist das Routing von Garmin auch auf Garmin-Karten.
Schön wäre es, wenn bessere Software als die von Garmin mit unseren Daten
zurecht käme. Mein mindestens 5 Jahre altes Navi von Aldi (Medion) hat bessere
Routing-SW als Garmin und funktioniert auch ohne Grammatik-Fehler ("Fahren Sie
in das Hauptstraße"...). Aber vorläufig kann ich damit ganz gut leben.
Gruß, Wolfgang
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
Am 2. September 2010 10:13 schrieb Peter Wendorff : > Ich hab mich auch nicht näher mit dem Thema beschäftigt - will aber trotzdem > einen Gedanken einwerfen, der mir grade gekommen ist. > Bei highway=construction - wie kann ich dann unterscheiden, welcher > Straßentyp hier gebaut wird? > Eine Autobahn im Bau ist immerhin was ganz anderes als eine Straße im > Wohngebiet... steht doch oben: construction=motorway bzw. residential Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
Am 2. September 2010 08:50 schrieb Garry : > Am 02.09.2010 01:02, schrieb M∡rtin Koppenhoefer: >> >> Am 2. September 2010 00:53 schrieb Garry: >> > > Das übliche tagging ist allerdings: > highway = construction > construction = tertiary > >>> >>> Das Thema war noch lange nicht ausdiskutiert. >>> >> >> doch, war es. > > Nur für die, die sich nicht für Details interessieren wie Trasse > freigeraümt, Trassierung angelegt, Fahrbahn vorhanden, > Brücken vorhanden, Fahrspur eingeengt, 4+0 Verkehr, Da gibt es bis heute > noch keine Lösung dafür. construction=yes hilft einem da auch nicht weiter. Wenn Du solche temporären Details mappen willst, dann schlag doch einen Tag vor und mach es. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
On 02.09.2010 10:26, Norbert Wenzel wrote: On 02.09.2010 10:13, Peter Wendorff wrote: Bei highway=construction - wie kann ich dann unterscheiden, welcher Straßentyp hier gebaut wird? On 01.09.2010 19:20, Carsten Gerlach wrote: > access = no > construction = yes > construction:period = Frühjahr 2009 bis Herbst 2010 > highway = tertiary Deshalb mein expliziter Bezug auf die von einigen bevorzugte Variante mit highway=construction. Dass das über construction=yes funktioniert, ist klar. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Am 2. September 2010 09:46 schrieb Peter Wendorff : > Ungenaue GPS-Signale sind aber kein Argument für ungenaue Karten - im > Gegenteil: Bei grob modellierten Kartendaten UND ungenauem GPS-Signal steigt > die Wahrscheinlichkeit, dass Fehler sich aufsummieren - und das Endergebnis > noch schlechter ist. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vorträge im OpenSource Park auf der In tergeo
Moin Moin, Anfang Oktober (05.10 - 07. 10) ist es wieder soweit, die Intergeo öffnet seine Türen. Der OpenSource-Park beinhaltet neben dem Ausstellungsbereich auch wieder einen Vortragsbereich. Dieser muss natürlich mit Vorträgen gefüllt werden. Aus diesem Grund können ab sofort Vorschläge für Vorträge in das FOSSGIS Wiki eingetragen werden. Redaktionsschluss für die Vorträge ist der 26.09.2010. Weitere Informationen gibts unter: http://www.fossgis.de/wiki/Intergeo_2010/Vortragsprogramm Viele Grüße, Dominik -- Dominik Helle Omniscale, Dominik Helle, Oliver Tonnhofer GbR Nadorster Straße 60, 26123 Oldenburg Web: http://omniscale.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] htc-Smartphone mit osm
Am Thu, 2 Sep 2010 10:09:44 +0200 schrieb Joerg Fischer: > Jan Tappenbeck wrote: > >> kann einer was zur Verwendung von OSM-Karten auf htc-smartphones >> sagen (schreiben)? > > Ich kann ein HTC Desire uneingeschränkt empfehlen. Anwendungen die ich > selber installiert habe: > > [Skobbler, OSMAnd, Andnav2, OSMTracker Vespucci, OSMDroid, GPSies] Dem lässt sich nur noch MapDroyd hinzufügen. Ist wegen der Vektordarstellung ganz nett und Dank der vorgefertigten Kartenpakete von Bundeslandebene bis weltweit sehr einfach für den Offlinebetreib vorzubereiten. GeoJ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] htc-Smartphone mit osm
Joerg Fischer wrote: Ich kann ein HTC Desire uneingeschränkt empfehlen. Anwendungen die ich selber installiert habe: schöne Zusammenfassung. Willst du das nicht ins Wiki reinkopieren? Wäre schade wenn das in den Mailarchiven untergeht. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap-Daten für Navigationssys teme der Automobilhersteller?
Florian Lohoff wrote: Mich wuerde mal interessieren wieviel Prozent der Straßen in den Kommerziellen Daten Hausnummern haben 3300 Millionen Adressdaten (damit auch Hausnummern) auf 31 Millionen Kilometer Straße. http://www.teleatlas.com/OurProducts/MapEnhancementProducts/AddressPoints/index.htm?Lang=DE http://www.teleatlas.com/OurProducts/TechnologyOverview/index.htm?Lang=DE In Deutschland 17 Millionen Gebäude in denen auch gewohnt wird. http://www.destatis.de/jetspeed/portal/cms/Sites/destatis/Internet/DE/Content/Publikationen/Querschnittsveroeffentlichungen/WirtschaftStatistik/Zensus/GebaudeWohnungsz,property=file.pdf Damit dürften die meisten Hausnummern erfasst sein. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
On 02.09.2010 10:13, Peter Wendorff wrote: Bei highway=construction - wie kann ich dann unterscheiden, welcher Straßentyp hier gebaut wird? Eine Autobahn im Bau ist immerhin was ganz anderes als eine Straße im Wohngebiet... On 01.09.2010 19:20, Carsten Gerlach wrote: > access = no > construction = yes > construction:period = Frühjahr 2009 bis Herbst 2010 > highway = tertiary Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
On 02.09.2010 08:37, bkmap wrote: Beispiele: Eine Sportstätte wird erschlossen und gebaut - mein Tagging für alle Bestandteile inclusive Parkplätze und Zufahrtswege: access=no, construction=yes Ein Teich wird leergelassen und inclusive Schutzhütte und Wege umfangreich rekunstruiert. Das Gebiet ist für jeglichen Zugang gesperrt - mein Tagging: access=no, construction=yes Mir fallen zig Situationen ein, bei denen durch Rekonstruktion vorübergehend kein Zugang möglich ist: Einkaufszentrum, Schwimmhalle, Eislaufbahn, Parkhaus, Aussichtsturm . Ich hab mich auch nicht näher mit dem Thema beschäftigt - will aber trotzdem einen Gedanken einwerfen, der mir grade gekommen ist. Bei highway=construction - wie kann ich dann unterscheiden, welcher Straßentyp hier gebaut wird? Eine Autobahn im Bau ist immerhin was ganz anderes als eine Straße im Wohngebiet... Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] htc-Smartphone mit osm
Jan Tappenbeck wrote: > kann einer was zur Verwendung von OSM-Karten auf htc-smartphones > sagen (schreiben)? Ich kann ein HTC Desire uneingeschränkt empfehlen. Anwendungen die ich selber installiert habe: Skobbler: Die derzeit ausgereifteste Navilösung, eigentlich kein großer Unterschied zu einem PNA an der Scheibe. Vernünftige Ansagen, super 3D Kartendarstellung. Nachteil: Permanente Datenverbindung nötig, weil die Kacheln online nachgeladen werden und Routen IIRC auf dem Cloudmade-Server berechnet werden und nicht im Gerät. OSMAnd und Andnav2: Weitere Navilösungen, die gegen Skobbler derzeit nicht so richtig anstinken können. Aber Konkurrenz ist ja immer gut, da muß man gucken was sich entwickelt. Andnav2 scheint bzgl. Weiterentwicklung momentan etwas tot zu sein. Skobbler kostet vermutlich irgendwann Geld und ist kein OS. Nachteil aller Navis: Datenverbindung nötig. Navilösungen mit im Gerät installierten Karten sind momentan keine kostenfreien verfügbar. Im Ausland ist das doof. Zumindest den Weg zum A1-Shop im Ösiland mußte ich also ohne Navi finden. *gg* Dann kommt halt eine Prepaidkarte rein. Auf dem Rückweg an der Grenze das gleiche Problem. OSMTracker: Macht genau was der Name sagt. Sehr, sehr komfortables erfassen möglich, entweder mit Sprachaufzeichnung am POI oder einem georeferenzierten Foto oder der Festlegung von POI-Eigenschaften via Klickermenü. Vespucci: Ein Online-Editor, man kann also erfasste Daten sofort bei OSM hochladen. Bedienung etwas hakelig, was aber nicht an der Software sondern am Smartphone-Prinzip mit Fingertouch auf einem dafür zu kleinen Display liegt. Ich tipper immer daneben. .-) OSMDroid: Simples "Anguckprogramm" wo man sich gerade herumtreibt. Gut um zu erkennen wo noch Wege / POI fehlen. Jenseits von OSM: GPSies: Android-Client für gpsies.de. Auch nicht schlecht. Bug: Das Einloggen mit eigenen Accountdaten und sofortigem hochladen ist kaputt. Google Maps: Das hat natürlich auch was, die Google-Satellitenbilder im Direktzugriff zu haben. Hat sich diesen Sommer bei Alpenwanderungen bewährt, weil man aus der Luft sieht wie der Weg so weiter gehen wird. Die Google-Kartendaten kann man selbstverständlich auch einblenden, aber in Bezug auf Wander- und Radwege kann Google mit OSM nicht mehr mithalten, wir sind viel detaillierter und aktueller. Regional natürlich mit Unterschieden. Google Navigation: Funktioniert sicher auch. Habe ich noch nicht im Detail getestet und mit Skobbler so richtig verglichen. Ich will primär sehen wohin mich Skobbler routet, was er ansagt und welche Fehler er macht. Genereller Nachteil (aller Smartphones) ist die erbärmliche Akkulaufzeit. Mit eingeschaltetem Display und diversen laufenden Programmen an ist da schon mal nach 2 oder 3 Stunden die Puste raus. Ich behelfe mir mit so einem externen Akkupack, in das 4 AA-Zellen kommen und ein USB-Anschluß zum Laden dran ist. Die Genauigkeit des GPS-Empfängers überzeugt mich. Ich habe auch in Gebäuden in Fensternähe oft einen Fix. Im Direktvergleich mit einem Garmin Edge 705 ist das Desire empfindlicher, genauer und hat kürzere Fixzeiten. In der Hoffnung das es auf den Chemnitzer Linuxtagen 2011 wieder einen OSM-Stand geben wird, ich bring das Teil mit so das die Möglichkeit zum begrabbeln besteht. HTH, Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap-Daten für Navigationssys teme der Automobilhersteller?
On Thu, Sep 02, 2010 at 12:34:50AM +0200, Johann H. Addicks wrote: > > Aber da ist OSM noch nicht. Es fehlt noch an Detailgrad "in der Pampa" > und -noch viel drastischer- an Hausnummern, auch in größeren Städten. > > (Wer würde heute ein Navi haben wollen ohne funktionsfähiges > Hausnummern-Routing? Das gab's bei den Kommerziellen beim Wechsel von > TomTom1 auf TomTom2, das muss ca. 2003 gewesen sein.) Mich wuerde mal interessieren wieviel Prozent der Straßen in den Kommerziellen Daten Hausnummern haben - Denn alle werden das nicht sein. Es gibt immer wieder Straßen wo ich auch im Harmann/Becker Festeinbau keine Hausnummer eingeben kann. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap-Daten für Navigationssys teme der Automobilhersteller?
On Wed, Sep 01, 2010 at 12:52:01PM +0200, Garry wrote: > Ich denke schon mal dass es ein Problem ist dass die Automobilhersteller > auf eine (Iso...)-Zertifizierung Ihrer > Lieferanten bestehen. OSM hat nicht mal ein konsistentes Datenmodell auf > das man sich verlassen kann - nicht mal > eine Versionierung so dass sich jedes Tag zu jedem beliebigen Zeitpunkt > ändern kann. Du glaubst also das Navted und Teleatlast eine ISO-900X zertifizierung haben? Und so wie ich die ISO-900X Geschichten verstanden habe geht es lediglich um dokumentation d.h. Prozessbeschreibung und eben Dokumentation. Und DA ist OSM allem ueberlegen. > OSM kann noch so tolle Kartendemos machen - ohne einer verlässlichen > Datenmodellbeschreibung bleiben es letztenendes nur Demos, > auch wenn die Daten 1000mal detailierter und präziser als die > kommerziellen Produkte sind. > Daher _auch_ mein Beitrag: > Lizenzumstellung - Warum kein OSM 2.0 mit besserem Datenmodell? Weil das Bullshit ist - Das ist wieder die nummer mit der Eierlegenden Wollmilchsau die 20 Jahre Entwickelt wird nur leider nie das licht der Welt erblickt. Revolution hat noch nie sauber funktioniert - schon gar nicht in der Softwareentwicklung - Lieber kleine Schritte - Evolution ... Wie hiess noch der super vorgaenger von Wikipedia bei nur zugelassene Authoren mitmachen durften? Ach ja - Nupedia - Super erfolgreich - aber halt alles schon definiert ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
On 02.09.2010 04:21, Matthias Versen wrote: Peter Wendorff wrote: Wie sollte man dann an einer Kreuzung die 4 (möglicherweise unterschiedlich ausgestatteten Fußgängerampeln taggen? Eine normale Straßenkreuzung sind 2 kreuzende ways mit einem Verbindungsnode in der Mitte. Dieser Node bekommt dann ein highway=traffic_signals Tag. siehe auch http://wiki.openstreetmap.org/wiki/Traffic_lights Das modelliert den Spezialfall, dass 1) an jeder Seite der Kreuzung eine Ampel existiert 2) dass diese Ampeln alle gleich ausgestattet sind - und nur mit highway=traffic_signals wird auch diese Ausstattung als standardisiert vorausgesetzt. Der Normalfall ist aber, dass kaum zwei Kreuzungen sich gleichen: Eigenschaften, die nämlich nicht auf die Kreuzung, sondern auf einzelne Querungen zutreffen (also z.B. 4x pro einfacher Straßenkreuzung) zutreffen, sind: - Ampel? - Mittelinsel? - Ausstattung der Ampel mit Auffindeakustik, akustischem Grünsignal, Vibration, Bodenvibration, Blindenanforderungspfeil, taktiler Mini-Karte, ...? Sogar auf jede Seite jeder Querung zutreffend: - taktile Bodenindikatoren (diese weißen riffelpflastersteine)? - Bordsteinkante (normal, keine, abgesenkt, besonders hoch, *cm) Das ist alles nicht auf einem highway=traffic_signals-Knoten beschreibbar, aber durchaus relevant für verschiedene Anwendungen. Die Ansage für Gerade Dein Beispiel mit der Spielstraße zeigt das der Ansatz der Fußgängernavigation die anscheinend metergenau erfolgen soll mit Vektoren nicht vernünftig umsetzbar ist.Als Fußgänger kann man quasi fast überall langlaufen.Dir ist auch hoffentlich bewusst das in Straßenschluchten die normale GPS genauigkeit von "nur" 7m+ noch wesentlich schlechter werden kann durch Reflektionen ? Falsch. Mir ist durchaus bewusst, dass die Navigation nicht die erforderliche Genauigkeit bieten kann. Um so wichtiger ist aber die Modellierung korrekter Topologie. Auch einem Blinden Fußgänger kann ich die Anweisung geben, den Fußweg entlangzugehen. Solange keine Rückfrage kommt "ich hab mist gebaut" kann das System davon ausgehen, dass der Fußgänger auf dem Fußweg geblieben ist, und entsprechend auch ungenaue GPS-Signale korrigieren. Nichts anderes machen Kfz-GPS, wenn sie das GPS-Signal auf der Straße einfangen, obwohl es teilweise danebenliegt. Ungenaue GPS-Signale sind aber kein Argument für ungenaue Karten - im Gegenteil: Bei grob modellierten Kartendaten UND ungenauem GPS-Signal steigt die Wahrscheinlichkeit, dass Fehler sich aufsummieren - und das Endergebnis noch schlechter ist. Selbst der Ansatz der Erfassung der Straße als Fläche würde hier nicht helfen wenn ich das richtig sehe. Du darfst nicht vergessen das solche Daten auch immer gewartet werden müssen und das von Mappern die das erst 3 Monate machen und Potlatch benutzen denn der typische OSM Mapper ist AFAIK nur 3 Monate dabei. Wieder ein Argument, die OSM aufzugeben? Bringt ja sowieso nichts? Bleiben wir bei Standarddaten, die notfalls auch von NavTec geliefert werden können? Die Wartung der Daten wird in naher Zukunft auch immer wichtiger werden und das ergibt dann irgendwann ein Motivationsproblem denn neue Straßen erfassen macht immer mehr Spaß als an alten herumzubasteln. Das heißt, nach einmal vollständig erfassten Straßen ist die OSM tot und alle Mapper hören auf? Ich erfasse momentan neue Fußwege - und das ist durchaus nicht uninteressant. Deswegen mag ich es nicht das irgendjemand für sein tolles Studienprojekt, Diplomarbeit oder sonstwas einfach Daten in die DB kippen will um die sich dann später keiner mehr kümmert. Wie gesagt - du schränkst die OSM stark ein, weil du Angst hast, es pflegt keiner mehr. Sollen Häuserkonturen dann auch nicht mehr erfasst werden? Hausnummern reichen für die meisten Zwecke schließlich aus. Ob das bei Dir der Fall ist weiß ich nicht ganz genau aber es hört sich danach an. Ich hoffe nicht, aber ich hoffe auch, dass die OpenStreetMap Potential nach oben hat - und nicht einfach durch Relevanzdiskussionen gestoppt wird, die künstliche Beschränkungen auferlegen. Dabei habe ich immer eine breite Fußgängerzone im Hinterkopf wo x virtuelle Fußgängerways eingetragen werden. Erstens, wie gesagt: ein Weg als Linie einzutragen ist immer in irgendeiner Art virtuell. Zweitens: Zugänge zu Gebäudeeingängen sind natürlich ebenso (virtuelle) Wege - die aber existieren und ihre Berechtigung haben. Drittens: Eine Fußgängerzone besteht nicht aus mehreren nebeneinanderliegenden Wegen, sondern aus einem breiten Weg. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hilfe bei osmosis-datei - Elemente filtern und verschmelzen
Hi ! ich habe eine OSM-Datei aus welcher alle Kindergärten als Node und Way extrahiert werden sollen. Hierzu habe ich ein OSMOSIS erstellt das zunächst die Typen extrahiert und dann diese wieder verschmelzen soll. Die einzelnen Dateien werden erstellt - sind auch vollständig vom Aufbau - aber das Verschmelzen funktioniert nicht ! Es macht den Eindruck das der erste Befehl schon nicht durchläuft. echo off echo Filterung aktiv ... %osmworkfolder%\osmosis\bin\osmosis.bat -v 99 --read-xml %osmworkfolder%\osmosis\bus_luebeck.osm --tee 2 --node-key-value keyValueList="amenity.kindergarten" --write-xml %osmworkfolder%\osmosis\temp_kita_node.osm --way-key-value keyValueList="amenity.kindergarten" --used-node --write-xml %osmworkfolder%\osmosis\temp_kita_way.osm echo. echo verschmelzen der Dateien %osmworkfolder%\osmosis\bin\osmosis.bat --read-xml %osmworkfolder%\osmosis\temp_kita_node.osm --read-xml %osmworkfolder%\osmosis\temp_kita_way.osm --merge --write-xml %osmworkfolder%\osmosis\kita_hl.osm pause Kann mir einer von Euch weiterhelfen ?? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] falsch addressiert - aber trotzdem danke !
Am 02.09.2010 09:26, schrieb Hanno Hecker: On Thu, 02 Sep 2010 08:55:38 +0200 Jan Tappenbeck wrote: Du hattest mir mal ein Script für das Auslesen einer Wiki-Tabelle geschrieben. Darin gibt es folgende Unterfunktion: sub get_browse_link [...] # wenn es wie ein OSM-Link aussieht nummer herausschneiden if($elm=~m!\[http://www.openstreetmap.org/browse/\w+/(\d+)\]!) [...] Wenn der OSM Link nicht [http://www.openstreetmap.org/browse/node/442860074] ist sondern * [http://www.openstreetmap.org/browse/node/442860074/history] ist dann ist es doch sicherlich auch möglich die Nummer zu extrahieren. Kannst Du mir sagen wie der RegEx dann aussehen müßte? if($elm=~m!\[http://www.openstreetmap.org/browse/\w+/(\d+)(/history)?\]!) Hanno ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hi ! war zwar falsch addressiert - aber danke dafür ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Am 2. September 2010 09:10 schrieb Peter Wendorff : >> Diese Trennung zu definieren >> um die Durchlässigkeit abzuschätzen wäre nicht schlecht (s. >> Area-Relation ;-) ). > > Diese Trennung lässt sich aber nicht als Standard für nebeneinanderliegende > Wege definieren. was meinst Du mit "Standard"? Den Default? Wenn es keine Daten gibt, ist es sowieso Wahrsagerei oder bestenfalls Wahrscheinlichkeitsrechnung. > Theoretisch könnte man dies tun, wenn man width=* für alle betroffenen Wege > zur Pflicht macht, da sonst nicht abschätzbar ist, ob noch etwas zwischen > den Wegen liegt. explizit bzw. mit tags (z.B. barrier=kerb in der area-relation) mappen, dann ist es definiert. > Dein Argument der baulichen Trennung hinkt übrigens überall da, wo > Abbiegespuren als *-link eingetragen werden. das macht man (richtigerweise) auch nur da, wo eine bauliche Trennung vorhanden ist, wobei baul. Trennung sich derzeit ausschließlich auf Kfz bezieht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zum Scannen einer Wiki-Seite
On Thu, 02 Sep 2010 08:55:38 +0200 Jan Tappenbeck wrote: > Du hattest mir mal ein Script für das Auslesen einer Wiki-Tabelle > geschrieben. Darin gibt es folgende Unterfunktion: > > sub get_browse_link [...] ># wenn es wie ein OSM-Link aussieht nummer herausschneiden >if($elm=~m!\[http://www.openstreetmap.org/browse/\w+/(\d+)\]!) [...] > Wenn der OSM Link nicht > > [http://www.openstreetmap.org/browse/node/442860074] > > ist sondern > > * [http://www.openstreetmap.org/browse/node/442860074/history] > > ist dann ist es doch sicherlich auch möglich die Nummer zu extrahieren. > > Kannst Du mir sagen wie der RegEx dann aussehen müßte? if($elm=~m!\[http://www.openstreetmap.org/browse/\w+/(\d+)(/history)?\]!) Hanno ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Hallo Martin. On 02.09.2010 00:30, M∡rtin Koppenhoefer wrote: Am 2. September 2010 00:22 schrieb M∡rtin Koppenhoefer: egal, wie das Tag heisst, aber wenn wir für highways grundsätzlich bauliche Trennung fordern wird es für den Mapper einfacher, als wenn man das alles mischt. prinzipiell funktioniert das mit den getrennten ways für sog. bauliche Trennung sowieso nicht so recht: Man könnte ja die Bordsteinkante auch als bauliche Trennung auffassen. Danke ;) es lag mir auf der Zunge ;) Es ist immer die Frage, für wen getrennt. Für Fußgänger (oder auch z.B: Fahrräder) sind andererseits Stellen, die für Autos baulich getrennt sind, oft durchlässig. Auch kann man kann oft an jeder beliebigen Stelle die Straßenseite wechseln. Oder eben auch nicht, weil es Brüstungen, Leitplanken, Gebüsch, Mauern oder Grasstreifen gibt. oder Bordsteinkanten - die für Rollstuhlfahrer unüberwindbare Hindernisse darstellen können. Es ist eben alles eine Frage der Perspektive. Diese Trennung zu definieren um die Durchlässigkeit abzuschätzen wäre nicht schlecht (s. Area-Relation ;-) ). Diese Trennung lässt sich aber nicht als Standard für nebeneinanderliegende Wege definieren. Theoretisch könnte man dies tun, wenn man width=* für alle betroffenen Wege zur Pflicht macht, da sonst nicht abschätzbar ist, ob noch etwas zwischen den Wegen liegt. Dein Argument der baulichen Trennung hinkt übrigens überall da, wo Abbiegespuren als *-link eingetragen werden. Beispiele (nein, nicht meine eigenen Eintragungen, wenn auch in Paderborn): http://www.openstreetmap.org/?lat=51.70718&lon=8.77665&zoom=17&layers=M http://www.openstreetmap.org/?lat=51.70166&lon=8.73868&zoom=17&layers=M Für ein sauberes Datenmodell sollten wir meines Erachtens auf Dauer Straßen und Wege als logische Verbindungen eines Routing-Graphen auffassen. Dass Renderer dies zu grafischen Karten extrapolieren können, ist um so besser. Für Routing-Zwecke sind aber Fußwege höchst relevant (solange wir nicht zum Hund-ausführen das Auto nehmen müssen), mindestens ebenso wie für Kfz-Routing Abbiegebeschränkungen etc. spannend sind. Das als Datenmüll zu bezeichnen schränkt die OpenStreetMap auf eine Kfz-Karte ein, die sie nicht ist. Wenn doch, dann beantrage ich mal provozierend, aber nicht ganz ernst gemeint, sämtliche Stromnetz-Eigenschaften, Bäume, Bänke, Kanu-Umsatzstellen, Staustufen und Umweltgift-Informationen fallenzulassen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
