raffi wrote:Ich bin echt begeistert von der OSM. , dass sie dank dir Sockeye auch fuer uns Magellaner nutzbar ist.
Ich habe am Hafen in Hildesheim einen Dartsellungsfehler auf dem Triton 500 (FW 1.56) und in VP gefunden. Das Hafenbecken wird nicht als Wasserflaeche angezeigt.
Zu finden bei:
52Grad10.879'N
9Grad55.699'E
Bei
52Grad18.288'N
10Grad13.726'E
ist quasi ein Uebergang zur "richtigen" bzw. gewollten Darstellung. Der waterway-Tag aendert sich dort von "canal" auf "waterbank". Vielleicht ist deshalb bei der Konvertierung etwas schief gelaufen?
Gruesse, raffi
Sollte der tag wohl eher riverbank anstelle von waterbank heissen? Sowas habe ich naemlich in den tag-Erklaerungen nicht gefunden. Bei Riverbank sollte das stimmen. Es ist ja zum Glueck kein Problem, das ganze zu aendern. Tauschst Du einfach den tag aus und gut ist...
Dann stimmt es in der naechsten Karte wieder.
S1G wrote:
Sollte der tag wohl eher riverbank anstelle von waterbank heissen? Sowas habe ich naemlich in den tag-Erklaerungen nicht gefunden. Bei Riverbank sollte das stimmen. Es ist ja zum Glueck kein Problem, das ganze zu aendern. Tauschst Du einfach den tag aus und gut ist...
Dann stimmt es in der naechsten Karte wieder.
Genau Da hatte ich mich vertippt Dann aendere ich mal den Tag in der OSM. Sollte dieser "Fehler" oefter auftreten, waere es dann aber eventuell zusaetzlich sinnvoll, wenn Sockeye das bei der naechsten Konvertierung beruecksichtigt.
Bei der Planung von Routen ist es sehr hilfreich, dass nun auch der Zustand der Feld- und Waldwege ("highway=track") angezeigt werden. Die Abstufungen von "tracktype=grade1" bis "tracktype=grade5" (siehe http://wiki.openstreetmap.org/wiki/Key:tracktype) lassen nun Freizeitradler und Mountainbiker die richtigen Wege finden.
Ich nutze die Zeit ohne Sockeye um die Karten diesbezueglich weiter zu vervollstaendigen, denn leider fehlen diese Angaben oft.
Zuweilen scheint auch jemand aus einem zweispurigen Waldweg einen highway=footpath zu machen, vielleicht weil er diese Weg zu Fuss gegangen ist?!
Es gibt noch viel zu tun, aber es lohnt sich und macht Spass obendrein.
Der Datenbestand in OSM ist unter aller SAU !! Der OSM Rederer kommt damit zurecht, da er anderst funktioniert als die Renderer fuer GPS Geraete. Diese benoetigen einfach saubere Daten:
- keine Ueberschneidungen von Polygonen von einem Typ
- keine Selbstueberschneidungen von Polygonen
- keine Polygone vom Typ "inner"
- keine Doubletten
Des Weiteren koennen sie mit Linien, wie Riverbank nichts anfangen, da sie eine Line darstellen und kein Polygon.
Die Aktuellen OSM Daten enthalten ca. 10.000 fehlerhafte Wald und Wasser Polygone.
Daher ist es mit den OSM Daten nicht moeglich eine saubere GPS Karte automatisch zu erstellen. Ich habe mit der letzten TOSMD angefangen die Wald und Wassergebiete zu bereinigen und diesen Datenbestand weiter zu pflegen. Daher bitte ich euch Fehler direkt hier zu posten, ich aktualisiere dann den Datenbestand bei mir.
Also wenn du anfaengst Multypolygone mit Inner und Outer zu "bereinigen" wirds Aerger geben. Hier musst halt schauen wie du das umsetzen kannst - bei Garmin klappst ja auch.
Denn "Inner" macht Sinn und ist mit dem Grossteil der Renderer ohne Probs darstellbar. Die anderen Punkte stimmen natuerlich und sind eindeutig Fehler.
Mkgmap hat mit "inner" kaum mehr Probleme. Die Loesung Waldluecken ueber layer=1 mit was anderem zu uebermalen ist als Alternative naemlich absolut nicht zu gebrauchen.
extremecarver wrote:Also wenn du anfaengst Multypolygone mit Inner und Outer zu "bereinigen" wirds Aerger geben. Hier musst halt schauen wie du das umsetzen kannst - bei Garmin klappst ja auch.
Ich habe nicht vor in den OSM Daten irgendwas zu aendern. Was ich mache ist die Daten im MP Format vorzuhalten. Ich konvertiere "inner" Polygone in entweder saubere Loecher oder ordne sie einem Loesch-Layer zu. Zur Not schau ich in GE nach, wie es in Wirklichkeit aussieht.
Naja das konvertieren in "saubere" Loecher, ist ja genau dass was die Renderer machen sollten mit der Anweisung inner. Dann passts eh.
Fuer die Benutzer ist es halt so einfacher, denn Loecher werden in OSM halt als Inner definiert.
Ich dachte zwar ich haette es schon geschrieben, aber irgenwdie seh ich es nicht:
In Hamburg wird die U-Bahn (zumindest in VP) nicht gerendert, obwohl sie in den OSM Daten drin ist. Zwar ist die Hamburger U-Bahn (gesetzlich gesehen) eine Strassenbahn. Sie ist aber defakto genauso eine Bahn wie die Fern- oder S-Bahn in Hamburg, d.h. die Gleiskoerper sind voellig getrennt von allen anderen Verkehrswegen (sei es durch Tunnel, Viadukte, Eingezaeunt, auf einem Bahndamm, etc.). Es waere toll, wenn sie wie die S-Bahn korrekt dargestellt wuerde, damit man vorallem beim Cachen erkennen koennte, ob eine Dose z.B. links oder rechts einer Strecke liegt. Ausserdem hat sie ja auch durchaus einen verkehrlichen Wert
in den POI unter Parkplatz (falls es ein Objekt vom Typ Punkt ist)
in dem Layer Parkplatz und damit in der Searchgroup BEBAUNG (falls es ein Objekt vom Typ Area ist)
, dass sie dank dir Sockeye auch fuer uns Magellaner nutzbar ist.
Da hatte ich mich vertippt 
Dann aendere ich mal den Tag in der OSM. Sollte dieser "Fehler" oefter auftreten, waere es dann aber eventuell zusaetzlich sinnvoll, wenn Sockeye das bei der naechsten Konvertierung beruecksichtigt.
