Navigator 10 free von Mapfactor ... nutzt OSM-Daten

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. :wink:
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

Sehe ich auch so. Auch ich wollte auch erst nur mappen. Das mit Grundregeln ist wichtig. Wenn diese aber dazu führen, das die Dank fleißiger Mapper höhere Detailtreue nicht in Karten ankommt, sonder diese “verschlechtert”, sollte man die Grundregeln überdenken.

Habe verstanden. Danke. Leider zeigt die Friemelei der Rechner aber hier ihre Grenzen.

Rasterung und Generalisierung sind mir bekannte Begriffe. Trotzdem Danke für die Tips zur Auffrischung aus kartografischer Sicht.

Trotz der vielen Hilfsmittel zur Qualitätssicherung führen dann wohl die von mapfactor erwähnten überschneidenden Wege bei der Alster oder ähnliche Kleinigkeiten zu Darstellungsfehlern, die wohl bei einfacherer Datenerfassung vermeidbar oder für die auswertende Seite fehlertoleranter sind.
Gerade weil der Spaß-Mapper keine Lust an komplizierten Eingaben hat, sollten wir überlegen, wo und wie weniger mehr ist. Das fängt bei einer aktuellen und gut strukturierten Wiki an und hört bei den (glücklicherweise schon sehr) anwenderfreundlichen Erfassungshilfen wie JOSM oder Potlatch auf.

FYI gibt es jetzt Daten Deutschlands aus planet-110105, die neu auch größere Seen umfassem (Diskussion über Relationen, “Lago di Garda” und “Großen Plöner See” ist besser, aber immer noch einige Probleme) TMC-Daten, extrahieren Andere Typs von POIs und PLZ wurden nur auf die Nummer verengert (so sollte es zum keinen Problem beschribenen im Beispiel von Berlin versiegen).
Gruß
Martin

Hallo mapfactor,
…ich habe die aktuelle Karte “Germany North” am 20.01.2011 installiert.

Zur Information:
=> Hier fehlen noch immer der Große Plöner See und die Schlei als Gewässer.

  • Der Große Plöner See fehlt komplett.
  • Im Bereich der Schlei fehlt deren Verlauf zwischen der Straßenbrücke “L283” (bei Stubbe) und Kappeln (kurz hinter der Brücke “B203”)

Dafür scheinen jetzt auch “alle” Flüsse zu fehlen:

  • die “Schwentine”
  • die “Alte Schwentine”
  • die “Eider” (im oberen Verlauf bis zum N-O-Kanal)
  • die “Trave”
  • die “Treene” (im oberen Verlauf bis ca. Fresendelf)
  • die “Stör” (im oberen Verlauf bis Kellinghusen)
  • …usw.

EDIT
Im Vergleich dazu habe ich heute für “Navit” die Karte mit dem gleichen Bereich über “Navit::Planet Extractor” geladen.

  • auch dort fehlen nach wie vor der Große Plöner See und die Schlei in dem oben angegebenen Bereich

aber:
=> dafür sind hier alle Flüsse korrekt eingezeichnet.
=> dort, wo die “Schwentine” durch den Großen Plöner See fließt, ist sie als Linie eingetragen
=> in dem Bereich der Schlei, der nicht als Gewässer eingetragen ist, wird der Verlauf der Schlei als Linie dargestellt

Gruß Jörg

Hallo mapfactor,
…heute am 23.01.2011 habe ich das update der Karte “Germany North” (Stand 19.01.2011) angeboten bekommen resp. herunterladen können.

  • Der große Plöner See ist jetzt als Wasserfläche vorhanden = ok
  • Die Schlei ist jetzt komplett als Wasserfläche vorhanden = ok

=> es fehlen aber weiterhin fast alle Flüsse (wie in dem vorherigen Post beschrieben)

Gruß Jörg

Hallo mapfactor,
…folgendes Problem bei der Darstellung mit landuse=residential und type=multipolygon
(Karte “Germany North” mit Stand 19.01.2011)

Ortschaften (landuse=residential) werden korrekt dargestellt.
Beispiel 1: http://www.openstreetmap.org/browse/way/87861851
Beispiel 2: http://www.openstreetmap.org/browse/way/24961414

aber:
Ortschaften (landuse=residential type=multipolygon) werden nicht dargestellt.
Beispiel 3: http://www.openstreetmap.org/browse/relation/1304643
Beispiel 4: http://www.openstreetmap.org/browse/relation/1347636

(Dieses Problem der Darstellung betrifft auch die Karten bei “navit” ticket )

Gruß Jörg

Ja, das wird das gleiche Problem wie mit Beziehungen bei den Seen (dh. es bearbeiten sich nur way und nicht relation). Ich schaue es an.
danke
Martin

Neuere Dateien germany_osm*.mca (aus planet-110202.osm) sind verfügbar. Die meisten Flüsse wurden repariert und jetzt sind die Autobahnnummern integriert. Hat jemand TMC in Deutchland versuchen?
danke
Martin