Am 04.09.2010 03:23, schrieb M∡rtin Koppenhoefer:
wie kommst Du da drauf. Es gibt viele Gründe, warum ein Weg mit einer
Fläche einen gemeinsamen Knoten haben sollte, z.B. Eingänge und Tore.
Eingänge und Tore sind in Zäune und Mauern und nicht in Grundstücksgrenzen.
Garry
Am 8. September 2010 01:44 schrieb Garry garr...@gmx.de:
Am 04.09.2010 03:23, schrieb M∡rtin Koppenhoefer:
wie kommst Du da drauf. Es gibt viele Gründe, warum ein Weg mit einer
Fläche einen gemeinsamen Knoten haben sollte, z.B. Eingänge und Tore.
Eingänge und Tore sind in Zäune und Mauern
Am 04.09.2010 13:07, Garry:
Am 04.09.2010 11:36, schrieb Claudius:
Du vergisst die dritte Option: Ein erfahrener Mapper wird durch ein
QS-Werkzeug auf den Fehler aufmerksam und korrigiert ihn. Denn das
Wiki-Prinzip beruht auch darin, dass jeder seine Stärken zum Projekt
beisteuert.
Dem fehlt
Tom Müller [tmerl...@web.de] schrieb am 3. September 2010 21:44
Entspricht dann bei der Relation ein member der mit role=inner
gekennzeichnet ist *immer genau einer* Insel? Also schneide ich für
jeden member mit role=inner aus, oder können auch mehrere member mit
role=inner ein Polygon sein
M∡rtin Koppenhoefer [dieterdre...@gmail.com] schrieb am 3. September 2010 21:34
das Problem ist halt, dass so große Multipolygone in vielen Anwendungen nicht
funktionieren / Probleme machen ...
Mapnik zeigt, dass es geht. Und man sollte nicht vergessen, dass die
Multipolygone geschaffen
Am 04.09.2010 06:22, schrieb Willi:
Am 4. September 2010 07:20 schrieb Garry [garr...@gmx.de]
An der Stelle die Frage: Warum gibt es eigentlich riverbanks?
landuse=water hätte doch an der Stelle genügt, oder?
Ja, stimmt eigentlich. Ist doch beides Wasser und beides wird auf den
Am 04.09.2010 08:59, schrieb Willi:
Meines Erachtens sollte man nie ein Detail ändern, ohne das gesamte Gebilde
angesehen und verstanden zu haben. Dies gilt bereits für einfache
Läuft dann bei OSM nicht irgendwas aus dem Ruder wenn nur noch Profis
mit umfangreichen Wissen Detailänderungen
Am 04.09.2010 08:59, schrieb Willi:
Meines Erachtens sollte man nie ein Detail ändern, ohne das gesamte Gebilde
angesehen und verstanden zu haben. Dies gilt bereits für einfache
Garry [garr...@gmx.de] schrieb am 4. September 2010 15:11
Läuft dann bei OSM nicht irgendwas aus dem Ruder wenn
On 04.09.2010 11:10, Willi wrote:
Am 04.09.2010 08:59, schrieb Willi:
Meines Erachtens sollte man nie ein Detail ändern, ohne das gesamte Gebilde
angesehen und verstanden zu haben. Dies gilt bereits für einfache
Garry [garr...@gmx.de] schrieb am 4. September 2010 15:11
Läuft dann bei OSM
Am 04.09.2010 11:31, Peter Wendorff:
On 04.09.2010 11:10, Willi wrote:
Am 04.09.2010 08:59, schrieb Willi:
Meines Erachtens sollte man nie ein Detail ändern, ohne das gesamte
Gebilde angesehen und verstanden zu haben. Dies gilt bereits für
einfache
Garry [garr...@gmx.de] schrieb am 4.
Am 4. September 2010 08:59 schrieb Willi wil...@gmx.de:
M∡rtin Koppenhoefer [dieterdre...@gmail.com] schrieb am 3. September 2010
21:34
das Problem ist halt, dass so große Multipolygone in vielen Anwendungen nicht
funktionieren / Probleme machen ...
Mapnik zeigt, dass es geht. Und man
Am 04.09.2010 11:10, schrieb Willi:
Wieso nur Profis? Ich habe für Sorgfalt plädiert und nicht für Wissen. Sowohl privat als auch
beruflich habe ich häufig erlebt, dass Profis schlampig arbeiten und Laien
sorgfältig und das Ergebnis entsprechend und nicht wie eigentlich ursprünglich erwartet
Am 04.09.2010 11:36, schrieb Claudius:
Ihm bleiben zwei Optionen (wenn nicht gerade stundenlang Zeit für
Einarbeitungen da ist): Schema durchbrechen und damit aus Sicht anderer
Daten kaputtmachen, oder aber aufhören zu mappen.
Ich persönlich finde beides nicht gut.
Du vergisst die dritte
Am 04.09.2010 12:58, schrieb M∡rtin Koppenhoefer:
Mapnik zeigt, dass es geht. Und man sollte nicht vergessen, dass die
Multipolygone geschaffen wurden, um den Anwendungen zu helfen. Der Mensch
benötigt sie nicht.
Multipolygone braucht man zwangsläufig, um Flächen aus anderen Flächen
Am 04.09.2010 08:16, schrieb Willi:
Mehrere Wege, die innere Mitglieder eines Multipolygons sind, können einen Ring
(geschlossenen Weg) bilden, der eine (innere) Fläche umrandet. Bei Insel im
See ist der Ring die Uferlinie und die enthaltene Fläche die Insel.
Generell gilt laut Wiki: Eine
Am Freitag, den 03.09.2010, 14:50 +0200 schrieb Fabian Schmidt:
Ich habe etliche Kilometer von Bächen gemappt, die nur selten bepaddelbar
sind, indem ich das Ufer abgelaufen bin. Die Tracks habe ich bewusst nicht
hochgeladen, da aus dem reinen Track nicht hervorgeht, wo der Bach
verläuft,
Tom Müller [tmerl...@web.de] schrieb am 4. September 2010 18:21
Wie kann ich denn rausfinden ob ein inner-member allein schon eine Insel
ist, oder ob ich da noch weitere Member zu einem Polygon zusammenfügen muss?
IM JOSM Relationseditor kann ein Mitglied der Relation nach rechtem Mausklick
Hallo,
ich müsste dies allerdings dynamisch machen in einem Java-Programm.
Danke
Am 04.09.2010 15:24, schrieb Willi:
Tom Müller [tmerl...@web.de] schrieb am 4. September 2010 18:21
Wie kann ich denn rausfinden ob ein inner-member allein schon eine Insel
ist, oder ob ich da noch weitere
On 03.09.10 10:54, Tom Müller wrote:
Sind die riverbank-Polygone schon geschlossen, oder muss ich das noch machen?
http://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Driver#Flussinsel
zeigt eigentlich sehr deutlich, wie man Flüsse mit waterway=riverbank mappt.
/al
Am 4. September 2010 14:31 schrieb André Reichelt andr...@online.de:
In so einem Fall sollte man dann aber unbedingt das Source-Tag sauber
ausfüllen, sodass für andere Mapper erkennbar ist, woher die Daten
stammen. Ohne dieses Wissen könnte man sehr leicht folgern, dass jemand
das Ganze
Hallo,
ich frage mich, wie die bekannten Renderer die Flüsse zeichnen.
Die Waterways sind ja schließliche keine Polynome. Trotzdem sehen die
Flüße wie welche aus. Auch nature=water ergibt nur 2 Polynome. Gibt es
noch ein Tag was ich übersehe? Oder muss ich das irgendwie aus den
waterways
Am 03.09.10 schrieb Tom Müller:
ich frage mich, wie die bekannten Renderer die Flüsse zeichnen.
Die Waterways sind ja schließliche keine Polynome.
Flußabschnitte sind Polygone. Im einfachen Fall wird der Fluß durch einen
waterway mit optionaler Breite definiert, das ist ein Weg in
Hallo,
es gibt da noch waterway=riverbank. Damit wird das Flussbett als Polygon
gemappt.
http://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Driverbank
Viele Grüße,
aighes
--
View this message in context:
http://gis.638310.n2.nabble.com/Zeichnen-von-Flussen-tp5494450p5494513.html
Sent from
Okay, danke.
Sind die riverbank-Polygone schon geschlossen, oder muss ich das noch
machen?
Danke!
Tom
Am 03.09.2010 10:48, schrieb Fabian Schmidt:
Am 03.09.10 schrieb Tom Müller:
ich frage mich, wie die bekannten Renderer die Flüsse zeichnen.
Die Waterways sind ja schließliche keine
Am 3. September 2010 10:54 schrieb Tom Müller tmerl...@web.de:
Okay, danke.
Sind die riverbank-Polygone schon geschlossen, oder muss ich das noch
machen?
die werden derzeit künstlich (also von Hand) in Abschnitte
geteilt, so dass sie nicht zu groß werden (d.h. es gibt
Querverbindungen in den
waterway=riverbank-Polygone sind geschlossen, JOSM muniert das als
überlappende Wege, aber das kannst du getrost ignorieren.
Claudius
Am 03.09.2010 10:54, Tom Müller:
Okay, danke.
Sind die riverbank-Polygone schon geschlossen, oder muss ich das noch
machen?
Danke!
Tom
Am 03.09.2010 10:48,
Tom Müller tmerl...@web.de wrote:
ich frage mich, wie die bekannten Renderer die Flüsse zeichnen.
Bei großen Flüssen wird das nur durch riverbank halbwegs schön.
Osmarender kann eine Breitenangabe (with=1m) auswetern. Bei Mapnik geht das
leider bisher technisch nicht.
Gut kann man das heir
Am 3. September 2010 12:07 schrieb Sven Geggus li...@fuchsschwanzdomain.de:
Osmarender kann eine Breitenangabe (with=1m) auswetern. Bei Mapnik geht das
leider bisher technisch nicht.
Gut kann man das heir erkennen:
http://osm.org/go/0D0yZdu2a-?layers=O
Im Mapnik leider nicht so prall.
Hallo,
Am Freitag 03 September 2010 12:18:46 schrieb M∡rtin Koppenhoefer:
spricht doch eigentlich nichts dagegen, auch bei kleinen Flüssen die
Ufer explizit anzugeben. Ganz regelmäßig (also aus der Breite
ableitbar) sind die doch sowieso praktisch nie, selbst bei befestigten
Ufern gibt es
Hallo,
Am Freitag 03 September 2010 12:28:02 schrieb Wolfgang:
Hallo,
Am Freitag 03 September 2010 12:18:46 schrieb M∡rtin Koppenhoefer:
spricht doch eigentlich nichts dagegen, auch bei kleinen Flüssen die
Ufer explizit anzugeben. Ganz regelmäßig (also aus der Breite
ableitbar) sind die
Am 3. September 2010 12:44 schrieb Wolfgang wolfg...@ivkasogis.de:
Hallo,
Am Freitag 03 September 2010 12:28:02 schrieb Wolfgang:
Hallo,
Am Freitag 03 September 2010 12:18:46 schrieb M∡rtin Koppenhoefer:
spricht doch eigentlich nichts dagegen, auch bei kleinen Flüssen die
Ufer explizit
Am 3. September 2010 12:44 schrieb Wolfgang wolfg...@ivkasogis.de:
Noch eine Idee: möglichst nahe am Ufer fahren und Uferlinie mit möglichst
großen Teleobjektiv fotografieren. In den Exif-Daten steht später die
Entfernungseinstellung, und aus der Uhrzeit und dem Track ergibt sich nach
Hallo,
also die Flüsse habe ich nun größtenteils!
Nun fehlen aber bei der Spree kleine Stücke (die Seenähnlich sein
müssten) und die Seen. Ich dachte die finde ich als natural=water, aber
dem ist nicht so, da gibt es für ganz Berlin nur 2.
Habe ich sonst noch ein Tag übersehen?
Danke!
Tom
Am 3. September 2010 13:54 schrieb Martin Simon grenzde...@gmail.com:
das Problem ist, daß unsere einzigen Quelldaten, die allen zur
Verfügung stehen, die gps-traces sind.
Und selbst die werden nicht von allen hochgeladen und - schlimmer -
nicht von allen beachtet. Ich habe mich gerade heute
Am 03.09.10 schrieb Martin Simon:
das Problem ist, daß unsere einzigen Quelldaten, die allen zur
Verfügung stehen, die gps-traces sind.
Und selbst die werden nicht von allen hochgeladen
Ich habe etliche Kilometer von Bächen gemappt, die nur selten bepaddelbar
sind, indem ich das Ufer
Am 03.09.10 schrieb Tom Müller:
Nun fehlen aber bei der Spree kleine Stücke (die Seenähnlich sein
müssten) und die Seen. Ich dachte die finde ich als natural=water, aber
dem ist nicht so, da gibt es für ganz Berlin nur 2.
dann gibt es bei der Suche ein Problem, es gibt viel mehr als 2
(
Am 3. September 2010 13:58 schrieb Martin Simon grenzde...@gmail.com:
gemappt und einen track hochgeladen habe, später jemand einfach den
kompletten Pfad sehr vereinfacht und verschoben hat,
ja, das passiert mir leider auch öfters mal. Das macht m.E. die sog.
Routing-Fraktion (unterstelle ich
Hallo,
Am Freitag 03 September 2010 14:50:38 schrieb Fabian Schmidt:
Am 03.09.10 schrieb Martin Simon:
das Problem ist, daß unsere einzigen Quelldaten, die allen zur
Verfügung stehen, die gps-traces sind.
Und selbst die werden nicht von allen hochgeladen
Ich habe etliche Kilometer von
Hi,
ich habe sie mittlerweile entdeckt :) und alles ist vollständig!
Danke
Tom
Am 03.09.2010 15:01, schrieb Fabian Schmidt:
Am 03.09.10 schrieb Tom Müller:
Nun fehlen aber bei der Spree kleine Stücke (die Seenähnlich sein
müssten) und die Seen. Ich dachte die finde ich als
On 03.09.2010 15:02, M∡rtin Koppenhoefer wrote:
Am 3. September 2010 13:58 schrieb Martin Simongrenzde...@gmail.com:
gemappt und einen track hochgeladen habe, später jemand einfach den
kompletten Pfad sehr vereinfacht und verschoben hat,
ja, das passiert mir leider auch öfters mal. Das macht
Am 3. September 2010 15:27 schrieb Peter Wendorff wendo...@uni-paderborn.de:
Und wieder ein Argument dafür, eine Routing-Ebene auch in der API
abzuspalten, die Routing-Relevante Daten von Kartendaten trennt.
nö, wieso? Jeder der Routing machen will, nimmt die Daten, die da
sind, und
Am 3. September 2010 10:54 schrieb Tom Müller tmerl...@web.de:
Sind die riverbank-Polygone schon geschlossen, oder muss ich das noch
machen?
Am 3. September 2010 16:04 schriebM∡rtin Koppenhoefer
[dieterdre...@gmail.com]
die werden derzeit künstlich (also von Hand) in Abschnitte
Am 3. September 2010 16:10 schrieb Willi wil...@gmx.de:
Geht doch einfach mit Multipolygon wie im Wiki beschrieben
http://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Driverbank.
Habe so kürzlich 1018 km Flussufer des Ping River in Thailand gezeichnet:
On 03.09.2010 15:35, M∡rtin Koppenhoefer wrote:
Am 3. September 2010 15:27 schrieb Peter Wendorffwendo...@uni-paderborn.de:
Und wieder ein Argument dafür, eine Routing-Ebene auch in der API
abzuspalten, die Routing-Relevante Daten von Kartendaten trennt.
nö, wieso? Jeder der Routing machen
Entspricht dann bei der Relation ein member der mit role=inner
gekennzeichnet ist *immer genau einer* Insel? Also schneide ich für
jeden member mit role=inner aus, oder können auch mehrere member mit
role=inner ein Polygon sein was zusammen ausgeschnitten werden muss?
Danke
Am 03.09.2010
Am 03.09.2010 15:27, schrieb Peter Wendorff:
Und wieder ein Argument dafür, eine Routing-Ebene auch in der API
abzuspalten, die Routing-Relevante Daten von Kartendaten trennt.
Sinnvoll ist es auf jeden Fall Katasterdaten(hier die geschlossenen
Polygone die eine Fläche beschreiben, also
Am 03.09.2010 15:35, schrieb M∡rtin Koppenhoefer:
Am 3. September 2010 15:27 schrieb Peter Wendorffwendo...@uni-paderborn.de:
Und wieder ein Argument dafür, eine Routing-Ebene auch in der API
abzuspalten, die Routing-Relevante Daten von Kartendaten trennt.
nö, wieso? Jeder der
Am 03.09.2010 15:07, schrieb Wolfgang:
Das Paddeln bezog sich auf das Erfassen von Uferlinien (riverbank). Bei so
einem Bach (2-4m) reicht deine Erfassung völlig aus.
Man sollte nur beachten dass bei kleinen Bach/Flussbreiten beide
Uferseiten gleichzeitig erfasst werden sollten
da sich
Am 4. September 2010 02:20 schrieb Garry garr...@gmx.de:
Am 03.09.2010 15:27, schrieb Peter Wendorff:
Und wieder ein Argument dafür, eine Routing-Ebene auch in der API
abzuspalten, die Routing-Relevante Daten von Kartendaten trennt.
Sinnvoll ist es auf jeden Fall Katasterdaten(hier die
Am 4. September 2010 07:20 schrieb Garry [garr...@gmx.de]
An der Stelle die Frage: Warum gibt es eigentlich riverbanks?
landuse=water hätte doch an der Stelle genügt, oder?
Ja, stimmt eigentlich. Ist doch beides Wasser und beides wird auf den Karten
blau dargestellt. Wozu sollte auch
50 matches
Mail list logo
