Re: [Talk-de] Linie endet an Gebiet
Hi, du meinst das hier? http://www.openstreetmap.org/?lat=53.988759lon=10.766189zoom=18layers=M In der aktuellen Fassung ist hier nichts falsch. Was hast du denn geändert? erhalte von JOSM die Warnung: Linie endet an Gebiet Diese Meldung bedeutet, dass die Straße mit einem landuse oder anderen Fläche verbunden ist, die kein highway=* ist. Hmm.. Wenn ich mir das BING -Bild hier anschaue ist das landuse=gras der Fläche entlang der Danziger Allee falsch, das sind doch offenbar Parkplätze und Bäume. Gruß, Micha. On Wednesday 05 June 2013 16:51:35 MVX wrote: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ 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] Bugs
Einfach als non-reproduceable/software bug mit Kommentar Zu wenig Info schließen. So mach ich das normalerweise mit solchen Meldungen. Wobei manchmal kann man aus den eingezeichneten Linien der berechneten Route und/oder dem gefahrenem Weg erkennen was gemeint sein könnte. In diesem Fall tippe ich mal darauf, dass der bemängelte Fehler das Routingverhalten ist. d.h. das der Ersteller hält die Route für nicht korrekt berechnet. Vermutlich hält er die erste Linksabiegung für falsch und meint das es rechtsrum schneller ginge. (Er hat ja fast als Routing profile eingestellt und die andere Variante ist ja vielleicht eine Sekunde schneller :-) ) Aber das ist reine Spekulation er schreibt ja nicht was er als falsch anmahnt. Micha. On Sunday 04 March 2012 16:46:01 Rainer Knaepper wrote: Moin, erklärt mir jemand, was man mit solchen Bugs anfangen soll? http://www.mapdust.com/detail/1761185 Hier in der Gegend gibt es etliche davon, fast alle ohne jeden Hinweis, was denn nu falsch ist. Rainer (rätselnd) ___ 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] Fwd: AW: Kontaktpersonen im Raum Frankfurt/ Hanau
Weitere Infos: In Frankfurt gibt es einen OSM Stammtisch der sich regelmäßig trifft. Das nächste Treffen wird am 6. März in der brotfabrik kp21 in Frankfurt-Hausen sein. http://www.openstreetmap.org/?mlat=50.13136mlon=8.62613zoom=18 Mehr dazu ist auch im Wiki zu finden: http://wiki.openstreetmap.org/wiki/Frankfurt_am_Main/OSM-Frühschoppen Für einen persönlichen Kontakt kann er sich auch gern an mich wenden. Gruß, Micha. Original-Nachricht Datum: Tue, 07 Feb 2012 19:54:50 +0100 Von: Georg Lösel georg.loe...@fossgis.de An: talk-de@openstreetmap.org Betreff: [Talk-de] Fwd: AW: Kontaktpersonen im Raum Frankfurt/ Hanau -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo i die Runde, ein pensionierter Vermesser möchte bei OSM mitmachen und kommt mit der Anmeldung bei der Liste nicht ganz zu recht. Kann einer der Admins mal bitte schauen was da los ist? Antwort bitte direkt an mich. Danke Gruß Georg - Original-Nachricht Betreff: AW: Kontaktpersonen im Raum Frankfurt/ Hanau Datum:Tue, 7 Feb 2012 13:12:42 +0100 Von: Günter Schölla guenter.schoe...@gmx.de An: 'Georg Lösel' georg.loe...@fossgis.de Hallo Herr Lösel, habe mich über Ihre schnelle Antwort sehr gefreut, und habe mich auch sofort bei OSM angemeldet wie von Ihnen unter [1] http://lists.openstreetmap.org/listinfo/talk-de empfohlen und dann per email mitgeteilt, dass ich bei OSM mitwirken möchte. Daraufhin habe ich folgende Meldung bekommen: Habe aber bis heute weder eine Freigabe noch eine Mitteilung über eine Ablehnung durch den Moderator erhalten. Finde ich schon sehr seltsam, dass man auf eine Genehmigung zur Mitwirkung in einem Team als Fachmann so lange warten muss. Können Sie mir weiterhelfen was ich noch tun kann, um möglichst bald Kontaktdaten von einem Kollegen in meiner Gegend zu bekommen. Würde mich sehr freuen von Ihnen einen Hinweis zu bekommen. Im Voraus herzlichen Dank für Ihre Unterstützung. Mit freundlichen Grüßen Günter Schölla __ Günter Schölla Dipl. Ing. Vermessung Im Lochseif 58 63517 Rodenbach email: guenter.schoe...@gmx.de Tel.: 06184 / 520383 Mobil: 01520 / 1737018 - -Ursprüngliche Nachricht- Von: Georg Lösel [mailto:georg.loe...@fossgis.de] Gesendet: Montag, 30. Januar 2012 20:50 An: Günter Schölla Cc: vorst...@fossgis.de Betreff: Re: Kontaktpersonen im Raum Frankfurt/ Hanau - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sehr geehrter Herr Schölla, herzlichen Dank für Ihre Nachricht (auch auf dem Telefon). Wir freuen uns dass Sie als Fachmann sich dem Thema OSM zuwenden und Ihr Wissen in diesem Projekt einbringen möchten. Für einen direkten Kontakt empfehle ich Ihnen sich auf der deutschen Mailingliste [1] einzutragen und dort dann nach einem Kontakt im Frankfurter Raum zu fragen. Die Community ist sehr aktiv und es wird sich mit Sicherheit jemand finden, der Ihnen den Einstieg in OSM erleichtert Sie könnten eventuell auch direkt zum Frühschoppen gehen der regelmäßig in Frankfurt stattfindet [2]. Dort können Sie dann direkt mit den Leuten vor Ort sprechen. Allgemeine Informationen über das Mitmachen bei OSM finden sie unter [3] Wir hoffen diese Informationen helfen Ihnen weiter. Wenn Sie darüber hinaus Fragen oder Anregungen haben, stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen Georg Lösel - - - - [1] http://lists.openstreetmap.org/listinfo/talk-de [2] https://wiki.openstreetmap.org/wiki/Frankfurt_am_Main/OSM-Fr%C3%BChschoppen [3] https://wiki.openstreetmap.org/wiki/DE:Getting_Involved Am 30.01.2012 15:21, schrieb Günter Schölla: Sehr geehrte Damen und Herren, bin Vermessungsingenieur und seit Juni 2011 in Altersteilzeit. Möchte mich weiterhin vermessungstechnisch / kartographisch betätigen und bei OSM mitmachen. Suche nach einem Ansprechpartner, der mich in die Thematik einführt und auch bei der Anschaffung eines Navi (Garmin, etc.) berät. Könnten Sie mir bei der Herstellung eines persönlichen Kontakts (Emailadresse, Telefonnummer) behilflich sein? Im Voraus herzlichen Dank Mit freundlichen Grüßen Günter Schölla /__/ /Günter Schölla/ /Dipl. Ing. Vermessung/ /Im Lochseif 58/ /63517 Rodenbach/ /email: guenter.schoe...@gmx.de/ /Tel.: 06184 / 520383/ /Mobil: 01520 / 1737018/
Re: [Talk-de] Lizenzwechler
Soviel ich mich erinnere wurden von AND nicht nur Daten für NL sondern auch für Indien und China bereitgestellt. Vielleicht sind die Indien oder China AND Daten nicht relizensierbar? Micha H. Am 10.11.2010 21:54, schrieb Fabian Schmidt: Am 10.11.10 schrieb Florian Gross: Ich rate mal: Weil der Importeur nicht zugestimmt hat. Oder gab es dafür einen extra Account? Den gibt es (AND). Frag mal bei talk oder talk-nl. Auf der Seite http://wiki.openstreetmap.org/wiki/Import/Catalogue ist AND in der Spalte ODBL-OK als grün markiert. Deshalb hat mich die rote Stadt gewundert. Aber ok, der Importeur muss halt auch Zustimmer sein. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Und genau diese dir so wichtige Community spaltest DU mit einem Fork. Micha H. Das wichtigste sind bei OSM nicht die Daten sondern die community die die Daten erfasst und weiter pflegt. Ohne community keine Daten. Wenn ich aus der Datenbank etwas lösche bedeutet das nicht das in der Realität dort ein schwarzes Loch entsteht. Man kann jederzeit wieder mappen. Das sollte natürlich in einem erträglichen Rahmen bleiben. Das mit einem Fork dann aber grundsätzlich Sachen doppelt erfasst würden ist maximal Unsinnig. Ich für meinen Teil will an der Integrität des Datenbestandes festhalten: kein Entfernen von Daten oder Verfälschen von Daten (durch Rückwerfen auf veraltete Versionen, wenn ein bearbeiter aus der Kette rausfällt). In einem DATENbankprojekt sind die DATEN das wichtigste und keine Lizenztheorie ... ___ 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] OSM-Garmin-Karten bei Ebay
On Monday 12 April 2010 21:34:18 Christian Hartnick wrote: Entschuldigt bitte, aber ihr habt das Prinzip von ebay schon verstanden, oder? Bei einer (ebay-) Auktion bezahlt jeder das, was er bereit ist, für ein Produkt zu zahlen. Ist schon klar, das Ebay eine Auktionsplattform ist. Aber gerade die hohen erzielten Preise zeigen ja, das der normale Nutzer eben nicht die Lizenzen versteht. Das hat nichts mit Kennen von Lizenzen oder Ähnlichem zu tun. Man sieht auf E- Bay oft Auktionen für diverse Neuware.-Artikel, die am Ende teuerer verkauft werden als beim normalen Online-Händler. Teilweise sogar teuerer als im nächsten Blöd-Markt oder gar dem Fachhändler um die Ecke. Micha H. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk
Hi, Achtung dass ihr euch da (als nicht Englisch-Muttersprachler) nicht in sprachlichen Missverständnissen verrennt. shop wird im Englischen nämlich durchaus auch für Handwerker-Werkstätten benutzt! D.h. Ein carpenter sagt durchaus, I'm going into my shop, wenn er zum Arbeiten geht und meint damit seine Werkstatt und nicht etwa den Verkaufsraum. Micha H. Hi Ich tagge hier auf dem Land und wir haben im Ort 2 Tischler [1], 3 Metallbauer [2] und einen Landmaschinenbau [3]. Keines davon ist ein Shop oder eine Fabrik. Ich würde es am ehesten als Handwerk klassifizieren. Daher finde ich shop=* oder eine Kombination aus man_made=works/works=* nicht passend. Dafür habe ich im Wiki noch keine Tagging Guideline gefunden. Auf der Mailingliste habe ich einen Vorschlag [4] für einen neuen Key craft gefunden, der mir eigentlich seht gut gefällt. OSMDoc ist der Tag auch nicht ganz unbekannt [5]. Ich würde ihn gerne in die MapFeatures liste aufnehmen, vorher jedoch noch um eine Kommentare bitten. Dieser Tag würde, ähnlich zu shop=* verwendet werden, jedoch für Gewerbe, die nicht nur verkaufen sondern bei bedarf erst Herstellen bzw. Verarbeiten, und bei denen das Herstellen/Verarbeiten im Vordergrund steht. Mögliche Kombinationen wären: craft=tailor (Schneider) craft=roofer (Dachdecker) craft=carpenter (Tischler) craft=electrician (Elektriker) craft=gardening (Gartenbau) craft=metal_construction (Metallbau) craft=painter (Maler) craft=paver (Fliesenleger) craft=carpet_layer (Teppichleger) craft=plasterer (Verputzer) Ich habe bereits einen Draft in meinem User-Bereich angelegt: http://wiki.openstreetmap.org/wiki/User:MaZderMind/DE:Key:craft http://wiki.openstreetmap.org/wiki/User:MaZderMind/Key:craft Lg, Peter [1] Maßgeschneiderte Schränke, Änderungen an Möbeln, Küchen, Innenausbau, Parkett, Holzdecken -- also definitiv kein Möbelhaus [2] Gitter, Treppen, Tore, Zäune, Rampen (Landwirtschaft) -- also definitiv kein Baumarkt [3] Anhänger für Traktoren, Metallfässer für den Weinbau, Zäune und Tore für Weiden [4]http://lists.openstreetmap.org/pipermail/talk-de/2009-March/041467.html [5]http://osmdoc.com/en/tag/craft/#values ___ 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] Garmin in USB-Zustand versetzen
Wie wär es mir gpsbabel -wt -i garmin -fusb: -o gpx -F wpt-trk-$date.gpx: Micha H. Jan Tappenbeck o...@tappenbeck.net wrote: Wegepunkte kann ich Dir morgen liefern. Häh? Das ist doch nicht das Problem: ~/ cat bin/gpstransfer #!/bin/bash #set -x date=$(date +%Y%m%d) gpsbabel $* -i garmin -fusb: -o gpx -F wpt-$date.gpx Ich würde halt gerne ohne in den Mass-Storage-Mode umzuschalten auch an die Trackdaten rankommen. Alternativ das hier im thread gewünschte umschalten in Mass-Storage-Mode per Befehl. Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Reit und Wanderkarte - ein bisschen Feedback
On Monday 09 February 2009 09:00:55 Nop wrote: Hallo! 4) Spielplatz Icon Sehr schöne Idee, besser als z.B. die aktuelle Schaukel beim JOSM Hast Du's wirklich erkannt? Ich hatte da so meine Zweifel was dieses Icon angeht. :-) Sofort erkannt! Wenn du da ne PD SVG Quelle hast, bau ich das sofort ohne Skrupel in den JOSM ein! :-) Sorry. Selbst handgepixelt. d) Haltestellen-Icon Paßt für U-/S-Bahn/DB noch nicht, da das Schild dort ja wirklich anders aussieht. Grundlegend die Icons zu nehmen, wie sie auch in der Realität auftreten find ich aber gut, siehe 2.). Für einen Stadtplan würde ich Dir zustimmen und das genau unterscheiden. Auf einer Wanderkarte ist die Haltestelle nur eine mindere Orientierungshilfe, da tut es ein Icon für alle Typen. Das ist jetzt der einzige Punkt wo ich dir widersprechen muß, obwohl ich nur selten Wanderer bin ;-) Wenn da ein Icon auftaucht, was definitiv nach einer Bushaltestelle aussieht, sollte da auch eine Bushaltestelle sein. Alles andere verwirrt doch nur. Außerdem geht es bei einer Wanderkarte gerade bei sowas ja nicht nur um die Orientierung, sondern auch um: wie komme ich da mit ÖPNV hin und wieder zurück. Sehe da nicht wirklich ein Problem. - Bushaltestellen sind Bushaltestellen - Bahnhöfe erkennt man an den sehr dominant gerenderten Schienen - Und U-Bahnen? In einer Wandergegend? Das gibts durchaus. In Frankfurt (Main) geht die U3 bis in den Taunus rein. Die Endhaltestelle Oberursel/Hohemark und ist Start- bzw Endpunkt für viele Wanderrouten. Micha H. Aber ich kann mal ein Zusatzicon einbauen wenn mir jemand ein hübsches zuschickt. :-) bye Nop ___ 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] Routingfähige De-Karte
Evtl. liegt es auch daran dass in den OSM Tiles die die Quelle der img tiles sind die Grenzen der Kachel fehlen D.h. dort fehlt das bound XML element mit den eigentlichen Kachelgrenzen. Das ist im übrigen auch warum im Mapsource an manchen Stellen die residential Fläche eines Ortes (z.B. in Glauberg 50.314N 9.001E) über einige Straßen gezeichnet wird. mkgmap schneidet die Karte dann nicht direkt an den Kachelgrenzen ab sondern nimmt auch noch die 'überstehenden' Wege und Flächen mit. Diese sind dann aber auch jeweils in den Kacheln also in der ganzen Karte mindestens doppelt vorhanden. Diese doppelten Wege bringen dann vermutlich das Routing durcheinander da es da ja auch keine in beiden Kacheln auf der gleichen Position liegende NOD-Node giebt den in der einen Kachel ist diese ja wahrscheinlich am einen in der anderen am anderen Ende des Wegs. MichaH. Am 20. Januar 2009 10:25 schrieb Bernd Wurst be...@bwurst.org: Naja, aber es ist doch klar, dass das irgendwann gehen muss. Auch Garmin bekommt es hin, dass man über Kachelgrenzen drüber routen kann. Vielleicht müssen dazu irgendwelche IDs aneinander angepasst werden oder whatever. Das bekommen die schon noch irgendwann hin. Moin! Ich habe neulich mal die mkgmap-dev mailingliste durchgelesen, weil mich interessierte, wie viel da im Moment passiert. Hier http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2008q4/000145.html ist ein commit beschrieben, der NOD3-Nodes an den Kachelgrenzen möglich macht, die für das routing über diese hinweg gebraucht werden. Irgendwo anders stand auch, daß dies das einzige sei, was dafür nötig wäre und das routen über Kachelgrenzen jetzt einigermaßen zuverlässig funktioniere... @Carsten: Ich habe versucht, in qlandkartegt alle Kacheln auszuwählen und als gmapsupp.img zu exportieren. Die resultierende Datei ist auch über 500mb groß, aber ich kann z.B. bei Köln ab 7° östlich auf meinem Garmin etrex Vista keine Objekte auswählen und auch nicht routen (westlich 7° innerhalb Kölns funktionert es...). Ich war schon in qlandkartegt skeptisch, weil es nicht so aussah, als seien wirklich alle Kacheln gewählt, aber da die Dateigröße stimmte... MfG, Martin ___ 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] Routingfähige De-Karte
On Tuesday 20 January 2009 20:14:31 Carsten Schwede wrote: Keine Kartenelemente sind doppelt vorhanden. Ein Weg wird genau in eine Kachel gepackt und dann nicht noch einmal behandelt. Ahh.. dann ist dein Cutter anders als Fredriks C osmcut aus dem osm svn, der einen Weg in alle (max 4) Kacheln einfügt, aus denen er Nodes enthält. Aber das ist m.M. trotzdem das Problem. Wenn ich das Germin Format mit NOD3 Nodes richtig verstehe, müsste dann nämlich auf allen Kreuzungspunkten der Wege, die in andere Kacheln hineinragen, mit den Wegen aus diesen anderen Kachel ein NOD3 Punkt liegen. mkgmap hat aber keine Möglichkeit zu wissen welche Nodes des Wegs (außerhalb der Kachel) eine Kreuzung ist und so dann als ein NOD3 zu setzten wäre und bei welchen nicht. Also m.M. nach bleibt es dabei, für über Kachelgrenzen routingfähige Karten müssen die osm Quelle ein bounds element mit der Kachelgrenze enthalten, so dass mkgmap die Kachel dann auf genau diese Grenze schneiden kann. Allerding muss dann auch jeder Weg der Kachelgrenzen überschneidet in alle OSM-Kacheln, die er trifft rein (wie es Frederiks osmcut macht), damit mkgmap ihn in jeder Kachel an der Grenze schneiden und dort die NOD3-Node(s) setzen kann. Micha H. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte
Das Teil sieht wirklich gut aus, klasse Arbeit. He, das freut mich daß Du sie für so einen prominenten Platz schon für brauchbar hältst. Du hast gesehen, daß es momentan nur Teilbereiche sind, die ich auf Anfrage sukzessive erweitere? Dann frage ich mal an ob du den Mittelrhein-Ausschnitt etwas nach Süden und Osten um den Taunus erweitern könntest d.h. Im Süden bis zum Main und im Osten bis Friedberg (liegt nördlich von Frankfurt). Micha H. bye Nop [1] http://wiki.openstreetmap.org/wiki/OSM_Composer [2] http://wiki.openstreetmap.org/wiki/Hiking_Map#Hiking_and_Riding_map ___ 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] Worldfile vom 3. Dezember 2008
HI, Stimmt, MapSource schmiert nicht mehr ab mit den neuen Karten. Dummerweise zeigt es aber auch nix mehr an. GAR NIX. Und zwar mit und ohne teddy.typ :( Die letzte mkgmap svn version bei der es noch funktioniert ist 726. Man kann mit dieser version das overview img und tdb file aus den neuen img Kacheln neu erzeugen und dann kann man auch die neue Worldmap wieder in MapSource nutzen. Micha H. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 26.11.2008
Hi, Hi Michael, Diese Karte funktioniert einwandfrei in meinen MapSource (V6.13.7) Und mit MapSource 6.14.1? Das hatte ich einmal installiert aber wieder runtergeworfen, diese Version ist a) noch recht buggy, und b) die neue Darstellung drückt heftig auf die Performanz. Du darfst mir gerne mal ein paar Kacheln um Böblingen rum zuschicken zum Test. Ich hab nicht die Resourcen um das selber zu rendern. -- PM Micha H. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 26.11.2008
Es scheint aber kein Bug in mkgmap zu sein. Ich habe die germany.osm in 0.5 Grad Kacheln geschnitten und mit der gleichen mkgmap svn version, die Carsten für dieses Worldfile benutzt hat, ins Garmin format konvertiert. Diese Karte funktioniert einwandfrei in meinen MapSource (V6.13.7) Installationen (sowohl auf Windows wie auch mit 'wine' auf Linux). Vielleicht ist inzwischen die OSM Datenmenge schon wieder so groß, dass die Datenfülle einiger 1Grad Kacheln (Berlin, Hamburg?) an irgendeine interne MapSource Speichergrenze stößt. BTW: Ich habe festgestellt, dass die Kachelgöße Anzeige in MapSource mit den 0.5 Grad Kacheln flächendeckend ist, d.h. beim Auswählen der zu übretragenden Kacheln in MapSource ist der gesamte Bereich flächendeckend unterlegt. Ab 0.6 Grad Kacheln aber entstehen diese Lücken in der Abdeckung, die in Wahrheit gar nicht vorhanden sind. Micha H. Am 28. November 2008 11:45 schrieb Sven Geggus [EMAIL PROTECTED]: Holger Issle [EMAIL PROTECTED] wrote: Die Karte in der derzeitigen Version tut nicht mit MapSource, und ich kann mit sehr beherrschen die auf einen Garmin zu spielen und zu riskieren daß der deswegen zum teuren Schrotthaufen wird. Ich habe betriebssystembedingt kein Mapsource und kann Dir bestätigen, dass die img Datei vom Mittwoch auf meinem Gpsmap läuft. Ich kopiere die Datei immer im Mass-Storage mode. Sven das ist sicher richtig, aber richtig ist auch, dass es bisher im Mapsource funktioniert hat und jetzt mit der neuen Version nicht mehr, irgendwas hat sich daher geaendert, im Sinne von Kompatibilitaet. Wenn man das herausfinden koennte, woran es liegt, waere es sicher nicht schlecht. Gruss Martin ___ 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] Lücken zwischen Kacheln in Mapsource/Q landkarte
Hi, Nach einigen Versuchen scheint das Problem zu sein, dass die img Kacheln Wege enthalten, die über die eigentliche Kachelgrenze hinausgehen. Dadurch kommt offenbar mkgmap beim Berechnen der tdb bzw übersichts img datei durcheinander und berechnet die Kachelgrenzen falsch. Die Kachelgrenzen im tdp bzw overview.img sind aber das, was bei der Auswahl von Kacheln benutzt wird. Die neuere (SVN-Version) von mkgmap können die Kacheln exact an den kachelgrenzen scheinten. Dazu muss in der OSM-source aber die boundingbox der Kachel stehen (also ein bounds XML element mit den kachelgrenzen). leider schreibt osmcut.c dieses element nicht, wenn es das planet.osm zerschneidet. Vor kurzem habe ich mal osmcut.c entsprechend angepasst und auf germany.osm losgelassen. Die resultierenden img kacheln Waren dann sauber beschnitten und beim Auswählen in MapSourse bzw QLandkarte war dann auch die Anzeige der ausgewählten Kacheln korrekt d.h. der ausgewählte Bereich war lückenlos - allerding seltsamerweise an den Rändern leicht überlappend obwohl die Kacheln selst exakt auf 'anstoss' waren. Wenn 'dein' OSMCutter Tool dieses bounds-Tag also in die OSM-Kacheln schreibt (natürlich mit den korrekten BB Werten), sollte dieses Anzeige-Problem nicht mehr auftreten. Micha H. Hallo, ich habe das Problem mit der Übersichtskarte bereits auf meiner Wiki-Seite beschrieben, dorst steht auch ein Workaround dafür. Aber gleich hier nochmal kurz: Die Kacheln sind lückenlos, das Phänomen auf der Übersichtskarte liegt an der unzureichenden Übersichtkarte. Um nun weniger Kacheln zu einem Datensatz hinzuzufügen als die komplette Karte zoomt man auf der Übersichtskarte etwas aus, und zieht den Bereich den man haben möchte großzügig auf. Die ausgewählten Kacheln erscheinen zwar so, als ob da Lücken wären, sind aber vollständig. (nur ein kleiner Bereich einer Kachel ist jeweils anklickbar bzw. erscheint ausgewählt, es ist jedoch tatsächlich die komplette Kachel ausgewählt) Eventuell kann man nun vom Rand einige Kacheln abwählen oder noch ein paar am Rand dazuklicken. Mit etwas Geschick kriegt man raus, wo sich die anklickbare Fläche befindet. Nun von anderen Karten weitere Kacheln hinzufügen, und aufs GPS übertragen. Wenn die komplette Karte (z.B. das Deutschland-File) aufs GPS soll mit weiteren Karten zusammen, dann einfach soweit auszoomen, bis der komplette Bereich derm Karte zu sehen ist, dann mit der Maus so groß aufziehen, dass alles umfasst wird und damit auch ausgewählt ist. Moritz schrieb: Morgen Holger, danke für die Antwort. Ich bin der Mapsource-Bedienung durchaus mächtig ;-) und auch über die Feinheiten weiß ich Bescheid Es ist so wie Willi sagte, da sind Lücken zwischen den Kacheln. Hier mal ein Bild davon: http://s1b.directupload.net/file/d/1609/cf4e6j8h_png.htm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 11.6.2008
--- Ich tippe auf die Vorschaukarte. Sieht ganz danach aus. Uebrigens, es gibt von Garmin einen neue 3.14.x Beta-Version von MapSource. Dort meldet MapSource bei einigen installierten Fremdkarten - u.A. die OSM Karten - dass diese Defekt sind und deinstalliert werden MUESSEN. Danach beendet sich MapSource sofort und startet erst wenn die beanstandeten Karten aus der Registry entfernt wurden. (? Klappt die Übertragung der Karte auf das Garmin wenn man die alte Vorschaukarte nutzt ?? - Hab ich noch nicht getestet) Das Uebertragenb aufs Geraet klappt auch wenn die Vorschaukarte vom 11. 6. benutzt wird. Man muss nur ein abgespeichertes Kartenset (gdb) verwenden und darf auf keinen Fall die OSM-Karte anzeigen (weder als zuletzt gesehene dem Einspielen der neuen Version -da sie dann ja beim Start sofort angezeigt werden wuerde - Crash, noch vor dem Uebertragen auf Geraet Umschalten auf die OSM Karte - Crash :-( ). Micha H. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Worldfile vom 11.6.2008
Sieht ganz danach aus. Uebrigens, es gibt von Garmin einen neue 3.14.x Beta-Version von MapSource. Dort meldet MapSource bei einigen installierten Fremdkarten - u.A. die OSM Karten - dass diese Defekt sind und deinstalliert werden MUESSEN. Danach beendet sich MapSource sofort und startet erst wenn die beanstandeten Karten aus der Registry entfernt wurden. Ich habe mir mal das MapSetToolKit heruntergeladen. http://cypherman1.googlepages.com/home Es hat eine CheckRegistry-Funktion Dort werden fuer das TDB und Stefans (Saftl) TYP file falsche (d.h. unterschiedliche) Familiy IDs gemeldet: TDB hat Family ID von 0 und einen Code von 42. TYP hat Family ID von 6315 und einen Code von 1. Da scheint das Family ID-Feld im TDB mit dem Code-Feld vertauscht zu sein. Ausserdem: Ich wollte das TYP file etwas abaendern bzw neu zu erzeugen und habe versucht mit GenTyp (Link auf obiger Website) ein neues zu generieren. Aber GenTyp weigert sich wegen der Family ID 0 des OSM TDB Files dieses als Basis zu nehmen. Ach ja ich habe das OSM Worldfile als Family registriert (und -ganz nebenbei - MapSource laeuft auf Linux mittels wine :-) ). --- REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Garmin\Mapsource\Families\OSM-WORLD] ID=hex:2a,00 Typ=C:\\Program Files\\Garmin\\OSM-World\\6324.TYP [HKEY_LOCAL_MACHINE\Software\Garmin\Mapsource\Families\OSM-WORLD\1] Bmap=C:\\Program Files\\Garmin\\OSM-World\\6324.img Loc=C:\\Program Files\\Garmin\\OSM-World\\ Tdb=C:\\Program Files\\Garmin\\OSM-World\\6324.tdb Typ=C:\\Program Files\\Garmin\\OSM-World\\6324.typ --- Micha H. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wiederherstellen einer geloeschten Relation
Da ich der Schuldige war, habe ich nun versucht die geloeschte Relation auf die geschilderte Weise wiederherzustellen. Also habe ich die vorletzte revision Relation aus der Histoy kopiert, den way den ich geloescht habe (weil er als duplikat ueber einem anderen way lag, der ebenfalls in der Relation war) aus der relation rausgenommen. das OSM file in JOSM geladen, und den upload angestossen. JOSM meldet keine Fehler beim upload aber die Releation wird nicht wiederhergestellt. Das schein ein Bug in JOSM zu sein mit curl bekam ich dann beim upload einen 412'er Fehler. Also nachgeschaut und festgestellt, dass noch einige weitere ways nicht mehr existieren, diese auch entfernt und nochmal (mir curl) hochgeladen. leider immer noch ein 412 precondition failed. Die jetzt noch referenzierten ways sind jetzt aber alle noch visible=true. Ich verstehe also nicht warum dann immer noch ein 412 Fehler kommt (Bug in der API?). Irgendwelche Tips wie da weiter vorzugehen waere? Micha. Hallo, Es geht um die Relation id=4388 ref=B 14 Der letzte Eintrag im History-file ist: relation id=4388 visible=false timestamp=2008-06-05T13:26:14+01:00 user=xx / Na, wenn Du die History schon hast, ist das doch die halbe Miete. Nimm die VORLETZTE Version aus der History und baue Dir damit im Texteditor ein File, das so aussieht: osm version=0.5 relation action=modify id=4388 visible=true ... ... ... ... /relation /osm Also einfach 1:1 die Relation nehmen, das osm.../osm drum, und das action=modify reintun. Dann oeffnest Du Deine Datei mit JOSM (Du wirst nichts angezeigt bekommen, aber das macht nichts) und klickst auf Upload. Fertig! (Ausser, jemand hat nicht nur die Relation, sondern auch beteiligte Objekte geloescht. Dann bekommst Du an dieser Stelle precondition failed und musst erst auf aehnliche Weise die Objekte wiederherstellen, die fehlen.) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Neues Worldfile vom 28.5.08
Warum das Rad zweimal erfinden? So eine SRTM Höhenlinen Karte im Garmin IMG Format gibts schon. So weit ich weiß ist sie auch transparent d.h. kann über jede andere Gamrin Karte (Von D) gelegt werden. http://www.glade-web.de/GLADE_geocaching/maps/TOPO_D_SRTM.zip MichaH. Original-Nachricht Datum: Thu, 29 May 2008 21:59:51 +0200 Von: Stefan Seifert [EMAIL PROTECTED] An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Neues Worldfile vom 28.5.08 ist ja kein Problem, einfach nicht mit den OSM Daten zusammenführen, durch mkgmap jagen (im feature file nur Höhenlinien) und schon hat man die Höhenkarte. Zum transparent machen gab es ein Tool, muss ich mal suchen. Das Problem ist aber, die OSM Karte hat dann keine Höheninformationen. Ich würde in einer Karte zum Wandern oder Radfahren aber gerne die Höheninformationen drin haben, dann kann man Routen planen und schon in etwa die Höhenmeter kalkulieren. Ausserdem sieht man sonst die Höhenlinien nicht in Mapsource, da das Ding nur eine Karte gleichzeitig darstellen kann... Ich würde es sehr begrüßen, wenn Höhenlinien mit vernünftigen Abständen (z.B. 20m) in Computerteddys Karte auftauchen würden. Mein Typfile ist übrigens schon drauf angepasst ;-) Gruß Stefan FreeWorld schrieb: Holger Issle schrieb: Hi, Ich habe es folgendermaßen probiert: srtm2osm.exe ... @Computerteddy: So in der Art müsste es doch auch automatisch funktionieren, oder? Einfach nur Deine Kacheln noch mit srtm2osm mit Höhenlinien versehen und dann erst durch mkgmap jagen... Dann sind aber die Karten *mit* Höhenlinien und selbige nicht abschaltbar. Damit Karten mit _nur_ Höhenlinien machen und die als transparent markieren, und zusammen mit der Straßenkarte einblenden wäre besser, oder? Dann hätte man auch auf den käuflichen Straßenkarten Höhenlinien drauf ;) Da würde ich auch zustimmen. Ist doch eigentlich kein Problem, ein Mal ne transparente Garminkarte nur mit Höhenlinien zu machen. Diese könnte man dann einfach mit der ganz normal gerenderten linken und denn ist das doch alles toll - oder stell ich mir das zu einfach vor? Grüße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Worldfile vom 9. April 2008
Hallo, da mir aufgefallen ist, dass sich Wege die als tertiary getagt sind nicht von esidentialunterscheiden habe ich mir mal deine mkgmap mapfeatures.csv naeher angeschaut. Welchen Grund hast du da den Garmin Strassentyp 0x03 auszulassen? d.h. motorway = 0x01 trunk = 0x02 aber dann primary = 0x04 secondary = 0x05 tertiary = 0x06 residential, pedestrian, und unclassified = 0x06 Ich wuerde primary dir 0x03 geben und secondary und tertiarty dan entsprechend 0x04 und 0x05. Ich habe das fuer mich mal geaendert und mir die Frankfurt Kachel selbst neu berechnen lassen. Das ergebmis ist m.M. nach viel besser, da man nun auf dem Garmin GPS die wichtigeren tertiary-Durchgangsstrassen von den reicnen Wohnstrassen unterscheiden kann. Da ich dann gerade dabei war habe ich gleich noch ein paar fehlende bzw m.M. falsch zugeordnete Features geaendert. z.B. - leisure=park polygon war einem Garmin Nationalpark zugeordnet anstelle des ebenfalls vorhandene und deutlich besser passenden City-Parks. - sport=-golf polygon auf ein allgemeines sport-polygon es gibt aber auch ein Garmin golf-polygon. - Andere sport polygone haben ganz gefehlt. - aeroway=taxiway ways wurden zu einer 0x07-polyline d.h. der selber Typ wie highway=service ich habe das auf runway geaendert. Das stimmt zwar technisch nicht, aber ich habe in Garmins CNV9 gesehen, dass die das genauso machen. - ausserdem habe ich landuse=residential ebenfalls als Garmin city-polygon hinzugefuegt. Schau die resultierenden img-Kacheln einfach mal selbst an und entscheide ob du meine Aenderungen in dein allgemeines Release aufnimmst. Es waere aber nett zumindest die highway typen in diesem Schema zu verwenden, da sonst die in OSM ja vorhande -m.M. nach durchauf wichtige- Unterscheidung der tertiary-Durchgangstrassen von normalen Wohnstrassen im Garmin GPS mit deinen aktuellem mapfeatures.csv nicht gegeben ist. Keep up the good work, Micha H. Hallo, das neue Worldfile steht wie immer auf meiner Wikipage zum Download zur Verfügung. http://wiki.openstreetmap.org/index.php/User:Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Worldfile vom 9. April 2008
Argh... ich habe natuerlich (mal wieder) vergessen das cvs-file anzuhaengen. also hier ist es. MichaH. Hallo, da mir aufgefallen ist, dass sich Wege die als tertiary getagt sind nicht von esidentialunterscheiden habe ich mir mal deine mkgmap mapfeatures.csv naeher angeschaut. Welchen Grund hast du da den Garmin Strassentyp 0x03 auszulassen? d.h. motorway = 0x01 trunk = 0x02 aber dann primary = 0x04 secondary = 0x05 tertiary = 0x06 residential, pedestrian, und unclassified = 0x06 Ich wuerde primary dir 0x03 geben und secondary und tertiarty dan entsprechend 0x04 und 0x05. Ich habe das fuer mich mal geaendert und mir die Frankfurt Kachel selbst neu berechnen lassen. Das ergebmis ist m.M. nach viel besser, da man nun auf dem Garmin GPS die wichtigeren tertiary-Durchgangsstrassen von den reicnen Wohnstrassen unterscheiden kann. Da ich dann gerade dabei war habe ich gleich noch ein paar fehlende bzw m.M. falsch zugeordnete Features geaendert. z.B. - leisure=park polygon war einem Garmin Nationalpark zugeordnet anstelle des ebenfalls vorhandene und deutlich besser passenden City-Parks. - sport=-golf polygon auf ein allgemeines sport-polygon es gibt aber auch ein Garmin golf-polygon. - Andere sport polygone haben ganz gefehlt. - aeroway=taxiway ways wurden zu einer 0x07-polyline d.h. der selber Typ wie highway=service ich habe das auf runway geaendert. Das stimmt zwar technisch nicht, aber ich habe in Garmins CNV9 gesehen, dass die das genauso machen. - ausserdem habe ich landuse=residential ebenfalls als Garmin city-polygon hinzugefuegt. Schau die resultierenden img-Kacheln einfach mal selbst an und entscheide ob du meine Aenderungen in dein allgemeines Release aufnimmst. Es waere aber nett zumindest die highway typen in diesem Schema zu verwenden, da sonst die in OSM ja vorhande -m.M. nach durchauf wichtige- Unterscheidung der tertiary-Durchgangstrassen von normalen Wohnstrassen im Garmin GPS mit deinen aktuellem mapfeatures.csv nicht gegeben ist. Keep up the good work, Micha H. Hallo, das neue Worldfile steht wie immer auf meiner Wikipage zum Download zur Verfügung. http://wiki.openstreetmap.org/index.php/User:Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de point|aeroway|airport|0x59|0x00|22 point|amenity|atm|0x2f|0x06|24 point|amenity|bank|0x2f|0x06|24 point|amenity|bank;atm|0x2f|0x06|24 point|amenity|biergarten|0x2d|0x02|24 point|amenity|bus_station|0x2f|0x08|24 point|amenity|car_wash|0x2f|0x0e|24 point|amenity|cinema|0x2d|0x03|24 point|amenity|college|0x2c|0x05|24 point|amenity|courthouse|0x30|0x04|24 point|amenity|drinking_water|0x50|0x00|24 point|amenity|fast_food|0x2a|0x07|24 point|amenity|fire_station|0x30|0x08|24 point|amenity|fuel|0x2f|0x01|24 point|amenity|grave_yard|0x64|0x03|24 point|amenity|hospital|0x30|0x02|24 point|amenity|library|0x2c|0x03|24 point|amenity|parking|0x2f|0x0b|24 point|amenity|bicycle_parking|0x2f|0x0b|24 point|amenity|pharmacy|0x2e|0x05|24 point|amenity|place_of_worship|0x2c|0x0b|24 point|amenity|police|0x30|0x01|24 point|amenity|post_office|0x2f|0x05|24 point|amenity|post_box|0x2f|0x05|24 point|amenity|pub|0x46|0x00|24 point|amenity|public_building|0x30|0x03|24 point|amenity|restaurant|0x2a|0x00|24 point|amenity|school|0x2c|0x05|24 point|amenity|shelter|0x61|0x00|24 point|amenity|supermarket|0x2e|0x02|24 point|amenity|telephone|0x51|0x00|24 point|amenity|theatre|0x2d|0x01|24 point|amenity|toilets|0x4e|0x00|24 point|amenity|townhall|0x30|0x03|24 point|amenity|university|0x2c|0x05|24 point|amenity|zoo|0x2c|0x07|24 point|highway|bus_stop|0x2f|0x08|24 point|historic|museum|0x2c|0x02|24 point|historic|ruins|0x64|0x16|24 point|historic|castle|0x64|0x02|24 point|historic|memorial|0x2c|0x02|24 point|leisure|golf_course|0x2d|0x05|24 point|leisure|marina|0x43|0x00|24 point|leisure|park|0x2c|0x06|24 point|leisure|pitch|0x2c|0x08|24 point|leisure|sports_centre|0x2d|0x0a|24 point|leisure|stadium|0x2c|0x08|24 point|leisure|track|0x2c|0x08|24 point|man_made|tower|0x64|0x11|24 point|man_made|power_wind|0x64|0x00|24 point|man_made|reservoir_covered|0x65|0x0f|24 point|man_made|reservoir|0x65|0x0f|24 point|power|tower|0x64|0x00|24 point|natural|beach|0x66|0x04|20 point|natural|cliff|0x66|0x07|20 point|natural|peak|0x66|0x16|20 point|natural|spring|0x65|0x11|24 point|place|city|0x04||10 point|place|hamlet|0x11||24 point|place|suburb|0x0a||24 point|place|town|0x08||18 point|place|village|0x0b||20 point|railway|halt|0x2f|0x08|22 point|railway|station|0x2f|0x08|22 point|railway|tram_stop|0x2f|0x08|24 point|shop|bakers|0x2e|0x00|24 point|shop|bakery|0x2e|0x00|24 point|shop|butchers|0x2e|0x00|24 point|shop|butcher|0x2e|0x00|24 point|shop|convenience|0x2e|0x00|24 point|shop|doityourself|0x2e|0x00|24 point|shop|kiosk|0x2e|0x00|24 point|shop|outdoor|0x2e|0x00|24 point|shop|bicycle|0x2e|0x00|24
Re: [Talk-de] Worldfile vom 9. April 2008
residential, pedestrian, und unclassified = 0x06 Hier bin ich schon immer unschlüssig, eigentlich wäre pedestrian genauso wie Fußwege zu taggen. Werd ich wohl auch machen. Die anderen Beiden passen aber doch. Die sind hier auch nicht als Kritik zu verstehen gewesen, ich finde, dass pedestrian durchaus den gleichen typ wie die anderen haben kann. pedestrian auf den gleichen typ wie footway zu setzten - also 0x16 = Trail - finde ich nun wieder nicht so gut... - leisure=park polygon war einem Garmin Nationalpark zugeordnet anstelle des ebenfalls vorhandene und deutlich besser passenden City-Parks. Ein Park ist nicht unbedingt ein City-Park. In erster Linie habe ich diese Polygone entsprechen dem Aussehen auf dem GPS-Gerät und einige auch anhand der Wiedergabe in der Topo (1) angelegt. Schon aber ein Nationalpark ist leisure=park schon aber auch nicht :-). Laut garmin-feature list (in mkgmap/resources) gibt es noch National-Park1-3, State-Park1-3 und City-Park. Was ich bisher in OSM als leisure=park getagged gesehen habe, war fast ueberall am besten als Stadtpark oder Gruenflaeche in einem Ort beschrieben. - aeroway=taxiway ways wurden zu einer 0x07-polyline d.h. der selber Typ wie highway=service ich habe das auf runway geaendert. Das stimmt zwar technisch nicht, aber ich habe in Garmins CNV9 gesehen, dass die das genauso machen. - ausserdem habe ich landuse=residential ebenfalls als Garmin city-polygon hinzugefuegt. Bei der Runway finde ich die Idee sehr schlecht, sind ja keine Landebahnen, nicht alles was Garmin selbst macht, paßt auf insbesondere die europäischen Gegebenheiten. Ein Beispiel sind das fehlende Icon für Burgruinen, da gibt es dann nur Geisterstädte, weil es in Amerika halt keine Burgruinen gibt. Sicher aber andererseits hast du das aeroway=apron polygon auch auf runway gesetzt was noch weniger passend ist. Ein aeroway=apron ist ja noch eher ein Parkplatz, da dort ja die Flugzeuge abgestellt werden, entweder tatsaechlich fuer laengere Zeit oder auch nur kurz zum Ein- und Aussteigen. Schau die resultierenden img-Kacheln einfach mal selbst an und entscheide ob du meine Aenderungen in dein allgemeines Release aufnimmst. Es waere aber Gerne, wenn Du sagst wo man Deine Kachel finden kann. nett zumindest die highway typen in diesem Schema zu verwenden, da sonst die in OSM ja vorhande -m.M. nach durchauf wichtige- Unterscheidung der tertiary-Durchgangstrassen von normalen Wohnstrassen im Garmin GPS mit deinen aktuellem mapfeatures.csv nicht gegeben ist. Ich denke das werde ich machen. Wie gesagt, eine kurze Liste mit Mapfeatures-Vorschlägen im passenden Format würde sehr helfen. Als Muster kann mein mapfeature-File von meiner Wiki-Seite genommen werden. (Bitte nur die Ausschnitte wo neues oder Änderungen vorkommen, nicht immer die Ganze Datei schicken) Sorry, das CSV-file hatte ich vergessen aber schon nachgeliefert. Wenn du das resultierende img file wirklich willst, kann ich es dir natuerlich auch noch per PM schicken. Aber mit dem mapfeature.cvs ist es ja kein grosser Akt es selbst zu erstellen, die OSM-Rohdaten der Kachel hast du ja sogar selbst erstellt (bzw aus dem planet.osm gesplittet) :-). Micha H. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tag für Briefmarkenautomat
Gibt es schon ein Tag für Briefmarkenautomaten? Stamp-machine ist wohl der englische Begriff dafür. Nein stamp machine übersetzt sich als Stempelmaschine ins Deutsche und post stamp machine ist dann die Maschine, die die Post im Briefzentrum abstempelt! Die richtige Übersetztung von Briefmarkenautomat wäre post stamp venting machine. (venting machine - Verkaufsautomat) amenity=venting_machine sell_type=post_stamps operator=Deutsche Post das kann dann auch locker auf andere Verkaufautomaten angewendet werden. z.B. ein Fahrtkartenautomat: amenity=venting_machine sell_type=train_tickets operator=Deutsche Bahn Micha H. Was haltet Ihr von amenity post_stamp-machine ? amenity post_officenode amenity post_boxnodeAlternative mail-carriers can be tagged via operator=. Grüsse Jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM Treffen in Nürnberg / Fürth / E rlangen? (war: Wer mappt denn sonst noch so in Nürnberg? )
Hi, ich bin in Nürnberg bzw. Schwabach nur ein selten anwesender Teilzeitmapper. Mein Hauptaktionsgebiet ist in Frankfurt (Main). Nur wenn ich - wie Ende Juli - die alte Heimat besuche, werde ich Schwabach und die südlichsten Nürnberger Ortsteile (Holzheim/Mühlhof/(Alt-)Katzwang) (weiter-)mappen. Der nächste Besuchl wird aber wohl erst um Weihnachten herum sein. Wenn ihr in dieser Zeit (wahrscheinlich werde ich ab Sa. 15.Dez. bis einschließlich der Weihnachtsfeiertage wieder meine Eltern besuchen) (nochmal) ein Treffen im Raum Nürnberg organisieren wollt, bin ich gern dabei. Gruß, Micha H. Andreas Volz schrieb: Hast du mittlerweile noch mehr OSM Interessierte im Bereich Nürnberg finden können? Mittlerweile passiert ja doch eine Menge im Bereich Nürnberg und Erlangen, wenn ich so auf die Karte schaue. Gruß Andreas Hallo! Wie Andreas ja auch schon schreibt, gibts in der Region Nürnberg inzwischen einige Leute, die sich um OSM verdient gemacht haben ;-) Ich denke man könnte inzwischen schon ein paar Leute für ein Treffen zusammenbekommen: Nürnberg: Karl Eichwalder ist da im Nordosten aktiv (er macht auch viele Rad- und Fußwege), viele Straßen stammen von mir (innerhalb des B4R Ring und südlich davon). Wer sonst noch? Fürth: liegt leider noch ziemlich brach, bin ich aber demnächst wohl öfters Erlangen: Die waren schon wesentlich weiter, als ich überhaupt erst angefangen habe (und da war NBG nur rudimentär vorhanden) - da kenne ich aber persönlich (noch?) keinen Schwabach: MichaH laut Karte, kenne ich aber leider auch noch nicht ... Mich würde schonmal interessieren: - die anderen überhaupt mal kennenzulernen - welche Gebiete eigentlich wieweit sind - die Erfahrungen mit Geräten (GPS, Voicerecorder, ...) - wie so gemappt wird (Auto, Fahrrad, Fuß, ...) - Pläne für die Zukunft - ... ... da läßt sich bestimmt genügend Gesprächsstoff finden! Wer hätte also Lust, sich zu einem OSM Erfahrungsaustausch in der (wie es ja inzwischen so schön heißt): Metropolregion Nürnberg zu treffen? Gruß ULFL P.S: Bei Treffpunkt und Termin wäre ich offen für Vorschläge (kann aber bei Bedarf auch gerne einen Vorschlag machen, daran soll es nicht scheitern) ... P.P.S: Oder wollen wir uns gleich zu einem Mapping Event treffen (allerdings ist es inzwischen schon ziemlich naß, kalt und dunkel)? Hier würde sich natürlich Fürth anbieten, wenn ich mir die Karte so anschaue ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
