Wald im Grenzgebiet

chris66 · 2011-09-02T06:50:28.000Z

Wir mappen nicht für die Geofabrik.

railrun · 2011-09-02T07:03:11.000Z

chris66:

Wir mappen nicht für die Geofabrik.

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.

Radeln · 2011-09-02T07:13:02.000Z

railrun:

chris66:

Wir mappen nicht für die Geofabrik.

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.

Wende Dich an die Geofabrik. Vielleicht reicht es ja, wenn der DE-Extrakt großzügiger ausgeschnitten wird.
Ob die da mitmachen?

railrun · 2011-09-02T07:17:37.000Z

Radeln:

Ob die da mitmachen?

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.

chris66 · 2011-09-02T08:05:20.000Z

railrun:

Einfache finde ich jedoch meine vorgeschlagene Variante.

Die aber glaube ich noch niemand verstanden hat?

railrun:

einen Way vom MP durch Wald auf dem Way der Grenze von D-CZ zu legen.

softcake · 2011-09-02T08:06:16.000Z

Habe das gleiche Problem (Grenzgebiet). Für uns gibt es eine Datenquelle DE+50km.

Siehe Thread: http://forum.openstreetmap.org/viewtopic.php?id=11792

Gruß, softcake

chris66 · 2011-09-02T08:15:37.000Z

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.

railrun · 2011-09-02T08:21:04.000Z

chris66:

railrun:

Einfache finde ich jedoch meine vorgeschlagene Variante.

Die aber glaube ich noch niemand verstanden hat?

railrun:

einen Way vom MP durch Wald auf dem Way der Grenze von D-CZ zu legen.

Hab ich mir schon gedacht

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.

softcake:

Habe das gleiche Problem (Grenzgebiet). Für uns gibt es eine Datenquelle DE+50km.
Siehe Thread: http://forum.openstreetmap.org/viewtopic.php?id=11792
Gruß, softcake

Hab es mir mal kurz angeschaut. Das gibt’s aber nur als osm.xz. Warum nicht als pbf?

chris66:

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.

Mag sein, aber was spricht gegen das Teilen des großen MP in 2 Teile?!

de_muur · 2011-09-02T08:26:01.000Z

railrun:

Und wenn du dir den “großen” Wald anschaust, müsste man deutlich großzügiger ausschneiden…

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.

Gruss
Torsten

wambacher · 2011-09-02T08:26:47.000Z

railrun:

Hat die Reihenfolge der Members einer Relation eine Auswirkung auf dessen Form?! (Doofe Frage, aber es gibt ja bekanntlich keine doofe Fragen )

Nö,
ist total unwichtig.
Allerdings hat es der “Doofe” an der Tastatur einfacher, wenn die Members geordnet sind. Dann sieht er Probleme leichter.

Gruss
Walter

p.s. ich würde dennoch darum bitten, die Wälder so stehen zu lassen.

railrun · 2011-09-02T08:38:33.000Z

de_muur:

railrun:

Und wenn du dir den “großen” Wald anschaust, müsste man deutlich großzügiger ausschneiden…

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.

Gruss
Torsten

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.

de_muur · 2011-09-02T09:08:09.000Z

railrun:

Wie sieht’s mit einem Fluss als “Teiler” aus?!

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.

Aber dennoch besteht das Problem dann in anderen Teilen der Republik?!

Nur dort, wo mit unsinnig grossen Flaechenobjekten gearbeitet wird. Aber das sollte man ja auch nicht machen.

Ich hoffe, dass für euch ersichtlich wird, warum ich den Wald gerne in 2 MPs teilen würde.

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.

Gruss
Torsten

mdk · 2011-09-02T09:29:52.000Z

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

Grüsse

mdk

railrun · 2011-09-02T10:09:59.000Z

mdk:

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

Grüsse

mdk

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?!

mdk · 2011-09-02T10:43:00.000Z

railrun:

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 …

Grüsse
mdk

Dennis_B · 2011-09-03T10:16:57.000Z

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.

railrun · 2011-09-03T10:25:27.000Z

'Dennis[B:

']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…

derstefan · 2011-09-03T22:20:46.000Z

Immer locker bleiben, Freunde…

Es gibt drei Grundregeln bei OSM:

Verwende nicht von nicht-freien Quellen.
Kartiere für die Datenbank, nicht für den Renderer.
Habe Spaß.

Viele Grüße
Euer derstefan.

railrun · 2011-09-13T07:24:28.000Z

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.

railrun · 2011-09-13T07:31:24.000Z

Kommando zurück… Jedes Tile welches man als neu rendern lässt, erscheint auch richtig