Hallo,
zunächst einmal: Ich habe mir den Grenzdatensatz nicht angeschaut. Angeblich sind die Grenzen “generalisiert” (d.h. ungenau); das koennte u.U. auch die von Dir beobachteten Probleme erklaeren.
Nein, man sollte nie irgendwas “einfach hochladen”, auch nicht diese Grenzen.
Das ist ein gutes Zeichen dafuer, dass dieser Grenzdatensatz nicht notwendigerweise in allen Belangen besser ist als das, was wir haben, und dass wir, statt diesen Datensatz hochzuladen und unseren wegzuwerfen, diesen Datensatz lieber als zusaetzliche Informationsquelle nehmen sollten, um unsere Daten zu pflegen.
Nein, auf keinen Fall. Wenn jemand wirklich genau diesen Grenzdatensatz benutzen will, dann soll er das tun - es ist zum Beispiel gar kein Problem, in Mapnik eine Regel einzubauen, die sagt “Grenzen nicht aus dem OSM-Datensatz einzeichnen, sondern aus diesem Shapefile”.
OSM ist ein Editiersystem. Was da hochgeladen wird, das kann und soll von Menschen bearbeitet werden und ganz gewiss nicht alle paar Jahre mal durch einen amtlichen Datensatz zweifelhafter Qualitaet ersetzt werden!
Das werden wir ganz bestimmt nicht tun, in unseren Grenzdatensaetzen steckt viel Arbeit. Du erwaehnst selbst die Grenzrelationen; zuweilen wird eine Grenze sich sicher auch an einer existierenden Geometrie orientieren (Fluss, Waldrand, Strasse) oder umgekehrt. Da muss sauber von Hand gearbeitet werden, da kann man nicht einfach einen Grenzdatensatz draufklatschen nach dem Motto “die haesslichen Stellen koennen die Mapper ja spaeter reparieren, ich mach jetzt erstmal den leichten Teil”.
Es gibt verschiedene Arten, wie man mit solchen Daten umgehen kann.
Moeglichkeit 1: Jemand bereitet einzelne OSM-Dateien mit Hilfe eines Skripts vor (z.B. eine pro Landkreis oder so), und Mapper koennen sich diese Dateien dann vornehmen und von Hand “einpflegen” und dabei alle Relationen usw. richtig machen. Diese Methode hat den Nachteil, dass es manchmal eifrige, aber schludrige Mapper gibt, die sich so ein Ding in JOSM laden und auf Upload druecken, ohne wirklich die erforderliche Handarbeit gemacht zu haben. Ausserdem ist diese Handarbeit manchmal verdammt schwer.
Moeglichkeit 2: Wir laden die Daten in einen WMS, so dass man sich das im Editor-Hintergrund anzeigen lassen und existierende Geometrien von Hand “zurechtzupfen” kann. Hier hat man zwar die Handarbeit des Geometrie-Nachmalens, aber man kann die existierenden Relationen unangetastet lassen - und “exakt” sind die Bayern-Datensaetze ja eh nicht, also spielt auch die Ungenauigkeit durch das “Nachmalen” keine Rolle. - Einen aehnlichen Weg haben wir vor langer Zeit mal mit Daten von “Strassen NRW” gewaehlt. Damals gab es sogar die Moeglichkeit, sich einzelne Linien, die in OSM noch gar nicht drin waren, auf Knopfdruck in den JOSM zu laden.
Moeglichkeit 3: Der “Snapshot Server” in Zusammenarbeit mit Potlatch. Das ist eine recht neue Entwicklung von Andy Allan; da konvertiert man die Daten in OSM-Format, laedt sie auf den “Snapshot Server” und kann dann mit Potlatch diese Daten zusaetzlich zu OSM-Daten sehen und auf Knopfdruck in OSM uebernehmen, und man kann sogar Daten auf dem Snapshot-Server als “erledigt” markieren. Das ist alles noch recht jung, aber wenn irgendwann mal jemand fuer JOSM die Unterstuetzung dafuer einbaut, dann wird das bestimmt eine verbreitete Art, mit freigegebenen Daten umzugehen.
Diesen Moeglichkeiten ist gemein, dass sie sich auf die Handarbeit von Menschen verlassen - in Gegenden, in denen sich niemand dafuer interessiert, werden die Daten auch nicht eingepflegt werden. Das ist aber eine Stärle und keine Schwäche dieser Moeglichkeiten - denn Daten, fuer die niemand bereit ist, ein bisschen Arbeit zu machen, sind “verwaist” in OSM, die liegen dann nur rum und verstauben.
Vermutlich gibt es noch weitere Moeglichkeiten. “Existierende Grenzen loeschen und neue hochladen” ist zwar eine technische Moeglichkeit, aber keine akzeptable.
Bye
Frederik
