Hi, > Yop, die Datenmenge lässt sich um über 50% verringern und das Ergebnis > ist immer noch weit über dem OSM-Durchschnitt.
Du hast Dir da eine etwas ueberhebliche Sprechweise angewoehnt, die zwischen den Zeilen immer anzunehmen scheint, OSM sei irgendwie geringwertiger als "professionelles GIS", was in dieser Allgemeinheit falsch ist. Ich hab das im Wiki-Artikel etwas geradegerueckt ;-) Was ich in Deinem Howto schmerzlich vermisse, ist eine allgemeine Erklaerung ueber Shape vs. OSM. Dass Shape eben nur eine begrenzte Anzahl fixer Attributspalten kennt, waehrend OSM eben ein bunt gemischtes Taggingschema hat, und daher das *wesentliche* Element bei einer Konvertierung nicht dasjenige ist, aus den Linien im Shapefile Ways zu machen, sondern anhand der Attributierung im Shape zu entscheiden, wie diese Ways getaggt werden sollen. (Und, aber das ergibt sich wohl auch aus der Vereinfachung, dass eine verlustfreie Konvertierung in aller Regel nicht moeglich ist.) Aber das ist vermutlich das "Mapset", zu dem Du noch etwas schreiben wolltest? Dabei sollte man dann auf jeden Fall erwaehnen, dass es hier keinesfalls einen Standard gibt - ein Laie koennte annehmen, dass ein Shapefile, das er von der Stadt X bekommen hat, automatisch mit den gleichen Regeln konvertiert werden kann, wie eins vom Landkreis Z. > Es gibt xx Arten zu generalisieren. Ich weiß nicht, welchen GPSBabel > verwendet, aber wenn Du mir den Link aus der Doku schickst, lese ich > es mir mal durch. Hauptsache, er ist konfigurierbar. Wie auch "simplify way" in JOSM benutzt gpsbabel den Douglas-Peucker-Algorithmus, der Parameter heisst "-x simplify", und Du kannst einen maximalen Cross-Track-Error angeben. Mit sehr grossen Dateien hat gpsbabel idR keine Probleme. > Das Problem ist aber anschließend, dass nur die wenigsten eine riesige > OSM-Datei nachbearbeiten können, JOSM schafft es nicht. Merkkaattorr > braucht ewig die Datei zu laden und einer 100%ig automatischen > Konvertierung _kann_ man nicht trauen. Man kann mit gpsbabel auch Teilbereiche ausschneiden und einzeln verarbeiten. Mit Grass sicher sowieso, aber ich teile die Vermutung von Sven, dass man sich Grass an dieser Stelle haette sparen koennen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
