“Stadtzentrum” erscheint in der Liste der Straßen, falls der Name “Center of Settlement” (‘place’ in OSM) enthält. Falls der Name ‘place’ und ‘boundary’=‘administrative’ identisch sind, dann verbindet es sich. Beispiel ‘Bleckede’ z.B. hat keine ‘boundary’='‘administrative’. In den ursprünglichen Daten überwog die Suche der nächsten.
Ich frage mich, wie eine Hommage an den Test zu schaffen. Ich glaube, ich könnte den Namen um [count] erweitern. Dann wird das verscmelzen der Namen nicht funktionieren, aber für die Vorstellung wird es warscheinlich besser sein.
Heute würde ich das neuste Deutschland (planet101201) aktualisieren. ‘boundary’=‘postal_code’ ist mitverarbeitet. Übrigens, ist dies eine Spezialität von Deutschland, oder ist dies der Fall auch anderer Ländern?
Ich zitiere an dieser Stelle meinen Chef: “NavigatorFREE bleibt solange kostenlos, wie OSM Daten kostelnost bleiben.”
Eine kostenlose Version wollten wir schon lange machen, leider hatten wir keine Daten, die gut genug und gleichzeitig kostenlos waren ohne diese subventionieren zu müßen. Zur Zeit sind in der FREE Version erweiterte Tools wie Programmsteuerung über TCP, welche vieleicht in Zukunft kostenpflichtig sein wird.
Generell scheint es noch mit den Gebietsgrenzen einiger Orte (besonders in Norddeutschland) das Problem zu sein, dass dort die Grenzen der Gemeinden, welche oft auch die Grenzen der Postleitzahlen sind, noch nicht eingearbeitet sind.
Somit würde erstmal für die mapfactor-Straßenliste dort nur das Verfahren “nearest node” möglich bleiben.
Ich habe auch mal die Software auf dem PC und PDA (HTC Touch Cruise) getestet. Die Installation lief problemlos und auch der eingebaute GPS-Empfänger im HTC wurde sofort erkannt.
Die Bedienung und auch die Zieleingabe ist etwas gewöhnungsbedürftig. Immerhin kann man zu Straßenkreuzungen navigieren - wenn man sich erstmal zum richtig Berlin durchgescrollt hat. Beim eingeben des Ortsnamens erscheinen erstmal die ganzen PLZ Einträge für Berlin und ich weiß grundsätzlich nicht zu welcher PLZ mein Ziel gehört.
Nun zur Navigation, bin vom Platz der Luftbrücke Richtung Siemensstadt gefahren. Ein Blick auf die Karte zeigt - ab auf die Stadtautobahn dürfte am schnellsten gehen. Der Navigator wählt aber trotzdem den Weg durch die Stadt. Dabei gibt er für rund 13 km eine Fahrzeit von 10 Minuten vor - in der Stadt und ohne Autobahn! Das dürfte wohl selbst bei freier Strecke und ohne Ampeln nichts werden.
Ich habe mich dann für meine eigene Strecke entschieden und der Navigator war stets bemüht eine neue Route zu ermitteln. Auf der Autobahn kam dann plötzlich an der Abfahrt Hohenzollerndamm/Schmargendorf rechts halten. Da wollte der Navigator doch tatsächlich von der Autobahn runter über die folgende Kreuzung rüber und auf der anderen Seite wieder auf die Autobahn rauf.
Am Dreieck Funkturm sollte ich dann wieder von der Autobahn runter und weiter durch die Stadt fahren. Der Navigator scheint also nicht dem Drang anderer Produkte zu folgen, immer die Autobahn nutzen zu wollen. Aufgrund der Fahrzeitrechnung oben gehe ich aber davon aus, dass er mit falschen Geschwindigkeiten auf der Straße rechnet. Wenn also nichts angegeben nimmt er vermutlich mehr als die in der Stadt zulässigen 50 km/h.
Weiterhin ist mir aufgefallen, dass der Navigator gerade beim Halten an Kreuzungen Probleme hat, auf der Straße zu bleiben. Da wandert die Position mal auf die Gegenfahrbahn oder ganz wo anders hin. Daraus folgt natürlich auch eine Neuberechnung der Route, was an der Kreuzung sehr irritierend ist. Auch so waren während der Fahrt einige Ansagen sehr ungenau. Bis zur Kreuzung heißt es immer schön “geradeaus fahren” und auf der Kreuzung soll man plötzlich links abbiegen.
Anzumerken wäre noch, dass die Sprachansage etwas autoritär klingt, da traut man sich gar nicht richtig von der Route abzuweichen. Aber das sollte das kleinste Problem sein.
Fazit: Endlich eine Navigationssoftware, die ohne große Probleme läuft und eingesetzt werden kann - und das für Win-PDA und nicht für Android oder IPhone-Apps. Im Stadtgebiet würde ich sie noch nicht einsetzen, da verwirrt sie mehr als das sie hilft. Bei Strecken übers Land mag es aber anders aussehen.
Der große Vorteil ist natürlich die Aktualität der Daten, der große Nachteil die recht unterschiedliche Qualität der Daten. Naja, Hauptsache wir haben die Höhe von Briefkästen und die Art und Anzahl von Bäumen korrekt erfasst.
In freier Navigationssoftware sehe ich den größten Anwendernutzen, um damit Fans und Mitmacher für OSM zu gewinnen. Du legst den Finger auf eine Wunde, die schon bei der (leider eingeschlafenen) Diskussion um die Gestaltung der openstreetmap.de-Seite offen klaffte.
Was wir brauchen, ist ein verständliches workaround zum Ausdrucken, das dem Neuling u.a. zeigt, welche Mindestanforderungen beim taggen von Straßen, Wegen, Plätzen erfüllt sein müssen, damit routing mit den Daten möglich ist. Auch wenn OSM frei ist, benötigt es im Anwenderinteresse (dazu gehören auch Renderer) gewisse Regeln, die leicht erkennbar sein müssen.
Kein Wunder, dass Briefkastenhöhen und Baumarten getaggt werden: Da muss man nicht soviel 'rumsuchen und hat trotzdem eine Menge nodes für die Statistik.
Ich weiß, dass eine Menge Postleitzahlen angezeigt wird (angezeigt werden zusammengestellte Zeilen, in denen einige der Wörter mit dem Text beginnen). Wenn Sie aber das ganze Wort “Berlin” schreiben, dann wird es automatisch auf die Erste Zeile verschoben.
p.s. Wäre es nicht sinnvoller/besser nur Nummern anzuzeigen, statt ‘name’ ‘postal_code’ benutzen? Oder nur manche ‘postal_code_level’?
Ich würde auf die Postleitzahlen verzichten, da es vermutlich mehr Städte mit mehreren PLZ gibt als doppelte Gemeindenamen in Dt. die anhand der PLZ unterschieden werden müssen. Wobei es m.W. auch ein Dorf Berlin in Schleswig-Holstein gibt.
Am besten wäre es natürlich alle PLZ einer Stadt unter dem Stadtnamen zu gruppieren, andere Ort mit dem gleichen Namen aber mit PLZ auszugeben. Vielleicht so ähnlich wie bei der Straßenauswahl: man wählt erst Berlin aus und wird dann gefragt meinen sie die Stadt/Land Berlin oder das Dorf mit der PLZ XXXXX.
Hallo zusammen,
habe Navigator 10 Free mal auf meinem Pocked Loox N560 installiert.
Läuft…Handhabung gewöhnungsbedürftig. Routing oft neben den Strassen…aber als Freeware OK.
Jedefalls immer aktuelle Streckenführung wegen fortwährender Aktualisierung der OSM-Karten.
Integrierter GPS-Empfänger sofort …manuell…eingestellt, direkt empfangsbereit.
Auch auf dem PC ist das Programm ausführbar und…eigendlich ganz gut !!
Bin aber verwöhnt durch den auf dem PDA installierten Mobile Navigator 5.
Der hat aber keine aktuelle Karte, weil schon etwas älter aber noch gut brauchbar.
Fazit…etwas umständliche Handhabung des Navigator 10 Free…aber nach Eingewöhnung OK.
Da das Programm Freeware ist, kann man sich sicher nicht beklagen.
Mit diversen, zunehmend hochwertigen, mobilen Programmen wie Mapfactor, Skobbler, Navmii und andere, scheinen inzwischen viele Leute OSM zur Navigation zu verwenden die zuvor noch nie etwas von OSM gehoert haben und somit die Sache mit TomTom und Navigon vergleichen und die gleiche Qualitaet erwarten. Hoffen wir mal das OSM schafft das als Ansporn zu sehen und die gleiche Deteilverliebtheit in der Navigation zu erreichen die es inzwischen in den gerenderten Karten-Kacheln erreicht hat.
mal ganz dumm gfragt… ich habe die navigator free version installiert, aber er fragt mich halt nach dem programmstart nach installierten karten… wie und woher beomme ich die nun und installiere sie in die free version?
Welche Version hast du denn installiert? Die für Windows auf einem PC oder die für WindowsMobile oder PocketPC bzw. WindowsCE?
Du musst zumindest in dem Installer und Setup-Utility auf deinem WindowsPC Den Unterpunkt “Daten installieren” wählen. Dann kommt eine Auswahl der verfügbaren Karten.
Falls du für die PocketPC-Version die Karten damit herunterlädst, müssen di dann noch manuell auf die Speicherkarte oder ähnliches für den PDA raufkopiert werden.
Teddy, hier is meine “übersetzte” Frage:
Teddy80 wies darauf hin, das Problem mit dem “Lago di Garda” in Italien, die nicht sichtbar sind in NavigatorFREE. Ich bemerkte, dass jemand vor kurzem taggen natural=‘water’ bedeutet auch, zugegeben hat, aber tag ist bereits in relation 8569. Ein ähnliches Problem ist mit dem “Lake Geneva”, aber dort ist ein taggen natural=‘water’ nur in relation 332617 und nicht alle ‘member’. Gibt es eine Regel über Tagging einer Beziehung? Wenn nicht, und während der Verarbeitung sollte ich entfernen alle ‘member’ einer bestimmten Beziehung (wenn man die gleiche Wasserfläche zweimal hinzufügen, wird es abgeschafft).
Vielen Dank für jede Beratung
Martin
Mir fällt auf, dass die Reit-und Wanderkarte bis auf den großen Plöner See mit den gleichen leeren Seen zu kämpfen hat. Da ist auch der Bodensee zum Großteil schon (als Trinkwasser im Schwabenlände?) verschwunden.
Ich kenne mich mit kartenerstellung absolut nicht aus, vermutete aber schon an anderer Stelle, dass die “Küstenlinien” der Seen seit der Aufsplittung infolge der 2000-nodes-Limitierung eine Ursache sein könnten. So war z.B. der Comer See bei Nop auch plötzlich verschwunden als dort gesplittet wurde. Der untere Bodensee ist als geschlossenen Linie angelegt und erscheint auf der Reit- und Wanderkarte.
@Nop:
Wenn du mit liest… vielleicht kriegt ihr gemeinsam eine Lösung hin.
Edit:
Habe mich mal in Chicago und Detroit umgeschaut. Die großen amerikanischen Seen haben alle eine coastline, obwohl diese laut (deutscher) Wiki hierfür nicht gedacht ist. http://wiki.openstreetmap.org/wiki/DE:Coastline
Dort steht, dass coastline nicht für Binnenseen verwendet werden sollte. Ein explizites Verbot kann ich nicht erkennen.
Und in der engl. Wiki für coastline steht:
Related tags
natural=coastline is used for ocean coastlines, and perhaps the borders of large lakes (coastline bigger than 1000 points).
Löst das nicht die Probleme?
…so ganz OT sind wir sicherlich nicht, da dieser thread mittlerweile die “inoffizielle deutsche Infoquelle” für Martin=mapfactor ist, um die Software “Navigator 10” für den Umgang mit den OSM-Daten zu optimieren.
Nach Vermutung von efred liegt das Problem der fehlenden Wasserflächen nicht an einem fehlerhaften taggen von OSM-Daten, sondern wahrscheinlich eher an einer fehlerhaften Verarbeitung der Daten durch die Software.
…im Fall des “Großen Plöner Sees” war es das Programm “Navit”, anhand dessen dieser “Fehler” auffiel.
Entsprechend wurde dort ein Ticket im Bug-Tracker eröffnet. (=> bisher aber wohl noch nicht bearbeitet)
Ok, nicht ganz OT. Aber das Thema geht deutlich über Navigator free hinaus, da auch andere Renderer mit dieser Darstellungsart überfordert sind.
Ich habe die Feststellung von efred im Thread mal bei den mir bekannten Seen (Bodensee, Genfer See, Gardasee, Comer See, Lago Maggiore), welche u.a. in der Reit- und Wanderkarte nicht erscheinen, gecheckt. Bei all diesen Seen liegt natural=water auf dem Multipolygon und die ways haben keine tags, was den Empfehlungen der Wiki entspricht.
Auch wenn wir nicht für Renderer bzw. Kartenersteller oder Anwendungsprogramme mappen, so sollten wir es ihnen auch nicht mit nur umständlich oder gar nicht auswertbaren Regeln und Empfehlungen unnötig schwer machen, denn Renderer machen unsere Arbeit erst verwertbar und sind somit das Schaufenster für die Welt auf OSM. Ohne sie wäre alles nur ein riesiger Datenhaufen im Netz, von dem niemand was hat.
Somit stellt sich die Frage, ob die Empfehlung in der Wiki für derartige Multipolygone nicht zurückgenommen werden kann. Dies mag zwar vor dem Hintergrund möglicher Redundanzen kritisch sein. Aber ich glaube nicht, dass in diesen konkreten Fällen dadurch erheblicher Schaden entstehen könnte, weil hier doch voraussichtlich nur noch zur Detailierung des Uferverlaufs nodes ergänzt oder verschoben werden. Deshalb könnten die beteiligten outer ways doch auch noch natural=water als tag erhalten.
Ein Vorteil dabei wäre auch, dass bei einer Größenüberschreitung der nodes (über 2000) bei bisher “grober” erfassten Seen durch zunehmende Detaillierung des Polygons nicht nach Splitten des ways und Bildung des Multipolygons auch noch in allen ways der tag entfernt werden muss. Außerdem bleibt bei Nacharbeiten, für die man das Multipolygon ggf. zerlegen muss (oder aus Versehen zerlegt hat), auf den beteiligten ways noch deren Bedeutung erkennbar.
Wenn nicht mir unbekannte Gründe, die an anderer Stelle Schaden aus dieser Vorgehensweise verhindern, dagegen sprechen, wäre dass doch die Lösung des Problems (trotz oohmm).
Dir unbekannte Gründe könnten z. B. sein, dass dann andere Anwendungen (vorerst fiktives, aber durchaus konkretes Beispiel: Anteil der Erdoberfläche von Wasser bedeckt) an den falschen Daten scheitern - zumindest sind die Daten dann falsch interpretierbar.
Da die “Schaufenster der Welt”-Renderer auf OSM (Mapnik und Osmarender) bereits keine Probleme mit diesem Tagging haben, ist die Lösung evtl. etwas schwieriger aber zumindest nicht unmöglich.
NB:
Du verwendest bei der Erstellung eines Multipolygons bei Größenüberschreitung die falsche (zu aufwendige) Reihenfolge.
Und das die Bedeutung eines ways erkennbar bleibt, liegt am Mapper selbst - wofür gibt es note=*.
besteht die Aussenlinie bei diesen Seen denn aus mehreren Ways? Dann wären es Advanced MPs und das natural=water am MP und nicht am Way
wäre absolut korrekt. Mapnik und Osma kriegen das doch auch hin oder?
