Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 17. Februar 2011 10:11 schrieb Stephan Wolff :
> Am 16.02.2011 15:13, schrieb Stefan Keller:
>> * Ein Kompromiss wäre, Einheiten in eckigen Klammern (o.ä.) zu setzen
>> (bzw. vom Editor das so setzen zu lassen). Beispielsweise
>> "generator:output:electricity=0.1 [MW]".
>
> Das wäre nicht nur inkompatibel zu existierenden Anwendungen, sondern
> für viele Nutzer unauswertbar.
> Wie wertet man diese Daten in einem Mapnik-Style aus?
müsste man wohl vorverarbeiten bzw. in der Datenbank rauswerfen
> Wie schreibt man eine Maperative-Regel?
ja, das ist ja ein Programm, dass es auch ohne "große" Vorkenntnisse
ermöglichen soll, mal kurz ne Karte zu rechnen, d.h. da müsste der
Entwickler sich vermutlich dem Problem annehmen.
> Wie schreibt man eine Osmanrender-Regel?
> Wie schreibt man eine Filter- oder Suchregel in JOSM? ('width=3 OR width="3
> [m]" OR width="300 [cm]" OR width="3000 [mm]"'wäre mir zu
> unhandlich)
ja, auch z.B. für mappaint styles. Habe vor kurzem einen Style
gemacht, der die entsprechenden Schilder von Geschwindigkeitslimits
anzeigen soll, wenn man da dann anfangen muss, rumzurechnen oder zu
parsen wird es so kompliziert, dass man es u.U. von vornherein sein
lässt. Vermutlich müsste man da auch was dazu entwickeln, vielleicht
kann JOSM das aber auch schon längst, und ich weiss nur nicht wie...
> Eine Alternative wäre es, Wert und Anzeigeeinheit zu trennen.
> Der Wert würde immer in der Basiseinheit des Tags gespeichert!
> Beispiel: Breite 700cm
> width=7
> width:displayunit=cm
-1, m.E. keine sinnvolle Alternative und man riskiert
Fehlinterpretationen. Wenn man nicht rund umrechnen kann, besteht das
Problem weiterhin.
> Die Lösung wäre kompatibel zu den meisten bestehenden Anwendungen.
nee, weil wenn 7 jetzt entweder 7 Kilometer oder 7 Meter oder 7
Meilen, oder 7 fathom bedeuten kann, dann hilft es einem auch nichts,
die Einheit zu ignorieren.
> Alle Anwendungen, die nur den Wert benötigen, können auf Umrechnungen
> verzichten.
Das wären sehr wenige Anwendungen m.E.
Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 16.02.2011 15:13, schrieb Stefan Keller:
Ich habe mich grad letzthin ziemlich abmühen müssen, so etwas
Einfaches wie "elevation" von peaks oder viewpoints zu parsen. Das "m"
nach der Höhenangabe ginge ja noch...
siehe Lösungsvorschlag unten.
* Dem Mapper überlassen, ob er eine Einheit hintendran hängt und dass
diese halt so ist, wie er es nach bestem Wissen meint.
Leider kombiniert man damit die Nachteile beider Varianten.
* Grundsätzlich die ISO-Basiseinheiten verwenden
(http://de.wikipedia.org/wiki/Internationales_Einheitensystem#SI-Basiseinheiten
) und Abweichungen davon selbstverständlich dokumentieren (:->).
Besser die üblichen Einheiten (km/h).
* Ein Kompromiss wäre, Einheiten in eckigen Klammern (o.ä.) zu setzen
(bzw. vom Editor das so setzen zu lassen). Beispielsweise
"generator:output:electricity=0.1 [MW]".
Das wäre nicht nur inkompatibel zu existierenden Anwendungen, sondern
für viele Nutzer unauswertbar.
Wie wertet man diese Daten in einem Mapnik-Style aus?
Wie schreibt man eine Maperative-Regel?
Wie schreibt man eine Osmanrender-Regel?
Wie schreibt man eine Filter- oder Suchregel in JOSM? ('width=3 OR
width="3 [m]" OR width="300 [cm]" OR width="3000 [mm]"'wäre mir zu
unhandlich)
Damit wäre die Nutzung der OSM-Daten auf diejenigen beschränkt,
die die Zeit, die Programmier- und Datenbankkenntnisse und die
Rechnerkapazität haben, die Rohdaten korrekt zu parsen und in
einer eigenen Datenbank zu speichern.
Eine Alternative wäre es, Wert und Anzeigeeinheit zu trennen.
Der Wert würde immer in der Basiseinheit des Tags gespeichert!
Beispiel: Breite 700cm
width=7
width:displayunit=cm
Die Lösung wäre kompatibel zu den meisten bestehenden Anwendungen.
Alle Anwendungen, die nur den Wert benötigen, können auf Umrechnungen
verzichten. Auch User, die nur Rendererregeln erstellen oder nur
einfache SQL-Abfragen machen wollen, können die Daten nutzen.
Die wenigen Programme, die das vom Mapper bevorzugte Format anzeigen
sollen, können den Wert relativ einfach umrechnen. Wenn eine Einheit
dem auswertenden Programm nicht bekannt ist, ist eine Darstellung in
der Basiseinheit trotzdem möglich. Die Rückrechnung ist viel einfacher
als die Auswertung zusammengesetzter Texte.
Viele Grüße, Stephan
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo. Am Mittwoch 16 Februar 2011, 18:52:55 schrieb Stefan Keller: > Die eckigen Klammern sind ein Kompromissvorschlag zwischen menschen- > und maschinenlesbarkeit bei der Speicherung/Codierung der Werte, bzw. > zwischen Mappern und Datenbank-Nutzern. Die in der Praxis gebräuchlichen Werte für ein bestimmtes Datenfeld sind in der Regel sehr überschaubar. Das kann jeder mit minimalem Aufwand erkennen, da braucht's keine eckigen Klammern dazu, die (über was du dich geflissentlich hinweg setzt) schlicht eine andere, reale Bedeutung haben, also explizit Verwirrung stiften bei all denen die diese andere Bedeutung kennen und versuchen die Zahlen zu lesen. Gruß, Bernd -- Wenn man bedenkt, dass die Leute vor 150 Jahren ihre E-Mails noch bei Kerzenlicht geschrieben haben... - Marianne Kestler, de.admin.net-abuse.mail, 6.5.2000 signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Die eckigen Klammern sind ein Kompromissvorschlag zwischen menschen- und maschinenlesbarkeit bei der Speicherung/Codierung der Werte, bzw. zwischen Mappern und Datenbank-Nutzern. Sie gehören eigentlich nicht zur Einheit; sie trennen den Wert von der Einheit (bzw. klammern sie ein), die eigentlich separat codiert werden sollte. Die Wahl der Einheit nach SI habe ich auch empfohlen aber letztlich offen gelassen. LG, S. Am 16. Februar 2011 16:49 schrieb Schorschi : > Moin, > > On Wed, 16 Feb 2011, Stefan Keller wrote: > >> * Ein Kompromiss wäre, Einheiten in eckigen Klammern (o.ä.) zu setzen >> (bzw. vom Editor das so setzen zu lassen). Beispielsweise >> "generator:output:electricity=0.1 [MW]". > > bitte auf keinen Fall in eckige Klammern - das ist nach SI und weiteren > gängigen Normen falsch. Die eckigen Klammern in Zusammenhang mit Einheiten > sind lesbar wie: "Die Einheit von ... ist ...". Also so: > > [U] = V > > Die Einheit der Spannung ist das Volt. So sind die eckigen Klammern > richtig eingesetzt. Das stand auch so in der entsprechenden DIN 1301. > Leider haben das sogar Hochschulprofessoren falsch verstanden (das kann > ich aus eigener Erfahrung bestätigen). Das Setzen der eckigen Klammern um > Einheitenzeichen ist eine Unsitte, die bitte nicht auch noch bei OSM > eingeführt werden soll. > > Grüße, Schusch > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 16. Februar 2011 15:13 schrieb Stefan Keller : > * Grundsätzlich die ISO-Basiseinheiten verwenden > (http://de.wikipedia.org/wiki/Internationales_Einheitensystem#SI-Basiseinheiten > ) und Abweichungen davon selbstverständlich dokumentieren (:->). bitte nicht. Ich plädiere dafür, übliche Einheiten beizubehalten, z.B. km/h für maxspeed und nicht m/s. So was führt nur zu Quatsch und unnötigem Runden (50 km/h wären z.B. 13,889 Meter / Sekunde...) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Moin, On Wed, 16 Feb 2011, Stefan Keller wrote: > * Ein Kompromiss wäre, Einheiten in eckigen Klammern (o.ä.) zu setzen > (bzw. vom Editor das so setzen zu lassen). Beispielsweise > "generator:output:electricity=0.1 [MW]". bitte auf keinen Fall in eckige Klammern - das ist nach SI und weiteren gängigen Normen falsch. Die eckigen Klammern in Zusammenhang mit Einheiten sind lesbar wie: "Die Einheit von ... ist ...". Also so: [U] = V Die Einheit der Spannung ist das Volt. So sind die eckigen Klammern richtig eingesetzt. Das stand auch so in der entsprechenden DIN 1301. Leider haben das sogar Hochschulprofessoren falsch verstanden (das kann ich aus eigener Erfahrung bestätigen). Das Setzen der eckigen Klammern um Einheitenzeichen ist eine Unsitte, die bitte nicht auch noch bei OSM eingeführt werden soll. Grüße, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Ich habe mich grad letzthin ziemlich abmühen müssen, so etwas Einfaches wie "elevation" von peaks oder viewpoints zu parsen. Das "m" nach der Höhenangabe ginge ja noch... Mit der Eingangsfrage "Werte mit/ohne Einheit" haben sich andere ja auch schon befasst, z.B. XML wo das einfach wäre aber hier nicht so Sinn macht. Meine Erkenntnisse aus diesen Erfahrungen sind: * Dem Mapper überlassen, ob er eine Einheit hintendran hängt und dass diese halt so ist, wie er es nach bestem Wissen meint. * Die Mapper aber immer wieder freundlich ermuntern, "nach bestem Wissen und Gewissen" zu handeln, bzw. editieren. * Grundsätzlich die ISO-Basiseinheiten verwenden (http://de.wikipedia.org/wiki/Internationales_Einheitensystem#SI-Basiseinheiten ) und Abweichungen davon selbstverständlich dokumentieren (:->). * Die - zugegebenermassen nicht-hinreichende - Voraussetzung zur Ermunterung und zur Dokumentation ist eine gute OSM-Wiki-Seite (:->). * Die an sich schon guten OSM-Editoren könnten einem (in Zukunft) bei der Auswahl der Masseinheiten helfen. * Ein Kompromiss wäre, Einheiten in eckigen Klammern (o.ä.) zu setzen (bzw. vom Editor das so setzen zu lassen). Beispielsweise "generator:output:electricity=0.1 [MW]". Letztere Notation wäre menschen- *und* maschinen-lesbar und löste auch das (noch schlumernde) Problem, dass in Zahlen ja auch Zeichen und Buchstaben vorkommen könnten (z.B. Exponential- oder Potenzangaben), was das "Entziffern" der Codierung endgültig zum Rätselraten verkommen lässt. LG, S. P.S. Als Programmiersprache zur OSM-Datenverarbeitung würde ich in diesem Fall Python anschauen und einen passenden Editor (Entwicklungsumgebung) dazu auslesen: vgl. http://www.gis.hsr.ch/wiki/Python Am 15. Februar 2011 03:20 schrieb Stephan Wolff : > Moin! > > Am 14.02.2011 19:42, schrieb Frederik Ramm: >> >> Stephan Wolff wrote: >>> >>> Wir muten den Mappern an anderer Stelle zuviel zu. Wenn ein Mapper >>> einen Weg teilt, der zufällig zu einer Relation gehört, dann muss >>> er den Aufbau dieser Relation erlernen, um sie ggf. zu reparieren. >>> Würden wir festlegen, dass man die Elemente jeder Relation teilen >>> darf (dann hätte eine Abbiegerelation evtl. mehrere "from" und "to" >>> Elemente), wäre das eine echte Erleichterung für die Mapper. >> >> Das hatten wir neulich schonmal - nur, weil anderswo etwas laestig ist, >> ist das keine Lizenz, neue laestige Sachen einzufuehren. > > Die Umrechnung zwischen metrischen Einheiten ist nicht lästig. Der > Mapper spart die dafür verwendete Sekunde wieder ein, da er keine > Einheit tippen muss. Die Einarbeitung in unbekannte Relationen > kostet dagegen viel Zeit. > >>> Wenn der Editor für das Feld "Breite in m" nur Zahlen erlaubt, >>> macht der Mapper keine Fehler und alle Programme werten die >>> Angabe richtig aus. Wenn er "width=700cm" bei einem Fluss einträgt >>> und Osmarender einen 700m breiten See malt, ein anderes Tool >>> die Textausgabe "Flussbreite : 700cm m" macht oder der Editor beim >>> Zusammenfügen die Angabe "width=700cm; 7" erzeugt, ist der Mapper >>> verwirrt. >> >> Es gibt bei OSM keine strenge Typisierung von Tags, und ich denke nicht, >> dass es die jemals geben wird. Du musst Dich von dem Gedanken >> verabschieden, dass das, was da in England auf dem Server ist, irgendwie >> eine saubere, leicht auswertbare Datenbank ist oder jemals sein kann. >> Kein Ausmass an Editorvorschriften und Bots wird dazu fuehren - diese >> Datenbank wird immer das "Rohmaterial" sein, aus dem man brauchbare >> Daten ableiten muss. > > Die OSM-Datenbank wird immer Daten in seltsamen Formaten enthalten. In > den meisten Fällen werden diese Daten keinen Nutzen haben und keinen > Schaden machen. In wenigen Fällen wird es Fehlinterpretationen geben > und ein Freiwilliger muss die problematischen Daten ändern. > Falls Osmarender einen Fluss mit "width=700cm" als 700m breiten See > malt (ich habe das nicht getestet), würde ich die Angabe in "width=7" > ändern. Dadurch habe ich Arbeit, das Kartenbild ist zeitweise defekt > und der ursprüngliche Mapper verliert seine Einheit. > >>> Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. >>> Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, >>> Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: >>> "8 fathom in m" -> "14.63 meters"), als alle Mapper und alle >>> Anwender mit diesen Einheiten zu belasten. >> >> Das ist etwas, was ganz gewiss nicht passieren wird. Erstens, weil wir >> keine Seetiefen mappen ;) > > Der Wittensee (http://osm.org/go/0Hm7TLEs-) und einige hundert Punkte > mit waterway=depth beweisen das Gegenteil :-) > >> zweitens wegen (Wolfram Alpha) "14.63 meters in fathoms" => "7.9998 >> fathoms" - > > Der Mapper meinte wahrscheinlich (8+-1)fathom, so dass alle Angaben > zwischen 14 und 15 Meter gleichbedeutend sind. Anderenfalls dürften wir > auch einen Kreis nicht durch ein Polygon mit endlich vielen Punkten > beschreiben. > >> der englische Mapper hat voellig zu >> recht den Anspruc
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Moin! Am 14.02.2011 19:42, schrieb Frederik Ramm: Stephan Wolff wrote: Wir muten den Mappern an anderer Stelle zuviel zu. Wenn ein Mapper einen Weg teilt, der zufällig zu einer Relation gehört, dann muss er den Aufbau dieser Relation erlernen, um sie ggf. zu reparieren. Würden wir festlegen, dass man die Elemente jeder Relation teilen darf (dann hätte eine Abbiegerelation evtl. mehrere "from" und "to" Elemente), wäre das eine echte Erleichterung für die Mapper. Das hatten wir neulich schonmal - nur, weil anderswo etwas laestig ist, ist das keine Lizenz, neue laestige Sachen einzufuehren. Die Umrechnung zwischen metrischen Einheiten ist nicht lästig. Der Mapper spart die dafür verwendete Sekunde wieder ein, da er keine Einheit tippen muss. Die Einarbeitung in unbekannte Relationen kostet dagegen viel Zeit. Wenn der Editor für das Feld "Breite in m" nur Zahlen erlaubt, macht der Mapper keine Fehler und alle Programme werten die Angabe richtig aus. Wenn er "width=700cm" bei einem Fluss einträgt und Osmarender einen 700m breiten See malt, ein anderes Tool die Textausgabe "Flussbreite : 700cm m" macht oder der Editor beim Zusammenfügen die Angabe "width=700cm; 7" erzeugt, ist der Mapper verwirrt. Es gibt bei OSM keine strenge Typisierung von Tags, und ich denke nicht, dass es die jemals geben wird. Du musst Dich von dem Gedanken verabschieden, dass das, was da in England auf dem Server ist, irgendwie eine saubere, leicht auswertbare Datenbank ist oder jemals sein kann. Kein Ausmass an Editorvorschriften und Bots wird dazu fuehren - diese Datenbank wird immer das "Rohmaterial" sein, aus dem man brauchbare Daten ableiten muss. Die OSM-Datenbank wird immer Daten in seltsamen Formaten enthalten. In den meisten Fällen werden diese Daten keinen Nutzen haben und keinen Schaden machen. In wenigen Fällen wird es Fehlinterpretationen geben und ein Freiwilliger muss die problematischen Daten ändern. Falls Osmarender einen Fluss mit "width=700cm" als 700m breiten See malt (ich habe das nicht getestet), würde ich die Angabe in "width=7" ändern. Dadurch habe ich Arbeit, das Kartenbild ist zeitweise defekt und der ursprüngliche Mapper verliert seine Einheit. Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: "8 fathom in m" -> "14.63 meters"), als alle Mapper und alle Anwender mit diesen Einheiten zu belasten. Das ist etwas, was ganz gewiss nicht passieren wird. Erstens, weil wir keine Seetiefen mappen ;) Der Wittensee (http://osm.org/go/0Hm7TLEs-) und einige hundert Punkte mit waterway=depth beweisen das Gegenteil :-) zweitens wegen (Wolfram Alpha) "14.63 meters in fathoms" => "7.9998 fathoms" - Der Mapper meinte wahrscheinlich (8+-1)fathom, so dass alle Angaben zwischen 14 und 15 Meter gleichbedeutend sind. Anderenfalls dürften wir auch einen Kreis nicht durch ein Polygon mit endlich vielen Punkten beschreiben. der englische Mapper hat voellig zu recht den Anspruch, dass aus seinen vom Verkehrsschild abgelesenen 20 mph nicht ploetzlich 19.9997 werden, weil irgendjemand das partout intern in Meter pro Sekunde speichern wollte oder so. Für gesetzliche Einschränkungen, insbesondere Verkehrsschilder sollte man sicherlich die offizielle Angabe nutzen. Bei geschätzten/gemessenen Größen hat ein einheitlich metrisches System viele Vorteile. Die Googlesuche nach "osm ist metrisch" lieferte mir gerade das Zitat: "... Und Wassertiefen immer in Faden angeben, ist ja klar, oder :-) Bye Frederik (PS: War Spass - OSM ist metrisch.)" Jeder der drei Anwender würde von einer Zahlenangabe in MW profitieren. Für den ersten vereinfacht sich das Umrechnungstool, der andere kann die Zahl ohne Vorverarbeitung nutzen. Der Mapper spart drei Zeichen und kann sich an der sinnvollen Nutzung seiner Daten erfreuen. Die mitgelieferte Einheit gibt eine groessere Sicherheit bei der Interpretation; die Freiheit des Mappers, die Zahl so eintragen zu koennen, wie er sei in der freien Wildbahn antrifft, ist m.E. hoeher zu bewerten als der Komfort des Programmierers. Eine Datenbank hat nur einen Nutzen, wenn die Daten sinnvoll auswertbar sind. Wenn ein Mapper "highway=Autobahn" eingibt (wie es im Gesetz und auf Schildern steht), ist das komfortabel, aber der Weg wird vom Renderer nicht dargestellt und von Router nicht ausgewertet. Die Umsetzung in "highway=motorway" ist beim ersten Mal lästig, aber der Weg wird dann gezeichnet und für das Routing benutzt. Jemand, der Regeln für Osmarender, Mapnik, Kosmos oder Maperative erstellt, kann Längen- und Breitenangaben mit beliebigen Einheiten in der Regel nicht korrekt auswerten. Jemand, der alle Straßen schmaler als x Meter aus einer bestehenden OSM-Datenbank ziehen will, wird scheitern oder sehr viel Zeit brauchen. Für den Komfort des Mappers, einen Wert im von ihm bevorzugten Textformat zu kodieren, möchtest du die Freiheit der Datennutzung
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14. Februar 2011 19:30 schrieb Stephan Wolff : > Ursprünglich ging es um die Angabe von elektrischer Leistung > bei BHKW. Eine Angabe von zwei Megawatt darf gemäß Vorschlag > im Wiki beliebig als "200 W", "2000 kW", "2 MW" oder > "0.002 GW" geschrieben werden. Dies hatte ich kritisiert. es geht ja dabei nicht nur um elektrische Leistung sondern auch um Wärme. In der Diskussion hier haben einige Leute sich dafür ausgesprochen, dass man noch weitergehend Einheiten verwenden können soll. Hier wäre es z.B. ja durchaus auch möglich, PS oder Kilokalorien pro Stunde anzugeben. Oder Pondmeter pro Sekunde. Im Prinzip fände ich das auch gar nicht schlecht, die "wünsch-dir-was-Version" wäre allerdings, man hätte ein von der Community entwickeltes Tool, mit dem man die Daten dann wieder normalisieren kann, so dass auch allen möglichen Einheiten, z.B. gerade auch die "nichtmetrischen", in einer (einfach) verwendbaren Form rauskommen. So eine Art "universeller Einheiten-Normalisierer", idealerweise gleich als Ergänzung eines bestehenden Tools und mit separaten Einheitendefinitionen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo, Stephan Wolff wrote: Wir muten den Mappern an anderer Stelle zuviel zu. Wenn ein Mapper einen Weg teilt, der zufällig zu einer Relation gehört, dann muss er den Aufbau dieser Relation erlernen, um sie ggf. zu reparieren. Würden wir festlegen, dass man die Elemente jeder Relation teilen darf (dann hätte eine Abbiegerelation evtl. mehrere "from" und "to" Elemente), wäre das eine echte Erleichterung für die Mapper. Das hatten wir neulich schonmal - nur, weil anderswo etwas laestig ist, ist das keine Lizenz, neue laestige Sachen einzufuehren. Wenn der Editor für das Feld "Breite in m" nur Zahlen erlaubt, macht der Mapper keine Fehler und alle Programme werten die Angabe richtig aus. Wenn er "width=700cm" bei einem Fluss einträgt und Osmarender einen 700m breiten See malt, ein anderes Tool die Textausgabe "Flussbreite : 700cm m" macht oder der Editor beim Zusammenfügen die Angabe "width=700cm; 7" erzeugt, ist der Mapper verwirrt. Es gibt bei OSM keine strenge Typisierung von Tags, und ich denke nicht, dass es die jemals geben wird. Du musst Dich von dem Gedanken verabschieden, dass das, was da in England auf dem Server ist, irgendwie eine saubere, leicht auswertbare Datenbank ist oder jemals sein kann. Kein Ausmass an Editorvorschriften und Bots wird dazu fuehren - diese Datenbank wird immer das "Rohmaterial" sein, aus dem man brauchbare Daten ableiten muss. Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten. Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte Einheit ohnehin nicht durchsetzten, Ja, genau darum geht es, dass jeder seine bevorzugte Einheit verwenden kann, ohne sie "durchsetzen" zu muessen. Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: "8 fathom in m" -> "14.63 meters"), als alle Mapper und alle Anwender mit diesen Einheiten zu belasten. Das ist etwas, was ganz gewiss nicht passieren wird. Erstens, weil wir keine Seetiefen mappen ;) zweitens wegen (Wolfram Alpha) "14.63 meters in fathoms" => "7.9998 fathoms" - der englische Mapper hat voellig zu recht den Anspruch, dass aus seinen vom Verkehrsschild abgelesenen 20 mph nicht ploetzlich 19.9997 werden, weil irgendjemand das partout intern in Meter pro Sekunde speichern wollte oder so. Bei Osmarender muss eine angepasste Version an alle Teilnehmer verteilt werden, bis eine neue Schreibweise zur korrekten Kartendarstellung führt. 1. tiles@home ist eh tot, 2. die meisten Tile-Renderer machen eh regelmaessig automatisch ein "svn up". Wenn Dein Argument stichhaltig waere, koennte es ja in tiles@home nie irgendwelche Stil-Updates geben. Ein Validator kann einfacher auf "Zahl" als auf "Zahl mit zulässiger Einheit" testen. Falsche Zahlen kann ein Validator nie erkennen. Eine Einheit mitzuführen bringt keinen Vorteil. Da bin ich aber entschieden anderer Ansicht. Zu den Möglichkeiten des Validators oder zu anderen Vorteilen wählbarer Einheiten? Dazu, dass die mitgefuehrte Einheit keinen Vorteil bringt. Jeder der drei Anwender würde von einer Zahlenangabe in MW profitieren. Für den ersten vereinfacht sich das Umrechnungstool, der andere kann die Zahl ohne Vorverarbeitung nutzen. Der Mapper spart drei Zeichen und kann sich an der sinnvollen Nutzung seiner Daten erfreuen. Die mitgelieferte Einheit gibt eine groessere Sicherheit bei der Interpretation; die Freiheit des Mappers, die Zahl so eintragen zu koennen, wie er sei in der freien Wildbahn antrifft, ist m.E. hoeher zu bewerten als der Komfort des Programmierers. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Moin! Am 14.02.2011 15:24, schrieb Tobias Knerr: Am 14.02.2011 14:45, schrieb Stephan Wolff: Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten. Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte Einheit ohnehin nicht durchsetzten, sondern müsste zwischen allen verwendeten Angaben umrechnen. Ein Standard erleichtert die Zusammenarbeit. Jetzt müssen wir aber mal klarstellen, worüber wir reden: Werte, die abgelesen werden (z.B. von einem Schild) oder vom Mapper selbst gemessene Werte? Ursprünglich ging es um die Angabe von elektrischer Leistung bei BHKW. Eine Angabe von zwei Megawatt darf gemäß Vorschlag im Wiki beliebig als "200 W", "2000 kW", "2 MW" oder "0.002 GW" geschrieben werden. Dies hatte ich kritisiert. Die Diskussion weitete sich auf andere geschätzte, berechnete oder gemessene Größen aus. Bei Schildern oder amtlich festgelegten Grenzen würde ich auch die offizielle Einheit verwenden. Damit hat man innerhalb eines Staates meist einheitliche Werte und auch weltweit nur wenige Sonderfälle. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.2011 14:45, schrieb Stephan Wolff: > Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten. > Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte > Einheit ohnehin nicht durchsetzten, sondern müsste zwischen allen > verwendeten Angaben umrechnen. Ein Standard erleichtert die > Zusammenarbeit. Jetzt müssen wir aber mal klarstellen, worüber wir reden: Werte, die abgelesen werden (z.B. von einem Schild) oder vom Mapper selbst gemessene Werte? Bei ersteren verwende ich einen ganz einfachen Standard: Das Schild gibt die Einheit vor, eine Umrechnung durch den Mapper findet nicht statt. Das betrifft Schlüssel wie maxspeed, maxheight, maxwidth, maxweight und so weiter. Das ist schon dann sinnvoll, wenn der nächste Mapper, der mit seinem Mobileditor vorbeispaziert, den Wert aus den Daten direkt mit dem auf dem Schild vergleichen und so nachprüfen kann. Da solche Schilder üblicherweise gewissen Reglements unterliegen, wird man auf diese Weise auch nur mit einem beschränkten Satz "vernünftiger" Einheiten konfrontiert, die keinen Auswerter überfordern sollten. Selbst gemessene Werte sind natürlich etwas anders gelagert, denn dort gibt es "on the ground" keinen Anhaltspunkt für die Wahl der Einheit. Missverständnisse vermeiden kann eine explizit angegebene Einheit dort aber sehr wohl. >> (Noch schlimmer bei Einheiten, bei denen nicht einfach >> der Dezimalpunkt verschoben wird.) > > Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. > Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, > Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: > "8 fathom in m" -> "14.63 meters"), als alle Mapper und alle > Anwender mit diesen Einheiten zu belasten. Da werden eher die Vorteile von "Einheiten wie ausgeschildert" noch deutlicher, denn eine standardisierte Einheit würde nicht nur denjenigen, der sie einträgt, zum Umrechnen zwingen, sondern auch jeden, der sie später nachprüfen will. Bei Verwendung einer ausgeschilderten Einheit muss nur einer umrechnen: Die Software, die irgendetwas aus der Angabe berechnen will. Aber da hier nur pro Einheit - statt pro Objekt, das die Einheit verwendet - menschliche Arbeitskraft gefordert ist, kann ich damit gut leben. Gruß, Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.2011 01:40, schrieb Frederik Ramm: Hallo, Stephan Wolff wrote: Wollte man Osmarender beibringen, Einheiten bei "width" auszuwerten, müsste man das Programm ergänzen und an hunderte Teilnehmer verteilen. Für Mapnik sind unhandliche Umrechnungen nötig. Bei Datenbankabfragen (etwa nach den 100 leistungsstärksten Kraftwerken) vervielfacht sich der Aufwand. Diese Regeln müssen für jede Auswertung erneut durchlaufen werden. Der Aufwand ist nicht klein und wird wohl meist unterbleiben. Es ist trotzdem nicht akzeptabel, diese Arbeit den Mappern aufzubuerden, egal wie trivial die Umrechnung ist. Da bin ich ein ziemlicher Hardliner - nur weil irgendein Programmierer es nicht hinkriegt, die Daten richtig auszuwerten, darf es fuer den Mapper nicht schwieriger werden. Ich bin auch hartnäckig und opfere für die Antwort sogar einen Teil meiner Mittagspause. :-) Ein Komma zu verschieben ist keine Arbeit. Ein Label/Tooltip im Editor "Breite in m" versteht jeder Mapper. Ein Label "Breite", bei dem nur im Wiki erklärt ist, welche Zahlen und Einheiten in welcher Formatierung erlaubt sind, kostet mehr Zeit. Wir muten den Mappern an anderer Stelle zuviel zu. Wenn ein Mapper einen Weg teilt, der zufällig zu einer Relation gehört, dann muss er den Aufbau dieser Relation erlernen, um sie ggf. zu reparieren. Würden wir festlegen, dass man die Elemente jeder Relation teilen darf (dann hätte eine Abbiegerelation evtl. mehrere "from" und "to" Elemente), wäre das eine echte Erleichterung für die Mapper. Auch eine Editor-Unterstuetzung hilft uns hier nicht, denn der Mapper wuerde "width=700cm" eingeben, der Editor das auf "7m" umrechnen, und der Mapper sich dann beim naechsten wundern, wieso seine Angabe nicht "richtig" ankam. Wenn der Editor für das Feld "Breite in m" nur Zahlen erlaubt, macht der Mapper keine Fehler und alle Programme werten die Angabe richtig aus. Wenn er "width=700cm" bei einem Fluss einträgt und Osmarender einen 700m breiten See malt, ein anderes Tool die Textausgabe "Flussbreite : 700cm m" macht oder der Editor beim Zusammenfügen die Angabe "width=700cm; 7" erzeugt, ist der Mapper verwirrt. Nicht allen Mappern gelingt es, ein Gebiet exklusiv zu bearbeiten. Sobald man mit anderen gemeinsam arbeitet, kann man seine bevorzugte Einheit ohnehin nicht durchsetzten, sondern müsste zwischen allen verwendeten Angaben umrechnen. Ein Standard erleichtert die Zusammenarbeit. (Noch schlimmer bei Einheiten, bei denen nicht einfach der Dezimalpunkt verschoben wird.) Dann werden die Vorteile der einheitlichen Angabe noch deutlicher. Besser ich zwinge einen Mapper, seine Angabe von Seemeile, yard, Landmeile oder fathom in Meter umzurechnen (Wolfram Alpha: "8 fathom in m" -> "14.63 meters"), als alle Mapper und alle Anwender mit diesen Einheiten zu belasten. Und "an hunderte Teilnehmer verteilen", was meinst Du damit? Bei Osmarender muss eine angepasste Version an alle Teilnehmer verteilt werden, bis eine neue Schreibweise zur korrekten Kartendarstellung führt. Wahrscheinlich hätten wir dauerhaft eine defekte Karte, weil der Mapper auf der Zulässigkeit seiner Einheit besteht und niemand den Renderer anpassen will. Ein Validator kann einfacher auf "Zahl" als auf "Zahl mit zulässiger Einheit" testen. Falsche Zahlen kann ein Validator nie erkennen. Eine Einheit mitzuführen bringt keinen Vorteil. Da bin ich aber entschieden anderer Ansicht. Zu den Möglichkeiten des Validators oder zu anderen Vorteilen wählbarer Einheiten? Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle einmal mit "generator:output:electricity=100 kW" und ein anderes Mal als "generator:output:electricity=0.1 MW" beschrieben wird? Mir wäre "generator:output:electricity=0.1" mit der eindeutigen Definition "Werte in MW" lieber. Deshalb sollst Du ein Tool nutzen, das Dir die Daten so umbaut, wie sie Dir am liebsten sind. Jemand anders will vielleicht fuer schnelles Rendering die Generatoren in 3 Groessenklassen unterteilen und will gar keine konkrete Zahl mehr, sondern nur noch "small","medium","large". Jemand drittes hat eine Software, die mit Kommazahlen nicht so gut umgehen kann und haette gern alles in vollen Watt. Deine Herangehensweise wuerde bedeuten, dass ihr Euch alle auf eine Loesung einigen muesst - wenn statdessen jeder nimmt, was er kriegt, und es geeignet umwandelt, gibt es diesen laestigen Abstimmungsbedarf (der aufd em Ruecken der Mapper ausgetragen wird) nicht. Jeder der drei Anwender würde von einer Zahlenangabe in MW profitieren. Für den ersten vereinfacht sich das Umrechnungstool, der andere kann die Zahl ohne Vorverarbeitung nutzen. Der Mapper spart drei Zeichen und kann sich an der sinnvollen Nutzung seiner Daten erfreuen. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.11 10:29, schrieb Schorschi: Der unplausibelste Wert ist 0 :-) Wieso? Ich bin schon etlichen Leitungen begegnet, die ohne Saft waren, und am Ende einfach so am Mast befestigt waren. Quasi 7 Erdleiter am Mast, auch als double oder quad ;-) Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
On Mon, 14 Feb 2011, Frederik Ramm wrote: > PS: zur Illustration die in Europa vorkommenden "voltage"-Werte samt > Anzahl (nur die, die > 10x vorkommen). Sind diese Werte plausibel und > tatsaechlich alle in Volt? schon ... die Werte zwischen 500 und 1000 V sind vermutlich von Straßen- oder U-Bahnen? Der unplausibelste Wert ist 0 :-) Es gibt auch noch ein paar Leitungen mit Spannungen über 380 kV (Stichwort HGÜ), da könnte es also Verwechslungen geben, aber wohl doch eher selten. Und dann gibt es noch das Gerücht, es gäbe in Europa 400-kV-Leitungen ... das konnte ich bisher nirgendswo bei den einschlägigen Netzbetreibern bestätigt finden - also bei den 40er Werten dürften so einige falsch sein - aber die müssten wohl statt dessen 38 betragen, liegen also nur "knapp" daneben. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
> Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle > einmal mit "generator:output:electricity=100 kW" und ein anderes Mal als > "generator:output:electricity=0.1 MW" beschrieben wird? Ja. Es gibt Menschen, die Probleme haben, kW in MW umzurechnen - und je nach Art des Kraftwerks (oder anderer technischer Anlagen), auch je nach Art der Veröffentlichung (Bauschild, Pressemeldung in Lokalblatt, Pressemeldung in Fachpresse) wirst du unterschiedliche Angaben bekommen. Mal in kW, mal in MW, mal GW, mal sogar in W (hört sich nach "viel" an). Und es wird immer Menschen mit Problemen bei der Eingabe geben. Das führt zu Fehlern, wenn du die Einheit auf nur eine Möglichkeit festlegst. Wir haben schließlich nicht nur Techniker hier (und selbst die haben manchmal massive Problem mit dem Unterschied zwischen Leistung und Energie ... um mal ein weiteres Feld aufzumachen). Ob man hinterher (per Bot?) alles auf eine Einheit geradebiegt, das ist ein anderes Thema - da gäbe es dann aber Argumente für W, kW oder auch MW - bei anderen Themen natürlich andere Einheiten. Diese Diskussion finde ich persönlich erstmal ziemlich müßig, ich erfasse da lieber draußen mehr Daten. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.02.2011 04:03, schrieb Ulf Lamping: > Am 14.02.2011 03:02, schrieb Frederik Ramm: >> Grundsaetzlich finde ich, dass der Editor dem Mapper da nicht >> dazwischenfunken sollte. > > Das ist gut für jemanden der weiß was er tut und schlecht für jemanden der > sich nicht so auskennt oder sich nicht erinnert und erst nachschauen muß. Unterstützen darf der Editor ja gern. Der kann ja verschiedene übliche Einheiten anbieten, und trotzdem die Möglichkeit bieten, auch andere Werte einzutragen. > Ich kann jetzt kein prinzipielles Problem erkennen sich auf "kW" (oder sogar > "W") zu einigen. Außer vielleicht, daß GW in "W" ausgedrückt ein wenig > unhandlich wird. Aus meiner Sicht macht das letztlich allen Beteiligten das > Leben leichter. Nur nicht dem Mapper, der genau die Angabe vom Schild eintragen _und_bei_einer_Überprüfung_auch_wiederfinden_ möchte. Auch wenn ich das keinem hier unterstellen möchte, gibt es Leute, die Schwierigkeiten mit Umrechnungsfaktoren haben. > Bei den Zahlenwerten gehe ich davon aus, ja. Die Einträge mit "unknow" und > "fixme" machen die Verarbeitung allerdings schonmal nicht leichter. Bei > "550V" ist die Angabe V nun wirklich redundant. Die Werte, die kleiner 10 mal > vorkommen hast du gnädig unter den Tisch fallen lassen, erfahrungsgemäß > lauern hier die wirklich üblen Sachen. Diese Werte sollten dann bei der Vorverarbeitung auffallen, so daß man sich Gedanken machen kann, ob man die korrigiert oder als ungültig betrachtet. Gerade solche Probleme werden aber nicht durch die Festlegung einer bestimmten Einheit gelöst. > Jetzt kannst du natürlich sagen: Alles unter 10 mal interessiert mich nicht, > allerdings fehlen damit laut "long tail" sehr viele Werte die man eigentlich > schon auch haben möchte - gerade bei einer special interest map. > Und da geht dann die Arbeit erst so richtig los - mit SQL möchte ich sowas > nicht lösen müssen. Warum klammert Ihr Euch so an SQL? Wer kann denn beliebige Abfragen auf die Original-OSM-Datenbank ausführen? Wenn es eine eigene DB ist, kann man doch die Daten beim Kopieren aus der OSM-Quelle beliebig normalisieren. >> 1453 >> 117 Wenn ich solche Werte ohne Zusammenhang betrachte, wäre ich mir nicht sicher, daß mit 380 wirklich 380V gemeint ist und nicht 380kV. (Nach dem Motto: Das ist eine Hochspannungsleitung, hier ist nur kV sinnvoll.) Auch hier würde eine Einheit helfen. Selbst wenn man sich auf eine Einheit geeinigt hat, hätte das hinzufügen einer Einheit in der DB außer der Platzverschwendung keinen Nachteil. Das könnte ja auch der Editor automatisch hinzufügen. Viele Grüße Bodo >> 110 >> 100 >> 92 >> 91 >> 89 >> 67 >> 64 >> 60 >> 49 >> 46 >> 38 >> 35 >> 34 >> 33 >> 33 >> 29 >> 24 >> 22 >> 21 >> 20 >> 18 >> 18 >> 15 >> 15 >> 14 >> 13 >> 13 >> 12 >> 12 >> 12 >> 11 >> 10 >> 10 >> 10 >> > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1Y2M8ACgkQnMz9fgzDSqfbQQCeJmyNunXw94c6D7TpMOGblJUR TUIAnjsXyQncwnFm+nprS2Bve9N3xBMG =peYS -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.11 03:02, schrieb Frederik Ramm: PS: zur Illustration die in Europa vorkommenden "voltage"-Werte samt Anzahl (nur die, die > 10x vorkommen). Sind diese Werte plausibel und tatsaechlich alle in Volt? 30390 > 6638 Sieht mir nach Mittelspannungsnetz aus. 9785 > 1453 > 1322 Ist das übliche in DE. 7823 2895 Ist eher Straßenbahnniveau. Diese hier: 165 141 110 64 sind tatsächlich "üblich", weil heutzutage gerne mehrere Leitungen mit unterschiedlichen Spannungen an einem Mast hängen. Um das sauber zu trennen, kann man (zusätzlich) Relationen einführen. Aber für die Leitung selber fällt mir da nichts besseres ein. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.2011 03:02, schrieb Frederik Ramm: Ich denk mir halt, der Mapper wird doch einen Grund haben, warum er 700cm eingibt und nicht 7m. Ich glaube, du unterstellst in sehr, sehr, sehr vielen Fällen dem Mapper eine Intention, die nie da war - "ist halt so geworden" - trifft es in vielen Fällen wohl eher ;-) Umgekehrt, wenn ich die Breite eines Flusses mit 10m abschaetze und das so eintrage, und der Editor macht mir daraus 1000cm, dann denke ich "Holla, so genau wollte ich das eigentlich nicht angeben...". Ja, das ist ein Punkt für die Angabe der Masseinheit. Grundsaetzlich finde ich, dass der Editor dem Mapper da nicht dazwischenfunken sollte. Das ist gut für jemanden der weiß was er tut und schlecht für jemanden der sich nicht so auskennt oder sich nicht erinnert und erst nachschauen muß. Alle drei von dir genannten Anwendungen wären mit einer eindeutigen Angabe (wie auch immer die aussieht) gut bedient Nein, denn wenn diese eindeutige Angabe "small", "medium", "large" ist, dann kann einer, der die Leistung als Zahl will, damit nichts mehr anfangen. Steht die Leistung als Zahl drin, muesste der, der nur drei Groessenklassen will, diese "zeitaufwendig" im SQL umrechnen. Und so weiter. Das "small", "medium", "large" wird bei der Detailgenauigkeit der Mapper eh nicht passieren. Das ist eine Erfindung von dir. Wenn man auf seiner Karte so eine 3er Klassifizierung (z.B. kleines, mittleres und großes Icon) haben möchte muß man diese entsprechend umrechnen, klar. Das ist aber nicht das Problem, das kriegt man hin. Das Problem sind drei verschiedene Schreibweisen, vier verschiedene Maßeinheiten und was weiß ich sonst noch an Varianten. Ein "konfuser String, der irgendwelche Zahlen enthaelt" ist in jedem Fall ein Problem. Es ist nicht so, das ich fuer "konfuse Strings, die irgendwelche Zahlen enthalten" bin und Stephan dagegen; es ist lediglich so, dass Stephan den Benutzern eine Masseinheit vorschreiben und dann lediglich die einheit-lose Zahl speichern will, waehrend ich die Benutzer anhalten will, die Masseinheit mit anzugeben. Das wird sich in den meisten Faellen hoechstwahrscheinlich auf ein paar wenige Werte beschraenken - auf "V" und "kV" bei Spannungen, auf "kW", "MW" und "GW" bei Kraftwerken, auf "m" und "cm" bei Laengen. Bei Spannungen "V" und bei Längen "m" sind bei OSM eigentlich inzwischen einheitenlos Standard - wenn man denn von den Engländern mit "ft" absieht. Ich kann jetzt kein prinzipielles Problem erkennen sich auf "kW" (oder sogar "W") zu einigen. Außer vielleicht, daß GW in "W" ausgedrückt ein wenig unhandlich wird. Aus meiner Sicht macht das letztlich allen Beteiligten das Leben leichter. Wenn die Leute irgendwelche komischen Punkte oder Leerzeichen in ihre Werte reinschreiben oder sowas wie "5-6m" oder das unselige (oft von den Editoren eingeschmuggelte) Semikolon genutzt wird, hat mit der Frage "Einheit oder nicht" nichts zu tun. Kannst du einen Editor nennen, der Semikolons "einschmuggelt"?!? Bye Frederik PS: zur Illustration die in Europa vorkommenden "voltage"-Werte samt Anzahl (nur die, die > 10x vorkommen). Sind diese Werte plausibel und tatsaechlich alle in Volt? Bei den Zahlenwerten gehe ich davon aus, ja. Die Einträge mit "unknow" und "fixme" machen die Verarbeitung allerdings schonmal nicht leichter. Bei "550V" ist die Angabe V nun wirklich redundant. Die Werte, die kleiner 10 mal vorkommen hast du gnädig unter den Tisch fallen lassen, erfahrungsgemäß lauern hier die wirklich üblen Sachen. Jetzt kannst du natürlich sagen: Alles unter 10 mal interessiert mich nicht, allerdings fehlen damit laut "long tail" sehr viele Werte die man eigentlich schon auch haben möchte - gerade bei einer special interest map. Und da geht dann die Arbeit erst so richtig los - mit SQL möchte ich sowas nicht lösen müssen. Gruß, ULFL 30390 9785 7823 6638 6588 2895 1453 1322 962 916 705 634 609 558 356 348 343 283 183 165 141 119 117 110 100 92 91 89 67 64 60 49 46 38 35 34 33 33 29 24 22 21 20 18 18 15 15 14 13 13 12 12 12 11 10 10 10 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo, Ulf Lamping wrote: Es ist für einen Mapper wesentlich leichter, einen Zahlenwert und evtl. die Maßeinheit aus einer Drop-Down-Box auszuwählen, als irgendwas einzutragen und dann zu raten ob das jetzt "gestimmt" hat. Wenn der Mapper dabei sowohl "700", "cm" als auch "7", "m" auswaehlen kann, soll es mir recht sein. Auch eine Editor-Unterstuetzung hilft uns hier nicht, denn der Mapper wuerde "width=700cm" eingeben, der Editor das auf "7m" umrechnen, und der Mapper sich dann beim naechsten wundern, wieso seine Angabe nicht "richtig" ankam. (Noch schlimmer bei Einheiten, bei denen nicht einfach der Dezimalpunkt verschoben wird.) Wieso ein Mapper sich drüber wundern würde, wenn sein Editor aus 700cm beim Tag maxwidth automatisch 7m macht, müßtest du nochmal genauer erklären. Ich denk mir halt, der Mapper wird doch einen Grund haben, warum er 700cm eingibt und nicht 7m. Meistens werden das Faelle sein, wo die Angabe 700cm eben irgendwo abgelesen ist und deshalb naheliegender als 7m. Umgekehrt, wenn ich die Breite eines Flusses mit 10m abschaetze und das so eintrage, und der Editor macht mir daraus 1000cm, dann denke ich "Holla, so genau wollte ich das eigentlich nicht angeben...". Grundsaetzlich finde ich, dass der Editor dem Mapper da nicht dazwischenfunken sollte. Bei einigen Sachen ist es relativ eindeutig, z.B. bei den Hoechstgeschwindigkeiten macht Potlatch das schon ganz gut mit den Schildern, und eine Hoechstgeschwindigkeit wird auch gewiss nirgens in Meter pro Sekunde angegeben. Dabei wird es immer Ausnahmen geben, z.B. wenn jemand abstruse Werte von einem alten Typenschild abschreibt und einträgt (weil er das nicht umrechnen kann oder will). Es sollte halt klar sein, das es dann eher nirgendwo angezeigt / ausgewertet wird. Ja, genau - ist ja bei Tags auch so: Wenn ich partout irgendwas obskures erfassen will, kann ich das machen, und eventuell gibt es sogar obskure Karten, die das rendern, aber im 08/15-Rendering ist es dann eben nicht drin. Deshalb sollst Du ein Tool nutzen, das Dir die Daten so umbaut, wie sie Dir am liebsten sind. Jemand anders will vielleicht fuer schnelles Rendering die Generatoren in 3 Groessenklassen unterteilen und will gar keine konkrete Zahl mehr, sondern nur noch "small","medium","large". Jemand drittes hat eine Software, die mit Kommazahlen nicht so gut umgehen kann und haette gern alles in vollen Watt. Deine Herangehensweise wuerde bedeuten, dass ihr Euch alle auf eine Loesung einigen muesst - wenn statdessen jeder nimmt, was er kriegt, und es geeignet umwandelt, gibt es diesen laestigen Abstimmungsbedarf (der aufd em Ruecken der Mapper ausgetragen wird) nicht. Alle drei von dir genannten Anwendungen wären mit einer eindeutigen Angabe (wie auch immer die aussieht) gut bedient Nein, denn wenn diese eindeutige Angabe "small", "medium", "large" ist, dann kann einer, der die Leistung als Zahl will, damit nichts mehr anfangen. Steht die Leistung als Zahl drin, muesste der, der nur drei Groessenklassen will, diese "zeitaufwendig" im SQL umrechnen. Und so weiter. und alle drei haben viel Arbeit beim aufdröseln von konfusen Strings die irgendwie Zahlen enthalten. Und das nicht nur bei diesem einen Tag, sondern bei ziemlich vielen! Ein "konfuser String, der irgendwelche Zahlen enthaelt" ist in jedem Fall ein Problem. Es ist nicht so, das ich fuer "konfuse Strings, die irgendwelche Zahlen enthalten" bin und Stephan dagegen; es ist lediglich so, dass Stephan den Benutzern eine Masseinheit vorschreiben und dann lediglich die einheit-lose Zahl speichern will, waehrend ich die Benutzer anhalten will, die Masseinheit mit anzugeben. Das wird sich in den meisten Faellen hoechstwahrscheinlich auf ein paar wenige Werte beschraenken - auf "V" und "kV" bei Spannungen, auf "kW", "MW" und "GW" bei Kraftwerken, auf "m" und "cm" bei Laengen. - Wenn die Leute irgendwelche komischen Punkte oder Leerzeichen in ihre Werte reinschreiben oder sowas wie "5-6m" oder das unselige (oft von den Editoren eingeschmuggelte) Semikolon genutzt wird, hat mit der Frage "Einheit oder nicht" nichts zu tun. Bye Frederik PS: zur Illustration die in Europa vorkommenden "voltage"-Werte samt Anzahl (nur die, die > 10x vorkommen). Sind diese Werte plausibel und tatsaechlich alle in Volt? 30390 9785 7823 6638 6588 2895 1453 1322 962 916 705 634 609 558 356 348 343 283 183 165 141 119 117 110 100 92 91 89 67 64 60 49 46 38 35 34 33 33 29 24 22 21 20 18 18 15 15 14 13 13 12
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 14.02.2011 01:40, schrieb Frederik Ramm: Es ist trotzdem nicht akzeptabel, diese Arbeit den Mappern aufzubuerden, egal wie trivial die Umrechnung ist. Da bin ich ein ziemlicher Hardliner - nur weil irgendein Programmierer es nicht hinkriegt, die Daten richtig auszuwerten, darf es fuer den Mapper nicht schwieriger werden. Der Mapper hat es eh schon schwer genug. Die Mapper sind bei uns die Arbeitspferde, denen muessen wir es so leicht wie moeglich machen. Dann gehört sowas in die Editoren rein. Es ist für einen Mapper wesentlich leichter, einen Zahlenwert und evtl. die Maßeinheit aus einer Drop-Down-Box auszuwählen, als irgendwas einzutragen und dann zu raten ob das jetzt "gestimmt" hat. Das sowas später dann bestenfalls auf irgendwelchen Spezialkarten auftaucht die kaum einer kennt macht die Überprüfbarkeit durch den Mapper halt auch nicht leichter. Auch eine Editor-Unterstuetzung hilft uns hier nicht, denn der Mapper wuerde "width=700cm" eingeben, der Editor das auf "7m" umrechnen, und der Mapper sich dann beim naechsten wundern, wieso seine Angabe nicht "richtig" ankam. (Noch schlimmer bei Einheiten, bei denen nicht einfach der Dezimalpunkt verschoben wird.) Wieso ein Mapper sich drüber wundern würde, wenn sein Editor aus 700cm beim Tag maxwidth automatisch 7m macht, müßtest du nochmal genauer erklären. Ich gehe eher davon aus, das dies dem Mapper die Arbeit eher erleichtern würde "ah, hat er erkannt, dann stimmt das mit meiner Werteangabe also wohl". Vorausgesetzt, die Implementierung im Editor taucht was. Vom "verbiegen" von geraden Zahlenwerten auf krumme Zahlenwerte in SI Einheiten (30 mph -> 4x.xxx km/h) halte ich allerdings auch nix. Dabei wird es immer Ausnahmen geben, z.B. wenn jemand abstruse Werte von einem alten Typenschild abschreibt und einträgt (weil er das nicht umrechnen kann oder will). Es sollte halt klar sein, das es dann eher nirgendwo angezeigt / ausgewertet wird. Deshalb sollst Du ein Tool nutzen, das Dir die Daten so umbaut, wie sie Dir am liebsten sind. Jemand anders will vielleicht fuer schnelles Rendering die Generatoren in 3 Groessenklassen unterteilen und will gar keine konkrete Zahl mehr, sondern nur noch "small","medium","large". Jemand drittes hat eine Software, die mit Kommazahlen nicht so gut umgehen kann und haette gern alles in vollen Watt. Deine Herangehensweise wuerde bedeuten, dass ihr Euch alle auf eine Loesung einigen muesst - wenn statdessen jeder nimmt, was er kriegt, und es geeignet umwandelt, gibt es diesen laestigen Abstimmungsbedarf (der aufd em Ruecken der Mapper ausgetragen wird) nicht. Alle drei von dir genannten Anwendungen wären mit einer eindeutigen Angabe (wie auch immer die aussieht) gut bedient und alle drei haben viel Arbeit beim aufdröseln von konfusen Strings die irgendwie Zahlen enthalten. Und das nicht nur bei diesem einen Tag, sondern bei ziemlich vielen! Du tust hier so, als ob die bösen Anwendungsentwickler hier unmenschliches von den Mappern verlangen - dabei ist bei vielen Tags eher das Gegenteil der Fall ;-) Mal davon abgesehen, das viele Tags meist sehr schnell "konform" werden, wenn sie von einer populären Karte angezeigt werden ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo, Stephan Wolff wrote: Wollte man Osmarender beibringen, Einheiten bei "width" auszuwerten, müsste man das Programm ergänzen und an hunderte Teilnehmer verteilen. Für Mapnik sind unhandliche Umrechnungen nötig. Bei Datenbankabfragen (etwa nach den 100 leistungsstärksten Kraftwerken) vervielfacht sich der Aufwand. Diese Regeln müssen für jede Auswertung erneut durchlaufen werden. Der Aufwand ist nicht klein und wird wohl meist unterbleiben. Es ist trotzdem nicht akzeptabel, diese Arbeit den Mappern aufzubuerden, egal wie trivial die Umrechnung ist. Da bin ich ein ziemlicher Hardliner - nur weil irgendein Programmierer es nicht hinkriegt, die Daten richtig auszuwerten, darf es fuer den Mapper nicht schwieriger werden. Der Mapper hat es eh schon schwer genug. Die Mapper sind bei uns die Arbeitspferde, denen muessen wir es so leicht wie moeglich machen. Auch eine Editor-Unterstuetzung hilft uns hier nicht, denn der Mapper wuerde "width=700cm" eingeben, der Editor das auf "7m" umrechnen, und der Mapper sich dann beim naechsten wundern, wieso seine Angabe nicht "richtig" ankam. (Noch schlimmer bei Einheiten, bei denen nicht einfach der Dezimalpunkt verschoben wird.) Was Osmarender betrifft, es gab frueher einen Praeprozessor, den man vor Osmarender laufen lassen musste, um Segmente umzudrehen. Es gibt heute noch ein Skript, das Kuestenlinien schliessen muss, damit Osmarender damit arbeiten kann. Es gibt einen Postprozessor fuer Bezierkurven. Ich sehe nicht, wieso man nicht einen "Einheiten-Umrechnungs-Praeprozessor" schreiben soll (oder, wie vorgeschlagen, einen Osmosis-Task dafuer bauen). Und "an hunderte Teilnehmer verteilen", was meinst Du damit? Das ist doch bei uns Standard, dass Software veraendert wird und Leute sich eine neue Version runterladen. Das kann nun wirklich kein Argument sein. Das ist eine Variation, mit der eine robuste Auswertung gut klarkommen kann. Dann ist es auch keine zusätzliche Fehlermöglichkeit, weil einfach beides funktioniert. Wer kann und will eine solche robuste Auswertung in SQL implementieren? Wenn SQL das falsche Mittel ist, dann muss die Auswertung eben anders implementiert werden. Es ist nicht die Aufgabe des Mappers, sich darueber den Kopf zu zerbrechen. Ein Validator kann einfacher auf "Zahl" als auf "Zahl mit zulässiger Einheit" testen. Falsche Zahlen kann ein Validator nie erkennen. Eine Einheit mitzuführen bringt keinen Vorteil. Da bin ich aber entschieden anderer Ansicht. Mapnik, Osmarender und sicherlich die meisten OSM-Anwendungen greifen direkt auf die Texte der Tags zu. Dort müssten komplexere und langsamere Abfragen implementiert werden. Die meisten Nutzer machen eh schon irgendwelche Vorverarbeitungsschritte - etwas mit Osmosis ausschneiden oder diffs mit Osmosis herunterladen zum Beispiel, da wuerde ein zusaetzlicher "und bitte rechne alle Einheiten nach diesem Schema hier um"-Schritt auch nicht stoeren. Die Reit- und Wanderkarte wie auch die OpenCycleMap haben sogar beide einen massiven Vorverarbeitungsschritt, in dem sie einen Grossteil der Tags auf eigene Nomenklatur umsetzen, bevor er mit osm2pgsl in die Datenbank wandert. Meiner Ansicht nach ist das der richtige Weg, diese Vorverarbeitung einfacher zu machen, so dass sich jeder leicht zusammenbauen kann, welche Tags er will und wie er die gern ausgewertet haette (zum Beispiel spraeche auch nichts gegen ein aufgebohrtes osm2pgsql, das Tag-Werte erst an eine Umformroutine uebergibt, bevor die in die Datenbank kommen). Der falsche Weg ist es, von Nutzern die Einhaltung von immer mehr Regeln zu verlangen, bloss weil der Datenauswerter ein einfacheres Leben haben will. Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle einmal mit "generator:output:electricity=100 kW" und ein anderes Mal als "generator:output:electricity=0.1 MW" beschrieben wird? Mir wäre "generator:output:electricity=0.1" mit der eindeutigen Definition "Werte in MW" lieber. Deshalb sollst Du ein Tool nutzen, das Dir die Daten so umbaut, wie sie Dir am liebsten sind. Jemand anders will vielleicht fuer schnelles Rendering die Generatoren in 3 Groessenklassen unterteilen und will gar keine konkrete Zahl mehr, sondern nur noch "small","medium","large". Jemand drittes hat eine Software, die mit Kommazahlen nicht so gut umgehen kann und haette gern alles in vollen Watt. Deine Herangehensweise wuerde bedeuten, dass ihr Euch alle auf eine Loesung einigen muesst - wenn statdessen jeder nimmt, was er kriegt, und es geeignet umwandelt, gibt es diesen laestigen Abstimmungsbedarf (der aufd em Ruecken der Mapper ausgetragen wird) nicht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Moin! Am 13.02.2011 13:21, schrieb Tobias Knerr: Am 13.02.2011 12:55, schrieb Stephan Wolff: Am 13.02.2011 00:54, schrieb Frederik Ramm: Stephan Wolff wrote: Die Kodierung der Leistung als Wert mit wählbarer Einheit ist m. E. ein Designfehler. Dann ist der Designfehler aber in Deinem Prozess Das sehe ich anders. Bei maxheight, maxwidth, maxspeed, width, voltage, etc. werden Zahlen ohne mitgeschriebene Einheit verwendet. Die Aussage ist falsch. Gerade bei maxspeed ist es Standard, dass andere Einheiten als km/h erstens verwendet und zweitens explizit mitgeschrieben werden. Bei maxspeed hast du recht. Ich hatte nur im Wiki bei DE:Map_Features nach nummerischen Daten geschaut. Dort und unter DE:Key:access werden nur Werte ohne Einheit in km/h genannt. Allerdings beruht hier die unterschiedlichen Einheiten auf anderen nationalen Gesetzen und nicht auf einer willkürlichen Wahl des Mappers. Bei Daten mit wählbaren Einheiten ist ein viel größerer Aufwand nötig. Der Aufwand ist größer, aber immer noch klein. Es ist ganz sicher keine unzumutbare Hürde. Wollte man Osmarender beibringen, Einheiten bei "width" auszuwerten, müsste man das Programm ergänzen und an hunderte Teilnehmer verteilen. Für Mapnik sind unhandliche Umrechnungen nötig. Bei Datenbankabfragen (etwa nach den 100 leistungsstärksten Kraftwerken) vervielfacht sich der Aufwand. Diese Regeln müssen für jede Auswertung erneut durchlaufen werden. Der Aufwand ist nicht klein und wird wohl meist unterbleiben. Eine Festlegung der Einheit würde dagegen pro Objekt einmalig eine triviale Umrechnung erfordern. Zudem gibt es mehr Fehlermöglichkeiten, wenn der Mapper die Einheit oder das Leerzeichen vor der Einheit vergisst Das ist eine Variation, mit der eine robuste Auswertung gut klarkommen kann. Dann ist es auch keine zusätzliche Fehlermöglichkeit, weil einfach beides funktioniert. Wer kann und will eine solche robuste Auswertung in SQL implementieren? Wer der Vermeidung von Fehlern, die ein simpler Validator automatisch erkennen kann, Vorrang vor der Vermeidung "unsichtbarer" Fehler gibt, setzt in meinen Augen falsche Prioritäten. Ein Validator kann einfacher auf "Zahl" als auf "Zahl mit zulässiger Einheit" testen. Falsche Zahlen kann ein Validator nie erkennen. Eine Einheit mitzuführen bringt keinen Vorteil. In einer Datenbank überwiegen die Vorteile einfacher Zahlen deutlich gegenüber ausgeschriebenen Einheiten mit wählbarem Präfix. In einer Datenbank, auf die eine produktive Anwendung direkt zugreift, ja. Allerdings nicht in einer Datenbank für menschenlesbare Attribute, die auch noch möglichst stabil gegenüber Fehlinterpretationen sein sollte. Glücklicherweise ist das kein Widerspruch, da wir hier in aller Regel von zwei verschiedenen Datenbanken sprechen. Mapnik, Osmarender und sicherlich die meisten OSM-Anwendungen greifen direkt auf die Texte der Tags zu. Dort müssten komplexere und langsamere Abfragen implementiert werden. Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle einmal mit "generator:output:electricity=100 kW" und ein anderes Mal als "generator:output:electricity=0.1 MW" beschrieben wird? Mir wäre "generator:output:electricity=0.1" mit der eindeutigen Definition "Werte in MW" lieber. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo, Tobias Knerr wrote: Ich erwäge gerade auch, in Zukunft einige der Verarbeitungsschritte für meine Software in die Vorverarbeitung zu ziehen, und der für mich spontan naheliegendste Ansatz wäre, einen eigenen Osmosis-Task zu schreiben. Eventuell kannst Du "TagTransform" entsprechend aufbohren. Das wuerden sicher noch mehr Leute nutzen wollen. Habe ich da ein Problem übersehen? Lediglich das, das Osmosis sich dem Programmieranfaenger unter Umstaenden nicht direkt erschliesst - und Martin schrieb ja, er koenne eh nichts und deshalb sei ihm jede Sprache gleich recht ;) Osmosis ist halt ein Java-Programm nach Industriestandard - mit einigen Indirektionen, Factories, Interfaces, Implementationen mehr, als es einem Einsteiger naheliegend erscheinen wuerde. Aber wenn man sowas regelmaessig macht, fuehlt man sich da natuerlich daheim ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 13. Februar 2011 12:21 schrieb Frederik Ramm : >> Das Präprocessing wäre also wohl an dieser Stelle sinnvoll (vor dem >> Import in die db). > > Ja - obwohl man es durchaus auch spaeter noch in der Datenbank machen > koennte, wenn einem das lieber ist. ja, teilweise versuche ich mich auch daran (aber bisher nur "Kleinkram"). > primitiven Sprache, u.U. sogar sed/awk, arbeiten kannst. Ein einfaches > Perl-Skript, das die Bevoelkerung trimmt, saehe z.B. so aus: > > #!/usr/bin/perl ... > Bye > Frederik vielen Dank Frederik für die Anregungen und Beispiele, d.h. ich sehe mir wohl mal Perl an ;-). Praktisch wird man vermutlich Zeile für Zeile durchackern (bzcat) und in Kopie (entweder verändert oder nicht) speichern. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 13.02.2011 12:21, schrieb Frederik Ramm: > M∡rtin Koppenhoefer wrote: >> Ich nutze derzeit Osmosis, hole mir >> damit einige Elemente aus dem Planet und kombiniere das Ergebnis mit >> einem Italy-Extrakt zu einem komprimierten osm-xml, den ich mit >> osm2pgsql in eine Renderdatenbank einlese. [...] >> Das Präprocessing wäre also wohl an dieser Stelle sinnvoll (vor dem >> Import in die db). > > Ja - obwohl man es durchaus auch spaeter noch in der Datenbank machen > koennte, wenn einem das lieber ist. [...] > Normalerweise muesste man dafuer einen XML-Parser nehmen. Das ist auch > nicht superkompliziert. Aber - und dafuer kriege ich regelmaessig > Schelte von "echten Programmierern" - da Du es hier it dem immer > gleichen Datenproduzenten zu tun hast, kannst Du auch die Annahme > treffen, dass die Daten immer gleich formuliert sind, d.h., Du bekommst > immer eine Zeile der Form > > > > fuer die Bevoelkerung. Das wiederum heisst, dass Du in einer beliebigen > primitiven Sprache, u.U. sogar sed/awk, arbeiten kannst. Ich erwäge gerade auch, in Zukunft einige der Verarbeitungsschritte für meine Software in die Vorverarbeitung zu ziehen, und der für mich spontan naheliegendste Ansatz wäre, einen eigenen Osmosis-Task zu schreiben. Gerade, wenn die Daten (wie bei Martin ja anscheinend auch) ohnehin schon durch die Osmosis-Pipeline wandern, müsste sich das ja ohne zusätzlichen Lese-/Schreibaufwand integrieren lassen. Ganz nebenbei wäre es auch noch "sauber", weil Osmosis das XML-Parsen übernimmt, und sollte außerdem für alle von Osmosis lesbaren Dateiformate klappen. Habe ich da ein Problem übersehen? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 13.02.2011 12:55, schrieb Stephan Wolff: > Am 13.02.2011 00:54, schrieb Frederik Ramm: >> Stephan Wolff wrote: >>> Die Kodierung der Leistung als Wert mit wählbarer Einheit ist >>> m. E. ein Designfehler. >>> Ich musste folgendes Ungetüm in SQL zur Umrechnung nutzen: >> >> Dann ist der Designfehler aber in Deinem Prozess - solange es wenigstens >> klar ersichtlich ist, was gemeint ist, musst Du halt vor dem Import in >> die Datenbank alles in Pferdestaerken umrechnen, oder was Du halt >> brauchst ;) > > Das sehe ich anders. Bei maxheight, maxwidth, maxspeed, width, voltage, > etc. werden Zahlen ohne mitgeschriebene Einheit verwendet. Die Aussage ist falsch. Gerade bei maxspeed ist es Standard, dass andere Einheiten als km/h erstens verwendet und zweitens explizit mitgeschrieben werden. Diese Praxis ist auch absolut sinnvoll, da Mapper so auf einfache Weise die vor Ort üblichen und auf einem Schild auch in dieser Einheit gegebenen Werte eintragen können. Der Wert mit expliziter Einheitenangabe ist zudem unmissverständlich - anders als Werte mit impliziter Einheit, bei denen kein Rückschluss auf die Intention des Mappers möglich ist. Auch bei Längeneinheiten finden sich übrigens explizit eingetragene Einheiten. > Bei Daten mit wählbaren Einheiten ist ein viel größerer Aufwand nötig. Der Aufwand ist größer, aber immer noch klein. Es ist ganz sicher keine unzumutbare Hürde. > Zudem gibt es mehr Fehlermöglichkeiten, wenn der Mapper die Einheit > oder das Leerzeichen vor der Einheit vergisst Das ist eine Variation, mit der eine robuste Auswertung gut klarkommen kann. Dann ist es auch keine zusätzliche Fehlermöglichkeit, weil einfach beides funktioniert. Übrigens sind Abweichungen und Fehler, die man als solche erkennt, kein ernsthaftes Problem. Schlimm sind Fehler, die man nicht erkennen kann - etwa, wenn jemand eine einheitenlose Zahl einträgt und sich seine Annahmen zu deren Bedeutung von den Annahmen desjenigen, der sie auswertet, unterscheiden. Wer der Vermeidung von Fehlern, die ein simpler Validator automatisch erkennen kann, Vorrang vor der Vermeidung "unsichtbarer" Fehler gibt, setzt in meinen Augen falsche Prioritäten. > In einer Datenbank überwiegen die Vorteile einfacher Zahlen > deutlich gegenüber ausgeschriebenen Einheiten mit wählbarem Präfix. In einer Datenbank, auf die eine produktive Anwendung direkt zugreift, ja. Allerdings nicht in einer Datenbank für menschenlesbare Attribute, die auch noch möglichst stabil gegenüber Fehlinterpretationen sein sollte. Glücklicherweise ist das kein Widerspruch, da wir hier in aller Regel von zwei verschiedenen Datenbanken sprechen. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Moin! Am 13.02.2011 00:54, schrieb Frederik Ramm: Stephan Wolff wrote: Die Kodierung der Leistung als Wert mit wählbarer Einheit ist m. E. ein Designfehler. Ich musste folgendes Ungetüm in SQL zur Umrechnung nutzen: Dann ist der Designfehler aber in Deinem Prozess - solange es wenigstens klar ersichtlich ist, was gemeint ist, musst Du halt vor dem Import in die Datenbank alles in Pferdestaerken umrechnen, oder was Du halt brauchst ;) Das sehe ich anders. Bei maxheight, maxwidth, maxspeed, width, voltage, etc. werden Zahlen ohne mitgeschriebene Einheit verwendet. Dadurch kann man diese Werte relativ einfach auswerten, vergleichen oder sortieren. Bei Daten mit wählbaren Einheiten ist ein viel größerer Aufwand nötig. Zudem gibt es mehr Fehlermöglichkeiten, wenn der Mapper die Einheit oder das Leerzeichen vor der Einheit vergisst oder "4 M" statt "4 m" schreibt. In einer Datenbank überwiegen die Vorteile einfacher Zahlen deutlich gegenüber ausgeschriebenen Einheiten mit wählbarem Präfix. Auch bei "highway=Autobahn" wäre klar ersichtlich, was gemeint ist, aber sinnvoll sind solche Werte in OSM nicht. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo,
M∡rtin Koppenhoefer wrote:
Ich komme leider nicht aus dem Informatik-Umfeld und selbst "triviale"
Aufgaben erfordern für mich einiges an Recherche bzw. riskiere ich,
die Probleme suboptimal zu lösen. Ich nutze derzeit Osmosis, hole mir
damit einige Elemente aus dem Planet und kombiniere das Ergebnis mit
einem Italy-Extrakt zu einem komprimierten osm-xml, den ich mit
osm2pgsql in eine Renderdatenbank einlese. Die Werte übernehme ich
dabei derzeit einfach so, wie sie aus der db kommen.
Das Präprocessing wäre also wohl an dieser Stelle sinnvoll (vor dem
Import in die db).
Ja - obwohl man es durchaus auch spaeter noch in der Datenbank machen
koennte, wenn einem das lieber ist.
Aber welches
Programm/Vorgehen/Programmier-/Scriptsprache bietet sich dafür an? (Da
ich das sowieso neu lernen muss, habe ich die Qual der Wahl). Oder
sowas wie sed / awk? Wie macht Ihr das normalerweise?
Normalerweise muesste man dafuer einen XML-Parser nehmen. Das ist auch
nicht superkompliziert. Aber - und dafuer kriege ich regelmaessig
Schelte von "echten Programmierern" - da Du es hier it dem immer
gleichen Datenproduzenten zu tun hast, kannst Du auch die Annahme
treffen, dass die Daten immer gleich formuliert sind, d.h., Du bekommst
immer eine Zeile der Form
fuer die Bevoelkerung. Das wiederum heisst, dass Du in einer beliebigen
primitiven Sprache, u.U. sogar sed/awk, arbeiten kannst. Ein einfaches
Perl-Skript, das die Bevoelkerung trimmt, saehe z.B. so aus:
#!/usr/bin/perl
while(<>)
{
if (/\n", $1);
}
else
{
print;
}
}
Nach diesem Muster waere es auch trivial, z.B. noch Leerzeichen zu
entfernen, oder ein "123.000" zu einem "123000" zu machen:
...
if (/\n", $p);
}
...
oder ein "MW" in "W" umzurechnen, usw.usw.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 13. Februar 2011 02:09 schrieb Frederik Ramm : > Wenn man nicht gerade, wie Stephan, vor dem Problem steht, alles mit SQL > machen zu wollen, dann ist es ja wohl trivial, die verschiedenen gaengigen > Einheiten fuer ein bestimmtes Mass in einem Programm abzudecken. Hier würde ich gerne mal einhaken, weil ich auch vor diesem (und ähnlichen) Problemen stehe. Wie (an welcher Stelle im Prozess) kann man die OSM-Werte am besten "normalisieren"? Ich komme leider nicht aus dem Informatik-Umfeld und selbst "triviale" Aufgaben erfordern für mich einiges an Recherche bzw. riskiere ich, die Probleme suboptimal zu lösen. Ich nutze derzeit Osmosis, hole mir damit einige Elemente aus dem Planet und kombiniere das Ergebnis mit einem Italy-Extrakt zu einem komprimierten osm-xml, den ich mit osm2pgsql in eine Renderdatenbank einlese. Die Werte übernehme ich dabei derzeit einfach so, wie sie aus der db kommen. Das Präprocessing wäre also wohl an dieser Stelle sinnvoll (vor dem Import in die db). Aber welches Programm/Vorgehen/Programmier-/Scriptsprache bietet sich dafür an? (Da ich das sowieso neu lernen muss, habe ich die Qual der Wahl). Oder sowas wie sed / awk? Wie macht Ihr das normalerweise? Ich würde z.B. bei "population" gerne alles so trimmen, dass es "echte" Zahlen sind, ohne Einheiten oder Quellenangaben im tag. Was ist die Methode, um das möglichst schnell zu berechnen? Für ein paar Anhaltspunkte, wie andere Leute hier vorgehen, wäre ich dankbar. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo, Henning Scholland wrote: Halte ich für recht gefährlich, wenn jeder Werte in beliebiger Einheit einträgt. Was bringt es, wenn ich statt Watt die Leistung in g*m^2*h^-3 [ W=J/s=N*m/s=kg*m^2/s^-3 ] angebe? Muss ich auf das Argument wirklich eingehen? Wenn g*m^2*h^-3 eine gaengige Einheit fuer die Leistung von Blockheizkraftwerken ist - wenn der Mapper diese Angabe der Presse oder einer Fachinformation oder einem Schild am Objekt o.ae. entnehmen kann - dann ist es selbstverstaendlich auch sinnvoll, die so in OSM zu schreiben. Wenn nicht, dann ist es ein missratener Versuch, Deine Sichtweise zu begruenden ;) Man sollte sich schon bei einer Eigenschaft auf eine Einheit einigen. Man braucht sich nicht zu einigen; bei jeder Eigenschaft wird es nur ganz wenige ueberhaupt in der Praxis vorkommende Einheiten geben, und je weniger der Mapper umrechnen muss, desto weniger Fehler gibt es bei der Aufzeichnung. Wenn dies nicht möglich ist (mp/h vs. km/h) sollte man sich auf das Minimum an Auswahl beschränken. Andernfalls hat es was von einem name-Tag, dessen Auswertung unmöglich ist. Wenn man nicht gerade, wie Stephan, vor dem Problem steht, alles mit SQL machen zu wollen, dann ist es ja wohl trivial, die verschiedenen gaengigen Einheiten fuer ein bestimmtes Mass in einem Programm abzudecken. Und genauso wie ueberall sonst in OSM ist da halt eine gewisse Dynamik drin. Wenn der Strassenbreitenauswerter bislang die Strassenbreite nur in Meter und Fuss unterstuetzt und die Leute jetzt ploetzlich vermehrt die Breite in mm eintragen, dann merkt der das und kann sein Programm anpassen. Mir waere in erster Linie wichtig, dass die Leute die Einheit dazuschreiben. Wenn man sich "auf eine einigt", dann denken die Leute, sie muessten sie nicht mehr hinschreiben - und dann gibt es doch erst Kuddelmuddel. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo Am 13.02.2011 00:54, schrieb Frederik Ramm: Stephan Wolff wrote: Die Kodierung der Leistung als Wert mit wählbarer Einheit ist m. E. ein Designfehler. Ich musste folgendes Ungetüm in SQL zur Umrechnung nutzen: Dann ist der Designfehler aber in Deinem Prozess - solange es wenigstens klar ersichtlich ist, was gemeint ist, musst Du halt vor dem Import in die Datenbank alles in Pferdestaerken umrechnen, oder was Du halt brauchst ;) Halte ich für recht gefährlich, wenn jeder Werte in beliebiger Einheit einträgt. Was bringt es, wenn ich statt Watt die Leistung in g*m^2*h^-3 [ W=J/s=N*m/s=kg*m^2/s^-3 ] angebe? Man sollte sich schon bei einer Eigenschaft auf eine Einheit einigen. Wenn dies nicht möglich ist (mp/h vs. km/h) sollte man sich auf das Minimum an Auswahl beschränken. Andernfalls hat es was von einem name-Tag, dessen Auswertung unmöglich ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Hallo, Stephan Wolff wrote: Die Kodierung der Leistung als Wert mit wählbarer Einheit ist m. E. ein Designfehler. Ich musste folgendes Ungetüm in SQL zur Umrechnung nutzen: Dann ist der Designfehler aber in Deinem Prozess - solange es wenigstens klar ersichtlich ist, was gemeint ist, musst Du halt vor dem Import in die Datenbank alles in Pferdestaerken umrechnen, oder was Du halt brauchst ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
Am 11.02.2011 22:51, schrieb Schorschi: generator:output:electricity = 1.8 MW (oder 1800 kW) Die Kodierung der Leistung als Wert mit wählbarer Einheit ist m. E. ein Designfehler. Ich musste folgendes Ungetüm in SQL zur Umrechnung nutzen: (CASE WHEN tags->'generator:output:electricity'~'^[0-9.]*[ ]*MW$' THEN to_number(tags->'generator:output:electricity',',999') WHEN tags->'generator:output:electricity'~'^[0-9.]*[ ]*kW$' THEN to_number(tags->'generator:output:electricity',',999')/1000 ELSE '-1' END) as out Laut Wiki zulässige Einheiten W und GW würden noch zusätzliche Fallunterscheidungen erfordern. Eine Angabe der Leistung als Zahl in MW ohne Einheit wäre für den Mapper allenfalls ein minimaler Umrechnungsaufwand und für jede Auswertung deutlich einfacher. "maxheight", "maxspeed", etc. werden nur als Zahlen geschrieben, "maxweight" wird in Tonnen (Megagramm) und nicht in der SI-Einheit "kg" benutzt. Somit würde auch "generator:output:*" als Wert in MW gut passen. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
