Frederik Ramm [EMAIL PROTECTED] wrote:
Ich hab nicht wirklich Verstaendnis fuer est_width. Machen wir doch
sonst auch nicht, dass wir unterscheiden zwischen geschaetzt und
gemessen. Wenn der Mapper nur eine geschaetzte Breite hat, kann er die
ja in width reinschreiben und source=estimate
Am 6. Juli 2008 19:37 schrieb Sven Geggus [EMAIL PROTECTED]:
Daniel Schmidt [EMAIL PROTECTED] wrote:
Feine Sache, Sven. Könnte man das vielleicht noch um est_width
erweitern? Bei vielen Flüssen werden wohl einfach nur grobe
Schätzungen zur Breite vorliegen, zumal sich die Breite oft alle paar
Am 17. Juli 2008 01:13 schrieb Frederik Ramm [EMAIL PROTECTED]:
Hallo,
gemeint war glaube ich, dass man falls vorhanden width berücksichtigt.
Für den Fall, dass es aber nur einen Tag est_width gibt, und kein
width, wäre es nicht schlecht, dies auch abzufragen und in diesem Fall
so wie sonst
Stefan Schwan wrote:
Am 17. Juli 2008 01:13 schrieb Frederik Ramm [EMAIL PROTECTED]:
Hallo,
gemeint war glaube ich, dass man falls vorhanden width berücksichtigt.
Für den Fall, dass es aber nur einen Tag est_width gibt, und kein
width, wäre es nicht schlecht, dies auch abzufragen und in
Ich verlagere mal die Diskussion (Flussbreite fuer osmarender.xsl [1])
mit hier her...
On Sun, 6 Jul 2008 21:12:03 + (UTC)
Sven Geggus [EMAIL PROTECTED] wrote:
Sven Geggus [EMAIL PROTECTED] wrote: OK Leute, nachdem
Raphael zurecht darauf hingewiesen hat, dass das Teil stinklangsam
Christian Koerner wrote:
width - 9623
est_width - 489
est width - 68
width_est - 16
Also wenn est_width gekippt werden sollte, wäre es ganz nett, die
vorhandene Information als width=xxx+width:source=estimated zu erhalten.
Hat jemand Lust ein Proposal für
On Sun, 6 Jul 2008 21:12:03 + (UTC)
Sven Geggus [EMAIL PROTECTED] wrote:
Hier also die Version 0.2 des Flußbreiten-Patch ich denke ihr könnt
schon mal eure Laser Entfernungmesser kaufen gehn!
Bei mir macht er das Casing nicht richtig. Da wir fuer
waterway-river-core und
On Mon, 7 Jul 2008 17:43:20 +0200
Christian Koerner [EMAIL PROTECTED] wrote:
-- Warum auf drawPathWithSmartLinecaps Funktion beschraenken?
Ob SmartLinecaps oder nicht wird ja in der Regeldatei angegeben. Wenn
der Benutzer nun fuer waterway=river aber smart-linecap=no in
der Regeldatei
Hi Sven,
Ich möchte das ganze jedoch erst ins svn einchecken wenn es jemand
ausprobiert und für funktioniell befunden hat.
Ich hab mal mein Lieblingsflüsschen zu einem River gemacht und die
Breite des Flusses in 1ner Schritten von 1 auf 35 vergrössert. Sieht
recht glatt aus, funktioniert
Raphael Studer [EMAIL PROTECTED] wrote:
Ich hab mal mein Lieblingsflüsschen zu einem River gemacht und die
Breite des Flusses in 1ner Schritten von 1 auf 35 vergrössert. Sieht
recht glatt aus, funktioniert tiptop, nur hab ich das Gefühl, dass
rendern dauert länger.
Sollte eigentlich nicht.
On Sat, 5 Jul 2008 17:56:18 + (UTC)
Sven Geggus [EMAIL PROTECTED] wrote:
Hallo zusammen,
so, jetzt kann ich endlich teilweise das anbieten, was ich eigentlich
schon länger haben wollte aber bisher mangels xslt Kenntnisse nicht
realisieren konnte.
Prinzipiell bin ich zwar auch kein
Christian Koerner [EMAIL PROTECTED] wrote:
Wir muessen zwei Breitenangaben beruecksichtigen 'width' und
'est_width' und ich empfehle die Verwendung von
'est_width' bei geschaetzter Breite.
Das sehe ich vollkommen anders! Müssen tun wir gar nichts. Außerdem
gefällt mir das nicht (Begründung
Sven Geggus [EMAIL PROTECTED] wrote:
Langer Rede kurzer Sinn! Ich hab trotzdem für orp einen patch gebaut,
der die Breite von Flüssen berücksichtig, wenn ein with=X Tag an den
Weg angehängt ist. X ist die Breite des Flusses in Meter.
OK Leute, nachdem Raphael zurecht darauf hingewiesen hat,
Hallo zusammen,
so, jetzt kann ich endlich teilweise das anbieten, was ich eigentlich
schon länger haben wollte aber bisher mangels xslt Kenntnisse nicht
realisieren konnte.
Prinzipiell bin ich zwar auch kein Perl Hacker sondern meine
Scriptsprachen sind eher Python und Tcl, aber trotzdem liegt
14 matches
Mail list logo
