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.
Ich werde mal weiter testen
Gruß
Norbert
Ich hoffe immernoch das irgendwann routing in die OSM-Hauptseite integriert wird (wie z.B. http://nroets.dev.openstreetmap.org/demo/index.html?lat=51.503&lon=-0.0847&zoom=13&layers=B000FTFTTT&v=motorcar&adj=recommended&markers=!51.49668%2C-0.09681!51.52916%2C-0.10917)) . Das hilft zwar vielleicht nicht mit dem “rumsuchen”, erhoeht aber vielleicht die Motivation Abbiegebeschraenkungen, Hoechstgeschwindigkeiten und access tags richtig zu taggen anstelle von jeden Baum mit Baumart einzutragen nur weil einem langweilig ist. Vorallem wuerde es helfen zu ueberpruefen ob man alles korrekt und machinen verstaendlich getaggt hat.
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?
hilfe wäre echt nett… danke
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.
Klappt das?
System? http://navigatorfree.mapfactor.com/de/
Bei der PC Version auf “Setup Utility”:
Bei der PC Version auf “Produkt Updates”:
und dann auswählen:
Hallo
habe gerade im nicht Deutschsprachigem teil vom Forum gefunden.
http://forum.openstreetmap.org/viewtopic.php?id=9840
Gruß Teddy
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
Hallo Martin (mapfactor),
…das Problem der “fehlenden Seen” betrifft auch z.B. den “Großen Plöner See” in Schleswig-Holstein.
http://www.openstreetmap.de/karte.html?zoom=12&lat=54.1306&lon=10.41506&layers=B0
Dieser ist in der von mapfactor Navigator 10 free benutzten aktuellen Karte nicht als Gewässer zu erkennen (= Fläche ist nicht blau gefärbt).
Das Problem betrifft u.a. auch die Software “navit”. Auch dort ist dieser See nicht blau eingefärbt.
Siehe hierzu auch http://forum.openstreetmap.org/viewtopic.php?id=9773 und dort speziell #14.
Bei “navit” wurde ein entsprechender Eintrag im Bug-Tracker vorgenommen.
http://trac.navit-project.org/ticket/689
Ich hoffe, daß dies weiterhelfen kann.
Gruß Jörg
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?
natural=water ist laut englischer Wiki für einen “simple lake” gedacht:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater
Wir sind hier aber OT. Wie gehen wir mit dem Seen-Thema weiter um?
…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)
siehe http://forum.openstreetmap.org/viewtopic.php?id=9773 #14:
Es scheint also eher um eine korrekte und angepasste Verarbeitung der Daten von Seiten der Software zu gehen als um ein “umtaggen” in den OSM-Daten.
Gruß Jörg
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).
Moin,
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=*.
Gruß
Georg
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?
Chris
Wenn man sich Mapnik näher betrachtet, dann wird man feststellen, dass bei einem Datenbankaufbau mit OSM2PGSQL aus Realtionen plötzlich Wege gemacht werden. Sprich Hilfsprogramme und Datenbanken breiten die Daten für Mapnik vor.
Ich glaube nicht das bei deinem fiktiven Beispiel ein paar Linien das Ergebnis signifikant verfälschen. Da haben wir neben Ungenauigkeiten andere Fehlerquellen, solange noch nicht jeder Teich und Bach erfasst ist. Außerdem glaube ich nicht, dass dieser seltene Fall die zig Anwender aufwiegt, welche sich über falsche Render-Ergebnisse wundern und dadurch die Qualität von OSM in Frage stellen.
Die sinnvolle Reihenfolge zur Anlage derartiger MP ist mir bekannt, aber was macht “Otto-Normal-Mapper”?
Da OSM als “die freie Weltkarte” vorgestellt wird, sollten wir uns nicht vor Renderproblemen verschließen. Ich denke OSM ist eine “Wertschöpfungskette”, die beim Erfassen der Daten anfängt und beim bewundernden Blick auf die Karte aufhört. Wenn es dazwischen hakt, war die Arbeit (zumindest teilweise) umsonst. Deshalb meine ich, dass wir mit der Vogel-Strauß-Politik “wir mappen nicht für…” OSM nicht wirklich nützen.
Ich wünsche mir Verständnis für die Rendererund deren Probleme. Wenn ich den post von viw anschaue, sehe ich, dass unsere Krücke zur Erfassung durch eine andere Krücke wieder weggebügelt werden muss. Wenn mir jetzt noch einer erklärt, warum ways kleiner als 2000 nodes bleiben müssen und in den hier diskutierten Fällen die ways in advanced mulipolygones keine (gleichlautenden) tags enthalten sollen, bin ich bereit, meine Meinung noch einmal zu überdenken.
zu chriss66:
Die Außenlinie besteht aus mehreren ways. Zu Mapnik usw. siehe oben.
Ist hier jemand, der sich mit den Vorgehensweise eines Renderers auskennt oder weiß, wo man was dazu findet?
Danke für die Informationen und Links. Neuen Datenprozess aus planet-110105 verarbeiten schon relation tag, so wir werden sehen.
In dieser Zeit läuft die Verarbeitung germany_osm_north und es sind dort diese “Fehler” (die Details habe ich noch nicht):
Bad water relation/polygon 541083 -
Bad water relation/polygon 282654 - Alster
Bad water relation/polygon 282754 - Schlei
Bad water relation/polygon 21142 - Schweriner See (Innensee)
Bad water relation/polygon 282735 - KĂźchensee
Bad water relation/polygon 1043584 - Breitling
…und wenn man sich die Reit-und Wanderkarte anschaut: leer
…und ein advanced multipolygon mit ways
Aber im Gegensatz zum Gardasee fehlt das outer bei den ways und dem MP, wobei type=natural getaggt ist???
Mal sehen, was der Rest zeigt.
Edit:
Die Schlei ist auf der Reit- und Wanderkarte blau trotz vergleichbarer tags. Mindestens ein beteiligter way hat natural=water und ist wie sein "Binnen-Nachbar geschlossen???
Ich habe jetzt auf “Relation: Alster (282654)” geschaut und es gibt dort zwei “way”, die sich überschneiden, was mir als Fehler gemeldet war. Das gehört aber in andere Diskusion (wie war es in den englisch Version über Navigator FREE angesprochen).
Dein Ansinnen ist natürlich lobenswert, aber es ist doch nicht schlimm, dass viele einfach “nur” mappen wollen. Sie wollen ihren Teil für das Projekt beitragen. Da muss man ebend Grundregeln festlegen, damit die Leute nicht dauernd ihre Sicht auf die Welt in die Daten anderer hineintragen.
Zu #1:
Eigentlich schlichtweg, weil man dann pro geometrische Operation so viele Knoten und Metadaten im Speicher halten muss. Wenn das kleinere sind lassen die sich besser handhaben und es ist für einen Rechner kein Problem die wieder zusammenzufriemeln. Soll er dagegen entscheiden, wo man einen Weg sinnvoll auftrennt sieht das schon ganz anders aus…
Zu #2:
Sorry da habe ich zu wenig hier gelesen und verstehe die Problemformulierung nicht.
Nun als erstes würde ich mal auf die Mapnik und Osmarender Wikiseiten schauen. Danach kann man allgemein GIS schauen also z.B. den Mapserver. Einen ganz allgemeinen Einstieg findest du natürlich unter
http://de.wikipedia.org/wiki/Rasterung_%28Computergrafik%29
http://de.wikipedia.org/wiki/Generalisierung_%28Kartografie%29