Re: [Talk-de] OSM Toolchain Mapnik2 in einfach
On Wed, May 02, 2012 at 12:43:58PM +0200, oliver...@naumann-clan.de wrote: > Die sqlite Pakete sind der Grund, warum ich Mobac > nutze. Der macht in der Einstellung RMap solche Pakete. Ich kenn leider > keine Möglichkeit, diese anders zu erzeugen. "generate_tiles.py" macht > ja sicher nur einzelne Bildateien, oder? Du kennst die Vektorkarten fuer Locus? http://www.vectormaps4locus.eu/ Klar, sieht gerendert etwas anders aus, ist aber viel einfacher. Ich hab die Daten von Bayern und Oesterreich drauf, und lass mir die Tiles on-the-fly rendern. Hat den grossen Vorteil, dass ich vorher nicht wissen muss, welche Tiles in welcher Zoomstufe ich brauche. Mobac benutz ich seitdem kaum noch... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
Am Thu, 14 Jul 2011 23:53:24 +0200 schrieb Henning Scholland : > Ich halte von sowas nicht viel. Das müllt doch nur die DB zu und > macht das taggen unübersichtlich. > > Entweder in einer Region gibt es Mapper, die sich um die > Aktuellhaltung der Daten kümmern oder es gibt sie nicht. Gibt es sie, > dann brauchen diese keine Infos darüber, wann sie das letzte mal > überprüft haben, ob das Objekt noch da ist oder nicht. Gibt es keine > Mapper, gibt es auch keinen, der die Aktualisierung vornimmt. Ergo > ist auch kein Tag nötig, dass den Bedarf anzeigt. > +1 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Josm hat ne Macke
Am Tue, 12 Jul 2011 19:59:22 +0200 schrieb Steffen Heinz : > > Was ist den an der Windows 7 Suchfunktion kaputt ? > ne, durchsucht aber lange nicht alles, mit der Suchfunktion habe ichs > jedenfalls nicht gefunden grepwin ist dein Freund ;-) signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sachen nicht mappen um sie zu schützen? (archaeological_site)
Am Samstag 05 März 2011, 15:06:05 schrieb Frederik Ramm: > Hallo, > > Guenther Meyer wrote: > > Sehr schoen. Legitimiert das auch, dass ich Daten loesche, von denen ich > > persoenlich denke, dass sie aus moralischen Gruenden nichts in OSM zu > > suchen haben? Es lebe die Zensur! > > Siehst Du, das ist genau das, worum es hier *nicht* geht. Es geht hier > nicht um eine zentrale Instanz, die vorgibt, was "legitim" ist und was > nicht, und der einzelne darf dann einfach der Botschaft folgen, ohne > selbst Verantwortung zu uebernehmen. > > Niemand "legitimiert" irgendwas, was Du tust. Wenn Dein Gewissen Dich > zwingt, irgendetwas zu loeschen, was jemand anders eingetragen hat, dann > tu das - aber Du musst dann eben auch die Verantwortung fuer die > Konsequenzen uebernehmen und kannst nicht sagen: "Es wurde doch aber auf > der Liste gesagt, dass das legitim ist..." Genau hier ist aber das Problem: Wenn irgendwo auf der Liste oder im Wiki geschrieben steht "dieses oder jenes sollte nicht getaggt werden, weil es koennte ja missbraucht werden", finden sich mit Sicherheit einige Leute, die Daten loeschen, weil sie glauben, diese koennten doch fuer boese Zwecke genutzt werden. Und genau das will ICH nicht! Weder bei "meinen", noch den von jemand anderem eingetragen Daten. 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] Sachen nicht mappen um sie zu schützen? (archaeological_site)
Am Samstag 05 März 2011, 11:27:35 schrieb Frederik Ramm:
> Hallo,
>
> UMAX974 wrote:
> > Es ist und bleibt in
> > der Verantwortung des einzelnen Mappers, wie auch Wissenschaftlers
> > eine Folgeabschätzung durchzuführen und dem entsprechend zu handeln.
>
> Ich denke, dass das spaetestens seit dem "Manhattan Project" auch den
> Wissenschaftlern klar ist. So einfach es waere, wenn man sich aus jeder
> moralischen Verantwortung heruashalten koennte ("ich forsche hier nur an
> Kernspaltung, was andere damit machen, liegt nicht in meinem
> Einflussbereich" - "ich mappe nur die Fakten vor Ort, und was andere
> damit machen, liegt nicht in meinem Einflussbereich"), das Recht dazu
> haette maximal der geistig Minderbemittelte, der diese Konsequenzen
> *tatsaechlich* nicht sieht.
>
> Ich stimme Henning zu, wenn er sagt: "Ob ich etwas eintrage, entscheide
> ich." - ich finde es sogar sehr wichtig, klarzumachen, dass (in weiten
> Grenzen!) bei uns wirklich der einzelne entscheidet und nicht irgendeine
> Vorschrift - bloss passt das Wernher-von-Braun-Zitat eben gerade nicht
> dazu, denn mit der Entscheidung, ob man etwas eintraegt oder nicht,
> uebernimmt man auch persoenlich die moralische Verantwortung fuer die
> Konsequenzen. Man kann sich eben gerade nicht darauf berufen, dass man
> ja nur das "uebliche" oder gar das "vorgeschriebene" getan habe.
Sehr schoen. Legitimiert das auch, dass ich Daten loesche, von denen ich
persoenlich denke, dass sie aus moralischen Gruenden nichts in OSM zu suchen
haben? Es lebe die Zensur!
Wenn ich irgendwelche Objekte NICHT eintrage, weil ich sie fuer nicht
nuetzlich oder sogar gefaehrlich halte, dann ist durchaus eine gewisse
Wahrscheinlichkeit gegeben, dass es irgendwann jemand anders tut - die Fakten
vor Ort sind ja schliesslich vorhanden.
Ausserdem:
Wenn sich jemand wirklich unbedingt als z.B. "Grabraeuber" betaetigen will,
dann kommt er auch ohne OSM an sein Ziel.
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] Anmeldeprozedur
Am Samstag 22 Januar 2011, 12:47:23 schrieb Markus: > Die Anmeldeprozedur für OSM ist bereits sehr benutzerfreundlich. > > In der Praxis (Einführungsworkshop mit 30 TN) bin ich auf zwei Dinge > gestossen, die man vielleicht noch besser machen könnte: > > _Lizenzbedingung_ > Hier muss man wählen zwischen Frankreich, Italien und "Rest der Welt". > Entsprechend erscheint der Text in Französisch, Italienisch, Englisch. > > Die meisten Benutzer in Europa kommen aber aus DE, AT, CH und sprechen > Deutsch. Hier sollte man unbedingt Deutsch als Sprache anbieten. > Besser als die Frage nach dem "Wohnsitz" wäre eine Auswahl der Sprachen. > > Beanstandet wurde auch, dass PD zu unscheinbar erscheint > und nicht als "default" vorgesehen ist. > > Vorgeschlagen wurde: > - je eine Zeile für die beiden Lizenzen PD und ODbL/CC-BY-SA, > - beide default, PD abwählbar, -1 ersteres sind die bestehenden bzw. wahrscheinlich zukuenftigen Lizenzen fuer das Projekt, PD nicht. PD anbieten meinetwegen ja, aber als Defaulteinstellung nicht angewaehlt. > - zu beiden je einen Link zu einem aufklappenden ganzen Text in der oben > gewählten Sprache (jeweils mindestens en, de). +1 > Begründung war: PD sei viel freier als die anderen Lizenzen, und deshalb > als Standard zu bevorzugen. Einige denken so, einige denken anders. Eine Diskussion zu dem Thema wird auch nie zu einem eindeutigen Erbegnis kommen... > *Bevorzugte Sprachen*: da steht "de-DE,de,en-US,en". > Eine kurze Info über die Bedeutung könnte helfen, die Unterschiede der > Kürzel zu verstehen. Man koennte auch stattdessen die Languebersetzung der entsprechenden Einstellung anzeigen, so wie es z.B. verschiedene Programme oder Betriebssysteme bei der Installation auch machen. > *Bevorzugter Editor*: Da steht "Standard (derzeit Potlatch 1)" > Hier könnte man noch einen Hilfetext hinzufügen, in dem erklärt wird was > das bedeutet, bzw. was die anderen Alternativen bedeuten. +1 zuviel Info koennte die Leute aber auch verwirren... 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] Bundeswehr mappen?
Am Samstag 04 Dezember 2010, 10:26:28 schrieb Falk Zscheile: > [1] http://www.gesetze-im-internet.de/stgb/__109g.html > Was fuer ein daemliches Gesetz: "...und dadurch wissentlich die Sicherheit der Bundesrepublik Deutschland oder die Schlagkraft der Truppe gefährdet..." Und das heisst jetzt was? Je nach Richter kann das wohl alles oder nichts sein... Kam es schon mal vor, dass Google, Microsoft oder deren Datenlieferanten Probleme deshalb bekamen, weiss da jemand was? Oder haben die sich explizit die Erlaubnis geholt? Falls letzteres, sehe ich da kein Problem fuer OSM, wenn wir die Bing-Bilder nutzen duerfen; schliesslich kann man beim Abmalen schlecht mehr Information einbauen, als bereits aus dem Luftbild ersichtlich ist... 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] Pumpwerk der Entsorgung
On Tue, Nov 16, 2010 at 08:53:41AM +0100, Andreas Labres wrote: > On 16.11.10 08:14, Guenther Meyer wrote: > > type = sewer > > Ich bin jetzt im Englischen auch nicht sooo fit, aber für mein Gefühl ist > sewer > eher das einzelne Abflussrohr, der Abwasserkanal, während "das Abwasser" (als > Kategorie) IMO eher "sewage" heißt. > Haette ich eigentlich auch gesagt. Da aber fuer pipeline wohl bereits sewer benutzt wird, hatte ich das vorgeschlagen. Man muss ja nicht alles neu erfinden... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pumpwerk der Entsorgung
Am Montag 15 November 2010, 21:37:07 schrieb Ulf Lamping: > Dann könnte man sich aber vielleicht besser ein man_made=pump_station > ausdenken, das alle möglichen Arten von solchen Pumpstationen enthält, > sei es Wasser, Gas oder was auch immer sonst. Mit einem weiteren Tag > wäre dann (ähnlich wie bei man_made=pipeline) das zu transportierende > Material zu taggen. Schon hätte man ein Tag was klar beschreibt worum es > geht und dennoch recht breit verwendbar wäre. > +1 das wuerde dann folgendes ergeben: man_made = pump_station type = sewer Bitte keine Aufweichung bereits existierender und klar definierter Tags! 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] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 19:56:54 schrieb Karl Eichwalder: > Bernd Wurst writes: > > Also klar, ein paar Ausnahmen gibt es: "name", "comment", solche Dinge, > > die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder > > Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. > > Manche dinge haben allerdings zwei doer mehr namen; standardbeispiel: > straße auf einer brücke. Das können wir so ohne weiteres nicht > abbilden. name:highway = foo name:bridge = bar 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] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 19:47:58 schrieb Jochen Topf: > Ganz absurd wird es, wenn es wie im aktuellen healthcare-Vorschlag einen > Tag "specialty" gibt, der die Art des Mediziners angeben soll, um den es > hier geht. das kann ich jetzt gar nicht nachvollziehen... > Aber wenn ich das wiederverwenden will, z.B. mit > "specialty=italian" an einem Restaurant oder "specialty=football" bei > einem Sportverein. Dann habe ich total verschiedene Dinge miteinander > vermischt. > Will ich jetzt im Editor eine Auswahlbox einbauen, die mir eine > Auswahl der wichtigsten Werte erlaubt, dann muss ich berücksichtigen, ob > ein "heathcare", "restaurant" oder "sports"-Tag zusätzlich hier dran ist. Ja, und? kontextabhaengige Menues sind nichts besonderes. > Schau ich eine Statistik der Werte an, finde ich alle möglichen wild > durcheinander. Das Wort "speciality" ist zu generisch, es sagt eigentlich > nichts aus, außer dass hier eine hierarchische Unterordnung stattfinden > will. das ist doch eine Aussage?! > Es wird niemals Sinn machen, die "specialty"-Fälle von healthcare > und restaurant zusammen zu betrachten, so wie man z.B. im Falle von "name" > gerne eine gemeinsame Suche hätte, sodass man nach Straßennamen und dem > Namen von Medizinern suchen kann. und deswegen soll man nicht dasselbe Tag verwenden duerfen? Betrachte specialty als generisches Tag, das einfach als genauere Spezifizierung des Haupttags benutzt wird. Das ist besser und v.a. einfacher, als fuer jede einfache Spezifizierung einen neuen Key zu erfinden... Ich muss da Martin vollstaendig recht geben: "So speziell wie noetig, aber so generisch wie moeglich." > Natürlich gibt es hier keine perfekte Definition, wie man diese Fälle > auseinanderhalten kann. Es gibt eher einen fließenden Übergang. Vielleicht > will man einer Brücke einen anderen Namen geben als der Straße darauf, > dann wäre ein bridge_name nicht schlecht. Sollte so ein Fall noetig sein, dann wuerde ich dafuer name:bridge bzw. name:street nehmen. Denn in erster Linie ist es immer noch ein Name wie jeder andere auch - der halt in diesem speziellen Fall fuer einen bestimmten Teil des Objekts gilt. > Hier hilft es auch, sich zu > überlegen, was denn der typische, häufige Fall ist und was eher ein > Spezialfall. Bei Namen will man sicher auch mal Namen bestimmter Objekte > auf verschiedene Arten schreiben. Aber notfalls reicht es eben, alle > gleich zu schreiben. Bei einem ref glaube ich da schon weniger dran. Ich > will sicher keine Bushaltestellen-Bezeichner haben, die aussehen wie die > typischen Straßensymbole (highway shields). Der einfache Fall sollte > einfach sein (also vorallem nicht die Kombination mehrerer Tags > erfordern), Spezialfälle aber durchaus. Bei ref macht eine Unterscheidung wesentlich mehr Sinn, als bei name, ja. Aber auch hier kann man die Bedeutung des Tags in den meisten Faellen vom Kontext ableiten. Fuer Spezialfaelle kann man immer noch sowas wie ref:highway bzw. ref:bridge verwenden. 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] Healthcare-Proposal
Am Sonntag 31 Oktober 2010, 21:57:51 schrieb Élisée Reclus: > Also irgendwie strukturieren und sortieren musst du es für Menschen ja > in jedem Fall ab einer gewissen Anzahl möglicher Werte, da man ansonsten > den Überblick verliert. Du kannst (oder solltest) weder im Wiki noch im > JOSM-Menue (z.B.) hundert Werte untereinander haben. Warum nicht also > schon eine Struktur im Datenformat abbilden? +1 > Ein (neuer) Mapper könnte außerdem, wenn er die Werte nicht nachschlagen > kann oder will, schonmal „healthcare=yes“ mit „fixme=*“ mappen. oder er kann, falls er was neues findet, wofuer es noch kein Tag gibt, dieses Objekt als healthcare = xyeinrichtung taggen, und man weiss sofort, dass es hier um eine Gesundheitseinrichtung handelt. waere ja nicht so, dass aehnliches nicht schon mal vorgeschlagen wurde... ;-) 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] Geofabrik-Downloads jetzt als Binaerformat
Am Freitag 29 Oktober 2010, 08:28:55 schrieb Frederik Ramm: > Uebertreibst Du da nicht ein bisschen? Ok, einige benutzen vielleicht > wirklich irgendeine bz2-Lese-Library, aber die meisten, die nicht direkt > Osmosis oder osm2pgsql einsetzen, werden doch derzeit in irgendeiner > Form ein "bunzip2 extract.osm.bz2 | meintollesprogramm" machen. Und die > machen halt kuenftig "pbf2osm extract.osm.pbf | meintollesprogramm". > Wobei sich die Laufzeit natuerlich drastisch reduzieren laesst, wenn man > dem "meintollesprogramm" das Binaer-Lesen direkt beibringt, damit spart > man naemlich das XML-Parsen. > Ich steh zwar auch nicht so auf Binaerformate, aber wenn dadurch die Verarbeitungsgeschwindigkeit inkl. Datentransfer signifikant zunimmt, ist das sicher eine gute Sache - grade bei den Mengen an Daten, die bei OSM anfallen. Ausserdem ist das Format im Gegensatz zu vielen anderen binaeren Formaten dokumentiert und frei erhaeltlich. > Allerdings richte ich mich mit den Geofabrik-Extrakten eher an die > Community - an diejenigen, die die Daten irgendwie auf eine von mir > nicht vorbestimmte Art weiterverarbeiten. Deswegen biete ich diese > verlustbehafteten Optionen nicht an, weil das die Daten fuer einige > Zwecke untauglich machen wuerde. Eine zweite gestrippte Version bereitzustellen waere wohl zuviel verlangt, oder ;-) > Das ist mir nicht recht - wie gesagt, das ganze ist von mir als > ein Service fuer die Community gedacht und nicht als allgemeiner > OSM-Downloadserver fuer die breite Masse. Wer den Anwendern seiner > Software sowas anbieten will, der sollte selbst Extrakte berechnen und > dabei eben auch die oben erwaehnte Filterung unnoetiger Daten einbauen. +1 Danke uebrigens, dass du die Daten ueberhaupt in der Form zur Verfuegung stellst! > Auf keinen Fall sollte Software an Endanwender verteilt werden, in die > irgendwelche Geofabrik-Downloadlinks fest eingebaut sind, denn es kann > durchaus sein, dass ich die Pfad-Struktur oder die Datenformate aendere. > Es kann sogar sein, dass ich das voellig unnoetig und absichtlich mal > mache ;) Es waere aber nett, wenn du das fuer den Fall des Falles wenigstens auf der dev-Liste ankuendigst - waere ja schade, wenn durch nicht mehr funktionierende Nichtendanwendersoftware die Nutzung von OSM-Daten behindert wuerde ;-) 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] ***SPAM(-1.4)*** Re: Portal Vorschlag (Was: Re: OSM quo vadis)
Am Sonntag 24 Oktober 2010, 19:44:39 schrieb Peter Wendorff: > Das ganze ist zu sehen unter http://jugglingsource.de/osm/portal.html > und wenn man es noch etwas kompakter machen wuerde? http://www.sordidmusic.com/osm/osm-portal.png 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] Portal Vorschlag (Was: Re: OSM quo vadis)
Am Sonntag 24 Oktober 2010, 12:35:02 schrieb Sebastian Hohmann: > Am 23.10.2010 20:10, schrieb Guenther Meyer: > > Deshalb braucht es eine Portalseite, die eben KEINE grosse Slippymap > > direkt zeigt; denn das weckt bei den Usern falsche Erwartungen. > > Analog zu den vorherigen Vorschlägen[1][2] habe ich mal eine Portalseite > gebastelt: ein paar Kleinigkeiten wuerde ich noch anpassen, aber prinzipiell sehr schoen! 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] OSM quo vadis
Am Samstag 23 Oktober 2010, 01:39:27 schrieb Ulf Lamping: > Am 22.10.2010 23:00, schrieb Frederik Ramm: > > Ich fuehre als Beispiel mal MapOsMatic an. Das ist doch ein > > Super-Service, den die da gebaut haben, und das ganz ohne dass > > irgendjemand rumgejammert haette "wir brauchen bessere PDF-Stadtplaene > > auf osm.org". Sowas kann und soll ruhig ausserhalb von osm.org gemacht > > werden - damit demonstieren wir naemlich etwas ganz wesentliches: Mit > > unseren Daten kann *jeder* coole Services bauen, nicht bloss die 5 > > Admins, die auf osm.org das Sagen haben! > > Und weil es irgendwo einen Service gibt der sowas kann, können wir die > Karte auf osm.org ruhig langsam versauern lassen? Genau das waere der falsche Weg. Wenn wir schon eine Slippymap anbieten (was wir auf jeden Fall tun sollten), dann sollte diese auch gepflegt werden. > Es wird immer Services geben, die Sachen besser können als osm.org, sei > es für bestimmte Benutzergruppen, Einfachheit der Bedienung, Schönheit > oder was weiß ich. Da sollten wir "unseren Nutzern" helfen diese Sachen > besser finden zu können. +1 Deshalb braucht es eine Portalseite, die eben KEINE grosse Slippymap direkt zeigt; denn das weckt bei den Usern falsche Erwartungen. Um mal beim gerne genannten Google-Vergleich zu bleiben: hat Google die Karte auf der Portalseite? Nein, denn die ist nur eine von vielen Anwendungen, die Google anbietet, und auf maps.google.de gut aufgehoben und auch gut zu finden. Andere Anwendungen finden sich auf anderen Subdomains. OSM ist vielleicht nicht so breit gefaechert wie Google, aber auch wir haben verschiedene Bereiche - die Slippymap ist nur einer davon. Warum sollte man also nicht die Bereiche entsprechend aufteilen, und die Seite www.openstreetmap.org wirklich als Portal sehen, die das Projekt ansprechend und kurz vorstellt, und die wichtigsten Bereiche direkt verlinkt (Die bisher vorgeschlagenen Layouts sind nicht mal soo schlecht.). Dadurch sehen Neulinge gleich, dass OSM nicht nur eine Slippymap mit etwas drumrum ist, sondern wesentlich mehr. Und wer sich wirklich nur fuer die Slippymap interessiert, kann sich (analog zu Google) problemlos die URL map.openstreetmap.org merken bzw. speichern. 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] Energiequelle bei Elektrotankstellen
Am Dienstag 12 Oktober 2010, 23:44:34 schrieb Ulf Lamping: > Wieso wird hier lang und breit drüber diskutiert, daß Elektrotankstellen > keine Tankstellen sind (z.B. ist ein Akku kein Tank!), und dann kommt > wenig später die nächste Träne und kommt mit der gleichen Geschichte > wieder an? Das macht echt keinen Spaß. weil das bei OSM so ueblich ist, dass dieselben Themen wieder und wieder aufgewaermt werden. ;-) Das mag einerseits daran liegen dass das Ergebnis nicht immer das Gelbe vom Ei ist und jemand einen besseren Vorschlag einbringt, oder (was in dem meisten Faellen wahrscheinlicher ist) es nicht gut dokumentiert/nicht zu finden ist. > Man tankt keinen Strom und Strom ist kein fuel (=Brennstoff). Auch wenn > euch das die Werbefuzzies was anderes weismachen wollen. Ohne das ganze wieder aufwaermen zu wollen: Es gibt auch Leute, die anderer Meinung sind, und das sind nicht wenige... Ende des Themas. 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] api-download bei semikon-getrennten-values
Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: > Ich hatte schon vor einiger Zeit mal angemerkt, daß die Sache mit dem > Semikolon so eine Sache ist ;-) das liegt aber meist nicht am Semikolon selbst, sondern an den Anwendungen, die das nicht verstehen (wollen)... > Wenn du ein amenity=pub;cafe einträgst, ist die Wahrscheinlichkeit sehr > hoch, das keiner der Renderer so ein "Haupttag" findet. Ich erwarte > nicht, das sich das in Zukunft großartig ändern wird. bloed nur, dass sich sowas nicht anders darstellen laesst. > Wenn du ein "Zusatztag" wie brand=Suzuki;Honda einträgst (das zusätzlich > zu einem "Haupttag" verwendet wird), werden das viele Renderer > vielleicht auch nicht auswerten können - ist aber hier erstmal kein so > richtig großer Beinbruch. Ein Renderer sucht aber eh erstmal nach sowas > wie shop=motorcycle, und weiß dann (bei Interesse), wie mit brand > umzugehen ist. > > Kommt also auf den "Tag-Einzelfall" an. Ob's jetzt in einem "Haupttag" vorkommt oder in einem "Zusatztag" ist relativ egal; je nach Anwendung kann beides leichter oder schwieriger auszuwerten sein... > Es ist gut eine Regel zu haben, wie man mit mehreren Werten in einem Tag > umgeht (sowas bei jedem Tag anders zu lösen macht ja keinen Sinn). +1 > Es ist aber nicht so gut zu glauben das die Renderer alle möglichen > Kombinationen schon irgendwie/irgendwo/irgendwann "schlucken" werden. > Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache > ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Das ist auch ganz unabhaengig davon, um welches Tag oder welche Kombinationen es sich handelt. Es stellt sich nur die Frage, tut man's oder tut man's nicht. 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] Zeilenumbruch in "name"?
Am Donnerstag 07 Oktober 2010, 10:41:46 schrieb Peter Wendorff: > On 06.10.2010 23:28, Guenther Meyer wrote: > > Am Mittwoch 06 Oktober 2010, 16:23:55 schrieb Peter Wendorff: > >>On 06.10.2010 15:09, Guenther Meyer wrote: > >>>> Außerdem wäre zu > >>>> überlegen, ob eine Regel in der Art "bevorzugt an Leerzeichen nach > >>>> Doppelpunkten umbrechen" nicht schon das gewünschte Resultat bringen > >>>> würde, oder ob es da nachteilige Nebenwirkungen gäbe. > >>> > >>> Das ist ein guter Ansatz, der aber nicht immer nutzbar ist. > >> > >> Gegenbeispiele bitte! > > > > Eine lange Bezeichnung in dem kein Doppelpunkt vorkommt!? > > Beispiele wurden ja schon genannt. > > Eine lange Bezeichnung, die kein Doppelpunkt, kein Leerzeichen und > keinen Bindestrich enthält, denn das sind IMHO stellen, an denen > Umbrüche möglich sein sollten. > > Um dein Argument zu entkräften, Beispiele seien schon genannt worden, > hier nochmal alle bisher aufgekommenen Beispiele im Schnelldurchlauf: > > Haus 49: Sekundarschule Augus Hermann Francke > ist mittlerweile von jemandem umbenannt worden, das Leerzeichen vor 49 > wurde entfernt, Also "Haus49"? Nicht schoen... Ansonsten: Wenn die Regel lautet: " Trenne bevorzugt bei Leerzeichen nach Doppelpunkten oder Kommas, und erst dann schau dir andere Moeglichkeiten an", Dann wird das wohl meistens so funktionieren, wie du beschreibst. > In allen Fällen kann und sollte man das trennen und trennen können. > Möglich wäre z.B. operator="universität X" name="institut y" Das halte ich prinzipiell auch fuer die beste Methode. Nur leider wird das erstens selten so gemacht, und ist zweitens auch nicht immer anwendbar. Was machst du z.B. mit "Jugendbildungsstätte der KAB und CAJ gGmbH und für den Bezirk Oberpfalz" Da waere doch ein Hinweis was zusammengehoert fuer den Renderer schon ganz nuetzlich, damit er es nicht ganz zerreisst, oder? Das Ding heisst offiziell uebrigens wirklich so... > Alternativ kommen für diese Dinge sonst auch Relationen in Frage. -1 das ist definitiv das falsche Mittel! 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] Zeilenumbruch in "name"?
Am Donnerstag 07 Oktober 2010, 11:26:05 schrieb Wolfgang: > Hallo, > > Am Mittwoch 06 Oktober 2010 13:51:58 schrieb Guenther Meyer: > > hier ein fiktives Beispiel: > > name = Kartographie- und Datenamt Musterstadt Aussenstelle Nord-West II > > > > Hier bricht man sinnvollerweise nach dem Ort um, falls noetig. Nur wie > > soll ohne Hinweis ein Renderer das wissen? Den Kontext versteht er > > nicht... > > name:umbruch:before=Aussen ? > > Lässt das name-tag unverändert, passt sich ggf einer Änderung auf > "Kartografie" an, stört nicht und kann ausgewertet werden. Warum muss das alles immer so komplizert gemacht werden?!? Das benutzt doch keiner... 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] Zeilenumbruch in "name"?
Am Donnerstag 07 Oktober 2010, 18:35:49 schrieb Heiko Jacobs: > Am 07.10.2010 18:24, schrieb Heiko Jacobs: > > Ähnliches gilt für > > ... wobei der nur im Wort gilt. Ob es sowas auch für bevorzugt > umzubrechende Leerzeichen gibt, weiß ich nicht, müsste man mal > den Unicode durchdtöbern, da sind etliche Nettigkeiten drin ... > nicht dass ich wuesste. > ist insofern nur bedingt brauchbar, als dass er weitere > Trennungen verhindern würde bei Bedarf ... naja, wenn alle Leerzeichen ausser denen, wo ein Umbruch stattfinden darf, durch s ersetzt werden, hast du genau den gewuenschten Effekt. > Sprich: man könnte A B C D mit nbsp in > A B > C D > trennen lassen, aber wenn's so eng würde, dass man's gerne > vierzeilig rendern täte, stünde man dumm da mit dem nbsp ... > Das ist dann Sache des Renderers. Wenn ihm die vorhandenen Trennmoeglichkeiten nicht ausreichen, dann muss er halt auch die eher nicht gewuenschten hinzuziehen. 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] Zeilenumbruch in "name"?
Am Mittwoch 06 Oktober 2010, 23:54:35 schrieb Ulf Lamping: > Am 06.10.2010 23:35, schrieb Guenther Meyer: > > Am Mittwoch 06 Oktober 2010, 15:57:06 schrieb Christian H. Bruhn: > >> Es gibt einige Tags [2] speziell für Osmarender, die direkt das > >> Renderergebnis beeinflussen. Wenn überhaupt sollte man höchstens an so > >> etwas denken. > > > > -1 > > keine Spezialtags fuer irgendeine spezielle Software! > > +1 > > Allerdings denke ich da eher an sowas wie name="plain text" (für die > bisherige "raw" Form) und name:line_wrapped="plaintext" (oder wie > auch immer) für spezielle Formatierungshinweise. Wozu? Das macht doch alles nur unnoetig kompliziert. Statt einem normalen Leerzeichen benutzt man an den entsprechenden Stellen einfach ein "geschuetztes Leerzeichen". > >> 'name' sollte dafür nicht mißbrauchen. Es würden wohl auch nur wenige > >> Mapper einen Zeilenumbruch im Namen einfügen. > > > > das ist kein Missbrauch. > > Jein. Führt aber aller Vorraussicht nach zu allen möglichen Problemen. zum Beispiel? > > Und wer's nicht eintragen will, traegt's halt nicht ein. Das soll aber > > den anderen nicht die Moeglichkeit nehmen, sinnvolle Informationen > > einzutragen... > > Sehe ich ähnlich. Sollte aber *zusätzlich* zu den bisherig üblichen > Infos eingetragen werden, nicht anstelle von. s.o. > >> Wenn Du dann eine Karte hast, in der die Zeilenumbrüche dort sind, wo > >> Du sie für richtig hältst, kann es natürlich sein, daß ein zweiter > >> anderer Meinung ist und die Darstellung anders haben möchte. > > > > Es ist ein Unterschied, ob man eine bestimmte Darstellung fuer ein > > bestimmes Renderering in einer bestimmten Schriftart und -groesse zu > > erzwingen versucht, oder ob man der Software einen Hinweis gibt, welche > > Teile des Namens sinngemaess zusammengehoeren und auch besser > > entprechend dargestellt werden sollten. > > Klingt jetzt für mich so, das Mapper diese "nicht Trennzeichen" an einer > bestimmten Stelle eintragen, weil es bei einem bestimmten Renderer dort > so paßt, beim anderen Renderer aber leider dann wieder nicht. Die Gefahr dieses Missbrauchs besteht immer, ist auch nix neues bei OSM. Ich finde das aber weniger schlimm, als Schiessplatzbeestandteile als Sessellifte zu taggen ;-) Abgesehen davon: Ich gehe davon aus, dass *wenn* Renderer das auswerten, meist was vernuenftiges bei rauskommt, waehrend das bei einem Renderer,der sich nicht dafuer interessiert, sowieso keinen Unterschied macht. 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] Zeilenumbruch in "name"?
Am Mittwoch 06 Oktober 2010, 15:57:06 schrieb Christian H. Bruhn: > Es gibt einige Tags [2] speziell für Osmarender, die direkt das > Renderergebnis beeinflussen. Wenn überhaupt sollte man höchstens an so > etwas denken. -1 keine Spezialtags fuer irgendeine spezielle Software! > 'name' sollte dafür nicht mißbrauchen. Es würden wohl auch nur wenige > Mapper einen Zeilenumbruch im Namen einfügen. das ist kein Missbrauch. Und wer's nicht eintragen will, traegt's halt nicht ein. Das soll aber den anderen nicht die Moeglichkeit nehmen, sinnvolle Informationen einzutragen... > Wenn Du dann eine Karte hast, in der die Zeilenumbrüche dort sind, wo > Du sie für richtig hältst, kann es natürlich sein, daß ein zweiter > anderer Meinung ist und die Darstellung anders haben möchte. Es ist ein Unterschied, ob man eine bestimmte Darstellung fuer ein bestimmes Renderering in einer bestimmten Schriftart und -groesse zu erzwingen versucht, oder ob man der Software einen Hinweis gibt, welche Teile des Namens sinngemaess zusammengehoeren und auch besser entprechend dargestellt werden sollten. 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] Zeilenumbruch in "name"?
Am Mittwoch 06 Oktober 2010, 16:23:55 schrieb Peter Wendorff: > On 06.10.2010 15:09, Guenther Meyer wrote: > >> Außerdem wäre zu > >> überlegen, ob eine Regel in der Art "bevorzugt an Leerzeichen nach > >> Doppelpunkten umbrechen" nicht schon das gewünschte Resultat bringen > >> würde, oder ob es da nachteilige Nebenwirkungen gäbe. > > > > Das ist ein guter Ansatz, der aber nicht immer nutzbar ist. > > Gegenbeispiele bitte! Eine lange Bezeichnung in dem kein Doppelpunkt vorkommt!? Beispiele wurden ja schon genannt. 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] Zeilenumbruch in "name"?
Am Mittwoch 06 Oktober 2010, 16:17:58 schrieb Peter Wendorff: > On 06.10.2010 13:51, Guenther Meyer wrote: > > Am Mittwoch 06 Oktober 2010, 13:13:28 schrieb Peter Wendorff: > >> Selbst, wenn dies nur aus Platzgründen geschieht: Welcher Platz ist denn > >> verfügbar? Reicht dein Soll-Umbruch aus? Muss es eventuell noch schmaler > >> werden? > > > > das weiss nur der Renderer. > > Aber wenn er umbrechen muss, dann kann er es erstmal an der gewuenschten > > Stelle versuchen, bevor er sich selber irgendeine brauchbare Stelle > > sucht. > > Nein: Stellen, an denen NICHT umgebrochen werden soll, wenn es IRGENDWIE > vermeidbar ist, sollten entsprechend markiert werden, nicht andersherum. ob so oder so rum ist doch eigentlich egal, der Zweck bleibt derselbe; ... > Eine Lösung dafür hast Du ja selbst schon geschrieben. ...diese Methode hat sich halt schon woanders etabliert und als sinnvoll erwiesen. 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] Zeilenumbruch in "name"?
Am Mittwoch 06 Oktober 2010, 14:46:14 schrieb Tobias Knerr: > Render-Hints (oder Hilfestellungen für andere Arten von Anwendungen) > sind an sich ein kontroverses Thema. Mindestanforderung an so etwas ist > aber in meinen Augen: > > 1. Es darf keine Konflikte mit etablierten Tags und anderen > Anwendungsmöglichkeiten der Daten erzeugen. das haengt davon ab, wie man es loest. Zumindest mit Unicode-Zeichen sollten alla Anwendungen umgehen koennen. > 2. Wenn eine bessere Anwendung auch mit den existierenden Daten auskäme, > hat es in der Datenbank nichts zu suchen, sondern es müssen die > Anwendungen verbessert werden. Eine Anwendung kann nicht alles wissen, warum soll man ihr bekannte und hilfreiche Informationen nicht zur Verfuegung stellen? > 3. Es muss von allgemeinem Nutzen sein, also nicht nur für eine einzige > Anwendung/Schriftgröße/Auflösung/... gelten. Ein Hinweis "hier sollst du bevorzugt umbrechen, falls noetig" oder "hier nach Moeglichkeit nicht umbrechen" oder sematisch ausgedrueckt "dieser Bereich gehoert zusammen" *ist* allgemein sinnvoll... > Für den vorliegenden Fall heißt das unter anderem, dass auf keinen Fall > das name-Tag selbst mit solchen Hinweisen angereichert werden, sondern > ein neu zu erfindendes Tag verwendet werden sollte. ... und ist Teil der Textinformation selbst; in einem zweiten Tag also nicht wirklich sinnvoll. > Außerdem wäre zu > überlegen, ob eine Regel in der Art "bevorzugt an Leerzeichen nach > Doppelpunkten umbrechen" nicht schon das gewünschte Resultat bringen > würde, oder ob es da nachteilige Nebenwirkungen gäbe. Das ist ein guter Ansatz, der aber nicht immer nutzbar ist. 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] Zeilenumbruch in "name"?
Am Mittwoch 06 Oktober 2010, 13:49:29 schrieb Elstermann, Mike: > > Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll > > ist - aber bitte schreibt doch einfach welche ;) > > Hab ich schon in der ersten Anfrage: > Siehe hier Bsp. 1: > "Beispiel: > http://www.openstreetmap.org/?lat=51.477066&lon=11.97303&zoom=18&layers=M > " SO ist wohl nicht glücklich. > > Bsp. 2: Und SO auch nicht: > http://www.openstreetmap.org/?lat=51.47707&lon=11.97303&zoom=17&layers=O ich wusste, dass es reale Bespiele gibt ;-) > Das Leerzeichen als Kennzeichen eines möglichen Umbruchs ist > definitiv zu wenig! Z.B. "Haus33: Spielehaus" - besser wäre "Haus > 33:Spielehaus" Ein Leerzeichen, bei dem nicht umgebrochen werden darf, gibt's in Unicode unter U+00A0 (in HTML bekannt als ). Dann muesste man hierfuer zumindest nicht das Rad neu erfinden; stellt sich nur noch die Frage, wie man das im Editor eingibt... 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] Zeilenumbruch in "name"?
Am Mittwoch 06 Oktober 2010, 13:13:28 schrieb Peter Wendorff: > > Es kann durchaus sinnvoll sein, wenn man einer Anwendung mitteilen kann > > "Falls du umbrechen musst, dann mach's bevorzugt an dieser Stelle!". > > Mit welchen Randbedingungen denn? > Warum bricht eine Anwendung um? > Selbst, wenn dies nur aus Platzgründen geschieht: Welcher Platz ist denn > verfügbar? Reicht dein Soll-Umbruch aus? Muss es eventuell noch schmaler > werden? das weiss nur der Renderer. Aber wenn er umbrechen muss, dann kann er es erstmal an der gewuenschten Stelle versuchen, bevor er sich selber irgendeine brauchbare Stelle sucht. > Außerdem fällt mir kein Anwendungsbeispiel ein, wo das wirklich sinnvoll > ist - aber bitte schreibt doch einfach welche ;) hier ein fiktives Beispiel: name = Kartographie- und Datenamt Musterstadt Aussenstelle Nord-West II Hier bricht man sinnvollerweise nach dem Ort um, falls noetig. Nur wie soll ohne Hinweis ein Renderer das wissen? Den Kontext versteht er nicht... 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] Zeilenumbruch in "name"?
Am Mittwoch 06 Oktober 2010, 12:44:08 schrieb Peter Wendorff: > On 06.10.2010 12:02, Elstermann, Mike wrote: > Außerdem kannst Du dich nicht darauf verlassen, dass Zeilenumbrüche > genutzt werden - und allen Zeilenumbrüchen hinterherzulaufen, weil dein > Renderer die unterstützt aber eben auch fordert, ist definitiv 'ne blöde > Idee. ein Renderer der sowas fordert, macht definitiv etwas falsch. > Zeilenumbrüche in den Daten entheben keinen Renderer von der Pflicht, > selbst Zeilenumbrüche zu finden, wo keine definiert sind. > Warum also überhaupt welche angeben? > ganz einfach: damit die Anwendung sich evtl daran orientieren kann. Es kann durchaus sinnvoll sein, wenn man einer Anwendung mitteilen kann "Falls du umbrechen musst, dann mach's bevorzugt an dieser Stelle!". Im einfachsten Fall koennte man dafuer einen Zeilenumbruch verwenden. Was die jeweilige Anwendung dann daraus macht (irgendwie muss z.B. ein Renderer diese sowieso behandeln), bleibt ihr ueberlassen. 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] öffentl. Schließfächer
Am Dienstag 05 Oktober 2010, 22:29:30 schrieb Johannes Huesing: > olvagor [Mon, Oct 04, 2010 at 10:52:25AM CEST]: > [...] > > > dimensions=20x50x50 (Breite x Höhe x Tiefe in cm) > > Da wäre ich eher für Meter, analog zu maxwidth. Das "x" sieht mir auch eher > wie ein Notbehelf aus. einerseits ja, da man einen einheitliche Masseinheit hat. andererseits nein, denn die Groesse von Schliessfaechern wird sich eher selten im Meterbereich bewegen. Ausserdem ist eine Angabe von 0.20x0.50x0.50 weniger gut leserlich. 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] öffentl. Schließfächer
Am Montag 04 Oktober 2010, 10:52:25 schrieb olvagor: > Hi Jan, > > Am 04.10.2010 06:16, schrieb Jan Tappenbeck: > > auf Zingst habe ich im Öffentlichen Raum Schließfächer gesehen - frei > > zugänglich. > > > > Wie würdet Ihr diese Taggen ? > > ich hab nach kurzer Suche auch nichts gefunden, würde aber folgendes > vorschlagen: > > tourism=lockbox > fee=yes/no > dimensions=20x50x50 (Breite x Höhe x Tiefe in cm) > operator=Bla > phone= > website= > > tourism, weil Schließfächer m.E. hauptsächlich von Reisenden verwendet > werden und um amenity nicht weiter zu verschmutzen. > klingt prinzipiell gut, nur wuerde ich in diesem Fall sogar lieber amenity als Key nehmen wenn keinem was Besseres einfaellt, denn das trifft es von der Bezeichnung ziemlich gut. Schliessfaecher werden nicht nur von Touristen benutzt, z.B. auch Partygaenger und Konzertbesucher greifen gerne mal darauf zurueck... 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] Seekabel, die Zweite - IMPORT FERTIG
On Mon, Sep 27, 2010 at 12:54:37PM +0200, M∡rtin Koppenhoefer wrote: > Am 24. September 2010 20:54 schrieb RalfGesellensetter : > > Am Freitag, 24. September 2010 schrieb Heiko Jacobs: > >> tunnel=yes > > ...jedenfalls besser als > > visible=no ;) > > > auf keinen Fall, visible=no halte ich immer noch für besser als > tunnel=yes. Tunnel=yes ist komplett falsch, visible=no naja, > halbfalsch. "unsichtbar" ist es ja nicht unbedingt, andererseits sieht > man es normalerweise nicht. definiere "normalerweise"... mMn ist visible=no genauso falsch, wenn das Kabel nicht grade eingegraben ist. Es gab doch div. Vorschläge, um "untersee" > auszudrücken, Tunnel gehört da definitiv nicht dazu. > +1 Ein allgemeines Tag der Form "Verlegungsart/Verlauf" = submarine|ground|buried|aerial|... sollte das ausreichend beschreiben. Da es auch nur EINE Verlegungsart gben kann, halte ich eine Schreibweise der Form submarine = yes fuer kontraproduktiv. signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seekabel, die Zweite
Am Donnerstag 23 September 2010, 01:44:07 schrieb Garry: > Am 22.09.2010 08:28, schrieb Guenther Meyer: > >> Wenn das erwünschte Verhalten keine Änderung des Programms erfordert, > >> ist das Tag kompatibel. > > > > schon wieder jemand, der den Status Quo in Stein meisseln will, und > > keinerlei Weiterentwicklung befuerwortet... > > Bei Daten die prinzip/nutzungsbedingt in OSM nur selten überprüft werden > sollte man mit solchen > Weiterentwicklungen sparsam sein um nicht unnötig viele bereits erfasste > Daten zu verfälschen. > tja, mit einer Versionierung haette man solche Probleme nicht... 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] OT: Javascript ist boese (war: Wi e trage ich folgendes ein?)
Am Mittwoch 22 September 2010, 15:04:02 schrieb Bernd Wurst: > Hi. > > Am Mittwoch 22 September 2010, 14:54:38 schrieb Guenther Meyer: > > On Wed, Sep 22, 2010 at 11:24:48AM +0200, Bernd Wurst wrote: > > > > JS bietet manchmal durchaus sinnvolle Zusatzfunktionalitaet, aber bei > > > > vielen Seiten koennte man genau so gut darauf verzichten, ohne > > > > irgendwelche Einschraenkungen zu haben... > > > > > > Man markt an diesem Thread, was "keine Einschränkungen" dann bedeutet. > > > :) > > > > "keine Einschraenkung" und "keine Zusatzfunktionalitaet" sind zwei ganz > > verschiedene Dinge. > > Irgendwie seh ich den Unterschied jetzt nicht. Also ja, man kann die Seite > (wie fast alles) irgendwie nutzen ohne JS. Aber es gibt doch einen > Unterschied ob ich es so nutzen kann wie der Autor sich das vorstellt oder > halt "mit Einschränkungen" (bei den Zusatzfunktionen). das haengt immer davon wie man "Funktion" definiert. Beispiel Suchfunktion: Man gibt einen Suchbegriff ein, und bekommt bei Abschicken das Ergebnis. Mit Javascript haette man vielleicht noch den Komfort einer Vorblendung von oft benutzten Suchbegriffen waehrend dem Tippen. Aber notwendig ist das nicht. > > Ausserdem, wer heute ohne JS unterwegs ist, tut das normalerweise ganz > > bewusst, und sollte auch wissen, das die Funktionalitaet nicht die > > gleiche ist. > > Meine Rede. Derjenige soll sich aber bitteschön nicht beschweren wenn > irgendwas nicht so komfortabel funktioniert wie es sein könnte. richtig. > > fuer ein Tracking muss man keine Daten senden, da reicht jeglicher > > Zugriff... > > Meine Rede. Was hast du dann gegen JavaScript? Tracking geht mit Bildern > und Cookies wunderbar, dazu braucht es keine Scripts. Trotzdem wird in letzter Zeit dafuer unnoetigerweise vermehrt auf JS gesetzt, hab ich das Gefuehl. Was ich gegen JS habe? Das Verhalten in den verschiedenen Browsern kann sehr unterschiedlich sein, ausserdem ist man von der Gnade des Users abhaengig, ob und was denn machbar ist. Und dynamische Typisierung mag ich auch nicht... 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] OT: Javascript ist boese (war: Wie trage ich folgendes ein?)
On Wed, Sep 22, 2010 at 11:24:48AM +0200, Bernd Wurst wrote: > > JS bietet manchmal durchaus sinnvolle Zusatzfunktionalitaet, aber bei > > vielen Seiten koennte man genau so gut darauf verzichten, ohne > > irgendwelche Einschraenkungen zu haben... > > Man markt an diesem Thread, was "keine Einschränkungen" dann bedeutet. :) "keine Einschraenkung" und "keine Zusatzfunktionalitaet" sind zwei ganz verschiedene Dinge. Ausserdem, wer heute ohne JS unterwegs ist, tut das normalerweise ganz bewusst, und sollte auch wissen, das die Funktionalitaet nicht die gleiche ist. > Eine Technologie gleich gar nicht einzusetzen obwohl sie sinnvoll ist, nur > weil einige Leute da irgendwelchen Voodoo rein interpretieren kann auch nicht > wirklich der Weg der Wahl sein. das hat auch niemand behauptet... > > > (Heutige Browser schaffen es doch ganz gut, die sinnvollen JS-Funktionen > > > zu unterstützen und die blödsinnigen zu ignorieren. Ausschalten ist > > > nicht mehr zeitgemäß.) > > Grade heutzutage ist sowas wie "NoScript", das selektives Aktivieren von > > JS bietet absolut sinnvoll. > > Ich kenne diese Extension nicht, aber wenn dem Script verboten wird zu einer > unbeteiligten Seite Daten zu senden fuer ein Tracking muss man keine Daten senden, da reicht jeglicher Zugriff... > Ich wunder mich grade, dass ich hier diese Sichtweise vertrete. Noch vor ein > paar Jahren war JS nur für Mist zu gebrauchen und ich wäre voll auf deiner > Seite gewesen. Heute ist das aber anders. Und wer meint, JS wäre Teufelszeug, > der sollte sich mal genauer damit befassen, was mit anderen Dingen möglich > ist. Oder vielleicht einfach keinen Google-/Facebook-Account machen, dann > können die auch nur halb so viel über einen tracken. Und die eigenen Cookie- > Richtlinien optimieren. > das brauchst du mir nicht sagen... ;-) signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seekabel, die Zweite
Am Mittwoch 22 September 2010, 01:55:51 schrieb Stephan Wolff: > > es ist komplett inkompatibel zu bestehenden Anwendungen, da keine > > Anwendung das kennt. Alle Anwendungen müssten erst dieses neue Tag > > lernen. > > Wenn das erwünschte Verhalten keine Änderung des Programms erfordert, > ist das Tag kompatibel. schon wieder jemand, der den Status Quo in Stein meisseln will, und keinerlei Weiterentwicklung befuerwortet... 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] Seekabel, die Zweite
Am Mittwoch 22 September 2010, 00:20:37 schrieb aighes: > Ein Stromkabel ist ein Stromkabel, egal wo es nun liegt. Das sollte sich > auch in den Taggs wiederspiegeln. Wir taggen schließlich eine Straße auch > immer als Straße, egal ob sie unter der Erde verläuft oder in der Luft > verläuft. Die Lage wird über zusätzliche Tags geregelt. +1 Ein Kabel ist ein Kabel ist ein Kabel. Ein Laie kann ausserdem nicht immer erkennen, ob es eine Kommunikations- oder Versorgungsleitung ist... > Anstatt submarine|underground|air=yes zu nutzen würde ich allerdings eher > etwas *=submarine|underground|air nutzen. Das macht das ganze mMn logischer > und fehlerrobuster. +1 ein allgemeines Tag fuer Verlauf/Verlegung. Das kann man dann z.B. auch fuer Rohrleitungen verwenden. > * passender englischer Begriff, der mir gerade nicht einfällt vielleicht "laying"? 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] OT: Javascript ist boese (war: Wie trage ich folgendes ein?)
Am Mittwoch 22 September 2010, 07:03:51 schrieb Bernd Wurst: > Da man im heutigen Internet mit ausgeschaltetem JavaScript zu Recht nicht > mehr weit kommt, sind es doch eher die Leute mit viel Ahnung und wenig > Bedarf an solchen Fragen, die JS ausgeschaltet haben. "zu recht" definitiv nicht! JS bietet manchmal durchaus sinnvolle Zusatzfunktionalitaet, aber bei vielen Seiten koennte man genau so gut darauf verzichten, ohne irgendwelche Einschraenkungen zu haben... Eine Technologie nur deshalb einzusetzen, "weil es geht", ist nicht immer toll. > (Heutige Browser schaffen es doch ganz gut, die sinnvollen JS-Funktionen zu > unterstützen und die blödsinnigen zu ignorieren. Ausschalten ist nicht mehr > zeitgemäß.) Grade heutzutage ist sowas wie "NoScript", das selektives Aktivieren von JS bietet absolut sinnvoll. Alleine das Usertracking von Google, Facebook und Co, das Einbinden externer Skripte bergen Gefahren und Sicherheitsrisiken. 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] Telefonzelle, Position
Am Mittwoch 15 September 2010, 16:21:36 schrieb M∡rtin Koppenhoefer: > Am 15. September 2010 14:47 schrieb Guenther Meyer : > >> ja, aber wenn sie dort (auf dem Schild) falsch sind (wie hier bei den > >> Telefonzellen, wo die angegebene Adresse gar nciht die der > >> Telefonzelle ist, sondern auf der anderen Straßenseite liegt) würde > >> ich sie auch nciht als opening_hours eintragen, sondern dort die > >> richtigen Daten benutzen. > > > > Die Angabe ist nicht falsch. Es ist nur keine Adresse im herkoemmlichen > > Sinne. Da koennte genau so stehen XY-13/45... > > Doch, wenn dort eine Hausnummer der anderen Straßenseite draufsteht, > ist es m.E. falsch. Gegen das: "es ist keine Adresse im herkömmlichen > Sinne" spricht m.E., dass es eben doch in der Adress-schreibweise > drauf steht, und eben nciht 23-0815 Der Betreiber hat sich nunmal entschieden, eine Schreibweise in Form einer Adresse zu benutzen, und er hat sich sicher was dabei gedacht. Dass du das fuer falsch haeltst, aendert nichts an der Tatsache, dass es auf dem Schild so geschrieben steht. 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] Telefonzelle, Position
Am Mittwoch 15 September 2010, 12:03:14 schrieb M∡rtin Koppenhoefer: > Am 15. September 2010 07:40 schrieb Guenther Meyer : > >> das spricht IMHO gegen addr und gegen "location", ich würde eher was > >> mit sign verwenden, > >> sign:location oder sign:addr > > > > Wieso sign? Weils auf einem Schild steht? Find ich doof. > > ja genau darum, weil es auf dem Schild steht. Gab es nicht auch mal > einen Vorschlag, wie man falsche Namen auf Straßenschildern eintragen > soll? Weiss noch jemand wie der Tag dafür war? > > > Ladenoeffnungszeiten und Zufahrtsbeschraenkungen stehen meist auch auf > > einem Schild... > > ja, aber wenn sie dort (auf dem Schild) falsch sind (wie hier bei den > Telefonzellen, wo die angegebene Adresse gar nciht die der > Telefonzelle ist, sondern auf der anderen Straßenseite liegt) würde > ich sie auch nciht als opening_hours eintragen, sondern dort die > richtigen Daten benutzen. Die Angabe ist nicht falsch. Es ist nur keine Adresse im herkoemmlichen Sinne. Da koennte genau so stehen XY-13/45... > > wenn, dann schon phone:location... > > stimmt halt nicht, weil die "location" wo anders ist. Standort = location > > Wie waer's mit official_location? > > hm, ist die Telekom denn "official"? k.A. official_location deshalb, weil es die Standortangabe des Betreibers ist. Die mag zur Identifikation des Objektes durchaus nuetzlich sein. 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] Alpen...
Ich finde den bestehenden Ausschnitt eigentlich auch gut wie er ist. Aber wenn man die suedwestliche Ecke noch dazunimmt um einen L-foermigen Ausschnitt zu machen, ist das nicht verkehrt. Reduzieren wuerde ich nix. 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] Telefonzelle, Position
Am Dienstag 14 September 2010, 21:14:54 schrieb M∡rtin Koppenhoefer: > > aber als addr:... finde ich nicht gut, denn die angegebene Adresse ist > > nicht die Adresse der Telefonzelle (oder des Briefkastens, da gibt's das > > auch) - oft ist diese sogar noch ein gutes Stueck davon entfernt... > > +1 > das spricht IMHO gegen addr und gegen "location", ich würde eher was > mit sign verwenden, > sign:location oder sign:addr > Wieso sign? Weils auf einem Schild steht? Find ich doof. Ladenoeffnungszeiten und Zufahrtsbeschraenkungen stehen meist auch auf einem Schild... wenn, dann schon phone:location... Wie waer's mit official_location? 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] Telefonzelle, Position
Am Dienstag 14 September 2010, 14:06:20 schrieb Wolfgang: > Hallo, > > Am Dienstag 14 September 2010 13:45:16 schrieb Jörk: > > moin, > > > > das dürfte der "Standort" der Zelle lt. Schild sein. > > Das ist ein Hinweis für denjenigen, der Hilfe braucht und gefragt wird, wo > er ist. Die Frage ist nur, kommt er mit rein, und wenn, wie. > rein auf jeden Fall. aber als addr:... finde ich nicht gut, denn die angegebene Adresse ist nicht die Adresse der Telefonzelle (oder des Briefkastens, da gibt's das auch) - oft ist diese sogar noch ein gutes Stueck davon entfernt... Wie waers mit location als key? 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] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
Am Sonntag 12 September 2010, 19:06:01 schrieb C. Brause: > >car_charging:VDE = 1 > >car_charging:schuko = 3 > > > > das ist wenigstens eindeutig und ausserdem dasselbe Schema wie > > > >fuel:diesel = ... > > Da halte ich es für sinnvoller, das wie bei amenity=parking zu machen. > Über capacity (oder ähnliches) für gesamtzahl der Ladestellen und dann > weitere Verfeinerung capacity:VDE=1 usw. Das ermöglicht, die Platzzahl > zu mappen, ohne die Art des Anschlusses zu kennen. > car_charging = 4 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] payment - Tag
Am Samstag 11 September 2010, 16:47:45 schrieb AssetBurned: > das problem ist wenn man schlicht > payment=coins,notes,mastercard,americanexpress,lasercard... dann wird es > schnell unübersichtlich. Na und? Wenn so viele Moeglichkeiten geboten werden, dann ist das halt so. In der Anwendung kann man das ja gerne noch durch lustige Icons dasrstellen. 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] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
Am Samstag 11 September 2010, 15:51:25 schrieb M∡rtin Koppenhoefer: > Am 11. September 2010 14:57 schrieb Guenther Meyer : > >> > warum nicht einfach: > >> > car_charging=yes (oder public/subscriber/private?) > >> > car_charging:systems=VDE;schuko > >> > car_charging:count=1;3 > >> > payment=... > > > > car_charging:VDE = 1 > > car_charging:schuko = 3 > > das ist wenigstens eindeutig und ausserdem dasselbe Schema wie > > > > fuel:diesel = ... > > Das sind vermutlich erstmal nur abstrakte Vorschläge, die man nicht > wörtlich so meint, oder? So hatte ich das verstanden, denn die Bezeichnungen sind natuerlich Unsinn. 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] OT: Elektroantriebe sauber? WAS: P rojekt DE des Monats - Tankstellen
Am Samstag 11 September 2010, 13:12:02 schrieb C. Brause: > Am 10.09.2010 12:38, schrieb Henry Loenwind: > > warum nicht einfach: > > > > car_charging=yes (oder public/subscriber/private?) > > car_charging:systems=VDE;schuko > > car_charging:count=1;3 > > payment=... > > > > Das lässt sich sowohl an eine Tankstelle als auch an ein Parkhaus oder > > eine Straßenlaterne dazu-taggen. > > > > cu > > Henry > > +1 > > Wobei ichmit car_charging:count=1;3 nichts anfangen kann. Aber das kann > man ja dokumentieren. > dann schon lieber car_charging:VDE = 1 car_charging:schuko = 3 das ist wenigstens eindeutig und ausserdem dasselbe Schema wie fuel:diesel = ... > Was spricht gegen diese Lösung? dass volltanken auch eine Art von car_charging ist... ;-) 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] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
Am Freitag 10 September 2010, 02:44:53 schrieb Ulf Lamping: > > Das stimmt überhaupt nicht. Man kann eine Checkbox auf yes, no oder > > unverändert setzen. Schon immer (oder fast immer, jedenfalls seit > > Jahren). > > Tatsächlich hast du recht, nur ist das aus meiner Sicht *völlig* > unintuitiv. > > Ich persönlich fände ein: > > O Ja O Nein O Unbekannt > > wesentlich intuitiver ... +1 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] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
Am Freitag 10 September 2010, 01:14:48 schrieb Garry: > Am 09.09.2010 23:10, schrieb Guenther Meyer: > > Aber ein explizites "yes", "no" oder "only" ist sicher nicht verkehrt. > > Das würde bedeuten eine "Elektrotankstelle" wäre dann mit > > amenity=fuel > fuel:electric=only > > zu taggen... richtig. > Und damit zeigen alle Anwendungen die mit der zweiten Zeile nichts anfangen > können eine hundsgwöhnliche "Sprit-Tankstelle" wo nur eine > Elektro-Ladesäule herumsteht. Die Anwender werden es Dir danken... > Insbesondere die, die auf der Tankstellensuche nach der dritten Ladesäule > ohne Sprit liegen bleiben Ach komm, schoen langsam wird es langweilig. OSM ist nun mal ein Moving Target, das sich staendig weiterentwickelt. Eine Anwendung, die ihr Parsing nicht aktualisiert, wird sowieso in absehbarer Zeit weitgehend nutzlos werden... Hatte ich schon mal erwaehnt, dass ich die Idee mit der Versionierung des OSM- Taggings sehr gut finde? 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] payment - Tag
Am Freitag 10 September 2010, 01:37:34 schrieb Garry: > Wenn ich mir die Liste und die Diskussionen dazu ansehe: > Es wird ein riesen Aufwand für etwas gemacht was keine verlässlichen > Daten liefern kann da > eine entsprechend notwendige Datenpflege ehr nicht zu erwarten bzw. > möglich ist. Du hast recht. Lassen wir das Ganze, tragen wir gar keine Tankstellen mehr ein. Am besten tragen wir ganr nichts mehr ein und wenden uns sinnvolleren Dingen zu. Wir finden sicher eine bessere Moeglichkeit, die Ressourcen zu nutzen, die zur Zeit fuer OSM verschwendet werden... 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] payment - Tag
Am Donnerstag 09 September 2010, 09:54:12 schrieb Bernd Wurst: > Am Donnerstag 09 September 2010, 09:13:25 schrieb Jan Tappenbeck: > > Abgesehen davon wie sollte eine automatische Auswertung erkennen das es > > sich um eine Creditkarte oder Tankkarte handelt ??? Dann müßten wieder > > Listen hinterlegt werden die gepflegt werden. > > Was ist der Unterschied? > > Also ja, ich kenne den Unterschied, aber wann muss eine Anwendung diese > Klassifizierung machen? > Ob eine Tankstelle nur Tankkarten nimmt oder auch noch VISA ist mir egal > wenn ich mit meiner EC-Karte oder MasterCard tanken gehen will. > +1 Verschiedene Kartenarten zusammenzufassen, und das auch noch mit mehreren Tags ist nicht sinnvoll. Was hilft mir ein payment=credit_cards wenn ich dadurch nicht erfahren kann, ob *meine* Karte genommen wird? > IMO sollte es einfach: > payment = foo;bar;baz;... > sein. Und dann im Wiki eine Liste welche Keywords welche Zahlungsart > ausdrückt. Also "EC-Karte" ist "maestro" und sowas. +1 jede Karte sollte explizit genannt werden. 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] OT: Elektroantriebe sauber? WAS: P rojekt DE des Monats - Tankstellen
Am Donnerstag 09 September 2010, 12:41:06 schrieb Wolfgang: > Am Donnerstag 09 September 2010 12:01:16 schrieb Georg Feddern: > > Moin, > > > > was bedeutet dann bitte > > amenity=fuel > > fuel:electric=yes > > > > Eine "Standard-Tankstelle" mit zusätzlicher Ladesäule? > > Oder eine Nur-Elektro-Ladestation? > > Eine Ladesäule ist definitiv vorhanden, alles andere ist Interpretationssache. > > NB: > > Im JOSM-Preset kann man zwar 'ja' sagen zu den einzelnen fuel-Sorten, > > aber leider nicht explizit 'nein' sagen - Damit ist eine > > Nur-Strom-Tankstelle wunderbar einzutragen ... > > Guter Einwand! > > Das Preset sollte so verändert werden, dass ja, nein oder unbekannt > angegeben werden kann. Manuell geht es sowieso. > "unbekannt" finde ich etwas sinnlos, das kommt auf dasselbe raus, wie gar kein Tag. Aber ein explizites "yes", "no" oder "only" ist sicher nicht verkehrt. 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] Werden Baumreihen gerendert?
Am Donnerstag 09 September 2010, 18:01:30 schrieb NopMap: > Aber in der Praxis wurde es anders definiert, es gibt weltweit geschätzte > 58000 Anwendungen, die geprüft und ggf. geändert werden müßten, niemanden > der das tut und 76-88% Mapper die es anders handhaben. > ja genau... 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] cycle-layer Styles?
On Thu, Sep 09, 2010 at 12:19:58PM +0200, Frederik Ramm wrote: > Hallo, > > Sven Geggus wrote: >> Wäre er offen könnte man sich dem dann auch mal annehmen mich nervt es seit >> Jahren dass das Teil keinen Support für Tracktypes hat. > > Andy hat das mal so erklaert: > > http://lists.openstreetmap.org/pipermail/talk/2010-January/046483.html > > Kurzer Rede langer Sinn, er will gern die Kartografie selber bestimmen > und eben *nicht* den ti...@home-effekt, dass jeder mal grad einbaut, was > er wichtig findet. Naja, wenn das der ganze Grund ist, spricht doch nichts dagegen, den Style trotzdem offenzulegen. Dann kann sich jeder der will, auf dieser Basis seine eigene Karte machen, und muss nicht von Null anfangen... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
Am Donnerstag 09 September 2010, 08:14:30 schrieb Bernd Wurst: > > Aber dazu braucht man kein extra Tag in der Art fuel=standard, dass man > > irgendwann wieder umdefinieren muss. > > Wo kommt diese obskure Theorie her? Von mir sicherlich nicht! nein, nicht von dir. > Ich merke nur an, dass ein Auswerter, der lediglich "amenity=fuel" > auswertet, bitte nicht jede Steckdose finden soll. That's it. eine Auswertung ohne sich die Zusatztags anzusehen ist heute nicht mehr zeitgemaess. Da wuerde bei vielen Dingen nicht das gewuenschte Ergebnis rauskommen. 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] Werden Baumreihen gerendert?
Am Donnerstag 09 September 2010, 07:49:26 schrieb NopMap: > Guenther Meyer wrote: > > Es stellt sich vor allem die Frage, wozu das gut sein soll. > > Wenn Baeume in irgendeiner Art gruppiert stehen, ergibt sich das, wie du > > schreibst, aus der Topologie. Warum also muss man das dann noch extra > > taggen? > > Es ist dazu gut, daß auf Karten, die das "Bäumchen-Symbol" einer Topokarte > rendern, nicht alle Straßen in den Innenstädten mit Bäumen zugepflastert > werden, so daß überhaupt nichts mehr zu erkennen ist. > > Daß es aus der Topologie hervorgeht bringt Dir erst mal nix, weil das nur > sehr aufwändig auszuwerten ist. Hast Du eine Vorstellung, wie lange es > dauert, die Entfernung von 25000 Bäumen in Deutschland zu jedem anderen > Baum auszurechnen? > Wozu? "Wichtige" Baeume sollen mit besonderen Zusatztags versehen werden (denotation, landmark, name, ...). Alle anderen Bäume haben diese Tags nicht, sind also "normale" Bäumen. Somit ist es ein Leichtes fuer eine Anwendung, sich das rauszupicken, was sie braucht: Alle Baeume, nur besondere Baeume, nur normale Baeume, Baeume mit Namen, ... 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] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
Am Donnerstag 09 September 2010, 01:19:50 schrieb Garry: > Am 08.09.2010 13:06, schrieb Guenther Meyer: > > Es gab und gibt auch Benzin/Diesel-Zapfsaeulen, die einfach so, ganz > > unauffaellig am Strassenrand rumstehen, ohne ein grosses > > Tankstellengedoens drum rum zu haben. Wo ist da jetzt der Unterschied?! > > Sind die heutzutage noch zulässig? Stichwort Auffangwanne, Rammschutz,... keine Ahnung. Ist zugegeben schon einige Zeit her, seit ich sowas gesehen habe. Allerdings bin ich auch nicht mehr soviel unterwegs wie frueher... > > Ich kann mir durchaus vorstellen, dass der Begriff "tanken" (auf Englisch > > uebrigens "to fuel") im Sprachgebrauch auch in Zukunft erhalten bleibt, > > egal ob jemand sein Fahrzeug mit Strom oder Diesel fahrbereit macht... > > Das kommt leider immer wieder vor das sich eigentlich klar abgegrenzte > Begriffe falsch einbürgern, aber muss OSM da unbedingt ein Vorreiter > davon sein? OSM *ist* ein Vorreiter, siehe Baeume ;-) Da OSM-Tags sprechend und menschenlesbar sein sollen, sollten sie auch in etwas den ueblichen Sprachgebrauch abbilden (siehe Parkplatz vs. Parkstand). Alles andere ist nicht intuitiv und fuehrt nur zu Missverstaendnissen. > >> weil Strom kein Energieträger ist? Zumindest kein primärer. > > > > Was soll es denn sont sein?!? > > Strom ist sekundäre Energie. Ein Energieträger ist Strom natürlich schon. Ob primaer oder sekundaer ist doch absolut irrelevant. 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] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
Am Donnerstag 09 September 2010, 01:59:58 schrieb Garry: > Die Aussage verstehe ich so dass wenn es nur noch einen Oberbegriff > "Tankstelle" für Strom und Treibstoffe > gibt keiner mehr erkennen kann ob es da jetzt Strom oder Sprit gibt wenn > keine Zusatztags vorhanden sind > bzw. ausgewertet werden. > schon klar. Deshalb sollte man fuer reine Stromtankstellen immer den Energietraeger taggen, denn dann sieht man klar "ok, hier gibt's Strom, aber was anderes ist nicht eingetragen, also kann ich nicht davon ausgehen, dass es auch Benzin gibt". Nur wenn gar nichts dazu getaggt ist, kann man vom derzeitigen Standard ausgehen - 100% darauf verlassen kann man sich allerdings auch nicht. > >> Mir geht es nur darum, die bisher eingetragenen Tankstellen nicht > >> aussagelos werden. Denn die wurden eingetragen mit der Maßgabe "normale > >> Tankstelle", also ohne Zusatztags erwartet man da Benzin und Diesel. > > > > bei einer amenity=fuel_station ohne zusaetzliche Tags erwartet man zur > > Zeit primaer Benzin und Diesel, richtig. > > > > Aber dazu braucht man kein extra Tag in der Art fuel=standard, dass man > > irgendwann wieder umdefinieren muss. > > Das soll aussagen dass dort nicht mit besonderen Kraftstoffsorten wie > Biodiesel oder Gas zu rechnen ist. Wie bereits erwaehnt aendern sich solche Standards mit der Zeit... Ausserdem geht doch Otto-Normal-Nutzer sowieso davon aus, wenn nichts explizit getaggt ist. > > Die Tankstelle selbst wird sich mit den Zeiten aendern, genauso wie die > > Bedeutung des entsprechenden Tags. > > > > Das Ziel sollte es sein, die jeweils angebotenen Arten von > > Energietraegern explizit zu taggen, wenn moeglich. > > Dagegen habe ich auch gar nichts einzuwenden was die "Brennstoffe" an > der Tankstelle angeht, im Gegenteil. > Nur sollte man auch berücksichtigen das auch der normale Autofahrer der > nur Benzin oder Diesel tankt zur Zeit ja. > und sich vieleicht nur merkt dass es da keine weitere Sorten oder ein > grosses Angebot gab sein Wissen > beisteuern bzw. eintragen kann > Naja, wenn anderes nicht explizit getaggt ist, sondern nur Benzin und Diesel, sollte man auch nicht davon ausgehen, dass es noch was anderes geben koennte. Das Problem hierbei ist ausserdem noch der Fokus: Der haengt oft stark davon ab, was fuer ein Fahrzeug jemand faehrt (Gasauto, E-Auto, Benziner, Diesel, Motorrad, Mofa, Fahrrad, LKW, ...). Man merkt sich Dinge, die man nicht braucht oder die einen nicht interessieren, nicht - ja nimmt sie oft gar nicht wahr. 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] Werden Baumreihen gerendert?
Am Mittwoch 08 September 2010, 22:39:37 schrieb NopMap: > Ich denke ich habe einen pragmatischen Weg gefunden, der garantiert keinen > Schaden anrichtet. Man kann zwar nicht automatisch erkennen, ob ein Baum > garantiert eine Landmark darstellt und deshalb keine solchen Tags vergeben. > Aber aus der Analyse der Topologie kann man zweifelsfrei feststellen, daß > ein Baum in einer Gruppe steht und nicht einzeln und damit > allerhöchstwahrscheinlich als Landmarke ausscheidet. > > Von daher habe ich von meinem Spamfilter alle Bäume, die in einer > 50m-Gruppe stehen, noch kein denotation-Tag und auch kein Name-Tag haben, > mit dem Zusatz-Tag denotation=cluster markiert. Das ist auf jeden Fall > richtig, ein genaueres tagging auf avenue, urban oder so müßte von Hand > erfolgen wenn's denn jemand interessiert. Wenn ein Baum einen eigenen > Namen hat, gehe ich davon aus, daß er signifikant ist. > 50m kommen mir irgendwie schon weit vor... Es stellt sich vor allem die Frage, wozu das gut sein soll. Wenn Baeume in irgendeiner Art gruppiert stehen, ergibt sich das, wie du schreibst, aus der Topologie. Warum also muss man das dann noch extra taggen? 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] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
Am Mittwoch 08 September 2010, 14:03:49 schrieb Bernd Wurst: > Am Mittwoch 08 September 2010, 13:29:08 schrieb René Falk: > > Tante Google findet über 40 Hits für den Begriff Stromtankstelle. > > [...] > > Den Begriff Stromtankstelle, sehe ich daher als etabliert an. > > Jetzt rechnest du mal alle Fundstellen raus, die auf das Konto > irgendwelcher Werbeagenturen gehen. > Und? Ob ein Begriff von einer Agentur oder von Volkes Mund etabliert wird ist doch absolut irrelevant. > Noch ein letztes Mal: > Wenn ich jemanden auf der Straße frage, was er an einer "Tankstelle" (und > ich schreibe nicht "Stromtankstelle") bekommt, werden die meisten Leute > nicht "Strom" sagen. Strom ist zum jetzigen Zeitpunkt nicht das was ich > *immer* erwarten kann, wenn ich an eine Tankstelle gehe. Hat das jemand behauptet? > Mir geht es nur darum, die bisher eingetragenen Tankstellen nicht > aussagelos werden. Denn die wurden eingetragen mit der Maßgabe "normale > Tankstelle", also ohne Zusatztags erwartet man da Benzin und Diesel. bei einer amenity=fuel_station ohne zusaetzliche Tags erwartet man zur Zeit primaer Benzin und Diesel, richtig. Aber dazu braucht man kein extra Tag in der Art fuel=standard, dass man irgendwann wieder umdefinieren muss. Die Tankstelle selbst wird sich mit den Zeiten aendern, genauso wie die Bedeutung des entsprechenden Tags. Das Ziel sollte es sein, die jeweils angebotenen Arten von Energietraegern explizit zu taggen, wenn moeglich. Uebrigens, um noch mehr Brennstoff ins Feuer zu giessen: Es gibt auch E-Auto-Konzepte, wo der Akku nicht konventionell geladen oder ausgetauscht wird, sondern nur den Inhalt. Dabei wird die entladene Fluessigkeit aus dem Fahrzeug abgesaugt, und eine neue geladene eingefuellt. Was ist das dann? Eine Strom-Ladestation? Oder eher eine Zapfsaeule zum Strom-Tanken? ;-) 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] OT: Elektroantriebe sauber? WAS: Projekt DE des?Monats - Tankstellen
On Wed, Sep 08, 2010 at 11:57:04AM +0200, Bernd Wurst wrote: > Am Mittwoch 08 September 2010, 11:37:14 schrieb Florian Gross: > > > Warum bricht man das Ganze nicht auf den kleinsten gemeinsamen Nenner > > > runter? EIne Tankstelle/Zapfsaeule ist ein Objekt, das primaer dafuer > > > gebaut wurde, um ein Fahrzeug mit Energie zur Fortbewegung zu versorgen. > > Jepp. So würde ich das auch definieren. > > Diese Einstellung ist aber wider der Realität. > Dann kannst du das sicher mit einer schluessigen Argumentation belegen... > Keine mir bekannte Tankstelle bietet Strom-Ladestationen an und keine der mir > bekannten Strom-Ladestationen würde irgend jemand als Tankstelle bezeichnen. > Schau einfach mal ueber deinen Tellerrand hinaus, und bemuehe die Suchmaschine deiner Wahl mit Begriffen wi "Stromzapfsaeule" oder "Stromtankstelle"... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
On Wed, Sep 08, 2010 at 11:38:38AM +0200, M∡rtin Koppenhoefer wrote: > > Warum bricht man das Ganze nicht auf den kleinsten gemeinsamen Nenner > > runter? > > EIne Tankstelle/Zapfsaeule ist ein Objekt, das primaer dafuer gebaut wurde, > > um > > ein Fahrzeug mit Energie zur Fortbewegung zu versorgen. > > > ich sehe das mehr aus praktischer Perspektive. Dann ist deine praktische Perspektive eine ganz andere als meine praktische Sicht ;-) > Es gibt ja mittlerweile > einige dieser Ladepunkte, zumindest in größeren Städten sind sie > durchaus schon "verbreitet" (an jeder Ecke noch nicht gerade). Ich > habe aber noch keinen einzigen an einer Tankstelle gesehen. Alle die > ich gesehen habe waren am Straßenrand einfach so, meist nicht mal > auffällig. > Es gab und gibt auch Benzin/Diesel-Zapfsaeulen, die einfach so, ganz unauffaellig am Strassenrand rumstehen, ohne ein grosses Tankstellengedoens drum rum zu haben. Wo ist da jetzt der Unterschied?! > wieso sollte man die als Tankstelle taggen? Es geht nicht um "tanken", > und Strom ist kein Kraftstoff. Ich kann mir durchaus vorstellen, dass der Begriff "tanken" (auf Englisch uebrigens "to fuel") im Sprachgebrauch auch in Zukunft erhalten bleibt, egal ob jemand sein Fahrzeug mit Strom oder Diesel fahrbereit macht... > weil Strom kein Energieträger ist? Zumindest kein primärer. Was soll es denn sont sein?!? > Mit Deiner > Definition könnte man als Fahrradfahrer durchaus jedes Restaurant und > jeden Supermarkt als Tankstelle taggen, und als Energieträger dann > "Nahrungsmittel" angeben. > Man kann aber auch alles uebertreiben, bis es laecherlich wird. "Tankst" du das Fahrrad oder den Fahrer? signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
Am Mittwoch 08 September 2010, 01:43:48 schrieb Garry: > > Wenn du die Definition fuer dein Standardfuel in der Zukunft aenderst - > > und der "Standard" wird sich irgendwann aendern, dann aenderst du damit > > implizit die Tags fuer die vorhandenen Kraftstoffsorten jeder damit > > getaggten Tankstelle, ohne zu zu wissen ob das vor Ort jeweils wirklich > > so ist. > > Wenn es zukünftig mal ein Problem wird lässt man den Tag einfach sterben > oder definiert ihn um. > So wie es gerade beim Baumtagging Thema ist. Ja und? du vergleichst hier Aepfel und Birnen! Ersten soll beim Baumtagging die Definition an die Tagging-Realitaet angepasst werden. Zweitens bleibt der Baum auch nach der Anpassung ein Baum. Wenn du die Definition fuer dein Standardfuel aenderst, dann kommt eine Kraftstoffart hinzu oder es faellt eine weg; das hat ganz andere Auswirkungen. > Es geht nicht darum ob mir die drei Klicks zuviel sind sondern darum ob > die Informationen auch im grösseren > Umfang angewendet werden - was quasi die Voraussetzung dafür ist dass > sie auch gepflegt werden. > Nach meiner Enschätzung sind die Datenpfleger dann nicht die > eingefleischten OSMler die jedes Detail > eintragen bzw. korrigieren da dies meist auch ehr eingefleischte > Radfahrer und Fussgänger als regelmässige Tankstellenbesucher > sind. > Also ich hab's beim Mappen lieber, wenn ich weiss, wie ich etwas eindeutig eintragen kann. Und ich bin hier sicher nicht der einzige; grade auch Anfaenger sind verwirrt, wenn sie ein fuel=standard vorgesetzt bekommen, das alles Moegliche bedeuten kann. Wenn ich die Kraftstoffarten nicht explizit eintragen kann oder will, dann lass ich sie besser weg. 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] OT: Elektroantriebe sauber? WAS: Projek t DE des Monats - Tankstellen
Am Mittwoch 08 September 2010, 02:06:24 schrieb Florian Gross: > Dann diskutiert bitte auch das tagging und nicht Themen wie > "Ist ein Elektroauto sinnvoll" o.ä. Sorry, das hat hier in > der Liste IMO gar nichts verloren. > +1 Ich finde, man macht es sich mit dem Tagging viel zu kompliziert. Eine Diskussion, welche Technologien sich durchsetzen werden, bringt nicht wirklich etwas; das weiss schlichtweg niemand zum jetzigen Zeitpunkt. Warum bricht man das Ganze nicht auf den kleinsten gemeinsamen Nenner runter? EIne Tankstelle/Zapfsaeule ist ein Objekt, das primaer dafuer gebaut wurde, um ein Fahrzeug mit Energie zur Fortbewegung zu versorgen. Die Tags fuer den Energietraeger lassen sich einfach erweitern: Es gab Tags fuer verschiedene Benzinarten. Es gab Tags fuer Diesel. Es kamen Tags fuer die verschiedenen Gase hinzu. Es gab ein neues Tag fuer Wasserstoff. Warum fuegt man nicht einfach neue Tags fuer Strom/Akkutausch/... hinzu? Weil der Energietraeger und die Art des "Tankens" anders aussieht? Kein Argument, das hatte man beim Gas auch schon. Weil es ploetzlich kein "Brennstoff" mehr ist ? So what. Der primaere Zweck der Einrichtung bleibt weiterhin derselbe. KISS! 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] Projekt DE des Monats - Tankstellen
Am Dienstag 07 September 2010, 13:33:32 schrieb Andreas Braunmiller: > On 07.09.2010 13:18, Guenther Meyer wrote: > > On Tue, Sep 07, 2010 at 11:39:24AM +0200, Thomas Ineichen wrote: > >> Das Hauptproblem bei dem Schema ist IMHO, ob/wie die Datenbank nach > >> Key:[Zeitraum] durchsuchbar ist. Falls ein Programm das nicht kann, > >> oder der Zeitraum in einem falschen Format angegeben ist, dann bleibt > >> Dir zur Auswertung nur der Haupt-Key, und daher wäre es vorteilhaft, > >> wenn dort das Minimum und nicht das Maximum drinstehen würde. > > > > beim derzeitigen (aeusserst eingeschraenkten) key/value-Schema von OSM > > ist das relativ egal, da man so oder so die Werte auf beiden Seitn > > irgendwie unterbringen muss. > > Würde folgender Ansatz weiter führen? > > payment = maestro > payment:period:1 = cash;master_card;maestro > payment:period:1:time = 07:00-22:00 > payment:period:2 = dkv > payment:period:2:time = 22:00-07:00 > viel zu kompliziert, damit ist nicht wirklich was gewonnen. prinzipiell waere das in einer baumartigen Struktur am besten abzubilden, aber das wird im key/value-System irgendwann zwangslaeufig immer komplizierter als noetig. 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] Werden Baumreihen gerendert?
Am Dienstag 07 September 2010, 10:18:41 schrieb Garry: > Am 07.09.2010 00:16, schrieb Guenther Meyer: > > Am Dienstag 07 September 2010, 00:11:03 schrieb M∡rtin Koppenhoefer: > >> werden Baumreihen denn nun gerendert oder nicht? > > > > er nu wieder... darum geht's doch gar nicht... ;-) > > Merkwürdig - genau das steht aber im Betreff ;-) > ja natuerlich, aber der ist doch nur Deko, den liest hier doch eh niemand... ;-) 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] Projekt DE des Monats - Tankstellen
On Tue, Sep 07, 2010 at 01:00:14PM +0200, Henry Loenwind wrote: > > > On 07.09.2010 12:48, M∡rtin Koppenhoefer wrote: > >>> (2) Eine Zapfsäule ist ein stationäres Gerät, das dazu dient, den> >>> Energiebedarf eines Fahrzeuges zu decken. >> >> Wozu braucht man das? Wikipedia finde ich da besser: "Eine Zapfsäule(oder >> auch Tanksäule) ist ein Teil einer Tankstelle, > > Um (a) Eletropzapfsäulen auch zu erfassen und (b) Zapfsäulen von > Tankstellen unabhängig zu machen. > +1 >>> (3) Eine einzelne Zapfsäule ist keine Tankstelle, auch wenn sie über ein> >>> integriertes Bezahlverfahren verfügt. >> >> warum nicht? Es gibt solche Tankstellen mit nur einer Zapfsäule. > > Dann haben wir wieder an jeder Steckdose eine Tankstelle. Meine > Definition war gerade dazu da, solche Einzelzapfsäulen von Tankstelle > (mehrere Zapfsäulen, Kassenhäuschen, Minishop, PKW-Zubehör...) zu > trennen. > -1 nicht jede Steckdose waere dann eine Zapfsaeule. Letzteres waere ein Objekt, das *primaer* dazu gebaut wurde, Fahrzeuge zu versorgen. > Beim Gedanken, ein Parkaus als Tankstelle zu taggen, nur weil es dort > auch Eletrosapfstellen gibt, schüttelt es mich... > Das waere dann auch primaer ein Parkhaus, mit dem zusaetzlichen Feature einer Zapfsaeule. Die liesse sich als Attribut des Parkhauses, oder besser als separater Node mappen. signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werden Baumreihen gerendert?
On Tue, Sep 07, 2010 at 11:26:07AM +0200, Chris66 wrote: > Am 06.09.2010 20:13, schrieb Guenther Meyer: > > >> Bei Stromleitungen wurde zur Unterscheidung von Hochspannungs- und > >> Mittelspannungsleitungen neben power=line auch power=minor_line > >> eingeführt, obwohl auch eine Mittelspannungsleitung technisch unter den > >> Begriff "line" fallen würde. > > > deswegen wuerde ich hier auch das minor als zusatzinformation zu einem > > allgemeinen power=line bevorzugen... > > Und alle bestehenden Anwendungen/Renderer die unter power_line > eine Hochspannungsleitung verstehen müssten angepasst werden. > > Ich verstehe nicht wieso Du verschiedene Dinge krampfhaft > unter _einem_ Key subsumieren willst. > Warum sollte man Dinge, die gleich, oder zumindest sehr aehnlich sind, unter verschiedenen Bezeichnungen ablegen? Letztendlich wird es durch einheitliche Tags sowohl fuer den Mapper als auch fuer de Softwareentwickler einfacher: Der Mapper kann einen Baum schnell im Vorbeifahren als solchen eintragen, ohne wissen zu muessen, welche "Sorte" Baum es ist. Er kann dies aber auch zusaetzlich vermerken, wenn ihm danach ist. Eine Software sieht das Baum-Tag, und weiss, dass es Baum ist, kann ein Baum-Icon malen, oder wasauchimmer... Sollte jetzt ploetzlich eine neue Art von "Baum" eingefuehrt werden, kann die Software diesen ohne Anpassung trotzdem noch als Baum erkennen, eben weil er das generische Baum-Tag hat. Es geht nichts kaputt. signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
On Tue, Sep 07, 2010 at 11:39:24AM +0200, Thomas Ineichen wrote: > Hallo Guenther, > > > Die Definition war: > > - Ein Tag ohne Zeitraumangabe ist erstmal immer gueltig. > > - Einzige Ausnahme: Ist zusaetzlich nochmal derselbe Key mit einer > > Zeitraumangabe vorhanden, wird das allgemeine Tag durch das > > eingeschraenkte ersetzt. > > Das Hauptproblem bei dem Schema ist IMHO, ob/wie die Datenbank nach > Key:[Zeitraum] durchsuchbar ist. Falls ein Programm das nicht kann, > oder der Zeitraum in einem falschen Format angegeben ist, dann bleibt > Dir zur Auswertung nur der Haupt-Key, und daher wäre es vorteilhaft, > wenn dort das Minimum und nicht das Maximum drinstehen würde. > beim derzeitigen (aeusserst eingeschraenkten) key/value-Schema von OSM ist das relativ egal, da man so oder so die Werte auf beiden Seitn irgendwie unterbringen muss. > (Bei maxspeed:wet, maxspeed:hgv sind es ja wenigstens noch feste > Begriffe, die nicht so variabel sind wie Zeitangaben.) > aber immer noch zuviele... > > mit deiner Logik waere das: > > > payment = maestro > > payment:[0700-2200h] = cash;master_card;maestro > > payment:[2200-0700h] = dkv > > > geht auch, finde ich aber unnoetig aufwaendiger... > > Aber dafür logischer. ;-) > Nicht wirklich, denn bzgl. der Logik sind die beiden Varianten absolut gleichwertig. Die Frage muesste lauten, welche ist intuitiver? > >> payment:cash = 07:00-22:00 > >> payment:mastercard = 07:00-22:00 > >> payment:dkv = 07:00-22:00 > >> payment:maestro = yes (oder 24/7) > > > das blaest das Ganze halt unnoetig auf, ohne grossen Mehrwert zu bringen. > > Ausserdem war das Ganze dazu gedacht, eben einerseits beliebige Tag- > > Kombinationen mit einer Zeitangabe zu versehen, andererseits nicht nur > > zeitliche, sondern auch andere Einschraenkungen (die natuerlich nicht fuer > > jedes Tag immer sinnvoll sind) wie Gewicht, Hoehe, Laenge, Breite anbringen > > zu > > koennen. > > Durch die Aufgeblasenheit ist es dafür die menschenlesfreundlichste > Art, die auch ein Computer noch gut verarbeiten kann. Die Subtags für > die Zahlungsarten werden sich mit der Zeit genau so standardisieren > wie die Tags für die verschiedenen Fahrzeugklassen.. > Es ist sowohl menschen- als auch computerlesbar, ja. Aber sicher nicht die menschenlesfreundlichste Art. Die haengt naemlich immer davon ab, was man einen interessiert: Will ich wissen, *WANN* ich meine Mastercard nutzen kann, oder interessiert mich, *WAS* ich zu einem bestimmten Zeitpunkt nutzen kann? > >> Hängt auch vom Anwendungsfall ab: > >> Wenn ich wissen möchte, mit welchen Mitteln ich dort bezahlen kann, > >> können Deine Tags besser ausgewertet werden, wenn mich interessiert, > >> ob ich mit *meiner* Karte bezahlen kann, dann kann mein Tagging > >> einfacher ausgewertet werden. > > > das gibt sich nicht viel... > > Das glaube ich Dir allerdings erst, wenn Du mir eine SQL-Abfrage für > Dein Schema bastelt, welche als Resultat hat, von wann bis wann ich an > einer bestimmten Tanke mit Maestero bezahlen kann. > das haengt ganz allein vom Datenbank-Schema bzw. der jeweiligen Anwendung ab. Drum kann ich dir hier keine pauschale Antwort geben. Aber es liesse sich durchaus bewerkstelligen, dass man in beide Richtungen schnell das gewuenschte Ergebnis bekommt, wenn es sein muss. Allerdings braucht es dazu mehr als ein simples key/value-Layout. signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
Am Dienstag 07 September 2010, 02:40:52 schrieb Thomas Ineichen: > > payment = cash;maestro;mastercard;dkv > > payment:2200-0700h = maestro > > > > oder wer's komplizierter haben will (dann waere der Automat noch mit drin): > > payment = cash;maestro;mastercard;dkv > > payment:2200-0700h = vending_machine > > vending_machine:payment = maestro > > Wenn schon, dann würde ich das umgekehrt machen > > payment = [wie jederzeit bezahlt werden kann] > payment:Zeitraum = [Zusätzlich kann in der Zeit auch mit XX bezahlt > werden] > > also > > payment = maestro > payment:0700-2200 = cash;mastercard;dkv > wuerde fuer diesen Fall so einfacher funktionieren, ja. Entwickelt wurde das Schema damals zwar fuer Zufahrtsbeschraenkungen entwickelt, aber es sollte durchaus auch universell verwendet werden koennen. Die Definition war: - Ein Tag ohne Zeitraumangabe ist erstmal immer gueltig. - Einzige Ausnahme: Ist zusaetzlich nochmal derselbe Key mit einer Zeitraumangabe vorhanden, wird das allgemeine Tag durch das eingeschraenkte ersetzt. Beispiel (zugegeben unwahrscheinlich, aber bei allgemeiner Verwendung des Schemas durchaus denkbar): Waehrend der Oeffnungszeiten kann man mit Bargeld, Kreditkarte und ec-Karte zahlen, ansonsten nur mit ec-Karte und Tankkarte. payment = cash;master_card;maestro payment:[2200-0700h] = maestro;dkv alternativ: payment = maestro;dkv payment:[0700-2200h] = cash;master_card;maestro mit deiner Logik waere das: payment = maestro payment:[0700-2200h] = cash;master_card;maestro payment:[2200-0700h] = dkv geht auch, finde ich aber unnoetig aufwaendiger... > > Wer das einfacher und eindeutiger hinbekommt, melde sich bitte... > > http://wiki.openstreetmap.org/wiki/Key:opening_hours > > payment:cash = 07:00-22:00 > payment:mastercard = 07:00-22:00 > payment:dkv = 07:00-22:00 > payment:maestro = yes (oder 24/7) das blaest das Ganze halt unnoetig auf, ohne grossen Mehrwert zu bringen. Ausserdem war das Ganze dazu gedacht, eben einerseits beliebige Tag- Kombinationen mit einer Zeitangabe zu versehen, andererseits nicht nur zeitliche, sondern auch andere Einschraenkungen (die natuerlich nicht fuer jedes Tag immer sinnvoll sind) wie Gewicht, Hoehe, Laenge, Breite anbringen zu koennen. > Hängt auch vom Anwendungsfall ab: > Wenn ich wissen möchte, mit welchen Mitteln ich dort bezahlen kann, > können Deine Tags besser ausgewertet werden, wenn mich interessiert, > ob ich mit *meiner* Karte bezahlen kann, dann kann mein Tagging > einfacher ausgewertet werden. das gibt sich nicht viel... 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] Werden Baumreihen gerendert?
Am Dienstag 07 September 2010, 00:11:03 schrieb M∡rtin Koppenhoefer: > werden Baumreihen denn nun gerendert oder nicht? er nu wieder... darum geht's doch gar nicht... ;-) k.A. ich wuerde vermuten nein, aber genau wissen das nur die Rendererbastler. 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] Projekt DE des Monats - Tankstellen
Am Montag 06 September 2010, 21:49:58 schrieb Jacques Nietsch: > Lange Rede, kurzer Sinn: tragt Tankstellen ein wo immer ihr sie findet. > Ob der Name des Pächters vorhanden ist, alle Kreditkartenoptionen > eingetragen wurden und, und ... ist so was von egal! > Besser drin als gar nicht! Meine Rede. Wenn detailierte Informationen vorhanden sind, mitnehmen. Wenn nicht vorhanden, oder aus bestimmten Gruenden kein genaueres Mapping moeglich ist, dann wenigstens einen Node mit Tankstellentag hinpflanzen. Sowas sollte eigentlich Standard sein, wenn man fuer OSM Daten sammelt... 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] Werden Baumreihen gerendert?
Am Montag 06 September 2010, 09:14:19 schrieb NopMap: > Friedhelm Schmidt wrote: > > Der Tag natural=tree ist intuitiv. Wir sollten ihn generalisieren und ab > > sofort beginnen, Zusatztags für weitere Eigenschaften festzulegen. > > Das ist genau der Denkfehler. Die Tags sind teilweise _nicht_ so definiert, > wie man das intuitiv erwarten würde und bei wortwörtlicher Interpretation > entsteht absolutes Chaos. genau darum geht es aber, das Tagging soll doch menschenlesbar und damit intuitiv sein, sonst koennten wir ja gleich irgendwelche kryptischen Kuerzel dafuer verwenden. natural=tree heisst Baum, nicht mehr und nicht weniger. "Wichtiger, alleinstehender Baum" als primaeren Zweck kann ich beim besten Willen nicht in dieses tag hineininterpretieren. Da haette man es schon natural=significant_tree oder so nennen muessen. Hier passen also bestehende Definition und Tag nicht zusammen. Also muss man entweder das Tag oder die Definition aendern. Die Definition zu aendern ist da deutlich der einfachere Weg, den auch ein signifikanter Baum bleibt ein Baum. Der Vergleich mit dem "Fahrradweg" hinkt uebrigens ein wenig, den dort ist die Materie wesentlich komplizierter. 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] Werden Baumreihen gerendert?
Am Montag 06 September 2010, 18:27:19 schrieb Stephan Wolff: > Bei Stromleitungen wurde zur Unterscheidung von Hochspannungs- und > Mittelspannungsleitungen neben power=line auch power=minor_line > eingeführt, obwohl auch eine Mittelspannungsleitung technisch unter den > Begriff "line" fallen würde. > deswegen wuerde ich hier auch das minor als zusatzinformation zu einem allgemeinen power=line bevorzugen... > Als natural=minor_tree oder natural=insignificant_tree können analog > auch Vorgartenbäume erfasst werden ohne mit den bisherigen Einträgen von > natural=tree zu kollidieren. > dann hast du schon wieder drei total verschiedene Tags, die im Prinzip erstmal dasselbe darstellen, naemlich einen Baum. Ausserdem musst du dann wieder definieren, was wohin gehoert, mit fliessenden Grenzen etwas schwierig... Dann doch lieber ein allgemeines Tag fuer Baum, und weitere Besonderheiten oder Groessenangaben koennen bei Bedarf ergaenzt werden. > Wenn jemand auf die Idee kommt natural=stone umgangssprachlich > umzudeuten, könnte der OSM-Datenbestand stark anwachsen... > Da seh ich keine so grosse Gefahr kommen; Steine von "nicht besonderer Groesse" sind im allgemeinen nicht an einen Ort gebunden, und haben damit nichts in einer Geodatenbank verloren. 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] PAYMENT und payment:fuel_cards
On Mon, Sep 06, 2010 at 09:46:37AM +0200, Jan Tappenbeck wrote: > Wenn ich z.B. die "Esso Card" habe - wie ist das Tag zu schreiben > esso_card - esso-card wie ist es allgemein mit Leerzeichen. Leerzeichen werden in Tags i.A. durch _ ersetzt. signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
Am Montag 06 September 2010, 00:42:18 schrieb Garry: > Für Deutschland gesprochen geht die EC-Karte an den Automatentankstellen > fast immer und die dürften die meisten Autofahrer > vor allen anderen Karten haben wenn sie eine als solche gekenzeichnete > Tankstelle zu unüblichen Zeiten anfahren. > OSM ist nicht nur Deutschland. > >> Für den Rest ist es schwierig die nötigen Informationen flächendecken > >> aktuell zu halten. > >> Schön wenn es klappt, aber wenn es zu Lasten der Masse (unverlässliche > >> Daten für alle) geht hat keiner was davon. > > > > Dieses Problem wirst du immer haben - und das nicht nur bei Tankstellen. > > Immer noch besser, als mit deiner Methode die Daten mutwillig zu > > faelschen. > > Wieso fälschen? Wenn du die Definition fuer dein Standardfuel in der Zukunft aenderst - und der "Standard" wird sich irgendwann aendern, dann aenderst du damit implizit die Tags fuer die vorhandenen Kraftstoffsorten jeder damit getaggten Tankstelle, ohne zu zu wissen ob das vor Ort jeweils wirklich so ist. > > Du vertraust darauf, obwohl du selbst behauptest, es waere schwierig, die > > Daten flaechendeckend aktuell zu halten? Komische > > Argumentation...http://lists.openstreetmap.org/listinfo/talk-de > > Ich behaupte je aufwendiger der zu erfassende Datensatz ist um so > geringer ist die Chance dass er flächendeckend erfasst und > vor allem aktuell gehalten wird. Ach komm, genaues Tagging ist in OSM sowieso schon relativ komplex, das muss man nicht auch noch durch unsinnige Zusatztags verschlimmern. Wenn dir die drei Klicks zuviel sind, muss man das halt im Editor machen: Die gaengigen Sorten sind beim Anlegen einer Tankstelle bereits ausgewaehlt, oder besser, es gibt ein "Standard"-Haekchen, das beim Anklicken die zur Zeit gaengigen Sorten automatisch auswaehlt. 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] Werden Baumreihen gerendert?
Am Sonntag 05 September 2010, 23:28:17 schrieb NopMap: > M∡rtin Koppenhoefer wrote: > > PS: Ich habe die Wikibeschreibung an das übliche Tagging angepasst. > > Wenn das zu einem Editwar führen sollte, müssen wir halt doch > > abstimmen > > Rückgängig gemacht. Die Definition steht so seit 2006. Die kannst Du nicht > mal eben so eigenmächtig umschmeißen. Wenn Du daran ernsthaft rütteln > willst, solltest Du vielleicht mal eine Diskussion auf der Taggingliste > anstoßen oder ein Gegenproposal einleiten. > > Die Definition ist meiner Ansicht nach einfach, gut zu verstehen und wo > immer ich sie angetroffen habe auch sinnvoll eingesetzt - bis auf das > neumodische Baum-Spamming in Ortschaften. und wozu soll eine "Definition" im Wiki gut sein, wenn der groesste Teil des praktischen Mappings ganz anders gehandhabt wird? natural=tree bedeutet Baum. Punkt. Ein besonderer Baum braucht eine zusaetzliche Info, warum er etwas besonderes ist. Schnell, einfach, eindeutig. 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] Projekt DE des Monats - Tankstellen
Am Sonntag 05 September 2010, 19:56:40 schrieb C. Brause: > Wo ist dieses Schema zu finden? Nur ums sich mal anzusehen. > hier gibt's eine Uebersicht, die ist aber nicht mehr ganz aktuell glaube ich: http://www.gpsdrive.de/development/map-icons/overview.en.shtml ansonsten wird es hier verwendet: http://svn.openstreetmap.org/applications/share/map-icons/geoinfo.db 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] Projekt DE des Monats - Tankstellen
Am Sonntag 05 September 2010, 20:11:17 schrieb M∡rtin Koppenhoefer: > Am 5. September 2010 19:56 schrieb C. Brause : > > Am 05.09.2010 19:04, schrieb Guenther Meyer: > >> Es gibt ein POI-Schema, da werden fahrzeugrelevante Objekte mit vehicle > >> = ... > >> gekennzeichnet. > > sowas ist keine schlechte Idee (ich weiss, Du hast das schon seit > Jahren, aber solange es halt nicht im Mapnik und den übrigen > "relevanten" Anwendungen ist, siehts schlecht aus). ich hatte ja damals um Mithilfe gebeten, das mal einzubauen, aber da kam ja leider nix... > Wenn man z.B. die Kfz-Zulassungsstelle taggen will, dann kann man das > mit vehicle tun. Ein anderer will aber z.B. alle Ämter+Behörden > taggen, und wenn wir jetzt alles als amenity drin haben (z.B. > amenity=public_building [1] ), bräuchten wir verschiedene Werte im > selben Key. Und damit siehts halt auch schlecht aus. Das kann dir bei jeder Art von Kategorisierung passieren. Aber ob alles in einen generischen Key zu packen, die bessere Loesung ist, wage ich zu bezweifeln... 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] Projekt DE des Monats - Tankstellen
Am Sonntag 05 September 2010, 18:28:02 schrieb Peter Wendorff: > > amenity=charging > > mir gefällt das amenity nicht, ich würde bei der Gelegenheit eventuell > versuchen, einen Oberbegriff zu finden für den Themenkomplex, also für z.B. > - Strommobil-Ladestationen > - Tankstellen > - Auto-Waschanlagen > - TÜV-Niederlassungen > - ? > +1 > mit car_service=* bin ich noch nicht ganz zufrieden - aber vielleicht > fällt jemandem was besseres dazu ein. > Es gibt ein POI-Schema, da werden fahrzeugrelevante Objekte mit vehicle = ... gekennzeichnet. (Fahrzeug im Sinne von "selbst fahren", also keine oeffentlichen Verkehrsmittel). 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] Projekt DE des Monats - Tankstellen
Am Sonntag 05 September 2010, 02:32:59 schrieb Garry: > > Was bringt' dir denn, wenn du dann mit leerem Tank vor dem Tankautomaten > > stehts, und dieser deine bevorzugte Kreditkarte gar nicht akzeptiert? > > Das Problem hatte ich schon öfters in Frankreich da deren Automaten sehr > wählerisch sind(bzw. waren) bzgl. der > Kartenakzeptanz. Es hat sich dann immer ein freundlicher "Mittanker" > gefunden der gegen Bares auf seine Karte für > mich getankt hat. > Eben, aber es wird nicht immer ein freundlicher Mittanker vorhanden sein. Deshalb ist eine alleinstehende Angabe wie 24h_service=selfpayment fuer den Anwender relativ nutzlos, wenn er nicht zufaellig alle moeglichen Karten inkl. genug Bargeld mit sich fuehrt. > > und wer definiert die "ueblichen" Sorten? > > die sind naemlich von Land zu Land durchaus verschieden, und aendern sich > > auch mit der Zeit. Frueher gehoerte "Super verbleit" zum Standard, in > > ein paar Jahren ist vielleicht auch Gas oder Strom darunter > > einzuordnen... > > OSM ist flexibel genug sich der Zeit anzupassen. Üblichen Sorten sind > einfach die die man in seinem Land > an jeder Tankstelle bekommt. und wie willst du das machen? Beispiel: Du definierst heute fuel=standard als "octane_95;octane_98;diesel". In einigen Jahre ist an deutschen Tankstellen zusaetzlich auch Gas und Biodiesel ueblich, also erweiterst du die Definition um "biodiesel;lpg". Damit veraenderst du automatisch die Bedeutung aller mit fuel=standard getaggten Tankstellen fuer z.B. Gasfahrer, weil du ihnen damit sagst sie koennten dort tanken, was aber in der Realitaet nicht ueberall der Fall sein muss. Abgesehen davon muss der laenderabhaengige Standard genau so gewartet werden. Ebenso ein Problem: Wenn ich im Ausland eine Tankstelle mappen will, weiss ich nicht, was dort Standard ist; ich sehe aber, welche Zapfsaeulen vor mir stehen... > Für den Rest ist es schwierig die nötigen Informationen flächendecken > aktuell zu halten. > Schön wenn es klappt, aber wenn es zu Lasten der Masse (unverlässliche > Daten für alle) geht hat keiner was davon. Dieses Problem wirst du immer haben - und das nicht nur bei Tankstellen. Immer noch besser, als mit deiner Methode die Daten mutwillig zu faelschen. > >> Kann mir schwer vorstellen dass sich das in der Anwendung niederschlägt: > >> "Das gewählte Ziel ist seit 5Jahren in der Datenbank unverändert, sind > >> Sie sicher dass sie dort hin wollen?" > > > > Ich kann mir das durchaus vorstellen. Wie sonst willst du das Problem > > angehen? > > Darauf vertrauen dass die Mapper die Daten aktuell halten - das tun Sie > um so ehr je einfacher sie ihr Wissen > einbringen können. Du vertraust darauf, obwohl du selbst behauptest, es waere schwierig, die Daten flaechendeckend aktuell zu halten? Komische Argumentation... 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] Werden Baumreihen gerendert?
Am Samstag 04 September 2010, 22:35:29 schrieb Friedhelm Schmidt: > Am 04.09.2010 20:55, schrieb Michael Kugelmann: > > Wenn das Tag so verwendet worden wäre, wie es seit Jahren (!) definiert > > ist, wäre es kein Problem gewesen... > > Im Wiki steht viel, wenn der Tag lang ist. Das weiß jeder ernsthafte > OSM-Teilnehmer. > > Man kann doch nicht einfach einen generischen Tag wie natural=tree in > Beschlag nehmen und sagen: "Das ist aber nur für besondere Bäume". Und > wie sollen dann normale Bäume heißen, etwa ordinary_tree? > +1 wenn man ein Tag fuer "besondere" Baeume definiert, dann sollte man auch passende Begriffe nehmen, die wenn meoglich irgendwie intuitiv nutzbar sind, ohne langes Studium im Wiki. Aus natural=tree laesst sich keineswegs lesen, dass das Tag nur fuer besondere Baeume gedacht ist... > Es stimmt schon: noch vor zwei Jahren hätte keiner gedacht, dass wir mal > einzelne Bäume erfassen werden. Daher wohl die völlig überflüssige > Einschränkung im Wiki. > deshalb: weg mit der Einschraenkung! > Es gibt aber nicht so viele bedeutende Bäume. Deshalb ist es kaum ein > Problem, denen ein Zusatztag zu verpassen. In "meinem Revier" kann ich > das in weniger als 10 Minuten erledigen. +1 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] Projekt DE des Monats - Tankstellen
Am Samstag 04 September 2010, 15:27:49 schrieb Garry: > Am 04.09.2010 12:15, schrieb Guenther Meyer: > > Das Problem laesst sich aber nicht einfach loesen, indem man gar keine > > Daten eintraegt. > > Nein, das nicht, aber ein-zwei einfache Tags die schnell und einfach > auszuwerten sind und dem Durschnittstankenden > die wichtigsten Informationen gibt wäre nicht schlecht: Also z.b. > 24h_service = yes/no/members/selfpayment - letzteres für > Automatenbezahlung ohne näher auf die Bezahlarten einzugehen und members > wenn Tanken nur für spezielle Kunden > möglich ist (gibt es z.B. manchmal in Industriegebieten für grössere > Firmen mit besonderen Berechtigungskarten/Chips) Diese Informationen anzugeben ist durchaus sinnvoll, aber nicht ausreichend. Was bringt' dir denn, wenn du dann mit leerem Tank vor dem Tankautomaten stehts, und dieser deine bevorzugte Kreditkarte gar nicht akzeptiert? > Und als zweites noch ein special_fuel = yes/no um anzuzeigen ob es nur > die üblichen Spritsorten (Benzin/Diesel) oder > ein erweitertes Angebot gibt. und wer definiert die "ueblichen" Sorten? die sind naemlich von Land zu Land durchaus verschieden, und aendern sich auch mit der Zeit. Frueher gehoerte "Super verbleit" zum Standard, in ein paar Jahren ist vielleicht auch Gas oder Strom darunter einzuordnen... > Kann mir schwer vorstellen dass sich das in der Anwendung niederschlägt: > "Das gewählte Ziel ist seit 5Jahren in der Datenbank unverändert, sind > Sie sicher dass sie dort hin wollen?" Ich kann mir das durchaus vorstellen. Wie sonst willst du das Problem angehen? 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] Werden Baumreihen gerendert?
Am Samstag 04 September 2010, 13:31:22 schrieb Falk Zscheile: > Natürlich kann man alles in die Karte eintragen, nur ist es auch Sinnvoll? wenn es eine Anwendungsmoeglichkeit gibt, die irgendjemanden nuetzt, ja. > Der einzelne Baum ist ohne Bedeutung. Die Orientierung bietet die > Baumreihe/Allee und sollte auch nur als solche eingetragen werden. > in einer Baumreihe mag das durchaus sinnvoll sein, nicht jeden Baum einzeln zu taggen. Ebenso innerhalb eines Waldes. Aber moeglich sollte es durchaus sein. Eine Grupe von 2-3 Bäumen zum Beispiel ist weder Wald noch Reihe, aber durchaus zur Orientierung nuetzlich. Ob du in deiner Karte die Einzelbäume anzeigst oder nicht, ist dann deine Sache... 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] Werden Baumreihen gerendert?
Am Samstag 04 September 2010, 13:09:18 schrieb M∡rtin Koppenhoefer: > Am 4. September 2010 11:16 schrieb NopMap : > > Wobei das allerdings so ein Mißbrauch ist, denn natural=tree steht für > > "lone, significant tree", also ein markanter Einzelbaum als Landmarke. > > Ich halte das für eine unsinnige Definition, die auch von der Realität > schon länger überholt ist. natural=tree ist intuitiv ein Baum. > Merkmale wie Markanz / Signifikanz sollten mit einem Zusatztag > ausgedrückt werden. +1 > > Ich arbeite momentan eher daran, solche nicht-markanten, > > nicht-orientierungsrelevaten Bäume aus dem Rendering auszublenden. > > Wie kannst Du sowas wie "nicht-orientierungsrelevant" postulieren? > Jedes Detail kann der Orientierung dienen, unabhängig von der Größe. +1 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] Im Bau befindliche Brücke
Am Samstag 04 September 2010, 03:06:36 schrieb M∡rtin Koppenhoefer: > > Mein Vorschlag dazu war das "construction" auch andere Zustände annehmen > > kann die den aktuellen > > Bauzustand wiederspiegelt -ähnlich wie "grade" bei den Tracks bzgl. der > > Wegqualität. > > construction=yes wäre nur der Grundtyp der überhaupt anzeigt das dort > > gebaut wird - einheitlich übergreifend für alle Objekte, > > nicht nur für highways. > > wie wärs mit "status"? Wenn das Wort "construction" nun schon anders > verwendet wird, musst Du halt was anderes verwenden. > vielleicht besser: construction:status = ... 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] Projekt DE des Monats - Tankstellen
Am Samstag 04 September 2010, 03:07:19 schrieb Garry: > > ja!? und worauf willst du jetzt hinaus? > > Darauf dass im Prinzip da wo die schlechteste Datenpflege zu erwarten > ist die Daten am wichtigsten sind. ah, ok. ich hatte mich schon gefragt, was das Ganze mit meinem Taggingvorschlag zu tun hat... Das Problem laesst sich aber nicht einfach loesen, indem man gar keine Daten eintraegt. Da das letzte Bearbeitungsdatum eines Objekts sowieso gespeichert wird, ist es fuer eine auswertende Software ein Leichtes, auf evtl. veraltete Daten hinzuweisen. 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] Projekt DE des Monats - Tankstellen
Am Samstag 04 September 2010, 01:16:10 schrieb Garry: > Hört sich meiner Meinung nach zu Aufwendig an als dass es gut genug > gepflegt wird. nicht aufwendiger als bereits Bestehendes... > Sieh es mal aus Anwendersicht - die ganzen Details nützen nur wenn sie > auch aktuell sind. > Das ist aber kaum zu erwarten wenn man bedenkt wie viele Tankstellen > heute noch gar nicht erfasst sind. > Bzw. wenn diese ganzen Details in der Anwendung auftauchen sollte auch > das Erstellungsdatum dazu damit sich > der Anwender wenigstens ein Bild davon machen kann wie aktuell die Daten > sind. > Schliesslich haben die ganzen Daten doch insbesondere dann ihren > höchsten Nutzen wenn der Anwender ausserhalb > der normalen Geschäftszeit in dünn besiedelten Gegenden auf eine > Tankstelle angewiesen ist. > ja!? und worauf willst du jetzt hinaus? 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] Projekt DE des Monats - Tankstellen
Am Freitag 03 September 2010, 10:12:02 schrieb Frank Sautter: > der name, marke, betreiber und der pächter: > der offizielle name ist "JET Tankstelle an der B464" oder tragen wir da > nur "JET" ein? > wenn das Ding offiziell so heisst, dann sollte man das auch vollstaendig so eintragen. > tragen wir zusätzlich "brand=JET" ein? > +1 > der operator ist in diesem fall die "ConocoPhillips Germany GmbH" (mit > ihrer marke "JET") hat aber einen pächter (tenant=Manfred Treffler). > bisher sind die ganzen pächter aber bei den meisten tankstellen als > "operator" eingetragen... in meinen augen falsch. > +1 > das bezahlen: > "payment:coins" und "payment:notes" (eigentlich für vending machines > gedacht) halte ich für unfug. da sollte man über "payment:cash" nachdenken. > waere fuer Nicht-Automatenzahlung einfacher, ja. cash ist dann quasi als coins;notes definiert. > wie werden die akzepzierten kreditkarten erfasst? wie sehen da die > gültigen werte aus? nur "no" oder "yes" oder sowas wie > "diners_club;visa;mastercard" > > wie werden die marken- und länderübergreifenden tankstellenkarten DKV, > UTA, etc. getaggt? als payment:dkv=yes oder eher > payment:accountcards=dkv;uta > Eine Konstruktion wie payment:accountcards oder payment:creditcards bringt keine sinnvollen Zusatzinformationen, denn die einzelnen Karten muessen sowieso explizit genannt werden. Warum also nicht die ganzen Bezahlarten in einem Tag zusammenfassen: payment = cash;maestro;mastercard;visa;dkv;uta dasselbe waere auch fuer die fuel-Arten sinnvoller... > was machen wir bei 24/7 tankstellen, die einen "normalen" > geschäftsbetrieb tagsüber haben und bei nacht nur noch > automatentankstellen sind (stichwort eingeschränkte bezahlarten) > ich hatte vor laengerer Zeit mal was fuer eingeschraenkte Zufahrtsbeschraenkungen (access...) vorgeschlagen; das Schema koennte man hier auch anwenden, das waere irgendwie so: payment = cash;maestro;mastercard;dkv payment:2200-0700h = maestro oder wer's komplizierter haben will (dann waere der Automat noch mit drin): payment = cash;maestro;mastercard;dkv payment:2200-0700h = vending_machine vending_machine:payment = maestro das bedeutet dann: * Bezahlen kann man normalerweise bar oder mit den genannten Karten * Einschraenkung: im Zeitraum von 22-7 Uhr gibt's nur einen Automaten * Der Automat nimmt nur ec-Karten an. Wer das einfacher und eindeutiger hinbekommt, melde sich bitte... 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] Navigations-Hinweise auf Autobahnen ( war: Autobahnrouting)
Am Dienstag 31 August 2010, 21:13:41 schrieb Michael Kugelmann: > Am 30.08.2010 23:31, schrieb Guenther Meyer: > > wie waer's mit name? > > passt m.E. nicht. > Name wäre z.B. "Autobahnkreuz Kleindorf" während das Schild sagt "hier > abbiegen Richtung 'Paris, Hamburg' ". > Aber der Parallel-Kommentar hat einen Hinweis gegeben. > ok, ueberredet. hatte jetzt nur an Ausfahrten, und nicht an Kreuze gedacht... 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] Navigations-Hinweise auf Autobahnen (war: Autobahnrouting)
Am Montag 30 August 2010, 23:05:15 schrieb Michael Kugelmann: > Die Ansage entsprach (fast) immer > der obersten Zeile in den Schildern. Aus den Zielen wo die Autobahn > hinführt kann dies nicht abgeleitet werden => muss von den kommerziellen > Navi-Anbietern erfasst und von der Navi-SW zur Ansagee verwendet werden. > Macht es Sinn diese Informationen von den Schildern zu erfassen und > zumindest an jeder entsprechenden größeren Kreuzung/Autobahnabfahrt zu > hinterleg? > das wird noch nicht gemacht? Ich hatte hin und wieder entsprechende Daten gesammelt, an´ber leider nie eingetragen... > Wenn ja: mit welchen Tags sollte man so etwas machen? > wie waer's mit name? 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] Fernsehbericht im Bayerischen Rundfunk
Am Sonntag 29 August 2010, 11:38:04 schrieb malenki: > Walter Nordmann schrieb: > >p.s. ihr rennt immer noch mit block rum? schnappt euch ne digi-cam und > >beschäftigt euch mal mit geotagging in josm. einfach tracks und bilder > >laden, kurz anpassen und loslegen. > > Dann mach bitte mal eine Skizze oder einen groben Lageplan einer > unübersichtlichen Ecke mit Digicam. > +1 manchmal ist das gute alte Papier immer noch die beste Wahl. Zum Bericht: Schoen gemacht, v.a. der Vergleich zu kommerziellem Material! 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] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Am Mittwoch 25 August 2010, 14:38:44 schrieb Bernd Wurst: > Am Mittwoch 25 August 2010, 12:37:13 schrieb Guenther Meyer: > > Das Thema Attributierung ist in den ganzen Jahren immer wieder mal > > hochgekommen, da gab's genug Gelegenheit, sich zu Wort zu melden. > > Aber das Warten auf eventuellen Einspruch ist halt in keiner Weise > rechtsverbindlich. ja was denn sonst? Wer bei OSM mitmacht, hat einer Lizenz zugestimmt. Wenn jemand mit der Ausfuehrung dieser nicht einverstanden ist, muss er sich melden. Ich koennte auch reihenweise kriminelle Dinge tun, solange mich keiner anzeigt, interessiert es niemanden und es hat auch keine rechtlichen Konsequenzen. 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] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Am Mittwoch 25 August 2010, 10:23:02 schrieb Bernd Wurst: > Ich habe aber ein Problem damit, dass manche Leute meinen, die CC-by-SA > wäre ne gute Lizenz für unsere Daten. > > Daher skizziere ich ein naheliegendes Szenario bei dem es eben für jeden > einzelnen, der die Daten unter CC-by-SA weiter verwenden will unweigerlich > zu Problemen kommt, sobald auch nur ein einziger Mapper auf seine Rechte > aus der Lizenz beharrt. > dann stell das bitte auch klar raus, was deine Meinung ist, und was das "Szenario". Ja, ich weiss, das hattest du irgendwann irgendwo im Thread getan, aber sowas geht bei der Fuelle der Paralleldiskussionen schnell verloren. > > Seit ich dabei bin (und das sind mehrere Jahre) gab es praktisch > > niemanden bei OSM, der mit "(C) OSM and Contributors" *nicht* > > enverstanden war. > > Hast du alle gefragt?! Ich kann mich nicht erinnern, von dir gefragt worden > zu sein. Oder von sonst irgend jemandem. > Nein, natuerlich nicht. Das Thema Attributierung ist in den ganzen Jahren immer wieder mal hochgekommen, da gab's genug Gelegenheit, sich zu Wort zu melden. Vereinzelt passierte das auch, aber Konsens war immer das von Michael beschriebene. > Die ODbL ist okay (hoffe ich verstanden zu haben), die CC-by-SA ist es > nicht (für diesen Zweck). > dann passt ja eh alles ;-) 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] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Am Mittwoch 25 August 2010, 09:47:53 schrieb Bernd Wurst: > Am Mittwoch 25 August 2010, 09:27:58 schrieb Michael Kugelmann: > > Deswegen ist ein "(C) OSM and Conrtibutors" für mich ein gangbarer Weg. > > Genau. Deswegen ist nicht *DEINE* Meinung wichtig sondern der gemeinsame > Nenner *ALLER* OSM-Autoren. > und dieser entspricht deiner Meinung?!?! Wo lebst du eigentlich?! Seit ich dabei bin (und das sind mehrere Jahre) gab es praktisch niemanden bei OSM, der mit "(C) OSM and Contributors" *nicht* enverstanden war. > Und da weder du noch ich noch sonst irgendjemand garantieren kann, dass der > "gangbare Weg" für alle Zeit von allen Autoren so gesehen wird, muss man > diesen Punkt ganz unstrittig in die Lizenz schreiben. Wenn du spezielle Klauseln in die Lizenz haben willst, dann haettest du dich an deren Entwicklung beteiligen koennen. Hier bringt das gar nichts. 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] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Am Dienstag 24 August 2010, 15:06:00 schrieb Dirk-Lüder Kreie: > Am 24.08.2010 10:32, schrieb Guenther Meyer: > > Macht doch einfach mal Naegel mit Koepfen: > > > > 1. Anschreiben aller Mapper mit Bitte um Zustimmung zur Lizenzaenderung > > (Bald!), und eine angemessene Zeit warten (einige Monate) > > Das ist für September/Oktober 2010 geplant > > > 2. Dann hat man konkrete Zahlen, und kann schauen, was geloescht werden > > muesste. Wenn's zuviel wuerde, > > > > 3. dann gibt man den Mappern, die bisher nicht zugestimmt haben, die > > Gelegenheit, doch noch zuzustimmen, bzw. sich ueberzeugen zu lassen. > > Das ist ebenfalls so schon geplant. na endlich mal was Positives in dieser ganzen Lizenzdiskussion :-) 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] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Am Dienstag 24 August 2010, 14:21:54 schrieb Bernd Wurst: > Am Dienstag 24 August 2010, 09:45:34 schrieb Ulf Lamping: > > Ob da dann auf der Karte dein > > oder mein Name draufstehen muß, ist damit erstmal überhaupt nicht > > gesagt, sondern (d)eine Interpretation des Lizenztextes. > > Letztlich habe ich halt keine hardcopy angefertigt, Beweise habe ich > folglich keine. Aber meiner Meinungn nach bin ich beim Registrieren meines > OSM- Useraccounts nicht darüber informiert worden, dass ich meine > Urheber-Rechte an die OSM-Datenbank abgebe. > da kannst du in Deutschland auch gar nicht... > Ich hätte das so verstanden, dass *ICH* meine Daten der OSM-Datenbank unter > CC-by-SA zur Verfügung stelle, damit das Gesamte dann eine tolle, "freie" > Weltkarte gibt. > ja. > Wenn ich die Daten unter der Lizenz zur Verfügung stelle und OSM diese nur > weiter nutzt, dann ist es naheliegender Weise nicht korrekt, wenn OSM > plötzlich festlegt, dass ich als Urheber nicht mehr genannt werden muss. > wo steht denn das?! Die Lizenz sagt "... in einer dem Medium angemessenen Form...", und das bedeutet sicher nicht, dass jeder einzelne Mapper explizit genannt werden muss. "OSM and Contributors" ist gut, wenn du dich nicht als "Contributor" siehts, ist das allein dein Problem. > Wie gesagt: Es wurde zwischenzeitlich (vermutlich mehrfach) der > Anmeldeprozess geändert, ausprobieren kann ich jetzt also nicht mehr, wie > das damals ausgedrückt wurde. Eine Analogie zu den aktuellen CT (»du gibst > deine Daten ab und wir werden die dann unter einer unserer Meinung nach > geeigneten Lizenz veröffentlichen«) gab es aber nicht. > wo steht das bitteschoen wieder?!? du solltest mal ein bisschen an deiner Wahrnehmung arbeiten... 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] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Am Dienstag 24 August 2010, 14:23:59 schrieb Bernd Wurst: > Es gilt halt nicht, was vermutlich manche gedacht haben sondern es gilt das > was anfangs kommuniziert wurde. Und das war CC-by-SA und nichts anderes. > richtig, aber man hatte ja nicht die Wahl, wenn man mitmachen wollte. Was ich eigentlich damit sagen wollte: Den meisten ist vermutlich die exakte Lizenz sch...-egal. Freie Daten fuer ein freies Projekt. Punkt. 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] 1 Jahr Lähmung von OSM durch Lizenzwechs el?
Am Dienstag 24 August 2010, 13:45:23 schrieb Sebastian Hohmann: > Nur werden die Daten unter einer anderen Lizenz veröffentlicht. Macht doch nix, die Daten sind ja trotzdem frei abrufbar ;-) > Gerade > mit der ODbL als Datenbank, kann man wohl kaum einzelne PD-Daten > rausziehen, selbst wenn die irgendwie geflaggt wären. > Jeder kann sich die Edits des entsprechenden Users als PD rausziehen, und damit machen was er will. Wenn diese allerdings auf Daten unter einer anderen Lizenz basieren, funktioniert das nicht mehr mit PD. Aber das sollte ja nichts neues sein... 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] 1 Jahr Lähmung von OSM durch Lizenzwechs el?
Am Dienstag 24 August 2010, 13:07:17 schrieb Sebastian Hohmann: > Darf man als PD-Befürworter keine Meinung zu einer Lizenz haben? schon. Nur ist das nicht ein bisschen widerspruechlich, wenn da steht "Macht mit meinen Daten was ihr wollt", und gleich daneben "Die ODBL find ich aber doof"? V.a. wenn die Wahrscheinlichkeit hoch ist, dass die Daten eben unter jener Lizenz genutzt werden? > Sicher, > sobald PD-Daten veröffentlicht sind, kann jeder damit machen was er > will. Nur müssen sie auch erstmal veröffentlicht werden. Die Daten ohne > Veröffentlichtung direkt in eine restriktivere Lizenz umzuwandlen, > dagegen kann ich sehr wohl sein. > Natuerlich. Nur im Falle von OSM sind die Daten sowieso oeffentlich, also stellt sich die Frage gar nicht. Selbst wenn sie nicht oeffentlich waeren, koenntest du das immer noch machen. > Oder sollte man auch dafür sein, dass z.B. staatliche Daten PD sein > müssen, gleichzeitig aber nichts dagegen haben dürfen, wenn die Daten > ohne Veröffentlichtung direkt einer Firma übergeben werden, die sie dann > unter eine unfreie Lizenz stellen? Das ist doch sinnlos. > Richtig. Das widerspricht zwar dem Gedanken von PD, waere aber durchaus denkbar. Doch wie gesagt: andere Baustelle > Insofern kann man doch auch dafür sein, dass OSM die Daten als PD > _veröffentlichen_ soll, aber gegen eine Veröffentlichung unter ODbL. *Du selbst* legst fest, unter welcher Lizenz *deine* Daten zu nutzen sind. Wenn du dich auf PD festlegst, kannst du hinterher keinen Einspruch mehr erheben, wenn die Daten in einer Form genutzt werden, die dir nicht zusagt. > Mit > den CT gibt man ja auch der OSMF die Möglichkeit, die Daten unter > CC-BY-SA oder ODbL zu veröffentlichen, man stellt sie ja nicht selbst > unter diese Lizenzen bevor man sie hochlädt (oder sehe ich das falsch?). > So sehe ich das auch. Nur mit der Auswahl von "PD" setzt du ganz klar diese Lizenz fuer deine Daten, wuerde ich sagen. 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
