date:20100721



"Dimitri Junker wrote:
> Einfach ausgedrückt ich wollte das Programm für mich haben und habe Visual
> C++, also hab ich es damit gemacht.
kann ich durchaus nachvollziehen, ging mir auch schon so. da ich aber immer
schon beruflich und privat auf mehreren hochzeiten - sprich platformen -
"tanze", bin ich auf opensource und platformunabhängigkeit gekommen.

Ich habe schon länger vor mal mit Java o.ä. anzufangen, aber jedesmal wenn 
> ich ein Programm brauche will ich es schnell nutzen und da verschiebe ich 
> das Einarbeiten in Java immer wieder.
was mutt, das mutt ;) ich bin auch noch dran.
allerdings ist java alleine noch nicht DIE lösung. es gibt hier im
osm-umfeld ein wirklich klasse programm, voll java mit prima gui, das unter
linux nicht laufen will, da dort MS-altlasten drin sind. wäre fast ein
kompletter rewrite notwendig. schade :(

gruss

walter


-
Ich bin root, ich darf das.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/neue-Windows-Programme-fur-OSM-tp5311737p5324210.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relation für relationale Struktur

2010-07-21 Diskussionsfäden Markus


Hallo ... ,


>>> Ist es ok, mit Relationen eine relationale DB-Struktur zu
>>> simulieren? Also Objekte zu Klassen zusammenzufassen?
>
> Also Relations sind keine Sammlungen von Daten mit den selben
> Eigenschaften.

Dazu entgegen habe ich folgendes gefunden:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults


http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories
und natürlich http://wiki.openstreetmap.org/wiki/Relationen


Ich kenne beide.
Aber wie sind die denn nun zu interpretieren?

Ich vermute mal, gesetziche Regelungen sind "Eigenschaften" die nicht 
über Relationen an Daten geknüpft werden sollen?

Also müsste solchen Relationen widersprochen werden?

Tilmann hingegen vermutet, dass sowohl gesetzliche Feiertage, als auch 
gesetzliche Regelungen (z.B. Höchstgeschwindigkeiten) über Relationen 
abgebildet werden sollen.


Ich möchte gern den "diskriminierenden Unterschied" wissen :-)

Gruss, Markus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Lizenzwechsel-Bauchscmerzen

2010-07-21 Diskussionsfäden Gehling Marc


Am 22.07.2010 um 08:09 schrieb Guenther Meyer:

> Am Mittwoch 21 Juli 2010, 23:05:09 schrieb Christian Schmitt:
>> Was könnte konkret passieren wenn die Quellenangabe nicht verpflichtend
>> ist? Ich sehe es momentan nicht - bitte hilf mir auf die Sprünge.
> 
> Es werden interessante Anwendungen geschaffen, kommerzielle Hersteller 
> profitieren von ausgezeichnetem Datenmaterial und kriegen den ganzen Ruhm.
> Von OSm als eigentlicher Datenquelle erfaehrt niemand was.
> Deshalb fragen sich potentielle neue Mapper auch, wieso sie ueberhaupt bei 
> OSM 
> mitmachen sollten, bzw. wozu das Projekt gut sein soll - denn die 
> kommerziellen haben doch eh alles, was man braucht...

Ich glaube ehr, das Hersteller in Zukunft damit werben, osm-daten zu benutzen. 

-> osm-inside


Wer es nicht macht, da kann man direkt vermuten, das er Lizenzprobleme mit dem 
Verschnitt von seinen und osmdaten hat.

Marc


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Lizenzwechsel-Bauchscmerzen

2010-07-21 Diskussionsfäden Guenther Meyer

Am Mittwoch 21 Juli 2010, 23:05:09 schrieb Christian Schmitt:
> Was könnte konkret passieren wenn die Quellenangabe nicht verpflichtend
> ist? Ich sehe es momentan nicht - bitte hilf mir auf die Sprünge.

Es werden interessante Anwendungen geschaffen, kommerzielle Hersteller 
profitieren von ausgezeichnetem Datenmaterial und kriegen den ganzen Ruhm.
Von OSm als eigentlicher Datenquelle erfaehrt niemand was.
Deshalb fragen sich potentielle neue Mapper auch, wieso sie ueberhaupt bei OSM 
mitmachen sollten, bzw. wozu das Projekt gut sein soll - denn die 
kommerziellen haben doch eh alles, was man braucht...




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] postgresql und/oder postgis


hi peter,

danke für die "späte" antwort ;)


Generell gibt es folgende Spalten:
> ...
> 
aha, einen kleinen schritt weiter; die spalten hatte ich schon aber manche
sind doch sehr "cryptisch". wenn ich erst an way/type geometry denke - aber
das brauche ich zur zeit hoffentlich nicht.

zusätzlich möchte ich dich auf diesen Abschnitt der Doku hinweisen. Die 
> Queries kannst du über den psql-Prompt ausprobieren:
> 
> 
> 
ohne dieses wiki würden ja die diff-updates bei mir nicht laufen. aber das
sind doch nur ein paar test-abfragen.es kann doch nicht sein, dass die
datenstruktur nirgens beschrieben ist. zumindest was die verschiedenen
tabellen bedeuten.
aber ich werd wohl an die developer rangehen müssen :( 

derzeit suche ich bei der postgis-doku um da weiter zu kommen.

-
Ich bin root, ich darf das.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/postgresql-und-oder-postgis-tp5322689p5324033.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?

2010-07-21 Diskussionsfäden Tirkon

Peter Körner  wrote:

>> Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall
>> helfen

Man beachte den Konjunktiv "könnten".

>Nur mal aus Interesse (bitte nicht als Kritik missverstehen):
>würdest du auch solche Feldwege mit zwei Linien abbilden? Fahren kann 
>man ja in beiden Richtungen drauf..
>
>Wie steht es mit kleinen Landstraßen, die keine Mittellinie haben, und 
>solchen, deren Mittellinie schon abgefahren ist?
>
>Es ist hier schwer die Grenze zu ziehen, denke ich.

Man beachte den Konjunktiv "könnten". Ich bin mir bewusst, dass
Linienbündel nur in vielen, aber nicht in allen Fällen helfen und
daher auch keine Allheilmittel sind, sondern nur eine Milderung des
Problems darstellen. Zudem können sie die Sache durchsichtiger machen.
Denn ein Tag auf der richtungsgebundenen Fahrspur ist suggestiver, als
forward und backward. Es bleibt aber trotz Linienbündel nach einer
Lösung zu suchen. Die komplexen Einzelheiten der Linienbündel bringen
unser Kernproblem hier nicht weiter.

>Angenehmer wäre ein definiertes Taggingschema für Richtungsabhängige 
>Tags, z.B. durch vier Namensräume in den Tags: right, left, forward, 
>backward. Die Tags könnten dann so aussehen:
>
>forward:maxspeed=30
>right:parking=yes
>
>es ist dann klar, dass bei einer Richtungsänderung aus allem was mit 
>forward: getaggt ist ein backward werden muss. Leider ist 
>"forward:maxspeed" weiter von "maxspeed" entfernt als 
>"maxspeed:forward", weshalb  das letztere häufige verwendet wurde.

Alles soweit klar. Nur hat das eben den Nachteil, dass dies Alles mit
der Richtung des Ways steht und fällt mit allen Problemen, die ich
schon im Ursprungsposting beschrieben habe. Darum wäre es sinnvoll,
Folgendes zu tun: 

>Generell wäre es möglich die definition von right, left, forward und 
>backward von der Wegrichtung zu lösen:
>
>Wenn ein Tag "direction" vorhanden ist, wird der statt der eigentlichen 
>Weg-Richtung verwendet. Was "direction" jetzt genau enthält bleibt zu 
>Diskutieren: 

Genau, jedes Tag und jede Routen-Relation müsste seine eigene
"Richtung" haben. Aber genau hier liegt der Hund begraben. Wie will
man diese Richtung festlegen und in der Datenbank unterbringen?

>Eine Himmelsrichtung

Himmelsrichtung habe ich auch drüber nachgedacht. Aber dann muss man
eine Grenze setzen, wo die Richtung umkippt. Wenn ein Way nahe an
dieser Grenze verläuft, dann kann die Richtung durch Ziehen von Knoten
im Way umkippen.

>eine Node-Nummer 

Das ist es! :-)

Bisher kannte ich von XML nur den Namen und habe gerade erst etwas
darüber gelesen. 

Ich habe mit JOSM einen Way mit drei Nodes erstellt:

und dann die Richtung umgedreht:

Das OSM Format gibt offenbar die Richtung eines Ways durch die Abfolge
der Node-Nummern an. Denn das ist das Einzige, was sich bei einer
Umkehr des Weges ändert. Jetzt müsste man statt "backward" und
"forward" ebenfalls die Richtung durch die Abfolge der Node Nummern
angeben. Ich will das Ganze mal mit "Richtung eines Tags" titulieren.
Jetzt kann man die Richtung des Weges umdrehen, wie man lustig ist,
ohne die Richtung des Tags zu ändern.

Wie gehabt: Ich habe gerade das erste Mal etwas über XML gelesen. Was
jetzt kommt, ist also mit Sicherheit nicht richtig. Aber entfernt
könnte das Ganze dann so aussehen:  

Ausgesagt werden soll, dass sich die jeweilige Maxspeed auf die
jeweilige Richtung bezieht. Möglicherweise lässt sich das auch soweit
eindampfen, dass man nur den ersten und den letzten Node angibt. Es
könnte aber Gründe geben, warum man dies beim Way nicht getan hat.
Dieselben Gründe könnten auch dagegen sprechen, beim Tag ebenso zu
verfahren. Ich kann das mit meinem derzeitigen Kenntnisstand nicht
beurteilen.

Vielleicht kann jemand mit *.osm bzw XML-Kanntnissen das Ganze noch in
eine korrekte Form bringen.

Jetzt muss man JOSM soweit bringen, dass er die Richtung eines Tags
anzeigen und umdrehen kann sowie den entsprechenden Output generiert.
Überdies müsste das Ganze auch auf Routen-Relationen ausgeweitet
werden, indem man auch denen eine Richtung gibt. Es gäbe da vielleicht
die Möglichkeit, die Richtung durch die Abfolge der eingeschlossenen
Ways zu spezifizieren. Aber im Prinzip müsste es funktionieren.  

Damit wäre eine Lösung gefunden, die Frederik weiter oben im Thread
als "weniger fragil" umschrieben hat und gleichzeitig seine Forderung
erfüllt, den User nicht in ein enges Korsett zu schrauben. 

>einen Ortsnamen 

>direction=Mainz
>maxspeed:forward=120
>maxspeed:backward=100

Aber wie willst Du die direction=Mainz festlegen, ohne Dich wieder auf
die Richtung des Weges zu beziehen?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Datenverlust

2010-07-21 Diskussionsfäden Daniela Duerbeck


Mal ne Frage zu unauffindbaren Mappern:

Angenommen, ich trage was unter Pseudonym xy ein, verschleiere meine 
Identität und versuche auch sonst, unauffindbar zu sein, habe ich dann 
nicht evtl. mein "geistiges" Eigentum aufgegeben?


Wenn ich nun auch noch einem Suchaufruf nicht folge, könnte man dann 
nicht meine Daten als "abandoned" oder so, weiterverwenden?



Viele Grüße von Dani


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] postgresql und/oder postgis


Am 21.07.2010 22:02, schrieb Walter Nordmann:

offen:
zugriff auf die db unter java mit jdbc, eigendliche anwendung


probiers mal so:

o...@osm:~$ psql -U gis gis
gis=> \d
... liste aller Tabellen ...

gis => \d planet_point
... liste aller Spalten in der point Tabelle ...

gis=> \q
... und raus ...


Generell gibt es folgende Spalten:
osm_id - die ID
way - die PostGIS Geometrie
tags - der HStore mit allen Tags
z_order - Sortier-Reihenfolge, nur bei line & polygon
way_area - Fläche, nur bei polygon
und eine Spalte für jeden Tag aus dem Import-Style.

zusätzlich möchte ich dich auf diesen Abschnitt der Doku hinweisen. Die 
Queries kannst du über den psql-Prompt ausprobieren:




Lg

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Deutsche OSM-Technik-HowTos


Am 21.07.2010 18:04, schrieb Benjamin John:

Wie stelle ich es am Besten an, nur den Teil zu aktualisieren, der in der
ursprünglich importierten Grenzen liegt?


Das ist nicht so einfach, denn es muss auf die Datenbank zurückgegriffen 
werden um festzustellen, ob ein Weg der vorher mal in deiner bbox war, 
jetzt vllt. nicht mehr drin ist und daher gelöscht werden muss. Es gab 
da verschiedene Ideen aber die sind alle experimentell.


Wie wäre es, wenn du einfach einmal pro Woche alles aus der DB löschst 
das du nicht brauchst. das sollte mit Postgis und dem Geo-Index recht 
gut gehen. Man müsste nur sehen, wie gut Postgres den so frei gewordenen 
Speicherplatz wiederverwenden kann.


Lg

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

Am 22. Jul 2010 um 01:23 schrieb Ulf Lamping :Am 22.07.2010 00:18, schrieb steffterra:
> Aber ja- ich vergaß, was lange in OSM so drin ist (parking=grßer
> Parkplatz mit Wegen dazwischen) darf auch nie, nie nie mehr geändert
> werden  aber dass es gar nciht so schlimm wäre, wenn der große
> Parkplatz nur am Key erkennbarv wäre, weil alle bisher gezeichneten
> Parkplätze serh leicht mit dem Key versehen werden könnten. Und solange
> ist es ja auch nciht falsch, wsenn man weiss, dass das eine
> Parkmöglichkeit ist, die laut capacity 500 Plätze hat.

Was kannst du denn dann *nach* dieser Umdefinition aus einem 
amenity=parking herauslesen? Ein irgendwie gearteter Platz wo ich 
irgendwas drauf parken kann. Die Zeit wird es brignen und dann hat es jeder mitbekommen, dass OSM fortschrittlicher wurde.Bislang konnte ich draus lesen, das dort wohl eine (größere) Fläche ist, 
auf der man Autos parken kann.

Irgendwie ist da alleine für 30 Einträge in Europa dann einiges an 
Informationen verloren gegangen. Schaltet ihr alle Euren Kopf aus, wenn sich was ändert im wiki? (nicht böse gemeint und schon gar nicht persönlich) Natürlich muss man amenity=parking so interpretieren, wie es bisher war, bis jemand einen Zusatzkey dranmacht ist es immer noch der gute alte große Parkplatz. *kopfschüttel*Wenn ich eine Software zur Suche von Parkplätzen bauen müsste, dann würde ich diesen, so lange so interpretierten, Tag auch so interpretieren, wie er mal war. Das versteht sich von selbst. Wenn dann jemand einen kley dranbaut, der was anderes sagt, ist klar, dass es vorher falsch getaggt war, weil es ein Parkstand war... Wenn jemand "parking_area" dran baut, ist es eine Bestätigung. Wo um himmels wilen ist euer Problem?Mann, geht mal an die frische Luft. Ich will ja hier keinen beleidigen, aber das ist der Grund, warum sich nichts bewegt.Also kein tag -> alte Interpretationkey dran -> Interpretation nach keyWo ist das Problem? Kann man doch auch im Wiki so festhalten. Dann weiss es jeder, dass amenity=parking ohne Zusatztag/key ein großer Parkplatz ist - ist das denn so abwägig?Ja, wenn dir nicht bewußt (oder es dir egal) ist, was eine Umdefinition 
eines Tags an Konsequenzen bedeutet ist das alles auch überhaupt kein 
Problem. Es ist eben eine Frage dessen, ob man sein Hirn ausschaltet, wenn der Tag neu interpretiert wird, oder nicht. s.o.Wenn man sich aber überlegt, was notwendig ist um das ganze konsistent 
in die OSM Welt zu bringen: Genau deshalb wird nichts in die Welt gebracht. Genau wegen solcher Argumente. Natürlich hist es einfacher, etwas schnell schlecht umzusetzen, als groß aufziehen zu müssen und dafür eine geordnete Tagging-Struktur zu bekommen.Tausende von Einzeltags sind _nicht_ besser als ein Überbegriff und darin den passenden key suchen. Letzteres ist wesentlich flexibler, aber letzeres ist "besser" in der Einzelkämpfer-Marnier hier durchzusetzen.Wir würden uns nicht "streiten", wenn es nicht darum ginge einen tag zu einem Überbegriff zu machen. Wenn amenity=parking schon ein überbegriff mit keys wäre, wäre es ein Kinderspiel, einfach einen neuen key einzuführen. Aber man muss ja nicht an die Zukunft denken... Lieber immer wieder neu einen Tag durchboxen.Eine Parkplatz/Parkstand/Stellplatz-Datenbank ist viel leichter aufzuziehen, wenn man nicht darauf achten muss, wieviele unterschiedliche Tags es fürs Parken gibt. Einfach den amenity nehmen, auslesen, welche keys dazu gemappt wurden und gut ist. Aber das wäre wohl zu fortschrittlich gedacht. Es ist einfacher, 1 bis 5 neue Tags für ähnliche Dinge einzuführen.  Wer bespricht diese semantische Änderung auf der englischen talk Liste 
(bislang habe ich dort kein Wort über diese Diskussion gesehen)?

Wer bespricht diese Änderung auf allen anderssprachigen Mailinglisten?

Wer kümmert sich darum, das diese Änderung im Wiki *konsistent* (über 
alle Sprachen) geändert wird?

Wer kümmert sich darum, das alle relevanten Kartenrenderer diese 
Änderung mitbekommen?

Wer kümmert sich darum, daß Editoren ihre Presets entsprechend anpassen?

... und ich hab mit Sicherheit noch so einiges vergessen. Angst! Arbeit! .. oder wie? Wenn man hier zusammenhalten würde und sich nicht jeder als Einzelkämpfer (der für "seine Art zutaggen" kämpfen würde) sondern vielmehr gemeinsamen nach _guten_ Lösungen (mit freiem Kopf!) gesucht würde, dann könnte man das auch stark gemeinsam flächendeckend umsetzen. Wenn man natürlich weiterhin weiss, hier eh auf sich alleine gestellt zu sein ... Na danke...Hier auf der Liste tolle Vorschläge zu machen ist recht einfach. Irgendwo muss man ja mal anfangen, sich andere Meinungen anzuhören. Nur so langsam merke auch ich, dass hier viele eben nicht an das denken, was aus osm werden könnte, sondern, wie man am besten alles in das derzeitige Schema presst. Man merkt das es bei richtungsabhängigen Sachen eigentlich immer konfuser wird, weil tagging-ketten keine bessere Lösung als Relationen sind, weil man merkt, dass Linienbündel einen haufen Arbe

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung


Hallo,

Dimitri Junker wrote:

1B is sowohl nach CC-BY-SA als auch nach ODbL erlaubt. Die DB auf der
DVD muss dabei unter der jeweiligen Lizenz stehen


Sorry, aber das das erlaubt ist ist ja klar,


Tut mir leid, die neue Lizenz wird zuweilen auf einem Niveau diskutiert, 
dass ich nicht immer weiss, was klar ist und was nicht ;)


diskutieren muß man ja nur die 
Fälle wo er seine Daten nicht unter unsere Lizenz stellen will.

Also:
1. der Anbieter erzeugt wirklich eine neue DB mit seinen und OSM-Daten und 
verbietet deren Weitergabe.


Unter CC-BY-SA muss er die DB ja gar niemandem geben (nur das 
Endprodukt, also Bild mit Punkt drin), da entfaellt die Frage. Unter 
ODbL muss er die DB denen geben, denen er auch das Endprodukt gibt, und 
sie muss ODbL-lizensiert sein. *Falls* er die Datenbank jemandem gibt, 
z.B. auf CD, muss sie CC-BY-SA bzw. ODbL lizensiert sein.


2. der Anbieter erzeugt 2 Datenbanken, die eine enthält seine Daten die 
andere einen Ausschnitt der OSM Daten. Er verbietet die Weitergabe der 
ersten, belößt die 2. aber unter der OSM-Lizenz.
3. der Anbieter erzeugt nur eine eigene DB und nutzt die OSM-Daten on the 
fly. Wieder verbietet er die Weitergabe seiner DB


Das geht beides, sowohl unter alter als auch unter neuer Lizenz.

Na toll, ich stelle also eine verschlüsselte Datenbank her, Stelle die offen 
auf meine HP und verkaufe ein Programm daß die Daten entschlüsselt


Ich dachte, ich haette bereits gesagt, dass die absichtliche 
Verschluesselung weder unter CC-BY-SA noch unter ODbL zulaessig ist.


CC-BY-SA: "You may not distribute, publicly display, publicly perform, 
or publicly digitally perform the Derivative Work with any technological 
measures that control access or use of the Work in a manner inconsistent 
with the terms of this License Agreement."


ODbL: "This License does not allow You to impose (except subject to 
Section 4.7 b.) any terms or any technological measures on the Database, 
a Derivative Database, or the whole or a Substantial part of the 
Contents that alter or restrict the terms of this License, or any rights 
granted under it, or have the effect or intent of restricting the 
ability of any person to exercise those rights."


Es ist klar, dass es ein schmaler Grat zwischen absichtlicher 
Verschluesselung und der Produktion von Dateien fuer bestimmte Formate 
ist. In der Hauptsache geht es aber darum, dass jeder, der die Datenbank 
bekommt, das *Recht* hat, sie zu beliebig benutzen. Ober auch die 
*Moeglichkeit* hat, das ist ausserhalb des Bereichs der ODbL. Zum 
Beispiel koennte man OSM-Dateien auf 8-Zoll-Floppy-Disks verkaufen, ohne 
dass man jetzt dafuer verantwortlich ist, dass die Leute auch 
8-Zoll-Floppy-Laufwerke haben ;)


Angenommen, ein Hersteller von Navi-Geraeten hat ein properietaeres 
Datenformat. Dieses Format ist hochoptimiert, und er will niemandem 
verraten, wie es aufgebaut ist, um seinen Vorteil gegenueber der 
Konkurrenz nicht zu verlieren. Der Hersteller verkauft nun OSM-Karten 
fuer seine Geraete. Man kann die nur mit seinen Geraeten lesen 
(eventuell hat er sogar ein Patent auf das Format). Das ist ok - aber 
weil die Datei unter ODbL steht, ist es erlaubt, dass einer, der die 
Datei kauft, sie an andere Besitzer des Geraets weitergibt; diese 
koennen die Datei dann nutzen. Der GPS-Hersteller ist meiner Ansicht 
nach nicht verpflichtet, eine geraeteunabhaengige Version der Daten zur 
Verfuegung zu stellen. Er darf aber auch nicht per DRM o.ae. dafuer 
sorgen, dass die Weitergabe von Kunde A zu Kunde B nicht funktioniert.


Wenn das erlaubt ist können 
wir die Diskussion einstellen und die Daten zu PD erklären. Also das 
Veröffentlichen der Daten muß eine lückenlose Dokumentation der 
Datenstruktur inkl. aller Informationen enthalten die nötig sind um sie zu 
lesen, 


Das ganz bestimmt nicht, wie gesagt, das Datenformat kann durchaus 
geschuetzt sein. Die ODbL hat allerdings eine Klausel in Ergaenzung zum 
oben zitierten, und zwar:


"You may impose terms or technological measures on the Database, a 
Derivative Database, or the whole or a Substantial part of the Contents 
(a “Restricted Database”) in contravention of Section 4.74 a. only if 
You also make a copy of the Database or a Derivative Database available 
to the recipient of the Restricted Database ..."


Das heisst, wenn man eine abgeleitete Datenbank eben doch mit DRM 
geschuetzt vertreiben will (es koennte ja zum Beispiel sein, dass man 
eine Vertriebsplattform a la Apple-Store nutzt, die einem da bestimmte 
Vorschriften macht), dann ist das erlaubt, vorausgesetzt, man stellt die 
Daten zusaetzlich auch noch ohne DRM irgendwo zur Verfuegung. Ich denke 
aber, dass diese Klausel im Falle eines einfachen "komplizierten, 
unveroeffentlichten Datenformats" nicht greift.


Das ist aber durchaus was, was man nochmal auf legal-talk diskutieren 
koennte, wie gesagt, die Grenze muesste vielleicht praeziser definiert 
werden.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remo

Re: [Talk-de] Behindertenparkplatz

Am 21. Jul 2010 um 22:20 schrieb Thomas Ineichen :
Zusammenfassend meine Sicht:

Es ist sinnvoll, zwischen den folgenden 3 Fällen zu unterscheiden:

a) 'grosse' Parkplätze/Parkhäuser
b) Parkmöglichkeiten entlang von Strassen
c) einzelner, isolierter  Parkplatz  (für 1, 2 Autos)  bzw. "Ausnahme-
   Gruppen" innerhalb von grösseren Parkplätzen


Bei  gezielter Einführung von c) kann die ganze Gruppe ein gemeinsames
'amenity'-Tag erhalten, welches mit den bekannten capacity:* erweitert
wird. +1sieeh meine mail diesbezüglich, dass parking n ciht parkplatz, sondern "ein Ort, wo man parken kann" heisst. und dann der große Parkplatz den key "parking_area" und der Parkstand/Stellplatz den key "parking_space" bekommt. Ich sehe da keien Probleme - auch nciht ,wenn man letzteres auf dem ersteren auf einem node unterbringen möchte.steffterra___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

Am 21. Jul 2010 um 11:39 schrieb yzemaze :On 21.07.2010 09:35, Bernd Wurst wrote:
> Am Mittwoch 21 Juli 2010, 09:06:25 schrieb Ulf Lamping:
>> In OSM wurde amenity=parking bislang explizit als Parkplatz beschrieben, 
>> einzelne Parkstände wurden nicht gemappt - so stand es zumindest seit 
>> Jahren im Wiki.
> 
> Was ist für den Nutzer der Unterschied zwischen einem Parkplatz und einem 
> Parkstand? Abgesehen von der Wahrscheinlichkeit, einen freien Platz zu finden.
> 
> Gruß, Bernd

e. g. Kollateralschäden:
http://gis.638310.n2.nabble.com/forum/PostLink.jtp?post=5320106

On 21.07.2010 10:15, Chris66 wrote:
> Ich hatte vorgestern in Lingen mit meiner Garmin OSM Karte
> den Bahnhof Lingen gesucht, aber nicht gefunden, weil
> ja in dem Untermenü "Finde Transport" jeder Parkplatz,
> jede Bushaltestelle (teilweise doppelt) usw. drin  ist. Ganz klares Versagen der Software in Kombination  mit fehlenden keys oder eigenen Tags für unterschiedliche Parkmöglickeitsarten.steffterra___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Vollkommen sinnlose, zerstörerrische R ichtungsfunktion in OSM?

Am 21. Jul 2010 um 10:16 schrieb Peter Körner :
Am 19.07.2010 23:58, schrieb Tirkon:
> Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall
> helfen

Nur mal aus Interesse (bitte nicht als Kritik missverstehen):
würdest du auch solche Feldwege mit zwei Linien abbilden? Fahren kann
man ja in beiden Richtungen drauf.. nana, siehst Du da zwei Fahrspuren? Ich meine nicht Fahrrinnen von den Rädern ;-)Wie steht es mit kleinen Landstraßen, die keine Mittellinie haben, und
solchen, deren Mittellinie schon abgefahren ist? Dort wo Fahrzeuge sich so begegnen können, ohne dass einer dabei halb in eine Straßengraben fahren muss hat zwei Fahrspuren, oder?Es ist hier schwer die Grenze zu ziehen, denke ich. Das ist zwar richtig, aber zum Glück haben wir alle eine Kopf zum denken.wäre ein definiertes Taggingschema für Richtungsabhängige
Tags, z.B. durch vier Namensräume in den Tags: right, left, forward,
backward. Die Tags könnten dann so aussehen: Das gibts in diverser Praxis und Proposals ja auch schon. Das problem ist nur, dass es an der Richtung des eingezeichneten way liegt und wehe einer dreht was. Unmd ja, JOSM warnt, aber ein Problem bleibt es dochforward:maxspeed=30
right:parking=yes

es ist dann klar, dass bei einer Richtungsänderung aus allem was mit
forward: getaggt ist ein backward werden muss. Leider ist
"forward:maxspeed" weiter von "maxspeed" entfernt als
"maxspeed:forward", weshalb das letztere häufige verwendet wurde.

Generell wäre es möglich die definition von right, left, forward und
backward von der Wegrichtung zu lösen:

Wenn ein Tag "direction" vorhanden ist, wird der statt der eigentlichen
Weg-Richtung verwendet. Was "direction" jetzt genau enthält bleibt zu
Diskutieren: Eine Himmelsrichtung, eine Node-Nummer, einen Ortsnamen -
sexy wäre das schon: viel zu kompliziertes Regelwerk.Ein Linienbündel würde die Tags vereinfachen, doch solange ein Steve Coast & Co. das bisherige Schema nciht erweitern wird es die Community nicht von selbst regeln. Dax gibts zuviele Diskussionen, bei denen man alle viertel Jahr immer wieder genau über dieses Thema redet. Ich glaube auch, dass wir deutschen zu viel wollen. Ich glaube die Engländer sind froh, dass überhaupt ne Straße getaggt wurde udn gehen lange nicht so ins Detail. Wir korrekten Deutschen halt wieder... ;-)Die Anwendungen werden es aber nötig machen und wenn sich da nix tut, weils keiner durchzieht, werden wir noch in Jahren darüber diskutieren, ob Relationen, forward oder rechts getaggt werden muss, um eine Reichtung zu beschreiben.Das mit der destination war mir neu (nicht der tag, sondern dass man daran die richtung festmacht). Das ist komplett unmöglich, weil Du dann ein Problem in Wohjngebieten hast. Oder machst Du dann destination "Zahnarztpraxis sowieso" rein? Nene, das geht nicht am destination-tag Der ist für sowas auch gar nciht gedacht und geeignet, da er die richtung zu einer Stadt (Autobahnauffahrt/Autobahn/Abfahrt) oder besonderer Einrichtung (Stadion, Bahnhof, etc.) und nicht um daran forward festzumachensteffterra___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

Am 21. Jul 2010 um 09:49 schrieb Ulf Lamping :Am 21.07.2010 09:35, schrieb Bernd Wurst:
> Am Mittwoch 21 Juli 2010, 09:06:25 schrieb Ulf Lamping:
>> In OSM wurde amenity=parking bislang explizit als Parkplatz beschrieben,
>> einzelne Parkstände wurden nicht gemappt - so stand es zumindest seit
>> Jahren im Wiki.
>
> Was ist für den Nutzer der Unterschied zwischen einem Parkplatz und einem
> Parkstand? Abgesehen von der Wahrscheinlichkeit, einen freien Platz zu finden.

Das ist bereits einer der Gründe.

"Hinterm Parkplatz links rein" als "Webbeschreibung" kann man vergessen, 
wenn auf der Karte überall Parkplätze drinstehen. Wenn das Deine Art ist Wege zu beschreiben, wie kommst Du dann mit den vielen Straßen zurecht? Nix für ungut.Und dass es vieel Parkplätze gibt, liegt an den vielen Autos und die Straßen, ja die kommen auch daher ...Und dass Du sie nicht gescheit auf eienr OSM-Karte von einander unterscheiden kannst, um daraus eine Wegbeschriebung machen zu können, liegt nur am Renderer - einzig und alleine daran. Denn taggen kann man vielens, mit eigenem Tag oder als key - dargestellt werden muss beides sauber.steffterra___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relation für relationale Struktur

Am 21. Jul 2010 um 08:55 schrieb Markus :Hallo Tilmann,

>>> Ist es ok, mit Relationen eine relationale DB-Struktur zu
>>> simulieren? Also Objekte zu Klassen zusammenzufassen?
>
> Siehe
> http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories
>
> Also Relations sind keine Sammlungen von Daten mit den selben
> Eigenschaften.

Dazu entgegen habe ich folgendes gefunden:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults
(aber mangels Übersetzung nicht genau verstanden)

Ist das eine "gute" Relation?
Und wenn ja: wofür genau? Dir sei das ans Herz gelegt: http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categoriesund natürlich http://wiki.openstreetmap.org/wiki/Relationensteffterra___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz


Am 22.07.2010 00:18, schrieb steffterra:

Aber ja- ich vergaß, was lange in OSM so drin ist (parking=grßer
Parkplatz mit Wegen dazwischen) darf auch nie, nie nie mehr geändert
werden  aber dass es gar nciht so schlimm wäre, wenn der große
Parkplatz nur am Key erkennbarv wäre, weil alle bisher gezeichneten
Parkplätze serh leicht mit dem Key versehen werden könnten. Und solange
ist es ja auch nciht falsch, wsenn man weiss, dass das eine
Parkmöglichkeit ist, die laut capacity 500 Plätze hat.


Was kannst du denn dann *nach* dieser Umdefinition aus einem 
amenity=parking herauslesen? Ein irgendwie gearteter Platz wo ich 
irgendwas drauf parken kann.


Bislang konnte ich draus lesen, das dort wohl eine (größere) Fläche ist, 
auf der man Autos parken kann.


Irgendwie ist da alleine für 30 Einträge in Europa dann einiges an 
Informationen verloren gegangen.


Ein ganz konkreter Nachteil um exakt welchen Vorteil zu erzielen?


Dann weiss man -
bis jemand den key nachliefert - auch aus dem Hirnschmalz heruas, dass
das ein grßer, groooßer Parkplatz ist.


Ja, wenn dir nicht bewußt (oder es dir egal) ist, was eine Umdefinition 
eines Tags an Konsequenzen bedeutet ist das alles auch überhaupt kein 
Problem.



Wenn man sich aber überlegt, was notwendig ist um das ganze konsistent 
in die OSM Welt zu bringen:


Wer bespricht diese semantische Änderung auf der englischen talk Liste 
(bislang habe ich dort kein Wort über diese Diskussion gesehen)?


Wer bespricht diese Änderung auf allen anderssprachigen Mailinglisten?

Wer kümmert sich darum, das diese Änderung im Wiki *konsistent* (über 
alle Sprachen) geändert wird?


Wer kümmert sich darum, das alle relevanten Kartenrenderer diese 
Änderung mitbekommen?


Wer kümmert sich darum, daß Editoren ihre Presets entsprechend anpassen?

... und ich hab mit Sicherheit noch so einiges vergessen.


Hier auf der Liste tolle Vorschläge zu machen ist recht einfach. Sich 
drum zu kümmern das die Änderungen konsistent überall bekannt, 
akzeptiert und entsprechend geändert werden ist eine ganz andere Geschichte.


Gruß, ULFL

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

2010-07-21 Diskussionsfäden Tobias Knerr

Am 22.07.2010 00:18, schrieb steffterra:
> Eben, warum für jede Unterart einer Parkmöglichkeit ein eigener Tag,
> wenhn es auch mit keys ginge???

Du definierst im Folgenden für jede Unterart einer Parkmöglichkeit ein
eigenes Tag:
- parking = parking_area als Tag für Parkplätze
- parking = parking_space als Tag für Stellplätze

Zusätzlich gibt es noch ein drittes Tag (amenity = parking), das dadurch
völlig sinnlos würde.

Was soll das für einen Vorteil haben gegenüber einer Lösung mit
- amenity = parking als Tag für Parkplätze
- amenity = parking_space als Tag für Stellplätze?


Hier schon mal ein paar Nachteile:
- Man braucht für jede Parkmöglichkeit zwei Keys statt einem
- hunderttausende bisherige Einträge sind ohne Nachbesserung nicht mehr
eindeutig

> Aber ja- ich vergaß, was lange in OSM so drin ist (parking=grßer
> Parkplatz mit Wegen dazwischen) darf auch nie, nie nie mehr geändert
> werden  

Richtig, der weltweit häufigste amenity-Wert sollte nicht ohne sehr
guten Grund geändert werden. Ist das so ungewöhnlich?

Tobias Knerr

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neue Windows-Programme für OSM

Hallo,


>schade, mal wieder nur windows :(


Es ist recht viel kompliziertes aus den Microsoft-Librarys drin, vor allem 
das ganze Schreiben von Grafik und Videodateien. Ob es da etwas so einfach 
nutzbares gibt das auch unter Linux oder Mac funktioniert weiß ich nicht. 
Aber das Programm ist unter der GPL, wenn es wirklich viele User geben 
sollte kann man ja mal jemanden suchen der es portieren kann. Einfach 
ausgedrückt ich wollte das Programm für mich haben und habe Visual C++, also 
hab ich es damit gemacht.
Ich habe schon länger vor mal mit Java o.ä. anzufangen, aber jedesmal wenn 
ich ein Programm brauche will ich es schnell nutzen und da verschiebe ich 
das Einarbeiten in Java immer wieder.

Ach es ging um Taho nicht um dyjtrack, egal da stimmt das gleiche aber 
zusätzlich hatte ich gehofft, daß irgendwer der sich mit Webprogrammierung 
auskennt sich mal hinsetzt und taho.pl in die Exportseite von OSM einbaut. 
Das wäre die einzig saubere Lösung, Taho.exe ist eine Krücke, ob als 
Windowsprogramm oder Plattformübergreifend.

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung

Hallo,


>1B is sowohl nach CC-BY-SA als auch nach ODbL erlaubt. Die DB auf der
>DVD muss dabei unter der jeweiligen Lizenz stehen


Sorry, aber das das erlaubt ist ist ja klar, diskutieren muß man ja nur die 
Fälle wo er seine Daten nicht unter unsere Lizenz stellen will.
Also:
1. der Anbieter erzeugt wirklich eine neue DB mit seinen und OSM-Daten und 
verbietet deren Weitergabe.
2. der Anbieter erzeugt 2 Datenbanken, die eine enthält seine Daten die 
andere einen Ausschnitt der OSM Daten. Er verbietet die Weitergabe der 
ersten, belößt die 2. aber unter der OSM-Lizenz.
3. der Anbieter erzeugt nur eine eigene DB und nutzt die OSM-Daten on the 
fly. Wieder verbietet er die Weitergabe seiner DB


>CC-BY-SA und ODbL sehen vor, dass der Anbieter nicht extra elektronische
>Verfahren anwenden darf, um die Weitergabe der Daten zu
>unterlaufen (z.B. DRM-Zeugs, das die Karte an ein Geraet bindet); wenn
>es aber einfach nur so ist, dass man fuer die Karte halt einen
>speziellen Reader braucht und diesen kaufen muss, dann greift dieser
>Passus vermutlich nicht.


Na toll, ich stelle also eine verschlüsselte Datenbank her, Stelle die offen 
auf meine HP und verkaufe ein Programm daß die Daten entschlüsselt, dieses 
Programm ist dann per DRM o.ä. kopiergeschütz. Wenn das erlaubt ist können 
wir die Diskussion einstellen und die Daten zu PD erklären. Also das 
Veröffentlichen der Daten muß eine lückenlose Dokumentation der 
Datenstruktur inkl. aller Informationen enthalten die nötig sind um sie zu 
lesen, sonst ist der Zwang die Daten zu veröffentlichen witzlos. 

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

Am 21. Jul 2010 um 08:11 schrieb Guenther Meyer :Am Dienstag 20 Juli 2010, 14:38:40 schrieb lulu-...@gmx.de:> Hier ist die Lösung, die sauber funktioniert:> http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces> > Es wird getaggt:> > amenity=parking> capacity=1> capacity:disabled=1> > und optional:> > capacity:standard=0> > So funktioniert es sauber und widerspruchsfrei.> +1zum Thema Parkplatz vs. Parkstand:sorry, fuer mich ist das jeweils ein Ort, wo ich mein Fahrzeug abstellen kann, der Zweck ist exakt derselbe. Weder der Anwender noch die StVO-Beschilderung macht da einen Unterschied. Deshalb sehe ich auch keinen Sinn drin, das in OSM zu unterscheiden. +1 Eben, warum für jede Unterart einer Parkmöglichkeit ein eigener Tag, wenhn es auch mit keys ginge???Und wo wir gerade dabei sind. "Parking heisst zwar übersetzt "auch" Parkplatz. Gibt man aber "Parkplatz" bei leo ein, ist das nicht gerade der Top-Score:http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed§Hdr=on&spellToler=&search=ParkplatzDenn Parking wird im allgemeinen (nicht OSM derzeit ;-) mit "einer Parkmöglichkeit im allgemeinen" übersetzt. Das heisst, auch Stellplätze/Parkstände werden so benannt, wenn man sie nicht direkt übersetzt, sie fallen halt darunter, genauso wie der große Parkplatz auch. Der große Parkplatz heisst direkt übersetzt "car_park" oder was ich fast "schöner" finde: "parking_area". Ein einzelner Stellplatz direkt wird als "parking_space" übersetzt. Wieso könnt ihr damit in den keys nicht leben? Also auch der große Parkplatz bekommt einen Key.Durch Keys lassen sich alle Unterarten darstellen. Um einen bestimmten Bereich innerhalb eines großen Parkplatzes als besonderen Parkstand wie zb den Behinderten-, Eltern-, Frauenparkplatz, etc. kann man diesen doch zusätzlich dort taggen, z.B. in einem node. Wo ist das Problem, das wolltet ihr doch auch als ihr einen eigenen Tag angestrebt habt. Dass der Rednerer dann 4x ein" P" draufmacht? Sorry, dann mauss er halt 4x ein anderes P draufmachen...Deshalb _würde_ ich einen großen Parkplatz so taggen und das Wiki am besten auch gleich umschreiben, denn das ist überaltet und stammt aus der Zeit, wo man froh war, wenn wenigstens die großen Parkplätze getaggt wären.:amenity=parkingparking:parking_areacapacity:standard:500capacity:disabled:2capacity:women:10capacity:parents:10wenn man nun an einer bestimmten Stelle den disabled hinstellen möchte dann an dem Node (oder zwischen zwei nodes des service):-> am node:amenity=parkingparking:parking_spacecapacity:disabled=2und weil parking in dieser mail als Überbegriff für Parkmöglickeit ist, ist dafür auch ein extra tag überflüssig, da der key aussagt, um welche Parkmöglichkeit es sich hier handelt-> wem der Node zu ungenau ist, kann es auch gemäß Proposal service zwischen zwei nodes taggen:service=paring_aisleparking:parking_spacecapacity:disabled=2oder wenn man die Seite des sevice noch angeben möchte, dann gemäß Proposal:service=parking_aisleparking:lane:leftcapacity:disbled=2Aber ja- ich vergaß, was lange in OSM so drin ist (parking=grßer Parkplatz mit Wegen dazwischen) darf auch nie, nie nie mehr geändert werden  aber dass es gar nciht so schlimm wäre, wenn der große Parkplatz nur am Key erkennbarv wäre, weil alle bisher gezeichneten Parkplätze serh leicht mit dem Key versehen werden könnten. Und solange ist es ja auch nciht falsch, wsenn man weiss, dass das eine Parkmöglichkeit ist, die laut capacity 500 Plätze hat. Dann weiss man - bis jemand den key nachliefert - auch aus dem Hirnschmalz heruas, dass das ein grßer, groooßer Parkplatz ist.steffterra___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map

2010-07-21 Diskussionsfäden Rainer Knaepper

li...@fuchsschwanzdomain.de (Sven Geggus)  am 20.07.10:
>Sven Geggus  wrote:

>Ich hab das jetzt mal schnell mit "klassischem" Tabellenlayout
>gemacht. Nicht schön aber tut. Im Gegnsatz zu vorher auch im IE8 und
>auf meinem Netbook mit 1024x600 Auflösung.

Danke, VIEL besser :-)

Rainer

-- 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Lizenzwechsel-Bauchscmerzen

2010-07-21 Diskussionsfäden Christian Schmitt

Hallo,


Am 21.07.2010 um 21:20 schrieb M∡rtin Koppenhoefer:

> Am 18. Juli 2010 12:03 schrieb Christian Schmitt :
>> Ich persönlich finde es nicht dramatisch, dass unsere Datenbank frei 
>> verfügbar ist wie Wasser, Sand oder Luft. Ob mit oder ohne Quellenangabe, 
>> wen juckt es letztlich? Die Daten sind frei, das ist doch das Tolle daran. 
>> Solange dieser Freiheit keine ernstliche Gefahr droht, wo liegt dann das 
>> eigentliche Problem?
> 
> 
> Ich hoffe, dass unsere Daten freier sind als Wasser und Sand, und auch
> die Luft ist zwar üblicherweise frei, aber nicht überall auch gut.
> Damit unsere Daten langfristig frei bleiben, und von einer aktiven
> Community gepflegt werden, finde ich eine Quellenangabe das mindeste,
> was man als Projekt fordern sollte.

Was könnte konkret passieren wenn die Quellenangabe nicht verpflichtend ist? 
Ich sehe es momentan nicht - bitte hilf mir auf die Sprünge.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Ein Icon pro Relation

Hallo zusammen,

Auf  meiner  Jogging-Karte  möchte  ich  gerne  für  tiefere Zooms pro
Strecke/Relation  ein  Jogging-Icon  anzeigen. Da die route-Relationen
aber  nur  indirekt  in der PostGIS-Datenbank gespeichert sind, ergibt
dies auf der Karte eine zufällige Anzahl von Icons:
http://toolserver.org/~ti/ftm/test.html?zoom=15&lat=47.34045&lon=8.64565&layers=BFTTF

Gibt  es  eine einfache Möglichkeit, pro Relation nur *ein* Icon anzu-
zeigen?


(Das  'normale'  Clustering ist kein Ausweg, da auch mal zwei Strecken
sehr  nah  beieinander  sein  können  und  ich  dann  lieber ein halb-
überdecktes Icon hätte..)


Gruss,
Thomas


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

Hallo M∡rtin,

> Am 21. Juli 2010 14:07 schrieb Tobias Knerr :
>> amenity=parking
>> => ein Ort, wo es nicht nur ein oder zwei, sondern ziemlich viele
>> Stellplätze gibt. Lohnt sich definitiv, das auch in einer allgemeinen
>> Karte zu rendern. Ist von allgemeinem Interesse, nicht nur für
>> Spezialanwendungen.


> nö, 16.4.2008 bis 16.6.2009
> http://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dparking&oldid=261073
>  amenity=parking: ein Ort, wo man (Autos, Motorräder, LKW) parken kann.

> erst danach wurde eingeführt, dass nur Parkplätze ab "vernünftiger"
> Größe eingetragen werden sollen.

Vielleicht,  weil vorher 'intuitiv' nur grössere Parkplätze gezeichnet
wurden und man das endlich im Wiki festhalten wollte?

> Während ich dem für Nodes zustimme
> ist es für areas nicht unbedingt nötig: Wie groß das ist, ergibt sich
> sowieso aus der Fläche. Ob man dann für jeden Parkplatz ein P
> darstellen will oder nur für die großen ist dem Renderer/Router/etc
> überlassen. Derzeit kenne ich allerdings keinen, der es gut macht ;-)

Weil  die  Grösse  in  einer  mit osm2pgsql importierten Tabelle nicht
drinsteht und darum für Mapnik nicht auswertbar ist?

>> => ein "Ort, wo man parken kann". Für sich genommen völlig nutzlos, weil
>> für *jeden* praktischen Zweck eine Unterscheidung zwischen einem
>> Einzelstellplatz und einem großen Parkplatz vorgenommen werden muss.

> Du meinst, wenn man mit mehr als einem Fahrzeug gleichzeitig parken
> will? Ich kenne aus der Praxis eher den Fall, dass man mit _einem_
> Fahrzeug parken will, und da reicht normalerweise ein Stellplatz aus.

Wenn  ich  in  einer  fremden  Stadt  nach einem Parkplatz suche, dann
möchte  ich in ein Parkhaus/zu einem grossen Parkplatz geleitet werden
und nicht von Stellplatz zu Stellplatz.


Zusammenfassend meine Sicht:

Es ist sinnvoll, zwischen den folgenden 3 Fällen zu unterscheiden:

a) 'grosse' Parkplätze/Parkhäuser
b) Parkmöglichkeiten entlang von Strassen
c) einzelner, isolierter  Parkplatz  (für 1, 2 Autos)  bzw. "Ausnahme-
   Gruppen" innerhalb von grösseren Parkplätzen


Bei  gezielter Einführung von c) kann die ganze Gruppe ein gemeinsames
'amenity'-Tag erhalten, welches mit den bekannten capacity:* erweitert
wird.


Gruss,
Thomas

PS:
Es  gibt  auch  andere Fälle, bei denen 'gross' und 'klein' des selben
Objekts unterschiedlich getagged werden:

landuse=forest vs. natural=tree
amenity=bus_station vs highway=bus_stop
railway=station vs. railway=halt
railway=level_crossing vss railway=crossing
etc.




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fehler in mapgen.pl 1.05?

2010-07-21 Diskussionsfäden Carsten Gerlach

Hallo,

Am Dienstag 20 Juli 2010 schrieb Gary68:
> anhängend mapgen.pm 1.061. habe es mit kleineren kartenausschnitten
> probiert, habe jedoch keinen großen bei der hand. bitte mal mit >180
> grad testen.

Ja, damit klappt es, wunderbar :-)

Ein weiterer Punkt ist mir aufgefallen. Bei großen Kartenausschnitten liegen 
die einzelnen Wegpunkte ziemlich nah bei einander. Das führt dazu, daß in der 
SVG-Datei viele Punkte mit denselben Koordinaten entstehen, z. B:
"
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] postgresql und/oder postgis


hi,

auf die gefahr hin, dass folgende antworten kommen:

- kennst du wiki?
. googel mal!
- schau doch im source-code nach!
- ???
- frag doch im developer-bereich nach!
- ...

kann mir jemand ne stelle nennen, wo die datenstruktur der db zumindest
ansatzweise beschrieben ist?
das dazu 100% passende wiki ist leer.

und ein hinweis auf einige beispiele wär auch nicht schlecht.

kurz zum status: 
postgresql läuft, planet-file ist drin (partial), automatischer diff-update
läuft - jetzt will ich endlich an die daten ran ;)

offen: 
zugriff auf die db unter java mit jdbc, eigendliche anwendung

gruss

walter

-
Ich bin root, ich darf das.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/postgresql-und-oder-postgis-tp5322689p5322689.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Sind Relationen komplex?

2010-07-21 Diskussionsfäden Tobias Knerr

Am 20.07.2010 19:36, schrieb Bernd Wurst:
> Ich bleibe bei meiner Meinung, dass die *verbreiteten* Relationen einfach 
> sind. In dem Sinne, dass maximal ein automatisches Sortieren der Elemente 
> nötig ist um den korrekten Zustand zu erhalten.

Bei "Routen-artigen" Relationen ja, aber bei einer restriction passt
diese Vorgehensweise beispielsweise gar nicht.

Wenn man sich darauf verlassen könnte, dass der Editor immer entweder
garantiert richtig mit einer Relation umgeht oder andernfalls
zuverlässig eine Warnung bei der entsprechenden Operation bringt, könnte
man zumindest im ersten Fall gelassener sein.
(Oder ist das in manchen Editoren womöglich sogar schon so?)

> Kann 
> man die Doku zu den Relations-Typen irgendwo per algorithmisch erkennbarem 
> Seitentitel aufrufen?

Für "etablierte" Relationen:
Relation:relationstyp

Die anderen sind normalerweise irgendwo unter
Relations/Proposed/Proposalname,
wobei der Proposalname oft nicht ganz dem Wert von type entspricht.

> Dann könnte man (auch wenn
> ich gerne glaube dass einige Leute da nicht so recht Bock drauf haben) sich 
> kurz die Dokumentation anschauen wenn man nicht weiter weiß.

Sobald ein RTFM nötig ist, kann man halt nicht mehr wirklich von
Benutzerfreundlichkeit reden. Persönlich finde ich z.B. den ganzen
Bereich "Öffentliche Verkehrsmittel" sehr unübersichtlich - bis man sich
da durchgelesen hat, das dauert. Besonders lästig, weil man ja
eigentlich gar keine öffentlichen Verkehrsmittel eintragen wollte,
sondern nur einen betroffenen Way bearbeiten!

Tobias Knerr

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Deutsche OSM-Technik-HowTos

2010-07-21 Diskussionsfäden Benjamin John

Peter Körner  mazdermind.de> writes:

> 
> Hi
> 
> Einige habe ich schon darauf verwiesen und da ich jetzt den zweiten Teil 
> auch fertig habe, möchte ich meine kleine HowTo-Reihe mal öffentlich 
> ankündigen.
> 
> Derzeit gibt es zwei Teile:
> 
> http://wiki.openstreetmap.org/wiki/DE:HowtoMinutelyHstore
> beschreibt Schritt für Schritt, wie eine osm2pgsql Datenbank mit hstore 
> Spalte in einer Linux-Umgebung eingerichtet und mittels der minütlichen 
> Diffs auf dem neusten Stand gehalten werden kann.
> 

Hallo,
die Anleitung ist prima! Zu der Aktualisierung hätte ich noch eine Frage:
Ich habe nur einen kleinen Teil (in meine Fall sachsen.osm.bz2 von der
geofabrik) in die Datenbank importiert. Nun will ich auch nur diesen Teil
aktualisieren. Mit den minütlichen Diffs habe ich aber in einer gewissen Zeit
die ganze Welt in der Datenbank.

Wie stelle ich es am Besten an, nur den Teil zu aktualisieren, der in der
ursprünglich importierten Grenzen liegt?

Benjamin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wie Tanzschule taggen?

2010-07-21 Diskussionsfäden Chris66

Am 21.07.2010 21:32, schrieb Andreas Tille:

> das Subject sagt's schon:  Wie taggt man eine Tanzschule?

amenity=dance_school ?
Laut tagwatch immerhin 8-mal in DE verwendet.


Chris


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map

2010-07-21 Diskussionsfäden AssetBurned

moin

On 20.07.2010, at 20:21, fx99 wrote:
> Tolle Karte, demnächst sollte auch hier etwas auftauchen:
> http://hausbräu.openstreetmap.de/?zoom=10&lat=29.45194&lon=-98.36656&layers=BT
> 
> Es wäre schön, wenn man die Aktualisierungszeit sehen könnte.

hmmm also richtig cool wäre es wenn man auch direkt nen link zum wiki artikel 
finden könne um die tags zu erfahren die man hinterlegen muss damit eine 
kleinstbrauerrei mit aufgeführt werden kann. ;-) hätte da wohl zwei.

cu assetburned

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Routenrelationen sortieren

2010-07-21 Diskussionsfäden M∡rtin Koppenhoefer

Am 16. Juli 2010 21:03 schrieb Manuel Reimer :
> Hintergrund: Merkaartor kennt AFAIK eine Sortierung nicht. Ein anderes
> Programm will ich nicht, da ich die Darstellung im Merkaartor gefälliger
> finde.
> Die bunten Linien im JOSM gehen irgendwie nicht an mich.


jeder hat so seine Präferenzen, mir ist z.B. Funktionalität bei einem
Editor wichtiger als das Aussehen. Man kann das Aussehen von JOSM
allerdings auch anpassen (bequem per externer style-datei) oder in den
Wireframe modus schalten (strg+w) und hat dann keine bunten Linien
mehr.


Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Wie Tanzschule taggen?

2010-07-21 Diskussionsfäden Andreas Tille

Hallo,

das Subject sagt's schon:  Wie taggt man eine Tanzschule?

Viele Grüße

 Andreas.

-- 
http://fam-tille.de

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Lizenzwechsel-Bauchscmerzen

2010-07-21 Diskussionsfäden M∡rtin Koppenhoefer

Am 18. Juli 2010 12:03 schrieb Christian Schmitt :
> Ich persönlich finde es nicht dramatisch, dass unsere Datenbank frei 
> verfügbar ist wie Wasser, Sand oder Luft. Ob mit oder ohne Quellenangabe, wen 
> juckt es letztlich? Die Daten sind frei, das ist doch das Tolle daran. 
> Solange dieser Freiheit keine ernstliche Gefahr droht, wo liegt dann das 
> eigentliche Problem?


Ich hoffe, dass unsere Daten freier sind als Wasser und Sand, und auch
die Luft ist zwar üblicherweise frei, aber nicht überall auch gut.
Damit unsere Daten langfristig frei bleiben, und von einer aktiven
Community gepflegt werden, finde ich eine Quellenangabe das mindeste,
was man als Projekt fordern sollte.


Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Osmosis Probleme, was: Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

On Mi, 2010-07-21 at 12:02 -0700, fx99 wrote:
> Mit dem osmosis Paket gibt es unter ./bin eine Datei osmosis, wo die ganze
> Aufrufprozedur für osmosis.jar drin steht.
> 
Danke! Hätte ich ja fast selber drauf kommen können...


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] Osmosis Probleme, was: Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

2010-07-21 Diskussionsfäden André Riedel

Am 21. Juli 2010 18:57 schrieb Benjamin Lebsanft :
> On Mi, 2010-07-21 at 18:50 +0200, Gary68 wrote:
>> also ich weiß nicht, ob das programm ohne parameter leben kann...
>
> Dann sollte es zumindest sauber schließen, oder?

osmosis benötigt einige zusätzliche Parameter zum starten, daher
sollte es nur mit Hilfe der .bat (windows) oder Shell-Datei aus dem
bin-Verzeichnis gestartet werden.

http://wiki.openstreetmap.org/wiki/Osmosis

André

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Osmosis Probleme, was: Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

2010-07-21 Diskussionsfäden fx99


Mit dem osmosis Paket gibt es unter ./bin eine Datei osmosis, wo die ganze
Aufrufprozedur für osmosis.jar drin steht.

-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Extrahieren-von-Daten-die-sich-innerhalb-eines-bestimmen-Polygons-befinden-tp5320308p5322423.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map

2010-07-21 Diskussionsfäden fx99


fx99  wrote:

> Tolle Karte, demnächst sollte auch hier etwas auftauchen:
> http://hausbräu.openstreetmap.de/?zoom=10&lat=29.45194&lon=-98.36656&layers=BT


War leider die falsche Stadt, hier jetzt richtig. 
http://hausbräu.openstreetmap.de/?zoom=11&lat=30.34274&lon=-97.6933&layers=BT

-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Announce-Die-Hausbrauereikarte-Open-Brewpub-Map-tp5312552p5322396.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Osmosis Probleme, was: Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

On Mi, 2010-07-21 at 18:50 +0200, Gary68 wrote:
> also ich weiß nicht, ob das programm ohne parameter leben kann...

Dann sollte es zumindest sauber schließen, oder?


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] Osmosis Probleme, was: Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

2010-07-21 Diskussionsfäden Gary68


also ich weiß nicht, ob das programm ohne parameter leben kann...


On Wed, 2010-07-21 at 18:34 +0200, Benjamin Lebsanft wrote:
> > Also nimm lieber ein passendes Extrakt der Geofabrik und setzt osmosis 
> > darauf an.
> 
> Habe gerade versucht osmosis auf meinem Ubuntu Rechner zum Laufen zu
> bringen, alles was ich bekomme ist:
> 
> java -jar osmosis.jar 
> 21.07.2010 18:24:27 org.openstreetmap.osmosis.core.Osmosis run
> INFO: Osmosis Version 0.35.1
> 21.07.2010 18:24:31 org.openstreetmap.osmosis.core.Osmosis main
> SCHWERWIEGEND: Execution aborted.
> java.lang.NoClassDefFoundError: org/java/plugin/PluginLifecycleException
>   at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:73)
>   at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30)
> Caused by: java.lang.ClassNotFoundException:
> org.java.plugin.PluginLifecycleException
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
>   ... 2 more
> 
> Weiß jemand Rat?
> 
> Liebe Grüße
> Benni
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Osmosis Probleme, was: Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

> Also nimm lieber ein passendes Extrakt der Geofabrik und setzt osmosis 
> darauf an.

Habe gerade versucht osmosis auf meinem Ubuntu Rechner zum Laufen zu
bringen, alles was ich bekomme ist:

java -jar osmosis.jar 
21.07.2010 18:24:27 org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.35.1
21.07.2010 18:24:31 org.openstreetmap.osmosis.core.Osmosis main
SCHWERWIEGEND: Execution aborted.
java.lang.NoClassDefFoundError: org/java/plugin/PluginLifecycleException
at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:73)
at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30)
Caused by: java.lang.ClassNotFoundException:
org.java.plugin.PluginLifecycleException
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
... 2 more

Weiß jemand Rat?

Liebe Grüße
Benni


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] Behindertenparkplatz

2010-07-21 Diskussionsfäden M∡rtin Koppenhoefer

Am 21. Juli 2010 14:07 schrieb Tobias Knerr :
> amenity=parking
> => ein Ort, wo es nicht nur ein oder zwei, sondern ziemlich viele
> Stellplätze gibt. Lohnt sich definitiv, das auch in einer allgemeinen
> Karte zu rendern. Ist von allgemeinem Interesse, nicht nur für
> Spezialanwendungen.


nö, 16.4.2008 bis 16.6.2009
http://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dparking&oldid=261073
 amenity=parking: ein Ort, wo man (Autos, Motorräder, LKW) parken kann.

erst danach wurde eingeführt, dass nur Parkplätze ab "vernünftiger"
Größe eingetragen werden sollen. Während ich dem für Nodes zustimme
ist es für areas nicht unbedingt nötig: Wie groß das ist, ergibt sich
sowieso aus der Fläche. Ob man dann für jeden Parkplatz ein P
darstellen will oder nur für die großen ist dem Renderer/Router/etc
überlassen. Derzeit kenne ich allerdings keinen, der es gut macht ;-)


> => ein "Ort, wo man parken kann". Für sich genommen völlig nutzlos, weil
> für *jeden* praktischen Zweck eine Unterscheidung zwischen einem
> Einzelstellplatz und einem großen Parkplatz vorgenommen werden muss.


Du meinst, wenn man mit mehr als einem Fahrzeug gleichzeitig parken
will? Ich kenne aus der Praxis eher den Fall, dass man mit _einem_
Fahrzeug parken will, und da reicht normalerweise ein Stellplatz aus.


> Die
> nötigen Zusatzinfos (capacity & co) sind in der Praxis fast nicht
> eingetragen und auch schwer zu erfassen.


approximativ reicht die Fläche eigentlich aus.


>> Wie dieser genau aussieht, kann durch Zusatztags spezifiziert werden.
>>
>> Wo ist also das Problem?!
>
> Wo ist das Problem mit amenity=parking_space? Ich finde das eine prima
> Lösung. Keine Zusatztags notwendig, und man kann - als Zusatznutzen -
> sogar problemlos Stellplätze innerhalb eines Parkplatzes kennzeichnen.


+1
kann man auch machen, gerade um die Stellplätze innerhalb des
Parkplatzes zu machen ist es besser.


> Wenn zwei Objekte in praktisch allen Anwendungen anders behandelt
> werden, sollten sie nicht dasselbe Tag haben. Wenn sie sich sogar
> überlappen können (Stellplätze auf dem Parkplatz), dann erst recht nicht.


+1


Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neue Windows-Programme für OSM



André Joost wrote:
> Nicht jeder hat alle Plattformen zum Testen zu Hause.
das läßt sich leicht und kostenlos ändern.

Ausserdem *wollen* Linuxer doch überhaupt keine GUI 
ist nen altes gerücht: wahr dran ist, dass vieles ohne gui ganz gut geht
aber mit ner guten gui - gerade für echte anwendungen - mach es durchaus
spass. z.b. bt747, prune, josm, webmin.

ich wollte hier ja nicht windows/unix mal wieder aufeinanderjagen sondern
meinte "wenn gui, dann bitte überall" 

*duck und wech*
> André Joostob das hilft? wir kriegen sie alle ;;)
ok, ich werd heute abend mal xp im fensterchen anwerfen (vbox) und mich mal
INHALTLICH mit dem program beschäftigen.

gruss

walter

-
Ich bin root, ich darf das.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/neue-Windows-Programme-fur-OSM-tp5311737p5321053.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung


Hallo,

Dimitri Junker wrote:

Nehmen wir als Beispiel eine bezahlte Webseite, auf der Kunden z.B.
sehen koennen, in welcher Gegend die Immobilienpreise wie hoch sind.
Angenommen, das ganze basierte auf einer abgeleiteten Datenbank.


Ich sehe da mehrere Varianten:
1. der Anbieter erzeugt wirklich eine neue DB mit seinen und OSM-Daten
2. der Anbieter erzeugt 2 Datenbanken, die eine enthält seine Daten die 
andere einen Ausschnitt der OSM Daten.
3. der Anbieter erzeugt nur eine eigene DB und nutzt die OSM-Daten on the 
fly.


Außerdem gibt es die Varianten:
A der User kann die DB nicht erwerben sondern nur die Karten im Web 
betrachten

B er kann eine DVD mit der/den DB und der Software erwerben.

1B fände ich nicht OK


1B is sowohl nach CC-BY-SA als auch nach ODbL erlaubt. Die DB auf der 
DVD muss dabei unter der jeweiligen Lizenz stehen (CC-BY-SA oder ODbL), 
der zahlende Kunde darf die DB weiterverteilen. Die Software muss nicht 
frei sein. Das kann dazu fuehren, dass der Kunde die DB zwar verteilen 
kann, aber niemand, der nicht die Software kauft, kann damit was 
anfangen. CC-BY-SA und ODbL sehen vor, dass der Anbieter nicht extra 
elektronische Verfahren anwenden darf, um die Weitergabe der Daten zu 
unterlaufen (z.B. DRM-Zeugs, das die Karte an ein Geraet bindet); wenn 
es aber einfach nur so ist, dass man fuer die Karte halt einen 
speziellen Reader braucht und diesen kaufen muss, dann greift dieser 
Passus vermutlich nicht.



1A eigentlich auch nicht, läßt sich aber von außen nicht von 2A unterscheiden


1A ist nach CC-BY-SA erlaubt. Bei CC-BY-SA muessen die auf der der 
Webseite abgebildeten Bilder CC-BY-SA sein. Bei ODbL muss die Datenbank 
auf Anfrage als ODbL-lizensiert an den Kunden rausgegeben werden (nicht 
jedoch an die nicht-zahlende Oeffentlichkeit).


2A und 2B fände ich OK, ähnlich wie bei der LGPL. Bei 2B müßte er aber ein 
Programm beifügen, welches aus den aktuellen OSM Daten den Ausschnitt 
extrahiert.


2A nach CC-BY-SA: Angezeigte Bilder muessen CC-BY-SA sein. 2A/ODbL: 
Nichts muss herausgegeben werden (vorausgesetzt, die Preisdatenbank ist 
tatsaechlich komplett ohne Bezug zu OSM hergestellt worden, also nicht 
etwa mit der Maus Rechtecke auf eine OSM-Karte gemalt oder so!).


2B/CC-BY-SA: Die OSM-Datenbank auf der CD muss CC-BY-SA sein, sonst 
nichts. 2B/ODbL: Die OSM-Datenbank auf der CD muss ODbL sein, sonst nichts.



3A und 3B fände ich OK


3A nach CC-BY-SA: Angezeigte Bilder muessen CC-BY-SA sein, ausser wenn 
sie tatsaechlich in Form zwei separater Layer an den Client geschickt 
werden (dann CC-BY-SA nur fuer den OSM-Layer). 3A nach ODbL: nichts muss 
freigegeben werden.


3B: Hier laedt der Client ja die OSM-Daten direkt, also keine Freigabe 
von irgendwas.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neue Windows-Programme für OSM


Am 21.07.10 14:35, schrieb Walter Nordmann:



Dimitri Junker wrote:


ich habe vor einigen Tagen eine neue Version meines Kartendownloaders
TAHO.exe fertiggestellt

schade, mal wieder nur windows :(


gibts auch als taho.pl plattformübergreifend ;-)


wo es  doch möglichkeiten gibt, platformunabhängig zu programmieren. sogar
mit gui.


Nicht jeder hat alle Plattformen zum Testen zu Hause.
Ausserdem *wollen* Linuxer doch überhaupt keine GUI 

*duck und wech*
André Joost


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neue Windows-Programme für OSM



Dimitri Junker wrote:
> 
> ich habe vor einigen Tagen eine neue Version meines Kartendownloaders 
> TAHO.exe fertiggestellt
schade, mal wieder nur windows :( 
wo es  doch möglichkeiten gibt, platformunabhängig zu programmieren. sogar
mit gui.

gruss
walter

-
Ich bin root, ich darf das.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/neue-Windows-Programme-fur-OSM-tp5311737p5320907.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung

Hallo,

>Nehmen wir als Beispiel eine bezahlte Webseite, auf der Kunden z.B.
>sehen koennen, in welcher Gegend die Immobilienpreise wie hoch sind.
>Angenommen, das ganze basierte auf einer abgeleiteten Datenbank.


Ich sehe da mehrere Varianten:
1. der Anbieter erzeugt wirklich eine neue DB mit seinen und OSM-Daten
2. der Anbieter erzeugt 2 Datenbanken, die eine enthält seine Daten die 
andere einen Ausschnitt der OSM Daten.
3. der Anbieter erzeugt nur eine eigene DB und nutzt die OSM-Daten on the 
fly.

Außerdem gibt es die Varianten:
A der User kann die DB nicht erwerben sondern nur die Karten im Web 
betrachten
B er kann eine DVD mit der/den DB und der Software erwerben.

1B fände ich nicht OK
1A eigentlich auch nicht, läßt sich aber von außen nicht von 2A unterscheiden

2A und 2B fände ich OK, ähnlich wie bei der LGPL. Bei 2B müßte er aber ein 
Programm beifügen, welches aus den aktuellen OSM Daten den Ausschnitt 
extrahiert.

3A und 3B fände ich OK

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neue Windows-Programme für OSM

Hallo,

>und heute die erste Version von gpx2map.

da mir eben aufgefallen ist, daß es bereits ein gleichnamiges Programm gibt 
habe ich meins vorsichtshalber umbenannt. Also ab sofort DyjTrack und als 
Dateiendung dyt statt g2m. Da auch im dyt-File Änderungen sind am besten 
alle alten g2m löschen. Noch solten ja nicht so viele existieren, daß sich 
ein Konverter lhnen würde

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

2010-07-21 Diskussionsfäden Tobias Knerr

Am 21.07.2010 13:37, schrieb Guenther Meyer:
>> Wenn jetzt jemand einen Parkstand mit einem amenity=parking taggt ist  
>> das eine Umdefinition der bisherigen Regelung. Alle bisher getaggten  
>> Parkplätze verlieren damit einen Teil ihrer Bedeutung - man weiß bei den  
>> bisherigen ~298883 Verwendungen von amenity=parking dann nicht mehr, was  
>> es letztlich bedeuten soll (Parkplatz oder Parkstand) und muß damit  
>> *alle* bestehenden nochmal anschauen/anfassen - ganz ohne Not viel 
>> Arbeit.
> 
> Wozu?
> Was aendert sich?

Bisher:

amenity=parking
=> ein Ort, wo es nicht nur ein oder zwei, sondern ziemlich viele
Stellplätze gibt. Lohnt sich definitiv, das auch in einer allgemeinen
Karte zu rendern. Ist von allgemeinem Interesse, nicht nur für
Spezialanwendungen.

Nach der "Besetzung" von amenity=parking für Stellplätze*:

amenity=parking
=> ein "Ort, wo man parken kann". Für sich genommen völlig nutzlos, weil
für *jeden* praktischen Zweck eine Unterscheidung zwischen einem
Einzelstellplatz und einem großen Parkplatz vorgenommen werden muss. Die
nötigen Zusatzinfos (capacity & co) sind in der Praxis fast nicht
eingetragen und auch schwer zu erfassen.

> Wie dieser genau aussieht, kann durch Zusatztags spezifiziert werden.
> 
> Wo ist also das Problem?!

Wo ist das Problem mit amenity=parking_space? Ich finde das eine prima
Lösung. Keine Zusatztags notwendig, und man kann - als Zusatznutzen -
sogar problemlos Stellplätze innerhalb eines Parkplatzes kennzeichnen.

> Was bringt es fuer einen Vorteil, fuer jeden Furz ein neues Tag zu erfinden?
> Erst recht wenn mit bereits vorhandenen Tags alles notwendige abgedeckt 
> werden kann?

Wenn zwei Objekte in praktisch allen Anwendungen anders behandelt
werden, sollten sie nicht dasselbe Tag haben. Wenn sie sich sogar
überlappen können (Stellplätze auf dem Parkplatz), dann erst recht nicht.

Ja, man *hätte* Bäume auch als landuse=forest + tree_count=1 eintragen
können. Wäre aber Blödsinn gewesen...

Tobias Knerr

* ich verwende "Stellplätze" hier leicht umgangssprachlich

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relation für relationale Struktur

2010-07-21 Diskussionsfäden Tilmann Sult

On 07/21/2010 08:55 AM, Markus wrote:

> 
> Dazu entgegen habe ich folgendes gefunden:
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults
> (aber mangels Übersetzung nicht genau verstanden)
> 
> Ist das eine "gute" Relation?
> Und wenn ja: wofür genau?
> 
> Gruss, Markus
> 

Die Relation ist auf jeden Fall keine Sammlung von Daten mit gleichen
Werten. Viel mehr sollen Redundanzen vermieden werden, beziehungsweise
Daten abgebildet werden, die keine direkte geographische Referenz haben,
aber dennoch wichtig für Router sind. Also entspricht diese Relation
genau dem, wozu Relations gedacht waren.

Als Beispiel werden Feiertage in bestimmten Ländern und Regionen
genannt, wobei ich jetzt nicht weiß, wieso das gut für die
Routingalgorithmen ist. Höchstens zur Vermeidung von bestimmten
Autobahnen, wenn die Niederlande Ferien hat ;). Als Beispiel für die
Feiertage hier die französischen
http://www.openstreetmap.org/browse/relation/957715
und die Ferien in Franche-Comté
http://www.openstreetmap.org/browse/relation/957702 . Wobei ich jetzt
ein bisschen neidisch auf die Franzosen bin. Die haben die Ferientermine
maschinenlesbar im Netz.

Aber auch die Tempolimits in unterschiedlichen Ländern sind abbildbar
z.B. http://www.openstreetmap.org/browse/relation/934933 für Frankreich.
Das hätte den Vorteil, dass man nicht an jeder Straße maxspeed=* taggen
müsste, sondern nur noch explizite Ausnahmen. Somit bräuchte man Tags à
la maxspeed=DE:urban nicht mehr.

Von dem Ganzen wird bloß Otto-Normal-Mapper nichts mehr mitbekommen, da
die Relation weitesgehend bei politischen Grenzen angewandt werden. Da
ist halt die Frage, ob dieses Schema nicht dem Anarchie-Prinzip von OSM
widerspricht. Aber das gilt ja für die meisten Relations.

Grüße,
Tilmann

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden


Am 21.07.10 13:45, schrieb André Joost:

Am 21.07.10 12:54, schrieb Manuel Reimer:

André Joost wrote:

Bei der XAPI darfst du derzeit locker ein paar Wochen Bearbeitungszeit
einrechnen, wenn überhaupt ne Antwort kommt.
Also nimm lieber ein passendes Extrakt der Geofabrik und setzt osmosis
darauf an.


Ich habe es gerade probiert und alle relevanten Server (sind ja
eigentlich nur noch zwei) antworten recht zeitnah.



Jetzt, ja. Gestern nachmittag und heute morgen tat sich da rein gar nix.


Und schon isser wieder weg *grummel*

Gruß,
André Joost


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden


Am 21.07.10 12:54, schrieb Manuel Reimer:

André Joost wrote:

Bei der XAPI darfst du derzeit locker ein paar Wochen Bearbeitungszeit
einrechnen, wenn überhaupt ne Antwort kommt.
Also nimm lieber ein passendes Extrakt der Geofabrik und setzt osmosis
darauf an.


Ich habe es gerade probiert und alle relevanten Server (sind ja
eigentlich nur noch zwei) antworten recht zeitnah.



Jetzt, ja. Gestern nachmittag und heute morgen tat sich da rein gar nix. 
Gerüchteweise soll von den zweien auch nur noch einer (der hypercube) 
betriebsfähig sein.


Gruß,
André Joost


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

2010-07-21 Diskussionsfäden Guenther Meyer

On Wed, Jul 21, 2010 at 09:06:25AM +0200, Ulf Lamping wrote:
>> zum Thema Parkplatz vs. Parkstand:
>> sorry, fuer mich ist das jeweils ein Ort, wo ich mein Fahrzeug abstellen 
>> kann,
>> der Zweck ist exakt derselbe. Weder der Anwender noch die StVO-Beschilderung
>> macht da einen Unterschied. Deshalb sehe ich auch keinen Sinn drin, das in 
>> OSM
>> zu unterscheiden.
>
> -1
>
> In OSM wurde amenity=parking bislang explizit als Parkplatz beschrieben,  
> einzelne Parkstände wurden nicht gemappt - so stand es zumindest seit  
> Jahren im Wiki.
>
> Wenn jetzt jemand einen Parkstand mit einem amenity=parking taggt ist  
> das eine Umdefinition der bisherigen Regelung. Alle bisher getaggten  
> Parkplätze verlieren damit einen Teil ihrer Bedeutung - man weiß bei den  
> bisherigen ~298883 Verwendungen von amenity=parking dann nicht mehr, was  
> es letztlich bedeuten soll (Parkplatz oder Parkstand) und muß damit  
> *alle* bestehenden nochmal anschauen/anfassen - ganz ohne Not viel 
> Arbeit.

Wozu?
Was aendert sich?

Es wird damit nachwievor ein Ort markiert, an dem man parken kann.
Wie dieser genau aussieht, kann durch Zusatztags spezifiziert werden.

Wo ist also das Problem?!



> Was hier noch keiner dargelegt hat: Was bringt es für einen Vorteil,  
> amenity=parking anstelle eines neuen z.B. amenity=parking_place (oder  
> was auch immer) zu nehmen.

Was bringt es fuer einen Vorteil, fuer jeden Furz ein neues Tag zu erfinden?
Erst recht wenn mit bereits vorhandenen Tags alles notwendige abgedeckt werden 
kann?




signature.asc
Description: Digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung


Hallo,

bernhard zwischenbrugger wrote:
Allerdings nur, wenn man die "Verortung der Kunden" auch öffentlich 
zugänglich macht. Eine Firma, die für den internen Gebrauch die 
Kunden-Adressen auf der Karte darstellt muss diese Daten natürlich 
nicht veröffentlichen.



Da stellt sich dann aber die Frage was öffentlich ist.
Ist es nicht öffentlich wenn man sich einloggen muss?


Es ist noch ein bisschen komplizierter als das. Wir sagen das immer so 
salopp mit dem "oeffentlich". In Wahrheit ist es aehnlich wie mit dem 
Source-Code eines GPL-Programms. Derjenige, dem Du das compilerte 
Programm gibst, dem musst Du auch den Source geben.


Nehmen wir als Beispiel eine bezahlte Webseite, auf der Kunden z.B. 
sehen koennen, in welcher Gegend die Immobilienpreise wie hoch sind. 
Angenommen, das ganze basierte auf einer abgeleiteten Datenbank. Dann 
musst Du diese Datenbank nicht direkt *veroeffentlichen*, aber Du musst 
sie einem zahlenden Kunden (der stellt ja die "Oeffentlichkeit" Deiner 
Webseite dar) auf Verlangen geben, und sie muss dann ODbL-lizensiert sein.


Du musst sie nicht veroeffentlichen. Aber der Kunde, dem Du sie gibts, 
der darf sie natuerlich veroeffentlichen, wenn er will, denn sie ist ja 
unter ODbL.


Es sind durchaus Faelle denkbar, in denen es auf diese Weise nie zu 
einer Veroeffentlichung kommt. Angenommen zum Beispiel, Du bist ein 
Spezialinstitut fuer Bodenanalysen und erstellst horrend teure 
Auswertungen ueber die Eignung bestimmter Gegenden fuer das Verlegen von 
Pipelines. Deine Kunden sind Energieversorger, und Du verkaufst 5 
Exemplare Deiner Publikation im Jahr fuer 10.000 Euro pro Stueck. 
Angenommen, hinter der Publikation stecke eine aus OSM abgeleitete 
Datenbank. Dann musst Du diese auf Verlangen Deinen Kunden geben. Die 
duerften sie theoretisch dann sofort auf ihre Webseite stellen und zum 
kostenlosen Download anbieten. Aber werden sie das tun (und damit ihren 
eigenen Konkurrenten 10.000 Euro sparen vorallem auch denen, die sich 
das vielleicht nicht leisten wollen)?


Die Situation ist uebrigens mit der CC-BY-SA im Augenblick fast genauso. 
Meine Firma, die Geofabrik, verkauft zum Beispiel Shapefiles, die nach 
Kunden-Anforderung generiert werden (z.B. "Westeuropa komplett, aber 
ohne Fusswege, und Geometrien vereinfacht" oder sowas). Der Kunde 
bekommt diese Daten unter CC-BY-SA und koennte sie, wenn er wollte, 
direkt ins Netz stellen. Hat bislang allerdings keiner gemacht.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

2010-07-21 Diskussionsfäden Manuel Reimer


André Joost wrote:

Bei der XAPI darfst du derzeit locker ein paar Wochen Bearbeitungszeit
einrechnen, wenn überhaupt ne Antwort kommt.
Also nimm lieber ein passendes Extrakt der Geofabrik und setzt osmosis
darauf an.


Ich habe es gerade probiert und alle relevanten Server (sind ja 
eigentlich nur noch zwei) antworten recht zeitnah.


Allerdings stimme ich in soweit zu, dass XAPI leider recht oft instabil 
und unzuverlässig ist. Aus diesem Grund habe ich für meine eigenen 
Zwecke einen Cache auf meinem Server, der automatisch nur dann 
aktualisiert wird, wenn einer der zwei Server innerhalb von 10 Sekunden 
antwortet.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung


Hallo Bernhard:

Am 21.07.10 12:06, schrieb Thomas Ineichen:

bernhard zwischenbrugger wrote:

Wenn ich eine Kundendatenbank mit OSM verorten will, dann müsste ich also
alle Kundendaten freigeben.



Genau.


Allerdings nur, wenn man die "Verortung der Kunden" auch öffentlich  
 zugänglich macht. Eine Firma, die für den internen Gebrauch die   
Kunden-Adressen auf der Karte darstellt muss diese Daten natürlich   
nicht veröffentlichen.

Da stellt sich dann aber die Frage was öffentlich ist.
Ist es nicht öffentlich wenn man sich einloggen muss?

Facebook würde ich jetzt mal als öffentlich bezeichen.
Den Login-Bereich des Fußballclubs ist eher nicht öffentlich.
Aber wo genau ist die Abgrenzung?


Vielleicht muss man zuest die erste Frage nochmals etwas ausführlicher  
beantworten:
Wenn Kunden-Datenbank und die OSM-Datanbank getrennt bleiben und die  
Adressen jeweils on-the-Fly dargestellt werden (also nicht in der  
'privaten' Kopie der OSM-Datenbank gespeichert werden), dann muss die  
Kunden-Datenbank nie veröffentlicht werden, egal ob das Ergebnis  
öffentlich genutzt wird oder nicht. (Es handelt sich dann um eine  
sogenannte Sammeldatenbank.) Eine Vereinigung von Kunden- und  
OSM-Datenbank macht aber in den seltensten Fällen überhaupt Sinn.


"Öffentlich" ist nach ODbL-Definition jede zur-Verfügung-Stellung an  
Personen, die nicht unter Deiner Kontrolle stehen. Eine Nutzung auf  
der internen Seite einen Sport-Vereins würde ich daher eher als  
'öffentlich' sehen - aber wie oben gesagt wird der Sportverein eh  
keine 'abgeleitete Datenbank' erstellen.



Gruss
Thomas

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung

Hallo,

es kann doch nicht sein, daß OSM stärker eingeschränkt sein soll als die 
Karte aus dem Buchladen. Wenn ich eine solche legal erworben habe darf ich 
darauf soviele Kreuzchen machen wie ich will. Gut ich darf das Resultat 
nicht kopieren, aber das hat nichts mit den Kreuzchen zu tuen. Mir ist es 
wichtig, daß meine Arbeit möglichst nützlich ist, mir ist es lieber einer 
verdient damit Geld als das viele die sie meiner Meinung nach nutzen können 
sollten es nicht dürfen. So muß z.B. meiner Meinung nach ganz klar geregelt 
sein, wie OSM-Daten mit anderen freien Daten verbunden werden können, das 
dürfte doch das Hauptproblem bei all den Lizenzen sein. Es müßte irgendo 
eine Tabelle aller freien Lizenzen gebildet werde aus der ersichtlich ist 
unter welcher Lizenz man Daten setzen muß wenn man Daten mit  verschiedenen 
Lizenzen kombiniert. Als Bsp mal die GPL, ändert man etwas an einem 
Programm das unter der GPL steht muß das Resultat wieder unter die GPL. 
Dumm nur wenn man 2 Programme kombinieren will, deshalb gibt es dort z.B. 
die LGPL, ändert man eine Lib die unter der LGPL steht selber nicht kann 
man sie zu anderen Programmen die unter einer anderen Lizenz stehen 
dazulinken. Das würde dem hier diskutierten Fall entsprechen, also die 
Kundendatenbank in einer DB, die OSM-Daten bleiben unangetastet. Dann kann 
man damit machen was man will, also Karten erzeugen, navigieren,... Man 
darf auch CDs pressen auf denen beide DB sind, muß aber gewährleisten, daß 
der Nutzer z.B. auch die aktuellen OSM Daten nutzen kann. Das Beilegen der 
OSM-Daten soll es also nur dem Nutzer einfacher machen. Also genau so wie 
ich den Source Code eines Programms incl. der o.g. Lib veröffentlichen 
dürfte.

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung

Hallo,


>Auch die Frage nach den Prognostizierten Datenverlusten hat bisher
>niemand beantwortet.


Das kann ich verstehen, schließlich weiß keiner welche User den Wechsel 
ablehnen. Aber das erste sollter doch möglich sein. Vieleicht sollten wir 
alle damit drohen den Wechsel abzulehnen wenn es eine solche Info nicht gibt 
;-) 

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung

2010-07-21 Diskussionsfäden Markus


Hallo Frederik,


Ich versuche mich mal an ein paar Szenarien:


Danke!
Das finde ich sehr anschaulich und auch für Nicht-Juristen verständlich.

Ich habe die Beispiele mal in eine Wikiseite eingefügt:


Vielleicht entsteht so mit der Zeit eine informative Sammlung...

Ergänzend wünsche ich mir noch die PD/CC0-Sicht...

Gruss, Markus

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung

2010-07-21 Diskussionsfäden bernhard zwischenbrugger


Am 21.07.10 12:06, schrieb Thomas Ineichen:

Hallo Frederik,


bernhard zwischenbrugger wrote:
Wenn ich eine Kundendatenbank mit OSM verorten will, dann müsste ich 
also

alle Kundendaten freigeben.



Genau.


Allerdings nur, wenn man die "Verortung der Kunden" auch öffentlich 
zugänglich macht. Eine Firma, die für den internen Gebrauch die 
Kunden-Adressen auf der Karte darstellt muss diese Daten natürlich 
nicht veröffentlichen.

Da stellt sich dann aber die Frage was öffentlich ist.
Ist es nicht öffentlich wenn man sich einloggen muss?

Facebook würde ich jetzt mal als öffentlich bezeichen.
Den Login-Bereich des Fußballclubs ist eher nicht öffentlich.
Aber wo genau ist die Abgrenzung?

lg
Bernhard

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung


Hallo,

Thomas Ineichen wrote:
Allerdings nur, wenn man die "Verortung der Kunden" auch öffentlich 
zugänglich macht. Eine Firma, die für den internen Gebrauch die 
Kunden-Adressen auf der Karte darstellt muss diese Daten natürlich nicht 
veröffentlichen.


Ja, das stimmt. Alles, was man fuer seinen eigenen Spass macht, hat 
keine Folgen.


Bye
Frederik


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung


Hallo Frederik,


bernhard zwischenbrugger wrote:

Wenn ich eine Kundendatenbank mit OSM verorten will, dann müsste ich also
alle Kundendaten freigeben.



Genau.


Allerdings nur, wenn man die "Verortung der Kunden" auch öffentlich  
zugänglich macht. Eine Firma, die für den internen Gebrauch die  
Kunden-Adressen auf der Karte darstellt muss diese Daten natürlich  
nicht veröffentlichen.


"If you publicly use any adapted version of this database, or works  
produced from an adapted database, you must also offer that adapted  
database under the ODbL."

http://www.opendatacommons.org/licenses/odbl/summary/

Gruss,
Thomas

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

2010-07-21 Diskussionsfäden Martin Simon

Am 21. Juli 2010 11:07 schrieb Bernd Wurst :
> Schwaches Argument. In der Praxis würde ich bei zwei Parkständen, die ein [P]-
> Schild haben auch nicht wissen ob das der von dir gemeinte Parkplatz ist oder
> der 10-Stellplätze-Parkplatz danach (den man von der Straße aus typischerweise
> schlechter sieht).

In der Praxis würde ich dir zutrauen, davon auszugehen, daß derjenige,
der dir die Wegbeschreibung gab, nicht den ersten Parkstand meinte,
der dir auf der aktuellen Straße begegnet - die Straßen sind voll von
diesen Dingern(und dann auch noch beschildertes Parken im Seitenraum,
auf Gehwegen etc. ...).

Dann nehmt halt amenity=parking für beides, wenn es eleganter ist, das
zu vermischen, *alles* mit capacity*=* zu taggen und dann damit wieder
auseinander zu sortieren. (Beispiel Markierung von einzelnen
Sonderstellplätzen/Parkständen auf flächig eingezeichneten
Parkplätzen)
Aber tragt es dann bitte auch auf die tagging-liste und ins englische
wiki, bevor die deutsche Seite alleine modifiziert wird...

Gruß,

Martin (der sich gerade fragt, ob du bei "hinter'm Wald links" auch
hinter dem ersten Baum vor'm Wald links abbögest. ;-) )

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden


Am 21.07.10 11:26, schrieb Bernd Wurst:

Am Mittwoch 21 Juli 2010, 11:20:24 schrieb Benjamin Lebsanft:

ist es möglich, wenn man die Stadtrelation hat, dass man eine API
Anfrage stellt, die einem nur die Hausnummern innerhalb dieser Relation
ausspuckt oder wird das komplizierter?


Die API macht keine komplexen geometrischen Operationen, das wäre in der Masse
viel zu rechenintensiv. Man kann das Gebiet lediglich rechteckig einschränken.

Um dein Ziel zu erreichen solltest du einen rechteckigen Bereich herunterladen
(evtl per XAPI nur die Hausnummern des Bereichs) und mit osmosis auf dein
Stadt-Polygon beschneiden. Das ist gar nicht so kompliziert.



Bei der XAPI darfst du derzeit locker ein paar Wochen Bearbeitungszeit 
einrechnen, wenn überhaupt ne Antwort kommt.
Also nimm lieber ein passendes Extrakt der Geofabrik und setzt osmosis 
darauf an.


Gruß,
André Joost


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung


Hallo,

bernhard zwischenbrugger wrote:

Die meisten Datenbanken sind nicht für die Öffentlichkeit gedacht.


Der Share-Alike-Anhaenger wuerde nun entgegnen: "Dann sollte man sie 
halt nicht mit OSM-Daten verschneiden." ;)



Wenn ich eine Kundendatenbank mit OSM verorten will, dann müsste ich also
alle Kundendaten freigeben.


Genau. Das ist ein Punkt, ueber den noch diskutiert wird, also wo das 
ganze seine Grenze hat. Wenn einer jetzt zu jedem Restaurant in OSM 
detaillierte Bewertungen sammelt (eventuell selbst dort essen geht und 
aufschreibt, wie das essen war) - muss das alles freigegeben werden? 
Sicherlich gibt es technische Loesungen, sich darum herumzumogeln, indem 
man beispielsweise Zusatzdaten in eine andere Datenbank tut und beide 
ueber einen Key verbindet. Aber andrerseits ist es auch ein bisschen 
komisch, eine neue Lizenz einzufuehren und sich gleich Tricks 
auszudenken, wie man ihre Regeln aushebeln kann.


Es steht und faellt mit der konkreten Definition einer abgeleiteten 
Datenbank. Diese Definition wird von der ODbL absichtlich nicht praezise 
getroffen, d.h. das ist in gewissen Grenzen unsere Sache als Community, 
wie wir das definieren.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

2010-07-21 Diskussionsfäden yzemaze

On 21.07.2010 09:35, Bernd Wurst wrote:
> Am Mittwoch 21 Juli 2010, 09:06:25 schrieb Ulf Lamping:
>> In OSM wurde amenity=parking bislang explizit als Parkplatz beschrieben, 
>> einzelne Parkstände wurden nicht gemappt - so stand es zumindest seit 
>> Jahren im Wiki.
> 
> Was ist für den Nutzer der Unterschied zwischen einem Parkplatz und einem 
> Parkstand? Abgesehen von der Wahrscheinlichkeit, einen freien Platz zu finden.
> 
> Gruß, Bernd

e. g. Kollateralschäden:
http://gis.638310.n2.nabble.com/forum/PostLink.jtp?post=5320106

On 21.07.2010 10:15, Chris66 wrote:
> Ich hatte vorgestern in Lingen mit meiner Garmin OSM Karte
> den Bahnhof Lingen gesucht, aber nicht gefunden, weil
> ja in dem Untermenü "Finde Transport" jeder Parkplatz,
> jede Bushaltestelle (teilweise doppelt) usw. drin  ist.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung

2010-07-21 Diskussionsfäden bernhard zwischenbrugger


hi
2. Angenommen, Du betreibst einen Web-Dienst, der das Internet nach 
"Impressum"-Seiten absucht und die Adressen davon automatisch mit OSM 
verortet. Das Resultat (viele hundert oder tausend Adressen) 
speicherst Du in einer eigenen Datenbank, und Dein Web-Dienst bietet 
eine Karte an, auf der diese POIs eingezeichnet sind.


In diesem Fall hast Du eine "Derived Database" (die POI-Datenbank) 
geschaffen und darauf basierend ein "Produced Work" (die Karte). Die 
Karte kann lt. ODbL unter einer beliebigen Lizenz sein, aber die 
Datenbank musst Du unter ODbL freigeben. - Unter der CC-BY-SA waere 
das genau andersrum gewesen, die Datenbank haettest Du fuer Dich 
behalten duerfen, aber die Karte haette frei sein muessen.

Der Punkt ist mir jetzt nicht klar.

Die meisten Datenbanken sind nicht für die Öffentlichkeit gedacht.
Wenn ich eine Kundendatenbank mit OSM verorten will, dann müsste ich also
alle Kundendaten freigeben.

Bernhard

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] "View From A Bridge" - Worldfile vom 16.Juli 2010

2010-07-21 Diskussionsfäden Johann H. Addicks


Am 21.07.2010 08:38, schrieb Carsten Schwede:


Das Ganze funktioniert nur so mit meinem Typfile und auf neueren
Geräten,


Wunderbar!
Vielen Dank für die konsequente Weiterentwicklung der Karten.

Mit etwas Glück habe ich morgen mein 62S, da kann ich dann auch mal 
Routing über längere Distanzen ausprobieren, hat das Ding doch etwas 
mehr Ram als das 60CSx.


-jha-


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

Am Mittwoch 21 Juli 2010, 11:20:24 schrieb Benjamin Lebsanft:
> ist es möglich, wenn man die Stadtrelation hat, dass man eine API
> Anfrage stellt, die einem nur die Hausnummern innerhalb dieser Relation
> ausspuckt oder wird das komplizierter?

Die API macht keine komplexen geometrischen Operationen, das wäre in der Masse 
viel zu rechenintensiv. Man kann das Gebiet lediglich rechteckig einschränken.

Um dein Ziel zu erreichen solltest du einen rechteckigen Bereich herunterladen 
(evtl per XAPI nur die Hausnummern des Bereichs) und mit osmosis auf dein 
Stadt-Polygon beschneiden. Das ist gar nicht so kompliziert.

Das Polygon kann man aus der Grenz-Relation erzeugen und (wenn man das öfter 
braucht) als fertiges Polygon aufbewahren, dann muss man das nicht jedes Mal 
machen.

Gruß, Bernd

-- 
Wie lange eine Minute ist, hängt davon ab, auf welcher Seite der
Toilettentür man sich befindet.


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] Behindertenparkplatz


Am 21.07.2010 11:07, schrieb Bernd Wurst:

Am Mittwoch 21 Juli 2010, 09:49:42 schrieb Ulf Lamping:

"Hinterm Parkplatz links rein" als "Webbeschreibung" kann man vergessen,
wenn auf der Karte überall Parkplätze drinstehen.


Schwaches Argument. In der Praxis würde ich bei zwei Parkständen, die ein [P]-
Schild haben auch nicht wissen ob das der von dir gemeinte Parkplatz ist oder
der 10-Stellplätze-Parkplatz danach (den man von der Straße aus typischerweise
schlechter sieht).

Du musst bei Beschreibungen schon präziser sein: Hinterm Aldi-Parkplatz rein
oder sowas.


Manchmal habe ich echt das Gefühl, einige Leute hier ziehen sich die 
Hose mit der Kneifzange an.


Gruß, ULFL

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Extrahieren von Daten, die sich innerhalb eines bestimmen Polygons befinden

Hallo zusammen,

ist es möglich, wenn man die Stadtrelation hat, dass man eine API
Anfrage stellt, die einem nur die Hausnummern innerhalb dieser Relation
ausspuckt oder wird das komplizierter?

Schon mal vielen Dank für Eure Antworten
Benni


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] Behindertenparkplatz

Am Mittwoch 21 Juli 2010, 09:49:42 schrieb Ulf Lamping:
> "Hinterm Parkplatz links rein" als "Webbeschreibung" kann man vergessen, 
> wenn auf der Karte überall Parkplätze drinstehen.

Schwaches Argument. In der Praxis würde ich bei zwei Parkständen, die ein [P]-
Schild haben auch nicht wissen ob das der von dir gemeinte Parkplatz ist oder 
der 10-Stellplätze-Parkplatz danach (den man von der Straße aus typischerweise 
schlechter sieht).

Du musst bei Beschreibungen schon präziser sein: Hinterm Aldi-Parkplatz rein 
oder sowas.

Gruß, Bernd

-- 
Aus dem WWW dringt niemand ein. Das internationale Datennetz heißt
Internet. WWW ist der Teil, in dem es Fickbildchen gibt.
  -  Andreas Riedel in de.comp.os.unix.linux.misc


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] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?

Hallo.

Am Mittwoch 21 Juli 2010, 10:16:26 schrieb Peter Körner:
> Am 19.07.2010 23:58, schrieb Tirkon:
> > Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall
> > helfen
> Nur mal aus Interesse (bitte nicht als Kritik missverstehen):
> würdest du auch solche Feldwege mit zwei Linien abbilden? Fahren kann
> man ja in beiden Richtungen drauf..
>
> Wie steht es mit kleinen Landstraßen, die keine Mittellinie haben, und
> solchen, deren Mittellinie schon abgefahren ist?
> 
> Es ist hier schwer die Grenze zu ziehen, denke ich.

Ich hab keine praktischen Erfahrungen mit dem Linienbündel-Vorschlag, aber 
meine Trennung wäre in etwa so: Gibt es irgend etwas, das ich mit normalen 
Tags an einem normalen Way nicht darstellen kann, dann sollte man beide 
Richtungen erfassen. Ein Feldweg ist üblicherweise nichts wo es asymmetrische 
Geschwindigkeitsbeschränkungen gibt.


> Angenehmer wäre ein definiertes Taggingschema für Richtungsabhängige
> Tags, z.B. durch vier Namensräume in den Tags: right, left, forward,
> backward. Die Tags könnten dann so aussehen:
> 
> forward:maxspeed=30
> right:parking=yes

Du hast wohl das überlesen was damals dazu geführt hat, dass man ein 
komplexeres Modell gebraucht hat:
Mehrere Dinge entlang der Fahrbahn. Also sowas wie: zwei Fahrbahnen, eine 
Rechtsabbiegerspur, ein Parkstreifen und ein Radweg. Alles physisch auf der 
Fahrbahn, daher idealerweise "ein Objekt". Nur wechselt der Radweg mal vor und 
mal hinter den Parkstreifen. Das wird mit den genannten Tags echt übel 
umständlich.


> Wenn ein Tag "direction" vorhanden ist, wird der statt der eigentlichen
> Weg-Richtung verwendet. Was "direction" jetzt genau enthält bleibt zu
> Diskutieren: Eine Himmelsrichtung, eine Node-Nummer, einen Ortsnamen -
> sexy wäre das schon:
> direction=Mainz
> maxspeed:forward=120
> maxspeed:backward=100

Wir kommen an der Weg-Richtung nicht vorbei, auch das hatten wir schon 
mehrfach. Es gibt Ring-Straßen, die im Extremfall in alle Himmelsrichtungen 
führen und es ist wenig "sexy", bei jedem Teilabschnitt einer Ringstraße eine 
andere Himmelsrichtung anzugeben. Das blickt auch keiner mehr.

Gruß, Bernd

-- 
I believe in making the world safe for our children,
but not our children's children, because I don't think
children should be having sex.  -  Jack Handey


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] Announce: Die Hausbrauereikarte - Open Brewpub Map


Am 20.07.2010 20:06, schrieb Sven Geggus:

Ist eigentlich der IE6 noch in relevanter Zahl in freier Wildbahn
vertreten? Ich nehm mal an mit dem gehts eher nicht hab aber keine
Möglichkeit mehr damit zu testen.
In größeren Konzernen leider ja. Ich tendiere jedoch, bei meinen 
privaten Projekten mit [1] einen Wechsel-Anreiz zu schaffen.


Lg, Peter


[1] http://plugins.jquery.com/project/crash

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Schreckgespenst "Datenverlust"


Am 19.07.2010 15:57, schrieb Florian Lohoff:

Und ich glaube das ist auch das Grundproblem. "Irgendjemand" hat entschieden
wir muessen relizensieren und hat es IMHO nicht geschafft der breiten Masse
das naeherzubringen oder die breite Masse zu ueberzeugen.
Das ist nicht entschieden worden sondern festgestellt, denn es ist ein 
Fakt. Der Nachsatz ist jedoch leider traurige Wahrheit.


Lg

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?

2010-07-21 Diskussionsfäden Falk Zscheile

Am 21. Juli 2010 10:16 schrieb Peter Körner :
>
> es ist dann klar, dass bei einer Richtungsänderung aus allem was mit
> forward: getaggt ist ein backward werden muss. Leider ist "forward:maxspeed"
> weiter von "maxspeed" entfernt als "maxspeed:forward", weshalb  das letztere
> häufige verwendet wurde.
>

Ich glaube "maxspeed:forward" ist auch ein gutes Stück tagging nach
dem Editor (JOSM). Dort sind die taggingvorschläge wenn man händisch
arbeitet alphabetisch geordnet. Und irgendwie fange ich bei der
Eingabe immer mit "maxpeed" an um dann eventuell eine Richtung zu
ergänten. Außerdem bleibt so (aufgrund der alphabetischen Ordnung der
Tags durch den Editor) Zusammen was zusammen gehört:
"maxspeed:forward" und  "maxspeed:backward". Mittlerweile hängen an
Elementen teilweise so viele Tags, dass es man leicht etwas übersieht,
wenn der Namensraum die Dinge nicht zusammen hält. Deshalb werde ich,
bis auf weiteres, das vorangestellte "maxspeed:" verwenden.

Gruß, Falk

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?



Am 19.07.2010 23:58, schrieb Tirkon:

Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall
helfen


Nur mal aus Interesse (bitte nicht als Kritik missverstehen):
würdest du auch solche Feldwege mit zwei Linien abbilden? Fahren kann 
man ja in beiden Richtungen drauf..


Wie steht es mit kleinen Landstraßen, die keine Mittellinie haben, und 
solchen, deren Mittellinie schon abgefahren ist?


Es ist hier schwer die Grenze zu ziehen, denke ich.

Angenehmer wäre ein definiertes Taggingschema für Richtungsabhängige 
Tags, z.B. durch vier Namensräume in den Tags: right, left, forward, 
backward. Die Tags könnten dann so aussehen:


forward:maxspeed=30
right:parking=yes

es ist dann klar, dass bei einer Richtungsänderung aus allem was mit 
forward: getaggt ist ein backward werden muss. Leider ist 
"forward:maxspeed" weiter von "maxspeed" entfernt als 
"maxspeed:forward", weshalb  das letztere häufige verwendet wurde.


Generell wäre es möglich die definition von right, left, forward und 
backward von der Wegrichtung zu lösen:


Wenn ein Tag "direction" vorhanden ist, wird der statt der eigentlichen 
Weg-Richtung verwendet. Was "direction" jetzt genau enthält bleibt zu 
Diskutieren: Eine Himmelsrichtung, eine Node-Nummer, einen Ortsnamen - 
sexy wäre das schon:


direction=Mainz
maxspeed:forward=120
maxspeed:backward=100

Lg

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Taggen fürs Finden

2010-07-21 Diskussionsfäden Chris66

Am 17.07.2010 01:36, schrieb Daniela Duerbeck:

> Ich hab jetzt mal meine Oregon-Karten völlig verwurstelt, um eben
> Restaurants besser finden zu können.

Ich hatte vorgestern in Lingen mit meiner Garmin OSM Karte
den Bahnhof Lingen gesucht, aber nicht gefunden, weil
ja in dem Untermenü "Finde Transport" jeder Parkplatz,
jede Bushaltestelle (teilweise doppelt) usw. drin  ist.

Hab ihn dann konventionell über die Schilder gefunden. ;-)

Kann man im mkgmap Style:

1) dafür sorgen, dass 2 zusammengehörende Bushaltestellen
   zu einer gemerged werden?

2) Bei Bahnhöfen ein "BF" oder so dem Namen voranstellen?

Chris



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz


Am 21.07.2010 09:35, schrieb Bernd Wurst:

Am Mittwoch 21 Juli 2010, 09:06:25 schrieb Ulf Lamping:

In OSM wurde amenity=parking bislang explizit als Parkplatz beschrieben,
einzelne Parkstände wurden nicht gemappt - so stand es zumindest seit
Jahren im Wiki.


Was ist für den Nutzer der Unterschied zwischen einem Parkplatz und einem
Parkstand? Abgesehen von der Wahrscheinlichkeit, einen freien Platz zu finden.


Das ist bereits einer der Gründe.

"Hinterm Parkplatz links rein" als "Webbeschreibung" kann man vergessen, 
wenn auf der Karte überall Parkplätze drinstehen.


...

Gruß, ULFL

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fragen zur OSM-Lizenzvererbung


Hi,

Gehling Marc wrote:

Am 21.07.2010 um 02:13 schrieb Frederik Ramm:

1. Angenommen, Du hast eine Adresse eines einzelnen POI und willst
den auf einer Karte einzeichnen. Du machst per Nominatim eine
Adress-Suche und laesst Dir dann selber eine Karte rendern mit dem
Punkt an der richtigen Stelle.



In diesem Fall hast Du ein "Produced Work" geschaffen, das nicht
frei sein muss, weil es keine Datenbank ist. ODbL fordert
share-alike nur fuer Datenbanken. 


[...]


unter welcher Lizenz stelle ich dann meine Karte ? CC-BY-SA
funktioniert für Karten ? oder PD ?


Das kannst Du Dir aussuchen. Du kannst auch "Copyright Marc, alle Rechte 
vorbehalten" waehlen.


(Meine Lesart der ODbL ist, dass die Lizenz eines "Produced Work" 
voellig egal ist. Andere sagen aber, dass es mindestens eine Lizenz mit 
Namensnennung sein muss, also z.B. CC-BY, damit sichergestellt ist, dass 
auch Leute, die Dein Werk weiterbearbeiten, noch OSM nennen muessen. Da 
steht eine endgueltige Beurteilung noch aus.)


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz

Am Mittwoch 21 Juli 2010, 09:06:25 schrieb Ulf Lamping:
> In OSM wurde amenity=parking bislang explizit als Parkplatz beschrieben, 
> einzelne Parkstände wurden nicht gemappt - so stand es zumindest seit 
> Jahren im Wiki.

Was ist für den Nutzer der Unterschied zwischen einem Parkplatz und einem 
Parkstand? Abgesehen von der Wahrscheinlichkeit, einen freien Platz zu finden.

Gruß, Bernd

-- 
Don't drink and su.


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] Fragen zur OSM-Lizenzvererbung


Hallo,

Tirkon wrote:

Zum Beispiel das hier:
http://62.154.206.92/mc2.1/index.htm


Das ist im Sinne der CC-BY-SA ein "Sammelwerk", also nichts anderes als 
z.B. das OSM-Buch, das ich mitgeschrieben habe - auf einigen Seiten sind 
OSM-Karten, die sind CC-BY-SA, und auf anderen Seiten ist mein eigener 
Text, an dem habe ich bzw. der Verlag alle Rechte und er darf nicht 
kopiert werden.


Bei der ODbL wird das auch nicht anders, genaugenomemen darf da sogar 
der Basislayer unter einer nicht-Share-Alike-Lizenz stehen.


Das alles unter der Annahme, dass OSM-Daten nicht zur Platzierung der 
Haltestellen benutzt wurden, sondern dass hier ein komplett separater, 
eigenstaendiger Datensatz als Layer ueber OSM angezeigt wird. Beide 
Datensaetze gelangen auf unterschiedlichen Wegen zum Benutzer und werden 
erst dort, unmittelbar vor der Anzeige, uebereinander dargestellt.


(Die CC-BY-SA wuerde diese Situation anders beurteilen, wenn die 
Haltestellenkarte in einem Buch abgedruckt waere. Dann waere es kein 
Sammelwerk mehr, denn es laesst sich ja auch nicht auseinanderdividieren.)


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz