[email protected] (Robert Kaiser), 2011.12.02 (Fri) 15:41 (CET): > Stefan Kopetzky schrieb: > >On 02.12.2011 14:21, MERIGHI Marcus wrote: > >>warum sind dann meine verd...... Hoehenlinien (NASA SRTM) nicht in der > >>DB?! (scherzhaft mit wahrem Kern) > > > >Ich vermute mal vorrangig aus Lizenzgründen... > > Ich denke, NASA STRM ist wahrscheinlich sogar PD. > > >Zudem gibts wenig (ich kenn keine auf der Ebene, auf der wir uns hier > >bewegen) Möglichkeiten bessere Höhenlinien zu erzeugen. Also ist es auch
NASA SRTM wuerd' mir schon reichen. Warte aber sehnlichst auf die laser-scans. > >eher nicht sinnvoll Höhenlinien editieren zu können. Wäre das anders > >würde auch wenig dagegen sprechen sie aufzunehmen. > Ja, bei Dingen, die die Mapper nicht sinnvoll editieren können, und > die (quasi) extern gewartet werden, ist es nicht sinnvoll, die in > der Datenbank zu haben. Wichtiger Unterschied der mir entgangen ist. Danke... > Es ist aber kein Problem für Renderer, diese Quellen in eine fertige > Karte einzubinden, und das habe ich auch schon in einigen > OSM-basierten Karten gesehen. Naja, die einzige, die halbwegs large-scale benutzbar ist, ist die opencyclemap. Die laesst wieder den letzten zoom nicht zu und hat viele Details nicht drin (unnoetige Details wie Seilbahnen etc.). Fuer mich (leider!) nicht nutzbar. Fesch waer' ja einfach ein TMS der contours. Nur der contours. Hab' nie einen gefunden (ausser fuer einen kleinen Bereich in Deutschland). > >Grundsätzlich liegt mMn das Abstrahieren und die Konfiguration desselben > >beim Renderer. Dass das kein aktueller kann, ist bedauerlich, sollte > >sich aber nicht auf die Erfassung der Daten durchschlagen. Ha! Jetzt > >kann ich auch mal das abgedroschene "Wir mappen nicht für den Renderer" > >auch mal anbringen :)) > > Mapnik 2 kann so weit ich weiß schon Teile davon, aber ich weiß > nicht, wann der für die "Hauptkarte" auf OSM.org eingesetzt wird. > Wer interessiert ist, sollte ihn aber probieren können und an der > Verbesserung mitwirken könne, AFAIK ist Mapnik 2 auch Open-Source. > > Trotzdem finde ich es ziemlich sinnlos, Details einzuzeichnen, die > so ungefähr unter einen Meter gehen, besonders, wenn es sich um Endlich 'mal ein WERT, danke. > natürlichen Bewuchs handelt, der sich sehr schnell ändert. Also sollten wir zwischen schneller/langsamer Veraenderlich unterscheiden? > Im Endeffekt muss man halt, so wie hier schon mehrmals erwähnt, > einen sinnvollen Kompromiss der Abstraktion schaffen - denn eine > eine Geodatenbank (noch mehr eine daraus erstelle Karte) ist > natürlich eine Abstraktion der Realität, ein Modell, das bestimmten > Zwecken dient, und diesen (vermeintlichen) Zwecken ist die > Genauigkeit anzupassen. Der Zweck der Karte bestimmt die Detailtiefe, und was an Details nicht gebraucht wird kommt nicht in die Datenbank. Datensparsamkeit 'mal anders. Weniger ist mehr. Unnoetige Informationen verwirren nur. Machen alles langsamer. Andererseits: Kennen wir den (zukuenftigen) Einsatzweck? Ist es legitim, map-bare Dinge nicht einzutragen, weil wir sie fuer unseren jetzigen Einsatz nicht brauchen? Pfirteich, Marcus _______________________________________________ Talk-at mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-at
