Re: [Talk-de] Erfassung von E-Mail Adressen und Spam

[Jochen Topf]

On Thu, Mar 15, 2012 at 12:03:41AM +0100, Martin Czarkowski wrote:
> beim Eintragen von Öffnungszeiten, Telefonnummern und Emailadressen
> ist mir aufgefallen, dass viele Webseitenbetreiber die Emailadresse
> in der Form name(at)domain.de im Impressum haben, (ob es gegen Spam
> tatsächlich hilft, kann ich nicht sagen) in die Datenbank tragen wir
> sie aber in der Form n...@domain.de ein. Geben wir somit den
> Herstellern von Spammails leichtes Futter für ihre Suchprogramme?
> Hebeln wir damit nicht den vermeintlichen Schutz der
> Internetseitenbetreiber aus? Wie soll man am besten vorgehen?

Spammer sind nicht so doof, dass sie sowas wie name(at)domain.de nicht erkennen
können. Diese Verballhornung von Mailadressen ist Vodoo, das allen legitimen
Usern das Leben schwerer macht, aber gegen Spammer nichts hilft.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

Re: [Talk-de] Stolperstein-Relation in Frankfurt /M

[Martin Koppenhoefer]

Am 15. März 2012 01:54 schrieb Stephan Wolff :
> Am 14.03.2012 20:17, schrieb Frederik Ramm:
> Mich stören solche Relationen nicht. Im Gegensatz zu großen Grenz- oder
> Routenrelationen, die häufig schwer lösbare Konflikte beim Hochladen
> verursachen, dürften ähnliche Probleme bei Sammlungen von POIs sehr
> selten sein.


wenn man die Relationen auswerten will (z.B. die Tags an die
Einzelobjekte hängen) dann muss man dazu für jede Relation nochmal die
Objekte durchgehen und die passenden raussuchen, das dauert. Je
weniger Relationen z.B. in den Diffs sind, um so schneller werden die
von osm2pgsql eingelesen.


> Die Zusammenfassung von gleichen Tags in einer Relation erspart die
> Wiederholung dieser Daten an allen Einzelobjekten.


gleichzeitig tendieren sie dazu, weniger transparent zu sein, d.h. es
besteht die Gefahr, dass tags an die Relation gehangen werden, die
nicht für alle Teile zutreffen, oder dass tags von der Relation
gelöscht werden, weil sie für einen kleinen Teil der member nicht
zutreffen.


> Die Relationen verwenden das "name"-Tag für eine Beschreibung der
> Relation.  Diese "name"-Missbrauch betrifft nicht speziell
> diese Relationen, sondern ist weit verbreitet. Leider wird bei JOSM nur
> "name", "ref" und "note" als Text in der Relationsliste angezeigt, aber
> nicht "description".


description tendiert dazu, sehr lang zu sein. Man könnte die
"Stolpersteine in Frankfurt am Main" hier auch in note:de oder so
setzen (wird AFAIK allerdings auch nicht angezeigt in JOSM).


> Die gesamte Aufschrift der Stolpersteine in einzelnen Tags zu erfassen
> (memorial:birth, memorial:death, ...), finde ich unpassend.


man könnte es auch gesammelt in inscription packen, aber wenn die
Leute es lieber strukturiert erfassen, warum nicht.


> Lebensdaten von Personen und Volltexte von Gedenkstätten oder Infotafeln
> sind keine Geodaten. Vermutlich wird eine Stolperstein-Karte
> die einzige Anwendung sein, die diese Daten verwendet. Diese Anwendung
> könnte dann auch eine externe Datenbank lesen.


Volltexte von Gedenksteinen und Infotafeln (je nach Länge, es gibt ja
auch eine Zeichenbegrenzung in den Werten, oder?) werden sicherlich
verschiedene Anwender nützlich finden, (sofern das Urheberrecht die
Wiedergabe gestattet). Ausgerechnet mit den Stolpersteinen jetzt eine
Relevanz-Debatte anfangen zu wollen finde ich übertrieben. Wir haben
derzeit ca. 5823 nodes mit Stolpersteinen in der db, die von ungefähr
170 Leuten eingetragen/angefasst wurden (Angaben von hier:
http://taginfo.openstreetmap.org/keys/memorial%3Atype#overview ). Das
sind alles Mapper, denen man mit solchen Forderungen auf die Füße
tritt. Und auch von einem anderen Standpunkt aus betrachtet: selbst
wenn das keine Gedenksteine wären, sondern einfach nur "seltene,
goldene" Pflastersteine, dann würden viele Mapper das vermutlich schon
taggen, z.B. auch zur Orientierung.

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

Re: [Talk-de] Stolperstein-Relation in Frankfurt /M

[Stephan Wolff]

Moin!

Am 14.03.2012 20:17, schrieb Frederik Ramm:

Es waere im Grunde genommen sinnvoll, alle Stolperstein-Relationen zu
loeschen. Die sind allerhoechstens als Uebergangsloesung akzeptabel,
solange wir keinen wirklich stabile XAPI- oder Overpass-Server haben,
mit dem man schnell "alle Objekte mit X=Y im Bereich Z" abfragen kann.


Mich stören solche Relationen nicht. Im Gegensatz zu großen Grenz- oder
Routenrelationen, die häufig schwer lösbare Konflikte beim Hochladen
verursachen, dürften ähnliche Probleme bei Sammlungen von POIs sehr
selten sein.
Die Zusammenfassung von gleichen Tags in einer Relation erspart die
Wiederholung dieser Daten an allen Einzelobjekten. Das macht nicht nur
die Übertragung und Verarbeitung der Daten schneller, sondern
erleichtert auch die Datenpflege. Gerade bei Kontaktdaten wie Telefon,
Fax, URL oder Wikipediareferenzen sind Änderungen absehbar.

Sammelrelationen fassen oft Objekte in politischen Grenzen zusammen.
Kann man mit der Overpass-API auch "alle Objekte mit X=Y im Kreis Z"
bekommen?
Die Untergliederung der Stolperstein-Relationen nach Stadtteilen finde
ich allerdings überflüssig.

Mich stören zwei andere Dinge an den Stolperstein-Daten:

Die Relationen verwenden das "name"-Tag für eine Beschreibung der
Relation. Ein Objekt "Stolpersteine in Frankfurt am Main" gibt es in
der Realität nicht. "description" wäre dafür geeigneter. Ein Mensch
kann Namen und Beschreibungen im name-Tag vielleicht unterscheiden, ein
Auswerteprogramm nicht. Diese "name"-Missbrauch betrifft nicht speziell
diese Relationen, sondern ist weit verbreitet. Leider wird bei JOSM nur
"name", "ref" und "note" als Text in der Relationsliste angezeigt, aber
nicht "description".

Die gesamte Aufschrift der Stolpersteine in einzelnen Tags zu erfassen 
(memorial:birth, memorial:death, ...), finde ich unpassend.
Lebensdaten von Personen und Volltexte von Gedenkstätten oder Infotafeln 
sind keine Geodaten. Vermutlich wird eine Stolperstein-Karte

die einzige Anwendung sein, die diese Daten verwendet. Diese Anwendung
könnte dann auch eine externe Datenbank lesen.

Gruß
Stephan


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

Re: [Talk-de] Umfrage über Anreize zum Beitragen bei OpenStreetMap

[Rainer Knaepper]

Am 15.03.2012 00:07, schrieb Marian Steinbach:


Zum Thema "Hürden" habe ich ehrlich gesagt nicht viel gefunden in den Fragen.


Knuffig finde ich, daß Menschen, die keine weiterführende 
Schule besucht und keinen Hochschulabschluß haben, von der 
Umfrage ausgeschlosssen sind.


Rainer


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

Re: [Talk-de] OSBugs bug?

[Michael Bemmerl]

Steffen Grunewald schrieb:
> On Mon 2012-03-12 (00:56), Michael Bemmerl wrote:
>>> Ich würde jedenfalls erst einmal die Geocoder-DB ansehen, welche 
>>> Überraschungen dort noch warten.
>> Richtig, in der Datenbank ist Mischmasch zwischen ISO-8819-x und UTF-8.
>> Beispiel ID 7: "Châteaugiron". Das â ist als 0xE2 in der DB, wäre als
>> UTF-8 aber 0xC3 0xA2.
> 
> Und noch schlimmer, der zugehörige Großbuchstabe wäre 0xC2, ein weit
> verbreiteter UTF-8-"Präfix".

> Ein einzelnes Byte >=0x80 ließe sich ja u.U. noch erkennen (und mit ein
> wenig Hintergrund, der die Zuordnung der Codierung erlaubt, auch automatisch
> korrekt nach UTF-8 wandeln), aber was ist mit aufeinanderfolgenden solchen
> Zeichen ("äß", etc, s.o.)? 

Die Änderung am Code, wodurch UTF-8-Zeichen in die Latin-1-DB gekommen
sind, ist ja am 10.08.2011 gepushed worden. Eventuell wäre es somit
möglich, nur die Texte der Bugs zu konvertieren, die vor diesem Datum in
die DB eingetragen worden sind?

Grüße,
Michael



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

Re: [Talk-de] Umfrage über Anreize zum Beitragen bei OpenStreetMap

[Marian Steinbach]

Zum Thema "Hürden" habe ich ehrlich gesagt nicht viel gefunden in den Fragen.

Grüße

Marian

Am 14. März 2012 13:47 schrieb Dominik Wilmsen :
> Wir möchten Sie zur Teilnahme an einer Umfrage einladen, in der es um
> Motivationen und Hürden geht, geographische Information zu
> OpenStreetMap beizutragen. OpenStreetMap ist ein Projekt, bei der eine
> freie und editierbare digitale Weltkarte erstellt wird.
>
> ...

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

[Talk-de] Erfassung von E-Mail Adressen und Spam

[Martin Czarkowski]

Servus,

beim Eintragen von Öffnungszeiten, Telefonnummern und Emailadressen ist 
mir aufgefallen, dass viele Webseitenbetreiber die Emailadresse in der 
Form name(at)domain.de im Impressum haben, (ob es gegen Spam tatsächlich 
hilft, kann ich nicht sagen) in die Datenbank tragen wir sie aber in der 
Form n...@domain.de ein. Geben wir somit den Herstellern von Spammails 
leichtes Futter für ihre Suchprogramme? Hebeln wir damit nicht den 
vermeintlichen Schutz der Internetseitenbetreiber aus? Wie soll man am 
besten vorgehen?


Gruß
Martin

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

Re: [Talk-de] Änderungen an der API zum Lizenzwechsel

[Frederik Ramm]

Hallo,

On 03/14/2012 02:50 PM, Walter Nordmann wrote:

Frage: Werden dabei DIFF-Files erzeugt?


Das ist noch nicht klar.


Wenn ja, bedeutet das letztendlich, dass fast der gesammte Planet "über die
Leitung" kommt und mir die DB "zumüllt". Bis jetzt kommen ja alle Änderungen
rüber, die weltweit gemacht wurden, aber das hier wäre dann dann ein
Super-Edit, der alles Bisheriges übertreffen würde. Da bliebe mir nur ein
Neuaufbau NACH dem bot.


So schlimm ist es nicht; es wuerden insgesamt 30 Millionen Objekte 
geaendert werden. Derzeit werden an einem durchschnittlichen Tag so 
ungefaehr 2 Millionen Objekte veraendert. Das heisst, wenn sich der 
Lizenzwechsel-Bot z.B. 2 Wochen lang vergnuegen wuerde, waeren das pro 
Tag 2,1 Millionen lizenzbedingte Aenderungen, also lediglich eine 
Verdopplung der Aktivitaet zwei Wochen lang.


Allerdings ist das ganze in der Tat ein rechtliches Problem, weil ich 
nicht glaube, dass aus einer bei Dir lokal vorhandenen 
CC-BY-SA-Datenbank so einfach durch Aufspielen von ein paar Diffs eine 
ODbL-Datenbank werden kann. Wie das also alles laeuft mit den Diffs 
usw., das muss man erst noch sehen.


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] Änderungen an der API zum Lizenzwechsel

[Frederik Ramm]

Hallo,

On 03/14/2012 07:11 PM, Steffen Wolf wrote:

Da steht nicht konkret, wann die Datenbank dann unter der ODBL
veroeffentlicht wird, aber anzunehmen ist, dass dies erst geschieht,
wenn der Bot durch ist.


Vorher geht ja nicht.


Bleiben die "geloeschten" Daten dann eigentlich in der Datenbank?


Vermutlich vorerst ja; langfristig ist es noch nicht klar.


Koennten Spaetkommer dann noch nach dem ersten Bot-Durchlauf zustimmen,
und wuerde der Bot einfach noch einmal laufen?


Technisch ist das denkbar, aber persoenlich wuerde ich sagen, wenn nicht 
ganz handfeste Gruende vorliegen (Person lag 2 Jahre im Koma und hat 
erst jetzt vom Lizenzwechsel erfahren), dann wird das nicht gemacht. 
Sonst haben wir lauter nicht-Entscheider, die meinen, sie koennten noch 
Poker spielen.



Und koennte man bei
strenger ODBL-Auslegung die OSMF auffordern, die gesamte Datenbank zu
veroeffentlichen, da diese ja in einem solchen Zwischenzustand einen Mix
aus ODBL- und weiteren Daten enthaelt?


Nein.

Der Grund dafuer ist der, dass die Datenbank, die die OSMF bei sich 
haelt, *nicht* unter der ODbL (und auch nicht unter CC-BY-SA) steht, 
sondern nur unter den Contributor Terms. Der Mapper sagt zur OSMF qua 
CT: "Hier, liebe OSMF, hast Du meine Daten, und Du darfst die gern 
veroeffentlichen, aber wenn Du das tust, dann nur unter der CC-BY-SA 
oder ODbL". Die Daten, die der Mapper der OSMF gibt, stehen aber nicht 
unter der ODbL - die ODbL kommt sozusagen erst an der "Ausgabeseite" der 
Daten zum Tragen.


Wuerde jemand anders das tun - die ODbL-Daten von der OSMF mit einem 
Extrakt eines alten Planetfiles mischen - so haette der vermutlich ein 
Problem ;)


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] Stolperstein-Relation in Frankfurt /M

[Frederik Ramm]

Hallo,

On 03/14/2012 04:45 PM, Jan Tappenbeck wrote:

auch wenn ich gleich Schläge bekomme wegen der Relation für
Stolpersteine - aber in Frankfurt/M sind für ca. 30 Steine (wenn ich es
richtig sehe) ca. 10 Relationen angelegt in einer Superrelation
(http://www.openstreetmap.org/browse/relation/1177132).

Wäre es nicht sinnvoll diese zumindest auf eine für ganz Frankfurt
zusammen zu fassen ?


Es waere im Grunde genommen sinnvoll, alle Stolperstein-Relationen zu 
loeschen. Die sind allerhoechstens als Uebergangsloesung akzeptabel, 
solange wir keinen wirklich stabile XAPI- oder Overpass-Server haben, 
mit dem man schnell "alle Objekte mit X=Y im Bereich Z" abfragen kann. 
Aber an der Front werden ja gute Fortschritte gemacht, so dass wir alle 
diese (und aehnliche) Relationen hoffentlich bald entsorgen koennen.


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] Änderungen an der API zum Lizenzwechsel

[Steffen Wolf]

Frederik Ramm schrieb

> mit dem Lizenzwechsel werden sich ein paar Details an der API aendern,
> und zwar ueberall dort, wo es um die Historie von Objekten geht.

> http://wiki.openstreetmap.org/wiki/Open_Database_License/Changes_in_the_API

Und dort steht:

| The license change will be performed on the live database (i.e. no
| dump and reload). Data contributed by non-agreers will, for the time
| being, be kept in the database but specially marked.

| For every object that is tainted in some way by non-agreeing edits, a
| bot will modify or delete the object so that the current version is
| ODbL compatible.

Da steht nicht konkret, wann die Datenbank dann unter der ODBL
veroeffentlicht wird, aber anzunehmen ist, dass dies erst geschieht,
wenn der Bot durch ist.

Bleiben die "geloeschten" Daten dann eigentlich in der Datenbank?
Koennten Spaetkommer dann noch nach dem ersten Bot-Durchlauf zustimmen,
und wuerde der Bot einfach noch einmal laufen? Und koennte man bei
strenger ODBL-Auslegung die OSMF auffordern, die gesamte Datenbank zu
veroeffentlichen, da diese ja in einem solchen Zwischenzustand einen Mix
aus ODBL- und weiteren Daten enthaelt?

Naja, es bleibt spannend,
 stw
-- 
"Ich hab grad einen Wecker auf meinem Computer installiert. Morgen um
6:40 macht er trrlllüp, trrlllup."
"Na und? Ich hab grad die Zeitschaltuhr an meiner Lampe angeschlossen."
 [Gespräch zwischen mir und meinem Bruder]

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

Re: [Talk-de] brachliegende ehmalige Bahngelände etc.

[Garry]

Am 13.03.2012 19:37, schrieb Jan Tappenbeck:

hi !

immer wieder kommt die Frage auf - vielleicht gibt es zwischenzeitlich 
eine Lösung.


Wie würdet Ihr brachliegende Flächen (z.b. auch alte Bahngelände die 
zugewuchert sind) taggen.


natural = scrub finde ich immer noch etwas unpassend!

Speziell bei "alten" Bahngeländen kommt es darauf an welchen Status das 
Gelände hat.
Ein stillgelegtes Bahngelände - oder besser das Bahngelände einer 
stillgelegten Bahn - ist immer noch ein Bahngelände, also landuse=railway.
Wenn es zwischenzeitlich zugewuchert ist passt ein zusätzliches 
natural=scrub schon so halbwegs.


Wenn konsequent eine Trennung zwischen Landnutzung, Bodenbedeckung,... 
umgesetzt würde wären solche Fälle auch eindeutiger zu beschreiben.

Ein z.B. landuse=grass ist da einfach ein Unding!
Sinnvoll wäre ein landcover=grass, dazu vielleicht noch ein 
grass=natural/.../.. um wildgewachsenes Grass (Brachflächen, 
Hochgebirgswiesen) vom englischen Rasen etc.  unterscheiden zu können


Garry

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

[Talk-de] Liste Filialschliessungen Schlecker

[Garry]

Hier wurde eine Liste von der Schliessung betroffener Schlecker-Filialen 
veröffentlicht:


http://www.swr.de/nachrichten/bw/-/id=1622/nid=1622/did=9428862/5m48oe/index.html

Vielleicht mag ja jemand eine OSM-Statistik daraus erstellen bevor die 
Filialen gelöscht werden...


Garry

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

[Talk-de] Stolperstein-Relation in Frankfurt /M

[Jan Tappenbeck]

Hi !

auch wenn ich gleich Schläge bekomme wegen der Relation für 
Stolpersteine - aber in Frankfurt/M sind für ca. 30 Steine (wenn ich es 
richtig sehe) ca. 10 Relationen angelegt in einer Superrelation 
(http://www.openstreetmap.org/browse/relation/1177132).


Wäre es nicht sinnvoll diese zumindest auf eine für ganz Frankfurt 
zusammen zu fassen ?


Vielleicht ließt ja einer von den Frankfurtern mit - würde dann auch 
versuchen eine autom. Vollständigkeitsauswertung mal auf die Beine zu 
stellen wie in HH.


Anfrage für Liste läuft.

Gruß Jan :-)

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

Re: [Talk-de] Remapping: Rettet die place-nodes! (Karte)

[BBO]

Hartmut Holzgraefe-2 wrote
> 
> Ich persönlich würde solche Nodes nicht ersetzen wollen
> sondern eher schon mit einem ODBL=clean versehen wenn
> ich die enthaltenen Informationen (außer TMC) alle
> bestätigen kann und evtl. die Nodeposition noch händisch
> anpassen wenn die nicht mit der gefühlten Ortsmitte
> übereinstimmt ...?

odbl=clean ist unter den bekannten Bedingungen natürlich eine Alternative
zum ersetzten.


Hartmut Holzgraefe-2 wrote
> 
> PS: nen Infolink auf osm.mapki.com damit man sehen kann
> welcher Teil der Nodedaten überhaupt problematisch
> ist wär auch fein? :)
> 

Ist drin...

Danke für dein Feedback!

Gruß
Bastian

--
View this message in context: 
http://gis.19327.n5.nabble.com/Remapping-Rettet-die-place-nodes-Karte-tp5564856p5565001.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] Remapping: Rettet die place-nodes! (Karte)

[Hartmut Holzgraefe]

On 14.03.2012 15:13, BBO wrote:

> Bedrohte place-nodes finden um diese im Editor zu öffnen um bei Kenntnis zu
> ersetzen.

wie ist dabei mit place nodes umzugehen die zB. der TMCbot (ein
Zustimmer) mit Attributen angereichert hat? z.B.:

  http://osm.mapki.com/history/node.php?id=149087425

Ich persönlich würde solche Nodes nicht ersetzen wollen
sondern eher schon mit einem ODBL=clean versehen wenn
ich die enthaltenen Informationen (außer TMC) alle
bestätigen kann und evtl. die Nodeposition noch händisch
anpassen wenn die nicht mit der gefühlten Ortsmitte
übereinstimmt ...?

PS: nen Infolink auf osm.mapki.com damit man sehen kann
welcher Teil der Nodedaten überhaupt problematisch
ist wär auch fein? :)

-- 
hartmut

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

[Talk-de] Remapping: Rettet die place-nodes! (Karte)

[BBO]

Moin
Da im License Change View des OSMI die meiner Meinung nach wichtigen
place-nodes oft in der Masse untergehen habe ich mal eine Karte (bzw. ein
Overlay) erstellt die nur diese nodes darstellt.

http://placerescue.betaforever.de/

Hinweise:
* Dargestellt werden die vom Lizenzwechsel bedrohten place-nodes in
Deutschland
* Updates gibt es mindestens einmal am Tag
* Zur Anzeige der nodes werden derzeit knapp 3MB geladen
* Der JOSM-Link lädt nur den place-node, vor dem Ersetzen sollte ein Gebiet
um den node nachgeladen werden um Konflikte zu vermeiden

Was ihr mit Hilfe der Karte machen könnt:
Bedrohte place-nodes finden um diese im Editor zu öffnen um bei Kenntnis zu
ersetzen.

Gruß
Bastian

--
View this message in context: 
http://gis.19327.n5.nabble.com/Remapping-Rettet-die-place-nodes-Karte-tp5564856p5564856.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] Änderungen an der API zum Lizenzwechsel

[Walter Nordmann]

hi,

am Anfang steht "The license change will be performed on the live
database..."

und diese werden ja durch einen bot gemacht.

Frage: Werden dabei DIFF-Files erzeugt? 

Wenn ja, bedeutet das letztendlich, dass fast der gesammte Planet "über die
Leitung" kommt und mir die DB "zumüllt". Bis jetzt kommen ja alle Änderungen
rüber, die weltweit gemacht wurden, aber das hier wäre dann dann ein
Super-Edit, der alles Bisheriges übertreffen würde. Da bliebe mir nur ein
Neuaufbau NACH dem bot.

Irgendwie erscheint mir das logisch, damit die lokalen Kopien auch
ODBL-Konform sind.

Gruss
Walter 


-
1---2-3-**4#
--
View this message in context: 
http://gis.19327.n5.nabble.com/Anderungen-an-der-API-zum-Lizenzwechsel-tp5564676p5564755.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

[Talk-de] Änderungen an der API zum Lizenzwechsel

[Frederik Ramm]

Hallo,

   mit dem Lizenzwechsel werden sich ein paar Details an der API 
aendern, und zwar ueberall dort, wo es um die Historie von Objekten 
geht. "Normale" API-Calls, die nur die aktuelle Version abfragen, 
bleiben unveraendert.


Hier ist eine vorlaeufige Dokumentation der Aenderungen:

http://wiki.openstreetmap.org/wiki/Open_Database_License/Changes_in_the_API

Wer Software oder Dienste betreibt, die historische Daten herunterladen, 
sollte sich damit beschaeftigen.


Leider gibt es noch keine Testinstallation der neuen API. (Weil der Code 
noch gar nicht fertig ist.)


Bye
Frederik

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

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

[Talk-de] Umfrage über Anreize zum Beitragen bei OpenStreetMap

[Dominik Wilmsen]

Wir möchten Sie zur Teilnahme an einer Umfrage einladen, in der es um
Motivationen und Hürden geht, geographische Information zu
OpenStreetMap beizutragen. OpenStreetMap ist ein Projekt, bei der eine
freie und editierbare digitale Weltkarte erstellt wird.

Die Umfrage besteht aus maximal achtzehn Fragen, deren Beantwortung
fünf bis zehn Minuten in Anspruch nehmen sollte. Die Teilnahme an
dieser Umfrage ist freiwillig und anonym.

Wir möchten Sie bitten, die Umfrage und die dazugehörigen Links weiter
zu verteilen. Jeder kann mitmachen und es wird kein Hintergrundwissen
zu OpenStreetMap vorausgesetzt.

Diese Studie ist Teil einer Diplomarbeit am Institut für Geoinformatik
an der Westfälischen Wilhelms-Universität Münster.

Um an der Umfrage teilzunehmen, klicken Sie auf folgenden Link:
https://www.surveymonkey.com/s/WSHWJ3M

Die Umfrage gibt es auch auf Englisch:
https://www.surveymonkey.com/s/WXBZ7LB

Vielen Dank im voraus für Ihre Teilnahme
Dominik Wilmsen

Falls Sie weitere Fragen haben, kontaktieren Sie mich bitte unter
wilms...@gmail.com.

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

Re: [Talk-de] Genauigkeit von "buildings"

[Martin Koppenhoefer]

Am 14. März 2012 13:13 schrieb Schorschi :
> Mit diesen "sehr detaillierten" Daten der Verwaltung erlebt man durchaus
> auch seine Überraschungen ;-) Oft sind sie aus Baueingaben, und Baueingabe
> und Realität passen nicht immer so ganz zusammen.
>
> Ich würde sagen (und mache das auch so):
>
> - immer die Ungenauigkeit vom GPS im Hinterkopf haben
> - Aufwand und Ergebnis sollten in Relation stehen
> - Wenn die Abschätzung gut möglich ist, ist ein eingezeichnetes Gebäude
>  immer hilfreich und begrüßenswert
> - was "gut" ist, muss jeder für sich definieren - für mich ist eine
>  Abweichung von 10 Metern für ein wirklich freistehendes Gebäude durchaus
>  tolerierbar, kann ja im nächsten Durchlauf verbessert werden.
>  Hauptsache, die groben Proportionen stimmen.


kann ich alles voll unterschreiben. Wir sollten anstreben, die Welt
abzubilden, durch Begehungen vor Ort verifiziert, und nicht die Daten
der Ämter übernehmen, die uns sicherlich meistens deutlich überlegen
sind, was die Detaillierung und Präzision angeht, die aber eben
gelegentlich auch Planungsstände und Genehmigungsstände (und zwar nur
der genehmigten Bauwerke, Schwarzbauten sind da normalerweise nicht
enthalten) abbilden und teilweise eben nicht den tatsächlichen Stand
wiedergeben.

Gruß Martin

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

Re: [Talk-de] Genauigkeit von "buildings"

[Schorschi]

Moin,

On Tue, 13 Mar 2012, Wolfgang Wienke wrote:

> Soweit ich die Daten der bei mir vor Ort eingezeichneten Häuser (vermutlich
> aus Luftbildern) überprüft habe, sind sie mit erheblichen Fehlern und
> Ungenauigkeiten behaftet. 

> Ich kann dies einerseits durch in Augenscheinnahme
> und auch durch Vergleich mit den sehr detaillierten Flurstück/Häuser-Daten der
> Stadtverwaltung beurteilen.

Mit diesen "sehr detaillierten" Daten der Verwaltung erlebt man durchaus 
auch seine Überraschungen ;-) Oft sind sie aus Baueingaben, und Baueingabe 
und Realität passen nicht immer so ganz zusammen.

Ich würde sagen (und mache das auch so):

- immer die Ungenauigkeit vom GPS im Hinterkopf haben
- Aufwand und Ergebnis sollten in Relation stehen
- Wenn die Abschätzung gut möglich ist, ist ein eingezeichnetes Gebäude 
  immer hilfreich und begrüßenswert
- was "gut" ist, muss jeder für sich definieren - für mich ist eine 
  Abweichung von 10 Metern für ein wirklich freistehendes Gebäude durchaus 
  tolerierbar, kann ja im nächsten Durchlauf verbessert werden. 
  Hauptsache, die groben Proportionen stimmen.

Gruß, Schusch___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Genauigkeit von "buildings"

[aighes]

So hat jeder seine Meinung:-)

Henning


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

Re: [Talk-de] Genauigkeit von "buildings"

[Ronnie Soak]

2012/3/14, aighes :
> Im Forum gibt es mehr Infos dazu:
>
> http://forum.openstreetmap.org/search.php?action=search&keywords=global+ortho&author=&forums=14&search_in=0&sort_by=0&sort_dir=DESC&show_as=topics

Auch dort nur gespanntes Warten, keine Infos ueber die Lizenz und
immer mal wieder der Hinweis, dass es in Deutschland noch nicht mal
los gegangen ist.

Mein Tip, ohne jede faktische Grundlage:
Ende 2012 gibt es ein paar Beispiele in Ballungszentren, dann zieht
sich das ueber die naechsten 3 Jahre bis zur flaechigen Abdeckung.

Ich wuerde auf jeden fall keine Mappingvorhaben deswegen aufschieben.

Gruss,
Chaos99

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

Re: [Talk-de] Backup der JOSM Konfiguration

[Martin Koppenhoefer]

Am 14. März 2012 09:36 schrieb Falk Zscheile :
> Gibt es bei JOSM keine Option, die das automatisch aller paar Minuten 
> erledigt?


Es gibt autosave, das speichert die Daten (osm-data), aber nicht die
Einstellungen (preferences) oder welche Layer gerade geladen waren,
bzw. sichtbar waren, etc.

Gruß Martin

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

Re: [Talk-de] Genauigkeit von "buildings"

[aighes]

Im Forum gibt es mehr Infos dazu:

http://forum.openstreetmap.org/search.php?action=search&keywords=global+ortho&author=&forums=14&search_in=0&sort_by=0&sort_dir=DESC&show_as=topics

Henning


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

Re: [Talk-de] Genauigkeit von "buildings"

[Ronnie Soak]

Am 14.03.12 schrieb Martin Trautmann :

>
> Hier auf der Liste wurde das genannt:
> 
>

Also da wuerde ich mal nicht darauf warten.. Klingt wie eine
Standard-Pressemeldung a la "Wir haben da diese tolle Firma aufgekauft
und wollen jetzt die Welt erobern".
Da steht kein Datum, keine Info ueber die Abdeckung und kein Wort zur
Lizensierung.

Nur 'Wir wollen das' und 'Wir haben mal angefangen'.

Gruss
Chaos99

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

Re: [Talk-de] Genauigkeit von "buildings"

[Martin Trautmann]

On 12-03-14 9:21, hike39 wrote:
> Am 13.03.2012 09:03, schrieb aighes:
>> Bedenke auch, dass in wenigen Monaten bessere Luftbilder verfügbar sein
>> werden.
> 
> Ist mir da etwas entgangen? Von wem sollen die denn zur Verfügung
> gestellt werden?

Hier auf der Liste wurde das genannt:


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

Re: [Talk-de] Backup der JOSM Konfiguration

[Falk Zscheile]

Am 14. März 2012 09:11 schrieb hike39 :
> Am 13.03.2012 17:50, schrieb malenki:
>> Walter Nordmann schrieb:
>>
>>> vor eventuellen Änderungen am besten sichern.
>>
>> Man sollte /regelmäßig/ sichern.
>
>  sag' ich meinen Freunden und Bekannten auch immer!   ;-)


Gibt es bei JOSM keine Option, die das automatisch aller paar Minuten erledigt?

Gruß, Falk

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

Re: [Talk-de] Genauigkeit von "buildings"

[hike39]

Am 13.03.2012 09:03, schrieb aighes:
> Bedenke auch, dass in wenigen Monaten bessere Luftbilder verfügbar sein
> werden.

Ist mir da etwas entgangen? Von wem sollen die denn zur Verfügung
gestellt werden?

hike39


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

Re: [Talk-de] Backup der JOSM Konfiguration

[hike39]

Am 13.03.2012 17:50, schrieb malenki:
> Walter Nordmann schrieb:
> 
>> vor eventuellen Änderungen am besten sichern.
> 
> Man sollte /regelmäßig/ sichern.

> Gruß
> Thomas

 sag' ich meinen Freunden und Bekannten auch immer!   ;-)
hike39


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