On 25/04/12 19:53, Christian Müller wrote:
Am 23.04.2012 23:29, schrieb Tirkon:
Von welcher Meldung sprichst Du konkret?
In der Abteilung Relationen wird jede betroffene Relation mit dem
Zusatz (unvollständig) versehen. Das veranlasst zum Nachzuladen,
womit es verschindet. Es ist demnach ein
Am 23.04.2012 23:29, schrieb Tirkon:
Von welcher Meldung sprichst Du konkret?
In der Abteilung Relationen wird jede betroffene Relation mit dem
Zusatz (unvollständig) versehen. Das veranlasst zum Nachzuladen,
womit es verschindet. Es ist demnach ein Kürzel für unvollständig
geladen.
Hallo,
Am Samstag, 21. April 2012 13:03:51 schrieb Wolfgang:
eine Kette von Polygonen zu teilen, die nicht jeder immer laden
Ist nicht korrekt ausgedrückt, es hätte Polygonlinien ( in Anlehnung
an geod. Polygonzug) oder offenes Polygon heißen müssen, da das
Polygon als Figur betrachtet wird
Martin Koppenhoefer dieterdre...@gmail.com schrieb:
Am 22. April 2012 18:08 schrieb Christian Müller cmu...@gmx.de:
Am 22.04.2012 14:47, schrieb Tirkon:
Multipolygon - zu deutsch etwa viele Vielecke
diese Übersetzung greift zu kurz, es sind Vielecke (eingeschlossen
sind Dreiecke
Am 22. April 2012 02:14 schrieb Garry garr...@gmx.de:
Es gibt auch Sonderfälle die nicht per MP gelöst werden können.
Beispiel:
Gib mir alle deutschen Bundestrassenabschnitte. - Ein Abschnitt der B317
bei Lörrach verläuft (Zollfreie,Freigabe im Laufe des Jahres) über
schweizer Gebiet und
Am 22. April 2012 18:08 schrieb Christian Müller cmu...@gmx.de:
Am 22.04.2012 14:47, schrieb Tirkon:
Multipolygon - zu deutsch etwa viele Vielecke
diese Übersetzung greift zu kurz, es sind Vielecke (eingeschlossen
sind Dreiecke aufwärts), die aus mehreren Umrissen und/oder
Umrissteilen
Hi,
On Sat, Apr 21, 2012 at 04:39:59AM +0200, Tirkon wrote:
Die ÖPNV Relationen sind das beste Beispiel dafür, wie sich ein als
möglichst umfassend und stimmig befundenes Oxomoa Schema einfach nicht
durchsetzt. Selbst die Spezialisten mappen das Schema in zig
Varianten. Die meisten örtlichen
Christian Müller cmu...@gmx.de wrote:
Wenn ich einen Umring teile, so sind diese Teile keine geschlossenen
Linien und somit kein Polygon mehr. Wo kommt also die Kette von
Polygonen her? Möchtest Du einen Staat in Flächenteile (Polygone)
zerlegen, um diese dann zu vereinen (Kette von
Florian Lohoff f...@zz.de wrote:
...
Wenn es keine technische Abhaengigkeit gibt wird es nicht gepflegt.
...
+1 für das gesamte Posting.
Schön, Dich wieder zurück im Projekt zu haben.
Aber bei der ganzen forward/backward Nummer
war meine Motivation weg - Es gibt IIRC keine Applikation
Wolfgang wolfg...@ivkasogis.de wrote:
Hallo,
Am Samstag, 21. April 2012 04:39:59 schrieb Tirkon:
Zurück zum multipolygon und zur boundary. Das multipolygon ist ein
geometrisches Objekt und hat zunächst einmal wenig mit OSM zu tun.
Was wir erfassen, ist eine Grenze, also boundary. Von daher
Am 22.04.2012 14:47, schrieb Tirkon:
Wenn ich einen Umring teile, so sind diese Teile keine geschlossenen
Linien und somit kein Polygon mehr. Wo kommt also die Kette von
Polygonen her? Möchtest Du einen Staat in Flächenteile (Polygone)
zerlegen, um diese dann zu vereinen (Kette von Polygonen)?
Martin Koppenhoefer dieterdre...@gmail.com wrote:
Am 20. April 2012 18:00 schrieb Christian Müller cmu...@gmx.de:
Der Optimierungswille den Du ansprichst, hat nicht nur etwas mit DBs zu tun.
Warum gehen davon eigentlich alle aus? Nicht immer stecken die zu
verarbeitenden Daten in einer
Hallo,
Am Samstag, 21. April 2012 04:39:59 schrieb Tirkon:
Zurück zum multipolygon und zur boundary. Das multipolygon ist ein
geometrisches Objekt und hat zunächst einmal wenig mit OSM zu tun.
Was wir erfassen, ist eine Grenze, also boundary. Von daher wird es
sich wesentlich weniger Mappern
Wolfgang-4 wrote
Bei Landkreisen sind normale Polygone noch handhabbar, bei Staatsgrenzen
teilweise nicht mehr. Da macht es Sinn, die Umringe in eine Kette von
Polygonen zu teilen, die nicht jeder immer laden muss. Das leistet das
Multipolygon.
jo, ganz deiner Meinung.
Schau dir mal
Am 21.04.2012 19:41, schrieb Walter Nordmann:
Wolfgang-4 wrote
Bei Landkreisen sind normale Polygone noch handhabbar, bei Staatsgrenzen
teilweise nicht mehr. Da macht es Sinn, die Umringe in eine Kette von
Polygonen zu teilen, die nicht jeder immer laden muss. Das leistet das
Multipolygon.
Am 20.04.2012 14:38, schrieb Martin Koppenhoefer:
Andererseits
könnte ein Verschnitt sehr komplex werden - wenn das MP aus mehreren
Einzelflächen besteht, also mehrere Verschnitte berücksichtigt werden
müssen.
dann werden die eben der Reihe nach abgearbeitet. Davon bekommst Du
Hallo,
Am Freitag, 20. April 2012 02:20:24 schrieb Christian Müller:
Moin,
ich mag in diesem Zusammenhang noch einmal kurz auf das Thema
Flächennetzwerk zurückzukommen.
Have a fun read..
Da hast du dir ja richtig Arbeit gemacht
;-)
Am 19.04.2012 13:05, schrieb Wolfgang:
-1 Das
Am 20. April 2012 12:04 schrieb Wolfgang wolfg...@ivkasogis.de:
Park mit inner = Schlosssockel. Die Seen, Wiesen etc würde ich als zum
Schlosspark zugehörig ansehen und nicht aus der Parkfläche ausschließen
wollen.
+1
Beim Sockel kommt es drauf an, wie der aussieht.
+1. Wenn es sich
Am 20.04.2012 03:14, schrieb Martin Koppenhoefer:
Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als
auch für die zukünftige Pflege bei Daten im Vergleich zu einer
site-relation als bunte Mischung aller möglichen Elemente und
Bestandteile ist ein schlichtes Polygon, das die
Am 20. April 2012 14:01 schrieb Christian Müller cmu...@gmx.de:
Am 20.04.2012 03:14, schrieb Martin Koppenhoefer:
Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als
auch für die zukünftige Pflege bei Daten im Vergleich zu einer
site-relation als bunte Mischung aller möglichen
Hallo Wolfgang,
Am 20.04.2012 12:04, schrieb Wolfgang:
Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um
zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon
völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern
verhindern, dass
- das
Duerfte ich als unbeteiligter Dritter dem OP diesen Link empfehlen:
http://en.wikipedia.org/wiki/Spatial_database
Interessanterweise gibt es keine gute Uebersetzung dafuer und Wikipedia
verlinkt es auch nicht zu einem deutsche Artikel.
Wer den findet, kann ihn ja gerne mal posten.
Ich glaube,
Am 20. April 2012 14:57 schrieb Ronnie Soak chaoschaos0...@googlemail.com:
Ich weiss ehrlich gesagt nicht, ob OSM wirklich so organisiert ist, aber
ich habe es zumindest bisher immer angenommen.
AFAIK ist die Haupt-db eine Postgres-db ohne PostGIS (das sind die
spatial-Erweiterungen), während
Hallo,
On 04/20/2012 02:54 PM, Christian Müller wrote:
Ist es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn
Schachtelungszusammenhänge explizit in den Relationen wären?
Als jemand, der mit solchen Fragen staendig in der Praxis umgeht, kann
ich sagen:
Es ist 100%
Hallo nochmal,
noch ein Nachtrag - für Statistiken, welche die implizite Variante der
Flächenbezüge als Grundlage nutzen, wäre zwar auch ein Cache für
aufwendig errechnete Ergebnisse denkbar - für einen solchen existieren
aber m.W. in und um OSM weder Standards noch die Möglichkeit ihn
Am 20. April 2012 17:27 schrieb Christian Müller cmu...@gmx.de:
Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries zu
tätigen, oder gibt es noch andere Dienste, die evtl. zusätzlich, aus den
OSM-Daten abgeleitete Daten bereitstellen? Die MapQuest-Dienste sind mir
geläufig.
Du kannst mit dem Planet Dump die Daten in jede DB stopfen, wenn Du dir
die Mühe machst einen Converter zu schreiben.
Nochmal: Es geht nicht darum, alle automatisch
ermittelbaren/herstellbaren Flächenbezüge, manuell zu erfassen, sondern
nur die, welche dem Mapper sinnvoll erscheinen.
Der
Am 20.04.2012 16:19, schrieb Frederik Ramm:
Hallo,
On 04/20/2012 02:54 PM, Christian Müller wrote:
Ist es nicht gerade für die Erstellung solcher Statistiken von
Vorteil, wenn
Schachtelungszusammenhänge explizit in den Relationen wären?
Als jemand, der mit solchen Fragen staendig in der
Am 20. April 2012 18:00 schrieb Christian Müller cmu...@gmx.de:
Der Optimierungswille den Du ansprichst, hat nicht nur etwas mit DBs zu tun.
Warum gehen davon eigentlich alle aus? Nicht immer stecken die zu
verarbeitenden Daten in einer fetten DB, die bereitwillig rechnet. Gäbe es
die
Am 20.04.2012 16:19, schrieb Frederik Ramm:
Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal
geometrisch gueltige Polygone hin...)
[...]
Oder wir haben zu wenig gute How To Vids.. Vielleicht eine Youtube
Hilfe in JOSM integrieren. Aber das feature nicht Video2Brain
Hallo,
Am Freitag, 20. April 2012 17:44:57 schrieb Martin Koppenhoefer:
Am 20. April 2012 17:27 schrieb Christian Müller cmu...@gmx.de:
Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries
zu tätigen, oder gibt es noch andere Dienste, die evtl.
zusätzlich, aus den OSM-Daten
Hallo,
On 04/20/2012 06:08 PM, Christian Müller wrote:
Es ist 100% klar, dass ich mich nie darauf verlassen kann, dass unsere
Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal
geometrisch gueltige Polygone hin...)
Liegt vielleicht auch an der elitären Haltung, die man ihnen
Frederik Ramm frede...@remote.org wrote:
Solche komplizierten Schemata muessen
ja auch pflegbar sein.
+1
Die ÖPNV Relationen sind das beste Beispiel dafür, wie sich ein als
möglichst umfassend und stimmig befundenes Oxomoa Schema einfach nicht
durchsetzt. Selbst die Spezialisten mappen das
Moin,
ich mag in diesem Zusammenhang noch einmal kurz auf das Thema
Flächennetzwerk zurückzukommen.
Have a fun read..
Am 19.04.2012 13:05, schrieb Wolfgang:
-1 Das Multipolygon sollte rein Fläche bleiben, und Fläche sollte nur
im Multipolygon erfasst werden. Wer was dazu sammeln will, kann
Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als
auch für die zukünftige Pflege bei Daten im Vergleich zu einer
site-relation als bunte Mischung aller möglichen Elemente und
Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche
beschreibt. Bei umfriedeten Grundstücken
35 matches
Mail list logo
