Re: [Talk-de] ??[patch] Breite von Flüssen :)
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" setzen oder so, und wenn > jemand anders spaeter nachmessen will, soll er width aendern. Es gibt > keinen Grund, warum ein est_width noch erhalten bleiben muss, wenn es > ein width gibt, und daher kommt mir der Aufwand um den Extra-Tag > unnoetig vor. Seh ich auch so. Wer das unbedingt haben möchte soll das in den Renderer einbauen, ich mach das jedenfalls nicht. Ich hatte mir mal kurz überlegt den Namen des width tags in der Regeldatei konfigurierbar zu machen dann das ganze aber letztlich doch hartcodiert. Sven -- "If you don't make lower-resolution mapping data publicly available, there will be people with their cars and GPS devices, driving around with their laptops" (Tim Berners-Lee) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?[patch] Breite von Flüssen : )
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 diesem Fall >>> so wie sonst width beim Rendern der Breite zu berücksichtigen. Also >>> nicht zusätzlich, sondern alternativ. >> Ich hab nicht wirklich Verstaendnis fuer est_width. Machen wir doch >> sonst auch nicht, dass wir unterscheiden zwischen geschaetzt und >> gemessen. > > "gemesen" scheint mir hier das Stichwort - wers dabei genaunimmt wird > wohl meißtens im Ergebniss eine Deziamalzahl abliefern - Vielleicht > kann man sich ja darauf einigen, nur in Ganzen Zahlen (Metern) zum > schätzen ? Und bei gemessen zur Not 5,01m draus zu machen? *duck* Du wirst imho nie eindeutig sagen können ob das 5cm mehr oder weniger sind bei einer Straße o.ä. Auch wird bei Flüssen etc. niemand die Breite an jedem Node messen. (Dann müsste man die Breite sogar eher an den Node schreiben als an den Flussabschnitt ... n) Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?[patch] Breite von Flüssen : )
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 width beim Rendern der Breite zu berücksichtigen. Also >> nicht zusätzlich, sondern alternativ. > > Ich hab nicht wirklich Verstaendnis fuer est_width. Machen wir doch > sonst auch nicht, dass wir unterscheiden zwischen geschaetzt und > gemessen. "gemesen" scheint mir hier das Stichwort - wers dabei genaunimmt wird wohl meißtens im Ergebniss eine Deziamalzahl abliefern - Vielleicht kann man sich ja darauf einigen, nur in Ganzen Zahlen (Metern) zum schätzen ? Gruß Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?[patch] Breite von Flüssen :)
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 width beim Rendern der Breite zu berücksichtigen. Also > nicht zusätzlich, sondern alternativ. 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" setzen oder so, und wenn jemand anders spaeter nachmessen will, soll er width aendern. Es gibt keinen Grund, warum ein est_width noch erhalten bleiben muss, wenn es ein width gibt, und daher kommt mir der Aufwand um den Extra-Tag unnoetig vor. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?[patch] Breite von Flüssen :)
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 >> Meter ändert. > > Wenn sich die Breite ändert trennt man den Weg auf und setzt eine > andere Breite, so wie man das bei Straßen mit wechselnden attributen > ebenfalls macht. Wenn Die Breite nur geschätzt ist kannst Du nen > zusätzlichen Tag dranhängen, der diese Aussage enthält. > >> Ich habe bisher meistens die Breite des Flusses auf einer Brücke >> abgeschritten und dann als geschätzte Breite eingetragen. > > Was spricht nun dagegen das tagging entsprechend meines Vorschlages > umzuändern? > > Der Renderer kennt hier nur schwarz und weiß ich halte es ehrlich > gesagt nicht für sinnvoll zusätzlich zu width auch noch est_width zu > berücksichtigen. > > Sven > 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 width beim Rendern der Breite zu berücksichtigen. Also nicht zusätzlich, sondern alternativ. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen XSL
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 angibt, kann er nicht mehr das Flussbreite-Feature > genieszen. > > Und spaeter will man sicher die Breite auch fuer andere Ways haben, > also gleich mit in drawPath() einbauen! Spricht was dagegen? > Korrektur: Ich meine nicht drawPath() sondern drawWay(). Christian signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen :)
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 waterway-river-casing die gleiche Strichbreite verwenden. Wir muessen fuer's Casing die Breite anpassen. Ohne width-Tag: waterway-river-casing { stroke-width: 10px; } waterway-river-core { stroke-width: 8px; } Grusz Christian signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen XSL
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 "*:source=estimated/meassured/*" zu schreiben? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen XSL
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 > geworden ist hab ich nochmal drüber geschaut und das Problem zusammen > mit Matthias Merz, der deutlich besser perl kann als ich gelöst! > Fuer die XSL-Version habe ich die Angabe honorWidth in die Regeldatei verlegt (also in osm-map-features-z*.xml) 8< >8 Das beschraenkt den XSL-Code auf eine einzige Abfrage 8< >8 ... statt dem Aufsplitten des 'class'-Strings, dem Pruefen ob fuer $class die Breitenangabe Verwendung findet, etc. . Gleiche Vorteile gelten natuerlich auch fuer or/p. -- Namen die ich ersetzt habe: minLineWidth => minimumWayWidth maxLineWidth => maximumWayWidth meter2pixel => meter2pixelFactor Warum 'minimum/maximum'? Es existiert schon 'minimumMapWidth' und 'minimumMapHeight', also einfach um eine gewisse Namenskonvention zu haben. -- 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 angibt, kann er nicht mehr das Flussbreite-Feature genieszen. Und spaeter will man sicher die Breite auch fuer andere Ways haben, also gleich mit in drawPath() einbauen! Spricht was dagegen? -- Verwendung von Breitenangaben in Europa (Tagwatch): "width" -> 9623 "est_width" -> 489 "est width" -> 68 "width_est" -> 16 Via Script 'est_width' & Co. in 'width' aendern und nur 'width'-Angaben beruecksichten? Bitte mal diese Sachen noch klaeren, dann folgt der Osmarender-Patch :) Beste Gruesze Christian [1] Flussbreite fuer osmarender.xsl - http://lists.openstreetmap.org/pipermail/talk-de/2008-July/015624.html signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen :)
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, dass das Teil stinklangsam geworden ist hab ich nochmal drüber geschaut und das Problem zusammen mit Matthias Merz, der deutlich besser perl kann als ich gelöst! Hier also die Version 0.2 des Flußbreiten-Patch ich denke ihr könnt schon mal eure Laser Entfernungmesser kaufen gehn! http://home.geggus.net/osm/orp-river-width.diff Apropos Laser Entfernungmesser. Kennt jemand die Geräte Bosch DLE 50 und/oder PLR 30? PLR 30 ist Bosch grün DLE 50 ist blau also die Profi Serie. 50m ist schon cool. Billiger als GPS das Zeug :) Gruss Sven --schnipp-- Index: orp-drawing.pm === --- orp-drawing.pm (Revision 8793) +++ orp-drawing.pm (Arbeitskopie) @@ -15,6 +15,7 @@ require "orp-bbox-area-center.pm"; our ($writer, $projection, $symbolScale, $textAttenuation, $debug); +our %widthconfig; # --- @@ -78,15 +79,53 @@ { my ($linenode, $layer, $way, $class) = @_; +# explicit way specific style +my $style=""; + # convenience variables my $id = $way->{"id"}; my $nodes = $way->{"nodes"}; return unless(scalar(@$nodes)); +# this is a special case for ways (rivers) where we honor a +# width=something tag. +# It is used to generate rivers of different width. +# This is done by an explicit specification of a +# style="stroke-width:..px" tag in the generated SVG output + +if (defined($way->{"tags"}->{"width"})) { + + # check whether width shall be honored for this way + my $cname=""; + foreach my $c (split(/ /,$class)){ + if($widthconfig{'honorWidth'}{$c}) { + $cname=$c; + last; + } + } + if ($cname ne "") { + my $width = $way->{"tags"}->{"width"}; + $width =~ s/m$//; + my $f = $widthconfig{'meter2px'}; + my $w; + # make sure, that width is a numeric value + { no warnings; $w = $f*$width if 0+$width;} + + if (defined($w)) { + # make sure that width is inside the desired range + my $maxw = $f* $widthconfig{'maxLineWidth'}; + my $minw = $f* $widthconfig{'minLineWidth'}; + if ($w > $maxw) {$w = $maxw;} + if ($w < $minw) {$w = $minw;} + $style = "stroke-width:${w}px"; + } + } +} + # first draw middle segment if we have more than 2 nodes draw_path($linenode, "way_mid_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-start osmarender-no-marker-end") +"osmarender-stroke-linecap-butt osmarender-no-marker-start osmarender-no-marker-end", $style) if (scalar(@$nodes)>2); # count connectors on first and last node @@ -116,32 +155,32 @@ if ($first_node_connection_count == 1) { -draw_path($linenode, "way_start_$id", "osmarender-no-marker-end"); +draw_path($linenode, "way_start_$id", "osmarender-no-marker-end", $style); } elsif ($first_node_lower_layer_connection_count > 0) { draw_path($linenode, "way_start_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-end"); +"osmarender-stroke-linecap-butt osmarender-no-marker-end", $style); } else { draw_path($linenode, "way_start_$id", -"osmarender-stroke-linecap-round osmarender-no-marker-end"); +"osmarender-stroke-linecap-round osmarender-no-marker-end", $style); } if ($last_node_connection_count == 1) { -draw_path($linenode, "way_end_$id", "osmarender-no-marker-start"); +draw_path($linenode, "way_end_$id", "osmarender-no-marker-start", $style); } elsif ($last_node_lower_layer_connection_count > 0) { draw_path($linenode, "way_end_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-start"); +"osmarender-stroke-linecap-butt osmarender-no-marker-start", $style); } else { draw_path($linenode, "way_end_$id", -"osmarender-stroke-linecap-round osmarender-no-marker-start"); +"osmarender-stroke-linecap-round osmarender-no-marker-start", $style); } } @@ -719,17 +758,18 @@ } # --- -# sub draw_path($rulenode, $path_id, $class) +# sub draw_path($rulenode, $path_id, $class, $style) # # draws an SVG path with the given path reference and style. # --- sub draw_path { -my ($rulenode, $path_id, $addclass) = @_; +my ($rulenode, $path_id, $addclass, $style) = @_; my $mask_clas
Re: [Talk-de] [patch] Breite von Flüssen :)
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 siehe unten). Ich werde das jedenfalls nicht zusätzlich zum width Tag (der BTW im Gegensatz zu est_width im Wiki dokumentiert ist) einbauen. Wenn ich den Verlauf einer Straße nicht kenne dann trage ich die ja auch ganz normal ein und füge im Zweifelsfall einfach noch ein source=interpolation hinzu. Wenn nun jemand der Verlauf genauer verifiziert hat nimmt er den Zusatztag einfach raus und gut iss. Wenn Du z.B. einen Fluß mit width=5m taggst und nun stellt ein anderer mit einem Laser Entfernungsmesser fest, dass das aber nur 4.754 Meter sind dann ändert er halt den width Tag und gut ist. Gruss Sven -- All bugs added by David S. Miller <[EMAIL PROTECTED]> Linux Kernel boot message from /usr/src/linux/net/8021q/vlan.c /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?[patch] Breite von Flüssen : )
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 > Meter ändert. Wenn sich die Breite ändert trennt man den Weg auf und setzt eine andere Breite, so wie man das bei Straßen mit wechselnden attributen ebenfalls macht. Wenn Die Breite nur geschätzt ist kannst Du nen zusätzlichen Tag dranhängen, der diese Aussage enthält. > Ich habe bisher meistens die Breite des Flusses auf einer Brücke > abgeschritten und dann als geschätzte Breite eingetragen. Was spricht nun dagegen das tagging entsprechend meines Vorschlages umzuändern? Der Renderer kennt hier nur schwarz und weiß ich halte es ehrlich gesagt nicht für sinnvoll zusätzlich zu width auch noch est_width zu berücksichtigen. Sven -- The main thing to note is that when you choose open source you don't get a Windows operating system. (from http://www.dell.com/ubuntu) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen :)
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 Perl Hacker sondern meine > Scriptsprachen sind eher Python und Tcl, aber trotzdem liegt > mir die prozedurale Welt wohl doch besser als xslt. > > 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. Wir muessen zwei Breitenangaben beruecksichtigen 'width' und 'est_width' und ich empfehle die Verwendung von 'est_width' bei geschaetzter Breite. Ich hab dein Patch etwas modifiziert (Anhang 'orp-river-width.diff'). > Ich möchte das ganze jedoch erst ins svn einchecken wenn es jemand > ausprobiert und für funktioniell befunden hat. > Fuer's Erste sollte es tun (ich werde mal noch 'ne Landschaft rendern in der ich mehr Breitenangaben habe). Grusz Christian Index: orp-drawing.pm === --- orp-drawing.pm (revision 8751) +++ orp-drawing.pm (working copy) @@ -78,15 +78,54 @@ { my ($linenode, $layer, $way, $class) = @_; +# explicit way specific style +my $style=""; + # convenience variables my $id = $way->{"id"}; my $nodes = $way->{"nodes"}; return unless(scalar(@$nodes)); +# this is a special case for ways (rivers) where we honor a +# with=something tag. +# It is used to generate rivers of different width. +# This is done by an explicit specification of a +# style="stroke-width:..px" tag in the generated SVG output + +my($way_width) = grep { defined } + map $way->{'tags'}->{$_} => qw( width est_width ); + +if( defined($way_width) and $way_width =~ /^ \d+\.?\d* m? $/x) +{ # width an integer number w/ optional unit (meters) + +$way_width =~ s/m$//; + +# get all classes where width should be honored +my @honorWidth = split ' ' => get_variable("honorWidth","waterway-river-core waterway-river-casing"); + +# check if the list of honored classes contains the current class +my %currentClass = map { $_ => 1 } split(/ /,$class); + +if(grep $currentClass{$_} => @honorWidth) +{ +my $meter2PixelFactor = get_variable("meter2px","0.1375"); + +$way_width *= $meter2PixelFactor; + +my $minLineWidth = get_variable("minLineWidth", "1"); +my $maxLineWidth = get_variable("maxLineWidth", "100"); + +$way_width = $minLineWidth if $way_width < $minLineWidth; +$way_width = $maxLineWidth if $way_width > $maxLineWidth; + +$style = "stroke-width:${way_width}px"; +} +} + # first draw middle segment if we have more than 2 nodes draw_path($linenode, "way_mid_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-start osmarender-no-marker-end") +"osmarender-stroke-linecap-butt osmarender-no-marker-start osmarender-no-marker-end", $style) if (scalar(@$nodes)>2); # count connectors on first and last node @@ -116,32 +155,32 @@ if ($first_node_connection_count == 1) { -draw_path($linenode, "way_start_$id", "osmarender-no-marker-end"); +draw_path($linenode, "way_start_$id", "osmarender-no-marker-end", $style); } elsif ($first_node_lower_layer_connection_count > 0) { draw_path($linenode, "way_start_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-end"); +"osmarender-stroke-linecap-butt osmarender-no-marker-end", $style); } else { draw_path($linenode, "way_start_$id", -"osmarender-stroke-linecap-round osmarender-no-marker-end"); +"osmarender-stroke-linecap-round osmarender-no-marker-end", $style); } if ($last_node_connection_count == 1) { -draw_path($linenode, "way_end_$id", "osmarender-no-marker-start"); +draw_path($linenode, "way_end_$id", "osmarender-no-marker-start", $style); } elsif ($last_node_lower_layer_connection_count > 0) { draw_path($linenode, "way_end_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-start"); +"osmarender-stroke-linecap-butt osmarender-no-marker-start", $style); } else { draw_path($linenode, "way_end_$id", -"osmarender-stroke-linecap-round osmarender-no-marker-start"); +"osmarender-stroke-linecap-round osmarender-no-marker-start", $style); } } @@ -719,17 +758,18 @@ } # --- -# sub draw_path($rulenode, $path_id, $class) +# sub draw_path($rulenode, $path_id, $class
Re: [Talk-de] ?[patch] Breite von Flüssen : )
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. Das einzige was bei jedem Weg nun dazugekommen ist ist die Prüfung auf die Existenz eines width Tags. Nur wenn dieses vorhanden ist läuft der Renderer überhaupt in meinen Code rein. Eventuell mal mit time ./orp-neu.pl -r osm-map-features-z17.xml foobar.osm vs. time ./orp-alt.pl -r osm-map-features-z17.xml foobar.osm verifizieren. Gruss Sven -- "We don't know the OS that God uses, but the Vatican uses Linux" (Sister Judith Zoebelein, Vatican Webmaster) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen :)
Am 05.07.2008 um 19:56 schrieb Sven Geggus: > > > 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. 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 Meter ändert. Ich habe bisher meistens die Breite des Flusses auf einer Brücke abgeschritten und dann als geschätzte Breite eingetragen. Gruß, Daniel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen :)
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 tiptop, nur hab ich das Gefühl, dass rendern dauert länger. Gratulation, saubere arbeit. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] [patch] Breite von Flüssen :)
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 mir die prozedurale Welt wohl doch besser als xslt. 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. Weiterhin kann man folgende Tags im Header der jeweiligen osm-map-features-z17.xml angeben: minLineWidth="1" maxLineWidth="100" honorWidth="waterway-river-core waterway-river-casing" meter2px="0.1375" Diese Werte sind die defaults, die auch verwendet werden, falls in der Styledatei nichts angegeben wurde. minLineWidth und maxLineWidth sind die min/max Werte für die Breite in Meter. meter2px ist der Skalierungsfaktor über den die angegebenen Werte von Metern in px umgerechnet werden. honorWidth sind die Klassen aus der Map-Features Datei, bei denen ein width Tag angewandt wird. Ich möchte das ganze jedoch erst ins svn einchecken wenn es jemand ausprobiert und für funktioniell befunden hat. Meine Flüsse hier in der Gegend muss ich auch erst noch messen gehn :) Den patch findet ihr unten oder unter http://home.geggus.net/osm/orp-river-width.diff Gruss Sven P.S.: Falls das jemand in die xslt Variante von osmarender einbauen möchte, nur zu! --schnipp-- --- orp-drawing.pm (Revision 8751) +++ orp-drawing.pm (Arbeitskopie) @@ -78,15 +78,57 @@ { my ($linenode, $layer, $way, $class) = @_; +# explicit way specific style +my $style=""; + # convenience variables my $id = $way->{"id"}; my $nodes = $way->{"nodes"}; return unless(scalar(@$nodes)); +# this is a special hack for rivers we honor a with=something tag in +# this case to generate rivers of different width. +# This is done by an explizit specification of a +# style="stroke-width:..px" tag in the generated SVG output + +if (defined($way->{"tags"}->{"width"})) { + + # get all classes where width should be honored + my @honorWidth=split(/ /, get_variable("honorWidth","waterway-river-core waterway-river-casing")); + + # check if the list of honored classes contains the current class + my %cClass=map{ $_ => 1 } split(/ /,$class); + + my $cname=""; + foreach my $c (@honorWidth){ + if($cClass{$c}) { + $cname=$c; + last; + } + } + if ($cname ne "") { + my $width = $way->{"tags"}->{"width"}; + $width =~ s/m$//; + my $f = get_variable("meter2px","0.1375"); + my $w; + # make shure, that width is a numeric value + { no warnings; $w = $f*$width if 0+$width;} + + if (defined($w)) { + # make shure that width is inside the desired range + my $maxw = $f*get_variable("maxLineWidth","100"); + my $minw = $f*get_variable("minLineWidth","1"); + if ($w > $maxw) {$w = $maxw;} + if ($w < $minw) {$w = $minw;} + $style = "stroke-width:${w}px"; + } + } +} + # first draw middle segment if we have more than 2 nodes draw_path($linenode, "way_mid_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-start osmarender-no-marker-end") +"osmarender-stroke-linecap-butt osmarender-no-marker-start osmarender-no-marker-end", $style) if (scalar(@$nodes)>2); # count connectors on first and last node @@ -116,32 +158,32 @@ if ($first_node_connection_count == 1) { -draw_path($linenode, "way_start_$id", "osmarender-no-marker-end"); +draw_path($linenode, "way_start_$id", "osmarender-no-marker-end", $style); } elsif ($first_node_lower_layer_connection_count > 0) { draw_path($linenode, "way_start_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-end"); +"osmarender-stroke-linecap-butt osmarender-no-marker-end", $style); } else { draw_path($linenode, "way_start_$id", -"osmarender-stroke-linecap-round osmarender-no-marker-end"); +"osmarender-stroke-linecap-round osmarender-no-marker-end", $style); } if ($last_node_connection_count == 1) { -draw_path($linenode, "way_end_$id", "osmarender-no-marker-start"); +draw_path($linenode, "way_end_$id", "osmarender-no-marker-start", $style); } elsif ($last_node_lower_layer_connection_count > 0) { draw_path($linenode, "way_end_$id", -"osmarender-stroke-linecap-butt osmarender-no-marker-start"); +"osmarender-stroke-linecap-butt osmarender-no-marker-start", $style); } else { draw_path($linenode, "way_end_$id", -"osmarender-stroke-linecap-round osmarender-no-marker-start"); +