ich erzeuge von Zeit zu Zeit eine Karte von Deutschland. Dafür benutze ich den Datenextrakt von der Geofabrik. Mir ist aufgefallen, dass der Wald hier nicht mit extrahiert wird. Meine Idee war jetzt, einen Way vom MP durch Wald auf dem Way der Grenze von D-CZ zu legen. Beim Extrakt sollte dann ein Wald entlang der Grenze entstehen.
Da ich nichts kaputt machen will (besonders will ich kein Loch in die D-Außengrenze reißen), wollte ich um eine kleine Hilfestellung bitten. Oder jemand erklärt sich bereit das zu übernehmen. Ich denke das es noch weitere Bereiche im Grenzgebiet gibt, die dem Geofabrik-Extrakt angepasst werden sollten.
Ja, das ist klar. Aber ich würde es für verschwendeten Datenverkehr halten, jedes Mal das Europaextrakt runter zu laden und dann noch einen eigenen Ausschnitt zu erstellen. Würde man einen Linie entlang der Grenze führen, wäre der Wald dann da auch beim Geofabrikextrakt da… Es wäre ja eher eine Optimierung als eine Zuarbeit für die Geofabrik
Ich will halt nicht einfach drauf los machen und dann müssen wieder Changesets rückgängig gemacht werden.
Das hab ich damals schon beide der Alsace/BaWü-Grenze probiert… Da war nichts zu machen…
Und wenn du dir den “großen” Wald anschaust, müsste man deutlich großzügiger ausschneiden…
Wie verhalten sich denn Elemente von MP wenn sie durch das eigentlichen MP laufen?!
Man könnte es auch in 2 MP aufteilen… Einfache finde ich jedoch meine vorgeschlagene Variante.
Und mit den neuen modernen Tools wie osmconvert/osmupdate ist es ja auch kein Problem
sich einen entspechenden Ausschnitt täglich per Diff aktuell zu halten.
Ich würde einfach die D-CZ-Grenze mit dem MP vom Wald verbinden und den Grenzabschnitt mit in das MP aufnehmen… Ich weiß nicht, wie ich es anders darstellen soll…
Hat die Reihenfolge der Members einer Relation eine Auswirkung auf dessen Form?! (Doofe Frage, aber es gibt ja bekanntlich keine doofe Fragen )
Wenn ja, müsste man es eh in 2 MP unterteilen.
Hab es mir mal kurz angeschaut. Das gibt’s aber nur als osm.xz. Warum nicht als pbf?
Mag sein, aber was spricht gegen das Teilen des großen MP in 2 Teile?!
Wir mappen zwar nicht fuer die Geofabrik, aber uebermaessig ausgedehnte Objekte sind sowieso ein ganz grosses Uebel. Durch zunehmenden Einsatz von multipolygon-Relationen scheint das z.Z. vrstaerkt aufzutreten, da uebersieht man wohl leicht, dass trotz Relation da letztendlich ein einzelnes Flaechenelement beschrieben wird.
Unabhängig von der Grenzproblematik solltest du also den Wald sinnvoll aufteilen, als Schneisen bieten sich da z.B. Hauptstrasse oder Bahnstrecken an. Eventuell beseitigt das bereits dein Grenzproblem (was macht Geofabrik bei einzelnen Polygonen, die ueber die Grenze hinaus ragen?), auf alle Faelle schraenkt das aber die negativen Auswirkungen erheblich ein.
Wie sieht’s mit einem Fluss als “Teiler” aus?! Aber dennoch besteht das Problem dann in anderen Teilen der Republik?!
Im Bild kann man erkennen, dass wenn das MP unvollständig ist, gar nicht auf der Karte erscheint (bzw. im Extrakt fehlt)
Ich hoffe, dass für euch ersichtlich wird, warum ich den Wald gerne in 2 MPs teilen würde.
Das ist reine Geschmacksfrage. Unstrittig ist das Teilen von Waeldern entlang von Schneisen, wo ja auch definitiv kein Wald ist. Da bieten sich halt Hauptstrassen oder Bahnlinien an. Ein Fluss, so er denn gross genug ist, faellt sicherlich auch in diese Kategorie.
Daneben gibt es auch noch den Ansatz, zu grosse Flaechenobjekte auch ohne echte Trennung zu teilen. Da gibt es zwei Varianten: 1. kann man entlang von anderen Objekten teilen, z.B. Waldwegen oder auch Grenzlinien, die in der Wirklichkeit keine echte Trennung des Waldes darstellen. Das hat den Vorteil, dass man in der Karte keine sichtbaren Schnittlinien hat; das hat aber den Nachteil, dass man entlang dieser Trennlinie ueberlappende Objekte hat (egal ob per Multipolygon oder per mehrerer einfachen Polygone). Das ist nicht jedermanns Sache, so dass 2. manche Leute lieber einen geraden Schnitt als Teilungslinie benutzen.
Nur dort, wo mit unsinnig grossen Flaechenobjekten gearbeitet wird. Aber das sollte man ja auch nicht machen.
Warum willst du unbedingt Multipolygone haben? Und warum sollen es unbedingt zwei sein. Zerlegen den Wald in sinnvolle, ueberschaubare Teilstuecke, und du ersparst dir und anderen Mappern und Kartenerzeugern in Zukunft viel Aerger.
Ich denke hier treffen wir auf ein generelles Problem mit MPs die ein mehrteilige ounter (aber auch inner) haben:
Bei einem Extract werden alle ways die mindestens einen Punkt innerhalb des auszuschneidenden Gebiets haben, in den Extract aufgenommen.
Bei einem “normalen” MP mit geschlossenen inner und outer ways ist dass in der Regel kein Problem (solange der outer way mitkommt). Selbst wenn ein paar inner fehlen ist das ok, da sie ja ausserhalb des gewünschten Gebietes liegen.
Wenn aber der outer aus mehreren nicht geschlossenen ways besteht und EINER dieser ways nicht im Extract landet, dann ist das MP unvollständig und wird von den meisten Renderern ignoriert. Das könnte auch bei einem unvollständigen inner passieren.
Wenn man solche Probleme generell vermeiden will, sollte man also darauf achten, dass alle Element eines MP immer geschlossen sind. Das wäre aber ein herber Schlag für alle, die MPs nutzen um ja nie einen way doppelt zu erfassen
Das versteh ich jetzt nicht. Alle Elemente der Relation sind outer-Elements. Dann sollte es doch z.T. auch im Extrakt auftauchen, oder hab ich jetzt was falsch verstanden?!
So weit ich es verstanden habe, läuft ein Extract wie folgt ab:
Alle nodes bestimmen, die im gewünschten Gebiert liegen → kommen in den Extract
Alle ways bestimmen, die einen dieser nodes beinhalten → kommen in den Extract
Alle relations bestimmen, die einen dieser nodes oder ways beinhalten → kommen in den Extract
3a) Eventuell: alle relations, die eine dieser relations enthalten
Das zusätzlich die anderen Element der Relationen in den Extract aufgenommen werden, würde eine gigantische Datenmenge bedeuten. Der selbe Mechanismus wird z.B. auch von JOSM benutz um eine BoundingBox nachzuladen. Die Relationen sind in der Regel unvollständig.
Man könnte natürlich den Exract Algorithmus erweitern:
4)
Wenn (Relation ist ein Multipolygon) {
Sortiere ways so, dass geschlossene Gebiete entstehen.
Wenn (Multipoligon ist ohne Fehler) {
Für alle (geschlossenen Gebiete) {
Wenn (mindestes ein way des Gebietes im Schritt 2 zum Extract hinzugefügt wurde) {
Füge alle ways dieses Gebietes zum Extract hinzu.
Wenn (das Gebiet ein inner ist) {
Suche das entsprechende outer Gebiet
Wenn (das outer Gebiet nicht zum Extrakt gehört) {
Füge auch alle ways des outer Gebiets hinzu.
}
}
}
}
}
}
Zugegeben, der Teil mit “Wenn (das Gebiet ein inner ist)” löst ein anderes Problem, nämlich ein fehlenden outer way, wenn der inner zum Extrakt gehört, aber generell wird der Algorithmus recht kompliziert.
Wenn man aber einfach sagt:
4) Füge auch alle Mitglieder einer Relation zum Extrakt hinzu.
Kann der Extrakt wirklich riesig werden. Es gibt Relationen, die enthalten Relatioen, die enthalten …
Wenn ich hier lese, es soll ein Fluss gezeichnet werden der gar nicht da ist, nur weil irgend ein 0815-Tool Schei*** baut, dann zweifel ich langsam dran, ob solche Leute überhaupt noch Mappen sollten.
Es muss die Realität gemappt werden. -Eins-Elf- Und nichts falsches. Einzig Vereinfachungen sind möglich, da man ja nicht jeden Grashalm einzeln zeichnen kann.
Wenn irgend ein 0815-Tool dann scheisse baut, dann muss man dieses Tool eben verbessern. Egal ob das was großes wie Geofabrik ist, ober ob das was kleines wie das Projekt von “railrun” werden soll. Aber es kann doch nicht sein, daß jemand Flüsse zeichnet, nur weil irgend jemand zu Faul ist einen Bug zu beheben.
Stellt Euch vor, ich würde morgen hier die Bundesstraße löschen, nur weil Mapnik den Parkplatz der 1:1 da drunter liegt nicht anzeigt. Das wäre für den Autofahrer das gleiche wie für den Kanufahrer, der Plötzlich mit seinem Kanu in Eurem Wald steht - absoluter Murks.
Ähm… Hast du dir das mal genau angeschaut?! Da gibt es wirklich einen Fluss
Also keine Angst, das Projekt “railrun” würde nichts eintragen, was nicht vorhanden ist. Es ist mehr ein Workaround um das Problem. Wenn du ein pfiffiger Programmierer bist, kannst du gern ein osmosis-Patch schreiben, welches bei gleichbleibender Geschwindigkeit dieses Problem behebt
Also bevor du meckerst, schau es dir mal an und lies genauer…
So, ich hab es jetzt das riesen MP in 4 Teile geteilt. In Mapnik wird es korrekt dargestellt, in Osmarender nicht. Wieso, weshalb warum??? Kann mal jemand einen Blick drauf werfen?!
Es betrifft die Relationen 1692259, 1750723, 1750717, 1750661.
In JOSM wird bei mir auch kein Fehler angezeigt.
)