date:20140216

Christoph schrieb:
 Verstehe ich das richtig ?
 Du möchtest jedem user einen account verpassen? Das muss dann
 konsequenterweise auch bei Browsernutzung passieren.

Jedem User, der eine Anwendung != Browser benutzt, die auf die API
zugreift.

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T12:25:39+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Simon Poole schrieb:
 - zu behaupten, dass eine Massnahme nicht funktionieren kann

Bitte genau lesen. Ich wies jedenfalls völlig richtig darauf hin, dass
der User-Agent nicht dazu geeignet ist, einen zugreifenden Client
(anders als ein Token oder besser ein Useraccount) einwandfrei zu
identifizieren, und daher als alleiniges Erkennungsmerkmal schlicht
ungeeignet ist.

Ich könnte wget anweisen, sich als „wget/1.15“ auszuweisen, oder aber
auch als „Skynet/1.0“ oder als ein aktueller Firefox. In allen drei
Fällen kann ich massenhaft scriptgesteuert Kacheln runterladen, bis die
Leitung glüht, und im letzten Fall kann ich nicht mal gesperrt werden
(IPs lassen sich wechseln), und alle drei Varianten ist der
entstandene Traffic sogar ein paar Byte je Abruf größer als ohne UA.

Die Maßnahme an sich funktioniert in einem gewissen Rahmen, nur stützt
sie sich auf etwas, das vom Konzept her von Grund auf als technisch
komplett unverifiziert einzustufen ist.

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T12:27:59+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Also kannst Du Anwendung und Browser voneinander unterscheiden?
Spannend...
Am UA-String ja offensichtlich nicht, denn dann könnte ja auch weiterhin
jede Anwendung sich einen Browser-UA-String suchen und den nutzen, ohne
dass das ein Problem wäre.

Abgesehen davon: Was ist ein Browser, was eine Anwendung?
Ist eine Facebook-App ein Browser, wenn sie Links verfolgt? Ist
Thunderbird ein Browser, weil man auch innerhalb von Thunderbird unter
Nutzung der Gecko-Engine Webseiten direkt öffnen kann?
Ist ein Browser-Plugin für Mails noch ein Browser? ist ein
Browserplugin, das die vorhandene Adressbuchfunktion um eine Karte
erweitert, die die Kontakte darauf darstellt?

Inwiefern würde eine solche Lösung das Verfahren einfacher,
fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter machen?

Gruß
Peter

Am 16.02.2014 12:27, schrieb Dirk Sohler:
 Christoph schrieb:
 Verstehe ich das richtig ?
 Du möchtest jedem user einen account verpassen? Das muss dann
 konsequenterweise auch bei Browsernutzung passieren.
 
 Jedem User, der eine Anwendung != Browser benutzt, die auf die API
 zugreift.
 
 Grüße,
 Dirk
 
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de
 


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

Re: [Talk-de] Datenschutz bei OSM (war: Mapnik Administration blockt QLandkarteGT)

2014-02-16 Per discussione Falk Zscheile

Am 16. Februar 2014 10:43 schrieb Jörg Frings-Fürst o...@jff-webhosting.net:


 Festzustellen ist jetzt also das Daten, die dem BDSG unterliegen und nur
 auf richterliche Anordnung anderen zur Verfügung gestellt werden dürfen,
 ohne besonderen Anlass [ZITAT] irgendwelchen Kollegen [/ZITAT] bekannt
 gegeben werden.



Und ich finde, dass es wesentlich besserer Stil wäre, jemanden auf
rechtlich problematisches Verhalten per PM hinzuweisen, anstatt ihn an
den Mailinglistenpranger zu stellen.

Für das eigentlichen Problem, bzw. für dessen Lösung, hat der
rechtlich vermutlich zutreffende Hinweis[1] leider keinerlei Relevanz.
Er geht nicht über ein: Ätsch, ich habe dich bei etwas erwischt, was
du nicht darfst. hinaus.

Gruß Falk

[1] Einmal unterstellt es ist deutsches Recht anwendbar.

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

Re: [Talk-de] Datenschutz bei OSM (war: Mapnik Administration blockt QLandkarteGT)

2014-02-16 Per discussione Jörg Frings-Fürst

Am Sonntag, den 16.02.2014, 13:10 +0100 schrieb Falk Zscheile:
 Am 16. Februar 2014 10:43 schrieb Jörg Frings-Fürst o...@jff-webhosting.net:
 
 
  Festzustellen ist jetzt also das Daten, die dem BDSG unterliegen und nur
  auf richterliche Anordnung anderen zur Verfügung gestellt werden dürfen,
  ohne besonderen Anlass [ZITAT] irgendwelchen Kollegen [/ZITAT] bekannt
  gegeben werden.
 
 
 
 Und ich finde, dass es wesentlich besserer Stil wäre, jemanden auf
 rechtlich problematisches Verhalten per PM hinzuweisen, anstatt ihn an
 den Mailinglistenpranger zu stellen.
 
An den Pranger hat er sich selbst gestellt, ich nur auf seine Mail 
geantwortet und festgestellt das das IMHO nicht in Ordnung ist.

 
 
 Für das eigentlichen Problem, bzw. für dessen Lösung, hat der
 rechtlich vermutlich zutreffende Hinweis[1] leider keinerlei Relevanz.
 Er geht nicht über ein: Ätsch, ich habe dich bei etwas erwischt, was
 du nicht darfst. hinaus.
 
Das denke ich nicht. Der deutsche Tile-Server wird von der FOSSGIS 
mit Sitz in Potsdam betrieben, unterliegt damit dem deutschen Recht.

Also nix Ätsch sondern ein big Problem.


 
 
 Gruß Falk
 
 [1] Einmal unterstellt es ist deutsches Recht anwendbar.
[...]


Gruß Jörg



-- 
Jörg Frings-Fürst
OSM privat
D-54526 Landscheid
GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A
Full GPG key: hkp://pool.sks-keyservers.net
CAcert Serialnr.: 0D:9A:23
SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E
http://cacert.org

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Peter Wendorff schrieb:
 Also kannst Du Anwendung und Browser voneinander unterscheiden?

Mittels anwendungsspezifischem Token, der aufgrund der API nur durch
entsprechende Header übermittelt werden kann eher, als über einen
simplen String, in den jeder reinschreiben kann, was er will.


 Abgesehen davon: Was ist ein Browser, was eine Anwendung?

Stelle dich doch bitte nicht bitte dümmer, als du bist.

Hier: Browser = Das Ding, mit dem du im WWW (!= „das Internet“) Seiten
aufrufen kannst, und eben auch die OSM-Seite; und Anwendung: Spezielles
Programm, das zum Abruf der OSM-Kacheln über die OSM-API verwendet
wird, ohne darüber hinaus andere Dienste im Internet (vgl. WWW) nutzen
zu können.


 Ist [beliebige Anwendung] ein Browser, wenn sie Links verfolgt?

In dem hier verwendeten Zusammenhang ist eine Anwendung dann ein
Browser, wenn sie die WWW-Seite benutzt. Wenn sie die API benutzt,
nein. Aber da du nur provozieren willst, brauche ich dir das sicher
nicht zu erklären, da du es bereits weißt.


 Inwiefern würde eine solche Lösung das Verfahren einfacher,
 fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter
 machen?

Die Vorteile eines anwendungsspezifischen Tokens sind, sofern der Token
geheim bleibt (Closed-Source oder sonstwie verschlüsselt, und nicht
einfach so durch andere Nutzbar, oder über Sniffer aus den übertragenen
Datenpaketen auslesbar), dass die Anwendung zuverlässig identifiziert
werden kann.

Die Vorteile eines „Accountzwangs“ bei einer Anwendung (vgl. Definition
weiter oben) ist, dass man eindeutig einen Useraccount identifizieren
kann, und man diesen Gezielt sperren kann. Natürlich kann ein Anwender
sich einfach einen neuen Account anlegen, aber ein Entwickler kann auch
seiner Anwendung den Firefox-UA-String verpassen.

Aber mal andersherum gefragt: Inwiefern ist alleinig die Auswertung
eines simplen Strings fälschungssicher? Was hindert einen Entwickler,
der alle Tiles runterladen will eher daran, das technisch umzusetzen?
Ein beliebig änderbarer String, eine App-Registrierung um einen Token
zu bekommen, oder die Notwendigkeit eines Useraccounts?


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T15:01:31+0100


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

Re: [Talk-de] Datenschutz bei OSM (war: Mapnik Administration blockt QLandkarteGT)

2014-02-16 Per discussione Falk Zscheile

Am 16. Februar 2014 13:52 schrieb Jörg Frings-Fürst o...@jff-webhosting.net:

 Das denke ich nicht. Der deutsche Tile-Server wird von der FOSSGIS
 mit Sitz in Potsdam betrieben, unterliegt damit dem deutschen Recht.

 Also nix Ätsch sondern ein big Problem.


Gut, dann kann es sich zumindest zu einem Problem auswachsen.

Ich hätte mit trotzdem gewünscht, dass die Diskussion zur
datenschutzrechtlichen Problematik von IP-Adressen und deren
Zugänglichkeit auf dem deutschen Tile-Server anders gestartet wäre.

Gruß Falk

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione Philipp Matthias Hahn

Moin,

On Sat, Feb 15, 2014 at 12:45:38PM +0100, Dirk Sohler wrote:
 hike39 schrieb:
...
  here is a quick release to end the OSM misery. I am still not
  convinced that transmitting the user-agent string does really help to
  prevent any misuse. […]
 
 Damit hat er KOMPLETT recht. Der User-Agent sagt absolut rein GAR
 NICHTS darüber aus, welcher Client auf den Server zugreift, da der
 User-Agent ohne weiteres verändert werden kann.

Leute! Überlegt euch mal bitte, was ihr hier verlangt. Die Ressourcen
von OSM sind begrenzt. Solange IHR nicht EUER Geld in die Hand nehmt und
damit Server und Bandbreite kauft, und das dann anschließend nicht nur
für euch nutzt, sondern KOSTENLOS der Welt zur Verfügung steht, solltet
ihr euch anderen gegenüber höflich verhalten. Das ist zumindest meine
bescheidene Meinung.

Und weil es leider einige gibt, die sich nicht an die Spielregeln
halten, muss es leider auch Mechanismen geben, die solche Spielverderber
bremsen.

Und hier gibt es zwei Kategorien:
1. Unbeabsichtigte Programmfehler, die unbeabsichtigt dafür sorgen, daß
das Programm Amok läuft und eben zu Lasten aller Ressourcen verbraucht.
Und hier ist ein aussagekräftiger User-Agent-String eben durchaus
hilfreich, weil man dann mit den Verursachern in Kontakt treten kann, um
eine sinnvolle Lösung zu entwickeln.

2. Absichtliches ignorieren der Spielregeln. Und hier hilft eben kein
User-Agent, denn wer genügend kriminell ist, der fälscht eben auch so
was, um solche Beschränkungen zu umgehen.

Was kommt als nächstes?

Du blockst meine IP-Adresse, also hacke ich deinen Rechner und nutze die?
Bei nur 4 Mrd. IPv4-Adressen mag man vielleicht noch auf die Idee kommen,
einfach pro Adresse ein gewisses Limit zu erzwingen, aber spätestens mit
IPv6 ist Schluss. Und warum soll ich dafür leiden, daß mein Nachbar im
zufällig selben IP-Adressbereich gerade die OSM-Rechner in die Knie
zwingt?

Du blockst meinen Account? Also hacke ich die von anderen und nutze die?

Soll OSM auch einen API-Key einführen, damit jede Anwendung eindeutig
trackbar ist, wie es Goggle tut?

 Ich hoffe, jemand forkt QLandkarteGT, und baut die OSM-Unterstützung
 wieder ein. Am besten mit durch den User änderbarem User-Agent-String,
 um zukünftigen bekloppt-heiten der OSM-Admins entgegenzuwirken.

Und hier widersprichst du dir dann schließlich selber: DU bist
scheinbar nicht in der Lage den UA-String zu ändern und schreist sofort
nach jemand anderem, der das für dich tut.
Und als Programmierer darf man IMHO ruhig noch ein Gewissen haben, um
eben auch zu sagen, daß man eine Funktion eben nicht implementiert, um
es anderen nicht zu einfach zu machen, die Spielregeln zu verletzen.


Ich jedenfalls möchte all den Leuten danke, die ihre Zeit dafür
aufwenden, OSM und OS im allgemeinen am Laufen zu halten.
Und dazu gehören auch die Entwickler von QLandkarteGT, was ich selber
gerne verwende, aber auch wenn die gerade ein wenig eingeschnappt
scheinen, hoffe ich, daß da eine konstruktive Lösung gefunden wird.

Philipp

PS: Und ja, ich bin Softwareentwickler und ja, ich habe auch schon
als Debian-Entwickler Patches für QLandkarte geschrieben, aber im Moment
fehlt mir selber die Zeit und die Priorität, da selber Hand anzulegen.
-- 
  / /  (_)__  __   __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ pmh...@pmhahn.de

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Hallo Dirk,
das ist uns und auch den Admins schon klar, dass man das umgehen kann.
Und auch, dass mutwillige Sabotage, zu der ich das zählen würde, damit
nicht ausschließen kann.

Die Pflicht zu einem gültigen UA-String hat aber nicht in erster Linie
den Hintergrund, böswillige Nutzer wie dich ;) direkt zu kriegen,
sondern gutwillige Entwickler, die zurecht erstmal davon ausgehen, dass
sie testweise und für Software, die mal eine Handvoll Kacheln braucht,
die öffentlichen osm-kacheln nutzen dürfen, darauf hinweisen zu können,
dass ihre Software eben wohl doch nicht nur eine Handvoll Kacheln zieht.

Insbesondere ist eben auch nicht ein Programm betroffen, was ähnlich zu
einem Browser genau die Kacheln herunterläd, die zur Darstellung der
Karte gebraucht werden - solange das Programm nicht verkauft wird, ist
dies eine analoge und normalerweise tolerierte Anwendung (vorausgesetzt,
die Attributierung ist korrekt).

Hier geht es aber um ein Programm, das unter anderem den Massenhaften
Download tausender Kacheln erlaubt, und genau das ist nicht mehr erlaubt.

Wenn Du persönlich wget anweist, sich als Firefox oder sonstwas
auszugeben, verstößt Du persönlich genauso gegen die Tile Usage Policy,
denn die besagt ganz eindeutig, dass ein sinnvoller, korrekter UA
gesendet werden soll, der die Identifikation der Anwendung erlaubt. Mit
gesundem Menschenverstand weißt vermutlich auch du, dass damit nicht
gemeint ist, dass sich ScrapeOSM (tm) als wget ausgeben darf, selbst
wenn es sich um ein Shellscript handelt, das wget für den eigentlichen
Download nutzt.

Da jetzt weiter zu diskutieren hilft auch nicht besonders - ganz
auszuschließen ist Missbrauch nicht, sicher; aber nur weil nicht jeder
Diebstahl aufgeklärt wird, verlangst du ja auch im Strafrecht nicht,
Diebstahl zu erlauben, oder?

Es geht nicht um die einwandfreie Identifikation eine Clients, sondern
um das Finden von möglicherweise ungünstig programmierten Anwendungen,
und wie du am Beispiel von QLandkarte merkst, scheint auch die
Weigerung, einen sinnvollen UA-String anzugeben, nicht sicher vor dem
Block zu schützen.

Du hast immer noch keine Alternative ohne Account-Pflicht (die ja, wie
wir bereits festgestellt haben, auch nicht funktioniert, solange online
ohne Account Kacheln dargestellt werden können sollen) vorgestellt. Bis
dahin brauchen wir glaub ich kaum weiterzudiskutieren.

Gruß
Peter

Am 16.02.2014 12:39, schrieb Dirk Sohler:
 Simon Poole schrieb:
 - zu behaupten, dass eine Massnahme nicht funktionieren kann
 
 Bitte genau lesen. Ich wies jedenfalls völlig richtig darauf hin, dass
 der User-Agent nicht dazu geeignet ist, einen zugreifenden Client
 (anders als ein Token oder besser ein Useraccount) einwandfrei zu
 identifizieren, und daher als alleiniges Erkennungsmerkmal schlicht
 ungeeignet ist.
 
 Ich könnte wget anweisen, sich als „wget/1.15“ auszuweisen, oder aber
 auch als „Skynet/1.0“ oder als ein aktueller Firefox. In allen drei
 Fällen kann ich massenhaft scriptgesteuert Kacheln runterladen, bis die
 Leitung glüht, und im letzten Fall kann ich nicht mal gesperrt werden
 (IPs lassen sich wechseln), und alle drei Varianten ist der
 entstandene Traffic sogar ein paar Byte je Abruf größer als ohne UA.
 
 Die Maßnahme an sich funktioniert in einem gewissen Rahmen, nur stützt
 sie sich auf etwas, das vom Konzept her von Grund auf als technisch
 komplett unverifiziert einzustufen ist.
 
 Grüße,
 Dirk
 
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de
 


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 15:13, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Also kannst Du Anwendung und Browser voneinander unterscheiden?
 
 Mittels anwendungsspezifischem Token, der aufgrund der API nur durch
 entsprechende Header übermittelt werden kann eher, als über einen
 simplen String, in den jeder reinschreiben kann, was er will.
Wenn jemand fälschen will, dann ist das auch da kein Problem, den Token
zieh ich mir eben von osm.org direkt.
Dazu gehört dann außerdem noch die Authentifizierung über alle
Tilecache-Instanzen etc pp - nicht grade wenig Aufwand für minimal mehr
Hilfe.
 
 
 Abgesehen davon: Was ist ein Browser, was eine Anwendung?
 
 Stelle dich doch bitte nicht bitte dümmer, als du bist.
 
 Hier: Browser = Das Ding, mit dem du im WWW (!= „das Internet“) Seiten
 aufrufen kannst, und eben auch die OSM-Seite;
also:
Firefox, Thunderbird, Thunderbird-Adressbuch mit OSM-Karten-Erweiterung
(gibt's die? wär praktisch...),
Internet-Explorer, jede Anwendung, die die entsprechende
IE-ActiveX-Komponente benutzt, um Webseiten darzustellen,
wget (cool, kann www-Seiten aufrufen...),
...
 und Anwendung: Spezielles
 Programm, das zum Abruf der OSM-Kacheln über die OSM-API verwendet
 wird, ohne darüber hinaus andere Dienste im Internet (vgl. WWW) nutzen
 zu können.
Okay, also wenn meine App Twitternachrichten und OSM-Kacheln darstellt,
ist es demnach ein Browser?

 
 Ist [beliebige Anwendung] ein Browser, wenn sie Links verfolgt?
 
 In dem hier verwendeten Zusammenhang ist eine Anwendung dann ein
 Browser, wenn sie die WWW-Seite benutzt. Wenn sie die API benutzt,
 nein. 
Und wo ist der Unterschied zwischen WWW-Seite und API?
Du bist ja derjenige, der mit Umgehungsmöglichkeiten argumentiert.
Wenn ich also www.osm.org mit entsprechendem permalink aufrufe und alle
damit verbundenen Kacheln mit runterlade, ist das wieder ok? wenn ich
das hundertmal tue, auch?

Aber da du nur provozieren willst, brauche ich dir das sicher
 nicht zu erklären, da du es bereits weißt.

Ich will nicht provozieren.
Du kritisierst eine seit langem angewandte Praxis, die weitgehend
funktioniert; und hängst die auch noch an einem Fall auf, der
offensichtlich ja eben sogar gefunden wurde.
Du äußerst aber Kritik, ohne einen funktionierenden und mit vertretbarem
Aufwand umsetzbaren Gegenvorschlag anzubringen.

 Inwiefern würde eine solche Lösung das Verfahren einfacher,
 fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter
 machen?
 
 Die Vorteile eines anwendungsspezifischen Tokens sind, sofern der Token
 geheim bleibt (Closed-Source oder sonstwie verschlüsselt, und nicht
 einfach so durch andere Nutzbar, oder über Sniffer aus den übertragenen
 Datenpaketen auslesbar), dass die Anwendung zuverlässig identifiziert
 werden kann.
CLosed-Source - cool, also auch noch alle OpenSource-Software im
OSM-Ökosystem rausschmeißen, weil damit das System nicht funktioniert.
Ich glaube, du hast das Grundprinzip immer noch nicht verstanden, und
das heißt Fairness und Offenheit.

Das Tool von Github kann keiner mal eben forken, weil das Token nicht
drin ist (und nicht drin sein kann, denn sonst wär das ja nicht mehr
verschlüsselt), dafür muss man sich zusätzlich bei OSM anmelden -
wunderbar... - aber irgendwie eben nicht Offen.

 Die Vorteile eines „Accountzwangs“ bei einer Anwendung (vgl. Definition
 weiter oben) ist, dass man eindeutig einen Useraccount identifizieren
 kann, und man diesen Gezielt sperren kann. Natürlich kann ein Anwender
 sich einfach einen neuen Account anlegen, aber ein Entwickler kann auch
 seiner Anwendung den Firefox-UA-String verpassen.
 
 Aber mal andersherum gefragt: Inwiefern ist alleinig die Auswertung
 eines simplen Strings fälschungssicher? Was hindert einen Entwickler,
 der alle Tiles runterladen will eher daran, das technisch umzusetzen?
 Ein beliebig änderbarer String, eine App-Registrierung um einen Token
 zu bekommen, oder die Notwendigkeit eines Useraccounts?
Abgesehen vom Aufwand auf dem Server, um die Token-Lösung einzusetzen -
wie würdest du das für, sagen wir, JOSM umsetzen wollen? Steht der Token
im Code und damit im SVN? Steht der Token nur im Build und auch da
Verschlüsselt? Wie passt das dann mit OpenSource zusammen? Soll sich
jeder Entwickler, der mal einen Patch einreicht, extra registrieren?

Und wenn ja, dann haben wir entsprechend hunderte Registrierungen, was
hindert dich als denjenigen, der sich hier als der Böse aufspielt, der
alles aushebeln kann, daran, deine Anwendung hundertmal zu registrieren
und und den Token immer wieder zu wechseln?

Sorry, irgendwie überzeugt mich das noch nicht.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Peter Wendorff schrieb:
 Wenn jemand fälschen will, dann ist das auch da kein Problem, […]

Eben. Und da ist so etwas wie ein User-Agent-String noch die
allergeringste Hürde.


 [Dummes zeug über Browser oder nicht]

Ach, so einer bist du. Sag das doch, dass du dich dummstellen willst,
um zu provozieren.


 Ich will nicht provozieren.

Dann bist du wohl dumm. Mehr Optionen gibt es nicht.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T16:18:49+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT


Am 15.02.2014 12:45, schrieb Dirk Sohler:

Pfui :(

[...]

um zukünftigen bekloppt-heiten der OSM-Admins entgegenzuwirken.

Pfui! zu so einer Aussage...:-(
Die Admins wissen sehr wohl was sich machen (bzw. leider machen müssen)


Grüße,
Michael.


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Philipp Matthias Hahn schrieb:
 Und weil es leider einige gibt, die sich nicht an die Spielregeln
 halten, muss es leider auch Mechanismen geben, die solche
 Spielverderber bremsen.

Na ja, und der User-Agent-String ist dabei die unsicherste Methode, die
es dabei gibt. Der QLandkarte-GT-Entwickler sieht das genau so, und
macht den Schwachsinn daher einfach nicht mit. Was er als
Ersatz angekündigt hat, klingt aber gut.


 2. Absichtliches ignorieren der Spielregeln. Und hier hilft eben kein
 User-Agent, denn wer genügend kriminell ist, der fälscht eben auch
 so was, um solche Beschränkungen zu umgehen.

Um den UA-String zu ändern, muss man nicht mal „genügend ‚kriminell‘“
sein. Das gehört in jedem Browser und bei vielen Anwendungen zum
Standard-Funktionsumfang.


 Soll OSM auch einen API-Key einführen, damit jede Anwendung eindeutig
 trackbar ist, wie es Goggle tut?

Das wäre tatsächlich eine sinnvollere und durchaus zuverlässigere
Maßnahme, als einen beliebig änderbaren String als einzige Quelle zur
Identifizierung einer Anwendung zu verwenden.


 Und hier widersprichst du dir dann schließlich selber: DU bist
 scheinbar nicht in der Lage den UA-String zu ändern und schreist
 sofort nach jemand anderem, der das für dich tut.

Stimmt. Ich habe mir den Code von QLandkarte GT bisher noch nicht
angeschaut. Ich vermute, das wird einfach nur eine weitere Option in
der Entsprechenden Klasse sein, die für den Download der Kacheln
zuständig ist. Allerdings wird mit späteren Versionen der Programmcode
bezüglich OSM wohl schrittweise aus der Anwendung fliegen, und durch
das vom Entwickler angekündigte System ersetzt werden.

Nach dem ersten Aufschrei und der Sorge um eines der besten
Kartenprogramme unter Linux scheint die Entwicklung doch in die
richtige Richtung zu gehen und QLandkarte GT nicht zu sterben.


 Ich jedenfalls möchte all den Leuten danke, die ihre Zeit dafür
 aufwenden, OSM und OS im allgemeinen am Laufen zu halten.

Natürlich. Eine Diskussion über (un)wirksame Sicherheitsmechanismen hat
auch nicht mit (fehlender) Anerkennung der Arbeit zu tun.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T16:21:11+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione pml1

Hallo Dirk,

Am Sonntag, 16. Februar 2014, 16:21:03 schrieb Dirk Sohler:
 Peter Wendorff schrieb:
  Wenn jemand fälschen will, dann ist das auch da kein Problem, […]
 
 Eben. Und da ist so etwas wie ein User-Agent-String noch die
 allergeringste Hürde.

Du hast aber schon mitbekommen, wie das mit dem User-Agent-String gedacht ist?

(Ansonsten hoffe ich, den hier aufkommenden Umgangston nicht mehr lange lesen 
zu müssen ...)

Gruß,
Peter



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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Peter Wendorff schrieb:
 Du hast immer noch keine Alternative ohne Account-Pflicht
 […] vorgestellt.

Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key), wie
bereits mehrfach erwähnt.

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T16:32:49+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 16:34, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Du hast immer noch keine Alternative ohne Account-Pflicht
 […] vorgestellt.
 
 Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key), wie
 bereits mehrfach erwähnt.
Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für den
Overhead in der Infrastruktur und zusätzlich gerade bei
OpenSource-Software für folgende Probleme präsentierst:

- Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine
Anwendung nutzen?
- Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was
committen, einen eigenen entwicklerspezifischen API-Key haben müssen?
bzw. wenn Du das nicht für notwendig hältst,
- wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im
Quelltext-Repository?

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Frederik Ramm schrieb:
 In Wahrheit ist es so, dass es eine ganze Menge Applikationen gibt,
 die sich als jemand anders ausgeben, als sie sind.

Vermutlich hauptsächlich als ganz normale Browser, die dann einfach
im Schwall an „echten“ Zugriffen durch Browser untergehen …


 Das ändert technisch nichts, aber es ändert sozial etwas.

Ich habe auch mal eine Zeit lang versucht, „sozial etwas zu verändern“.
Irgendwann wurde mir das zu aufwändig, langwierig und anstrengend, und
ich bin dazu übergegangen, allen einfach immer direkt meine Meinung zu
sagen, und hinzunehmen, dass nicht alle damit klar kommen – Lebt sich
gleich viel entspannter …

Nur, weil ich im FLOSS-Umfeld aktiv bin, heißt das nicht, dass ich
automatisch ein „guter Mensch“ bin :)


 […] weil es automatisch ständig zufällige User-Agents gültiger
 Browser auswählt oder so, […]

Ich würde einfach eine Art „Mini-API“ für das Programm erstellen, für
die dann jeder mittels einfacher Konfigurationsdateien entsprechende
Parameter (Name, URL, Nötige/Beliebige Header, etc.) übergeben kann, um
dann innerhalb des Programms auf die Jeweiligen Dienste zugreifen zu
können. Das würde den UA-String selbstverständlich mit einschließen.

Im kleinen Kreise (ein Uploader im Umfeld einer Forencommunity) habe ich
so etwas tatsächlich schon mal gemacht, weiß also, in welchem Umfang
sich der Aufwand für so etwas bewegt.

Soweit ich das verstanden habe, ist so etwas in der Art (mittels
zentraler Datei auf einem Server, in der die nötigen Parameter
stehen, und die über die Anwendung abgerufen werden kann, und dann
nicht nur OSM beinhaltet) für QLandkarte GT auch geplant.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T16:43:57+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

p...@wuzel.de schrieb:
 Du hast aber schon mitbekommen, wie das mit dem User-Agent-String
 gedacht ist?

Laut Diskussion ist es so, dass der String ausgewertet wird, und wenn
er leer ist, die Anwendung geblockt wird, dass es aber reicht, einen
Quasi „beliebigen“ String anzugeben. „Beliebig“ hierbei in
Anführungszeichen, weil der der String „ehrlich“ sein muss, um den
Nutzungsbedingungen zu entsprechen. Aber eben beliebig, da der String
vom Entwickler komplett selbst frei wählbar ist.

Aber wenn ich das im Kern falsch verstanden habe, kannst du mich gern
aufklären.

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T16:54:14+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Peter Wendorff schrieb:
 Am 16.02.2014 16:34, schrieb Dirk Sohler:
  Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key),
  wie bereits mehrfach erwähnt.
 
 Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für
 den Overhead in der Infrastruktur […] präsentierst:

Sicherheit und Komfort schließen sich leider gegenseitig aus :(


 - Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine
 Anwendung nutzen?

Genau so, wie die OSM-Admins aktuell Missbrauch verhindern: Gar nicht.


 - Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was
 committen, einen eigenen entwicklerspezifischen API-Key haben müssen?

Bereits nötiger User-Account.


 - wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im
 Quelltext-Repository?

Anwendungen müssen eine Funktion behalten, über die der Anwender
entweder selbst einen API-Key eingeben kann, oder ein vorhandener
Useraccount kann für den Zugriff auf die API verwendet werden.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T16:59:18+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione pml1

Hallo Dirk,

Am Sonntag, 16. Februar 2014, 16:58:30 schrieb Dirk Sohler:
 p...@wuzel.de schrieb:
  Du hast aber schon mitbekommen, wie das mit dem User-Agent-String
  gedacht ist?
 
 Laut Diskussion ist es so, dass der String ausgewertet wird, und wenn
 er leer ist, die Anwendung geblockt wird, dass es aber reicht, einen
 Quasi „beliebigen“ String anzugeben. „Beliebig“ hierbei in
 Anführungszeichen, weil der der String „ehrlich“ sein muss, um den
 Nutzungsbedingungen zu entsprechen. Aber eben beliebig, da der String
 vom Entwickler komplett selbst frei wählbar ist.
 
 Aber wenn ich das im Kern falsch verstanden habe, kannst du mich gern
 aufklären.

Für mich ist der Kern, dass der User-Agent-String dazu gedacht war, 
Anwendungen zu identifizieren, die (nicht böswillig, möglicherweise nicht mal 
bewusst) gegen die Regeln verstoßen. Dies mit dem Ziel, die Entwickler dieser 
Anwendung kontaktieren zu können, um eine Lösung zu suchen.

In diesem Kontext spielt für mich die Fälschbarkeit keine Rolle. Das kann man 
natürlich auch betrachten, ist aber eine andere Baustelle.

Gruß,
Peter


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

p...@wuzel.de schrieb:
 Für mich ist der Kern, dass der User-Agent-String dazu gedacht war, 
 Anwendungen zu identifizieren, die (nicht böswillig, möglicherweise
 nicht mal bewusst) gegen die Regeln verstoßen.

Also, für alle Fälle, in denen der Entwickler ehrlich ist, keine Bösen
Absichten hat, einen eindeutigen UA-String verwendet, seine Anwendung
nicht unter Kontrolle hat, und Online erreichbar ist, ist das sicher
eine tolle Maßnahme …

Nur hilft das leider gegen alles andere nicht die Bohne. Wenn er nicht
ehrlich ist, und einfach nur die Kacheln will (warum auch immer), wird
er den UA-String fälschen; wenn er beim Zugriff auf OSM nicht erkannt
werden will, wird er den UA-String ebenfalls fälschen; und wenn er
online nicht erreichbar ist, und die Anwendung gesperrt wird, wird er
den UA-String fälschen.

Ein „erzieherischer Effekt“, wie in einer anderen Mail erwähnt, tritt
also nur dann ein, wenn mindestens vier Grundvorassetzungen gegeben
sind, von denen mindestens zwei unverifiziert sind. Auch Amok laufende
Anwendungen setzen alle drei anderen Dinge voraus.


 Das kann man natürlich auch betrachten, ist aber eine andere
 Baustelle.

… aber komplett außen vor lassen kannst du das bei der Diskussion aber
auch nicht.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T17:53:03+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione Frederik Ramm

Hi,

On 16.02.2014 18:02, Dirk Sohler wrote:
 Nur hilft das leider gegen alles andere nicht die Bohne. Wenn er nicht
 ehrlich ist, und einfach nur die Kacheln will (warum auch immer), wird
 er den UA-String fälschen; wenn er beim Zugriff auf OSM nicht erkannt
 werden will, wird er den UA-String ebenfalls fälschen; und wenn er
 online nicht erreichbar ist, und die Anwendung gesperrt wird, wird er
 den UA-String fälschen.

Und genau diese Leute sind auch die, die trivialerweise Deine API
Key-Vorschläge umgehen. Was soll denn an dem API Key besser sein als
am User-Agent - oder anders, wieso sind die Admins alle wahlweise naive
Deppen oder sammelwütige Datenkraken, wenn sie nach einem UA fragen, und
ein API Key ist irgendwie plötzlich vernünftig?

Bye
Frederik

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

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Frederik Ramm schrieb:
 Und genau diese Leute sind auch die, die trivialerweise Deine API
 Key-Vorschläge umgehen. Was soll denn an dem API Key besser sein

Einen API-Key muss man beantragen, ggf. mit Authentifizierung oder
sonstiger Validierung, und ist mit wesentlich mehr Aufwand verbunden,
als ein paar Zeichen in eine Variable zu schreiben.

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T20:25:18+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione Manuel Reimer


On 02/16/2014 12:09 AM, Sven Geggus wrote:

Ich selbst werde mich jetzt wohl auf die Suche nach einer equivalenten
Alternativen machen.   8-((


viking?


Ob das Programm eine Alternative zu QLandkarteGT ist, kann ich nicht 
sagen. Letzteres kenne ich nicht.


Allerdings nutze ich Viking viel und oft.

Zum einen um damit GPS-Tracks testweise auf Karten zu legen (Qualität 
prüfen) und diese ggf. zu editieren (Anfahrt und Ausreißer raushauen).


Zum anderen verwende ich Viking auch um auf Basis der Mapnik-Karten mal 
eben schnell eine Karte zu generieren und drucken bei der z.B. eine 
bestimmte Route hervorgehoben ist oder ein paar Punkte gekennzeichnet sind.


Gruß

Manuel


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 17:13, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Am 16.02.2014 16:34, schrieb Dirk Sohler:
 Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key),
 wie bereits mehrfach erwähnt.

 Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für
 den Overhead in der Infrastruktur […] präsentierst:
 
 Sicherheit und Komfort schließen sich leider gegenseitig aus :(
 
 
 - Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine
 Anwendung nutzen?
 
 Genau so, wie die OSM-Admins aktuell Missbrauch verhindern: Gar nicht.
Also bietest Du als Alternative für ein nur sehr eingeschränkt
funktionierendes System ein System, was genauso eingeschränkt
funktioniert, aber zusätzlichen Organisationsoverhead benötigt - hüpsch...
 
 
 - Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was
 committen, einen eigenen entwicklerspezifischen API-Key haben müssen?
 
 Bereits nötiger User-Account.
Häh? Ich red von JOSM-Entwicklern, die am JOSM-Code arbeiten, nicht die
mit JOSM osm-Daten hochladen.
JOSM ist hier nur ein Beispiel von vielen Programmen, die irgendwo
OSM-Tiles benutzen, QLandkarteGT passte nur deshalb nicht, weil da ja
offensichtlich praktisch nur ein Entwickler dransitzt.

 - wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im
 Quelltext-Repository?
 
 Anwendungen müssen eine Funktion behalten, über die der Anwender
 entweder selbst einen API-Key eingeben kann, oder ein vorhandener
 Useraccount kann für den Zugriff auf die API verwendet werden.
Also nicht für jeden Entwickler einen Key, sondern sogar für jeden User.
Wie sieht das dann jetzt mit Privacy aus? Du möchtest also jeden
einzelnen User tracken können (denn nichts anderes tust du damit).

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 20:26, schrieb Dirk Sohler:
 Frederik Ramm schrieb:
 Und genau diese Leute sind auch die, die trivialerweise Deine API
 Key-Vorschläge umgehen. Was soll denn an dem API Key besser sein
 
 Einen API-Key muss man beantragen, ggf. mit Authentifizierung 
Wie soll die funktionieren?

Mit Mailadresse? gut, krieg ich tausende, und irgendwer muss sich darum
kümmern, darunter die fake- und wegwerfadressen rauszufiltern - das
Problem haben wir schon mit dem UA-String, also verbessert es nicht.

Mit Persönlichen Daten? Post-Ident? Und das auch noch weltweit? Viel
Spaß. Abgesehen vom finanziellen ein enormer logistischer Aufwand.
oder
 sonstiger Validierung, und ist mit wesentlich mehr Aufwand verbunden,
 als ein paar Zeichen in eine Variable zu schreiben.
Eben: Der Aufwand ist immens, sobald man ernsthaft authentifizieren
wollte, und da den vermutlich niemand wirklich machen will (und außerdem
ja auch noch die Webseiten funktionieren sollen). Die Fragen in
Kombination mit OpenSource-Software haben wir ja an anderer Stelle
bereits angerissen.

Welche Lösung genau schlägst Du vor, und warum ist sie besser als die
(natürlich nicht perfekte) aktuelle Vorgehensweise?

Betrachte dabei:
- Aufwand auf Administrativer Seite von OSM (technisch und ständig
personell)
- Kosten auf beiden Seiten (OSM und Entwickler und Nutzer entsprechender
Anwendungen)
- Vereinbarkeit mit Offenheit von OSM und so weiter.

Ich weiß, ich hab die Frage schon mehrfach gestellt in diesem Thread,
aber bisher flamest du weiter über den ach so schlechten status-quo,
ohne diese Frage zu beantworten.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Peter Wendorff schrieb:
 Am 16.02.2014 20:26, schrieb Dirk Sohler:
  Einen API-Key muss man beantragen, ggf. mit Authentifizierung 
 
 Wie soll die funktionieren?

Habe ich bereits geschrieben.


 Welche Lösung genau schlägst Du vor, und warum ist sie besser als die
 (natürlich nicht perfekte) aktuelle Vorgehensweise?
 
 Betrachte dabei:
 - Aufwand auf Administrativer Seite von OSM (technisch und ständig
 personell)
 - Kosten auf beiden Seiten (OSM und Entwickler und Nutzer
 entsprechender Anwendungen)
 - Vereinbarkeit mit Offenheit von OSM und so weiter.

Nach abwägen aller Punkte: User-Account. Verhindert auch nicht den
Missbrauch, ist aber zuverlässiger als der User-Agent-String, und
weniger aufwändig umzusetzen (da schon vorhanden) als ein Token oder
ein API-Key.


 Ich weiß, ich hab die Frage schon mehrfach gestellt in diesem Thread,
 aber bisher flamest du weiter über den ach so schlechten status-quo,
 ohne diese Frage zu beantworten.

Du liest nur nicht alle Mails von mir :)


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T21:47:08+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione Henning Scholland


Am 16.02.2014 21:50, schrieb Dirk Sohler:

User-Account. Verhindert auch nicht den
Missbrauch, ist aber zuverlässiger als der User-Agent-String, und
weniger aufwändig umzusetzen (da schon vorhanden) als ein Token oder
ein API-Key.


Also wer auf DER Hauptseite (nach außen hin) von OSM etwas mehr sehen 
will als eine weiße Fläche braucht einen Login? Klingt nach einer super 
Werbung für das Projekt.


Jeder, der die Tiles in seine Homepage einbindet, muss diese so 
gestalten, dass der Nutzer sich vor der Kartenansicht bei OSM einloggt? 
Klingt ebenfalls wie der letze Schrei der Benutzbarkeit.


Mit so einem tollen Account ist man dann natürlich auch nicht verfolgbar 
(ist ja dein zweites großes Steckenpferd)?


Wäre es dann nicht einfacher und effektiver gleich den Stecker zu ziehen?

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Peter Wendorff schrieb:
 Also bietest Du als Alternative für ein nur sehr eingeschränkt
 funktionierendes System ein System, was genauso eingeschränkt
 funktioniert

Nein, ein eingeschränkter Missbrauchsschutz (da der Missbrauch auch auf
Seite des Missbrauchenden aufwändiger wird) als Ersatz für ein
technisch wirkungsloses System.


  - Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal
  was committen, einen eigenen entwicklerspezifischen API-Key haben
  müssen?
  
  Bereits nötiger User-Account.
 
 Häh? Ich red von JOSM-Entwicklern, die am JOSM-Code arbeiten, nicht
 die mit JOSM osm-Daten hochladen.

Ahso :) Ja, die müssten sich dann natürlich einen API-Key holen (oder
eben, siehe andere Mail – diskutieren in zwei Thread-Zweigen ist
irgendwie anstrengend – ihren User-Account nutzen).


 Also nicht für jeden Entwickler einen Key, sondern sogar für jeden
 User. Wie sieht das dann jetzt mit Privacy aus? Du möchtest also jeden
 einzelnen User tracken können (denn nichts anderes tust du damit).

Ja, wie mit dem Useraccountzwang beim Commiten von Geodaten an OSM. Das
ist 1:1 übertragbar. Zudem würde eine einmalige Authentifizierung
innerhalb der Anwendung völlig ausreichend sein.

Alternative: Die Anwendung bekommt durch Anmeldung mit den
OSM-Userdanten innerhalb eben dieser Anwendung einen usergebundenen
Token, mit dem sie sich an der API anmelden kann, und erhält dadurch
einen nicht mehr usergebundenen Token, der diese Installation
der Anwendung legitimiert, die API zu nutzen. Somit ist nicht
nachvollziehbar, welcher User über die Anwendung auf die API zugreift,
sondern nur, DASS ein Zugriff stattfindet.

Im Falle des Missbrauchs kann der jeweilige Token (automatisiert)
gesperrt werden. User, die mehrmals für die selbe Anwendung einen Token
durch Anmeldung mit den OSM-Daten anfordern, können dies nur in einem
Abstand von N Zeiteinheiten pro Account, müssten also erst Abwarten,
oder einen neuen Account anlegen, um Token zu „sammeln“.

Natürlich ist dies mit Programmieraufwand und zusätzlichen Ressourcen
verbunden, aber ich wiederhole mich da: Sicherheit und Bequemlichkeit
schließen sich aus.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T21:50:31+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione malenki

On  16.02.2014 20:26, Dirk Sohler wrote:

 Frederik Ramm schrieb:
  Und genau diese Leute sind auch die, die trivialerweise Deine API
  Key-Vorschläge umgehen. Was soll denn an dem API Key besser sein
 
 Einen API-Key muss man beantragen

Oder klauen/abschnorcheln.
DU argumentierst doch sonst immer mit den pöhsen Purschen, die an allen
Ecken des Internets lauern.

m(



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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

malenki schrieb:
 On  16.02.2014 20:26, Dirk Sohler wrote:
  Einen API-Key muss man beantragen
 
 Oder klauen/abschnorcheln.

… ist aber immer noch aufwändiger, als einen simplen String zu ändern :)

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T22:16:49+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Henning Scholland schrieb:
 Also wer auf DER Hauptseite (nach außen hin) von OSM etwas mehr sehen 
 will als eine weiße Fläche braucht einen Login?

Nein, da die dahinterstehende Anwendung bereits mit der API verbunden
ist, und man davon nur die AUSGABE im Browser sieht.


 Jeder, der die Tiles in seine Homepage einbindet, muss diese so 
 gestalten, dass der Nutzer sich vor der Kartenansicht bei OSM
 einloggt?

Auch hier: Nein, da die dahinterstehende Anwendung bereits mit der API
verbunden ist, und man davon nur die AUSGABE im Browser sieht.


 Mit so einem tollen Account ist man dann natürlich auch nicht
 verfolgbar (ist ja dein zweites großes Steckenpferd)?

Wenn man weiter denkt, als nur bis zu seinem eigenen Tellerrand (oder
einfach die anderen Mails liest, die in diesem Thread hier so
eingehen), kann man recht schnell rausfinden, wie es gehen könnte.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T22:17:39+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione malenki

On  07.02.2014 17:33, Carsten Schwede wrote:

 ich kann überhaupt nicht verstehen, warum so viele offenbar
 QLandkarteGT mit den Onlinekacheln verwenden.

* Aktueller als die meisten OSM-basierten Garmin-Karten, die meist
  1-4wöchig aktualisiert werden.
* Flüssiger zu bedienen. Wenn man eine Garmin-Karte ganz Europas
  geladen hat, ist das Programm zäh zu bedienen.

 Das Programm ist in erster Linie dafür entworfen worden mit den
 Kartenpaketen für Garmingeräte zu arbeiten. Die einfachste und von
 Onlinequellen unabhängige Methode ist eines der Pakete zu nutzen und
 in QLandkarte zu integrieren. Der Vorteil ist auch noch, daß man
 eigentlich noch ein paar Möglichkeiten mehr hat zu planen, da die
 Kartenelemente dann magnetisch sind, und man Route anhand der Wege
 und Straßen legen kann ohne jede Biegung mitzumachen. (Die entstehen
 dann automatisch)

Sinnvoller wäre, wenn QLandkarteGT mit den Garminkarten routen könnte.
Im jetzigen Zustand ist es praktischer, von POI zu POI per Onlinedienst
zu routen.
Die magnetischen Kartenelemente sind nicht so komfortabel, weil man an
jedem Wegsegment (zB nach einer Brücke) einen Punkt setzen muss, um
weitermalen zu können. Wenn man größere Distanzen überbrücken will und
deshalb weiter herauszoomt, liegt der gemalte Weg trotz magnetischer
Elemente ein gutes Stück neben diesen.

Thomas



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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Carsten Schwede schrieb:
 ich kann überhaupt nicht verstehen, warum so viele offenbar
 QLandkarteGT mit den Onlinekacheln verwenden.

Es ist die schnellste und einfachste Möglichkeit. Die ist in der
aktuellsten Version zwar nicht mehr direkt gegeben, aber die
zusätzlichen Onlinekarten, die bisher eher Stiefmütterlich behandelt
wurden, bekommen jetzt wieder mehr Relevanz.


 Die einfachste und von Onlinequellen unabhängige Methode ist eines
 der Pakete zu nutzen und in QLandkarte zu integrieren.

Ich habe das mal mit der Freizeitkarte Deutschland probiert. Das
„magnetische“ hat mich extrem aufgeregt, außerdem war die Performance
doch eher mau, wegen dem ganzen Vektorkrams. Da sind mir flotte und
aktuelle Online-Kacheln doch lieber :)


 QLandkarte ist typfile-fähig, das heißt man kann sich ziemlich
 einfach auch den Kartenstil ändern.

Das ist für mich der einzige Vorteil von Offline-Karten.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T22:32:05+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione Henning Scholland


Am 16.02.2014 22:20, schrieb Dirk Sohler:

Henning Scholland schrieb:

Also wer auf DER Hauptseite (nach außen hin) von OSM etwas mehr sehen
will als eine weiße Fläche braucht einen Login?

Nein, da die dahinterstehende Anwendung bereits mit der API verbunden
ist, und man davon nur die AUSGABE im Browser sieht.


Jeder, der die Tiles in seine Homepage einbindet, muss diese so
gestalten, dass der Nutzer sich vor der Kartenansicht bei OSM
einloggt?

Auch hier: Nein, da die dahinterstehende Anwendung bereits mit der API
verbunden ist, und man davon nur die AUSGABE im Browser sieht.


Was wäre denn jeweils die dahinterstehende Anwendung? Meinst du damit 
den Homepage-Betreiber oder eher den Browserentwickler oder OpenLayers 
als Framework zum Einbinden der Tiles?


Warum sollten Browserentwickler und OpenLayers sowas tun? Also wohl eher 
der Websitebetreiber. Wenn der nun an jeden Tileaufruf ein key=12345 
dran hängt hilft das genau 0,0 mehr als die aktuelle Methode. Entweder 
ich bin ehrlich und beantrage einen eigenen Key oder ich schaue mich bei 
einer anderen Seite/einem anderen Projekt im Quelltext um und nehme 
einen anderen.


Henning


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Henning Scholland schrieb:
 Was wäre denn jeweils die dahinterstehende Anwendung?

Die PHP- Python- Ruby- oder Wasauchimmer-Anwendung, die dafür sorgt,
dass beim Aufruf eine Seite generiert und an den Browser gesendet wird.


 Wenn der nun an jeden Tileaufruf ein key=12345 dran hängt hilft das
 genau 0,0 mehr als die aktuelle Methode.

Darum wird das auch in der dahinterstehenden Anwendung erledigt. Da
bekommt der Nutzer nichts von mit.


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-16T22:57:18+0100


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT


Am 16.02.2014 16:53, schrieb Dirk Sohler:

Das ändert technisch nichts, aber es ändert sozial etwas.

[...]

Nur, weil ich im FLOSS-Umfeld aktiv bin, heißt das nicht, dass ich
automatisch ein „guter Mensch“ bin :)

[ ] Du hast verstanden wie OS und Community funktioniert.

BTW: dann wundere Dich bitte auch nicht, dass die Community nicht mit 
Dir spielen will.


Ach ja: Du kannst Dir ja einen eigenen Tile-Server aufsetzen und damit 
Dich und alle Welt bedienen, Dann kannst Du davon auch so viel Tiles 
saugen wie Du willst und diesen plattsaugen...



Grüße,
Michael.


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

Re: [Talk-de] St.-ZickeZacke-Str.


Am 03.02.2014 15:14, schrieb Dietmar:

Ich habe am Samstag wieder eine Straße gehabt, an deren nördlichem Ende
Frühlingsstraße
und am südlichen Ende
Frühlingstraße
steht.
Soll ich die jetzt beide mit Semikolon getrennt erfassen?
Nein: der Stadt sagen, daß Ihre Schilder falsch sind. Zu zumindest die 
Aussage der Stadt München bei einem Gespräch mit dem Vermessungsamt dort...



Grüße,
Michael.


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

Re: [Talk-de] St.-ZickeZacke-Str.


Am 05.02.2014 16:40, schrieb ubahnverleih:

reg_nameLeipzsch

brrr:-(

Fangen wir jetzt an überall Lautschrift dazuzupacken?


Grüße,
Michael.


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

Re: [Talk-de] St.-ZickeZacke-Str.


Am 03.02.2014 18:52, schrieb Falk Zscheile:

Eine (noch) einfachere Regel ist aber Ins name-Tag kommt es so, wie
es vor Ort steht.

+1!

Und bei Ungereimtheitenm sollte man sich für eines entscheiden. 
Eigenständig. Und sich bei der Stadt/Gemeinde beschweren.



Grüße,
Michael.


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-16 Per discussione NopMap


Hi!

Um mal wieder einen konstruktiven Vorschlag ins Spiel zu bringen: Es wäre
technisch möglich, einen korrekten User Agent und eine Entlastung der Server
miteinander zu verbinden.

Das könnte so ähnlich funktionieren wie auf meinem Server:
- eine Massendownloader-Applikation identifziert sich mit ihrem User Agent
- der Server leitet alle Aufrufe mit den User Agents bekannter Downloader
z.B. mit einem Rewrite auf eine andere URL um, die nur vorhandene Tiles
ausliefert aber kein Rendern auslöst. Das erzeugt keine nennenswerte Last
- Aufrufe mit fehlenden oder unbekannten Agents oder Browser laufen normal
weiter und werden wie gehabt ab einer bestimmten Anzahl von Anfragen
gedrosselt

Vorteile:
- Server wird von unnötigen Renderanfragen entlastet
- korrekter User Agent und Kooperation werden belohnt
- in vorgerenderten oder häufiger angesehenen Gebieten liegen die Tiles
sowieso auf dem Server rum

Nachteil:
- Funktioniert nicht in den höchsten Zoomleveln

bye, Nop




--
View this message in context: 
http://gis.19327.n5.nabble.com/Mapnik-Administration-blockt-QLandkarteGT-tp5795663p5796602.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Michael Kugelmann schrieb:
 [ ] Du hast verstanden wie OS und Community funktioniert.

Na ja, zumindest in so weit, dass ich selbst Software veröffentliche,
und es sogar Leute gibt, die diese benutzen.


 BTW: dann wundere Dich bitte auch nicht, dass die Community nicht mit 
 Dir spielen will.

Ach, da komme ich mit klar :)


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-17T05:57:10+0100


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

Re: [Talk-de] St.-ZickeZacke-Str.

2014-02-16 Per discussione gmbo


Am 17.02.2014 01:08, schrieb Michael Kugelmann:

Am 03.02.2014 18:52, schrieb Falk Zscheile:

Eine (noch) einfachere Regel ist aber Ins name-Tag kommt es so, wie
es vor Ort steht.

+1!

Und bei Ungereimtheitenm sollte man sich für eines entscheiden. 
Eigenständig. Und sich bei der Stadt/Gemeinde beschweren.


Beschweren, eher informieren, Die Stadt  ist im Normalfall froh, wenn 
sie es gemeldet bekommt und ändert was dran. Als Antwort wird sie die 
ofizielle Schreibweise schicken.


Liebe Grüße
Gisbert



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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 22:59, schrieb Dirk Sohler:
 Henning Scholland schrieb:
 Was wäre denn jeweils die dahinterstehende Anwendung?
 
 Die PHP- Python- Ruby- oder Wasauchimmer-Anwendung, die dafür sorgt,
 dass beim Aufruf eine Seite generiert und an den Browser gesendet wird.
 
 
 Wenn der nun an jeden Tileaufruf ein key=12345 dran hängt hilft das
 genau 0,0 mehr als die aktuelle Methode.
 
 Darum wird das auch in der dahinterstehenden Anwendung erledigt. Da
 bekommt der Nutzer nichts von mit.
Ach?
Und wie kommen dann die Kacheln zum Browser des Nutzers?

Bisher kriegt der Browser von der Webanwendung auf dem Server den
Befehl, Kartenkacheln von einem anderen Server (nämlich dem
osm-tileserver) abzurufen und anzuzeigen.

Wenn der Webserver den key=12345 dranhängt, du sonst aber nichts
änderst, dann bekommt also in Zukunft der Browser (!) den Befehl,
Kacheln von einem anderen Server abzurufen, und dabei den key=12345 zu
benutzen.
Ach so... stimmt, dann weiß das also der Browser, und ach so, dann weiß
ich als böser Angreifer das aber auch, weil was der Browser tut, kann
ich mir angucken; und ich muss damit nichtmal einen Browser im engeren
Sinne benutzen; ein HTTP-Aufruf reicht.

Denken wir also mal nach: Dan kriegt also der Nutzer doch was davon mit.

Gruß
Peter

P.S.: Ja, man kann das ohne lösen,  indem tatsächlich die
Webseiten-Serveranwendung direkt mit dem Tileserver redet, verschlüsselt
ein Sitzungstoken aushandelt, nur dieses an den Browser sendet und in
der Server-Server-Kommunikation dann aushandelt, welche Kacheln wie
dabei heruntergeladen werden dürfen/sollen, aber abgesehen davon, dass
das nun wirklich irre aufwändig ist, funktioniert es nicht für statische
Webseiten, die zwar eine Slippy-Map anzeigen, aber eben keinen
serverseitigen Code ausführen; und damit gerade für die kleinen Seiten,
die durchaus gewollt erlaubt sind, zum Teil unbrauchbar.

 
 
 Grüße,
 Dirk
 
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de
 


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 17.02.2014 01:23, schrieb NopMap:
 
 Hi!
 
 Um mal wieder einen konstruktiven Vorschlag ins Spiel zu bringen: Es wäre
 technisch möglich, einen korrekten User Agent und eine Entlastung der Server
 miteinander zu verbinden.
 
 Das könnte so ähnlich funktionieren wie auf meinem Server:
 - eine Massendownloader-Applikation identifziert sich mit ihrem User Agent
 - der Server leitet alle Aufrufe mit den User Agents bekannter Downloader
 z.B. mit einem Rewrite auf eine andere URL um, die nur vorhandene Tiles
 ausliefert aber kein Rendern auslöst. Das erzeugt keine nennenswerte Last
 - Aufrufe mit fehlenden oder unbekannten Agents oder Browser laufen normal
 weiter und werden wie gehabt ab einer bestimmten Anzahl von Anfragen
 gedrosselt
 
 Vorteile:
 - Server wird von unnötigen Renderanfragen entlastet
 - korrekter User Agent und Kooperation werden belohnt
 - in vorgerenderten oder häufiger angesehenen Gebieten liegen die Tiles
 sowieso auf dem Server rum
 
 Nachteil:
 - Funktioniert nicht in den höchsten Zoomleveln
Weiterer Nachteil:
Funktioniert nur, solange tatsächlich die Render-Queue das (einzige)
Argument ist, die Usage Policy so auszulegen wie sie ausgelegt ist.

Wenn es zusätzlich darum geht, den Traffic auf sinnvolle Anwendungen zu
beschränken, hilft das natürlich nicht. Da kenne ich aber die Kosten
oder Sponsoring-Regelungen der entsprechenden Serverstandorte nicht, ob
das ausreicht.

Gruß
Peter

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

Re: [Talk-it] R: R: R: ruolo admin_centre assente per molte amministrazioni

Come al solito in poche ore il problema si dimezza : ora siamo agli
ultimi *20* comuni!

Ho rigenerato la tabella [1], allargando la ricerca a tutti i place, con
qualunque valore, con lo stesso nome della relazione municipale. Come
sospettavo alcuni place non erano stati identificati dalla precedente query
perchè non city, town, village o hamlet (sembravano quelli più corretti),
ma locality (Ronciglione, Viterbo, corretto in village) o suburb.
I riferimenti sulla colonna di destra sono i nodi place che hanno lo stesso
nome presente nella relazione.

Secondo voi è corretto avere un suburb come admin_centre comunale ? Dalla
definizione sulla pagina wiki, sembra di si, anche se più comune all'estero.

A presto!

--
*FabC*

[1] https://www.dropbox.com/s/dnd7c5g7o6gm82o/comuni_no_admin_centre.html
[2] http://wiki.openstreetmap.org/wiki/IT:Key:place

Il giorno 15 febbraio 2014 23:53, Fabrizio Carrai fabrizio.car...@gmail.com
ha scritto:

Ora siamo veramente vicini alla fine del lavoro e, come al solito, gli
ultimi passi sono i più difficili. Mancano solo *38* comuni e per cercare
di facilitare il lavoro ho creato una tabella delle relazioni dei comuni
ancora senza admin_centre
https://www.dropbox.com/s/dnd7c5g7o6gm82o/comuni_no_admin_centre.html .

Ho già completato tutti quei comuni che contentevano un nodo
place=city|town|village|hamlet con lo stesso nome della relazione. I comuni
rimanenti o sono Comuni sparsi (es. Lampedusa e Linosa), luoghi assenti
su OSM o magari taggati non correttamente, es:

Vedo ora che Ronciglione esiste, ma è un place=locality, luogo non
popolato. Visto che è un comune, direi che il tag è da rivedere.

C'è anche un FIXME che vi invito a controllare.

A presto!

*--*

*FabC*

Il giorno 09 febbraio 2014 22:57, Fabrizio Carrai
fabrizio.car...@gmail.com ha scritto:

Ed ora mancano solo *83 *comuni. Ho fatto un controllo su diverse
regioni ed ho visto che sono state lasciate incomplete diverse relazioni,
principalmente con queste caratteristiche

- Comuni sparsi [1]
- Nuovi comuni istituiti dalle recenti fusioni
- Con place mancanti
- Con place non facilmente identificabili come admin_centre

Qualche mapper può controllare per la sua regione ?

Ciao

*--*
*FabC*

[1] http://it.wikipedia.org/wiki/Comune_sparso

Il giorno 02 febbraio 2014 11:25, Fabrizio Carrai
fabrizio.car...@gmail.com ha scritto:

La macchina OSM continua il processo inesorabilmente:

Al momento mancano solo *223* comuni. Vi metto a disposizione il
risultato della query [1] alla data attuale. Il file .OSM potete caricarlo
direttamente su JOSM. Attenzione: sono circa *34 MB*. Solo ieri sono
stati completate 430 relazione comunali.

Buon mapping a tutti!

*---*
*FabC*

[1]
https://www.dropbox.com/s/frick708qkp2bye/2014-02-02%20Comuni%20senza%20admin_centre%20%28Italia%29.osm

Il giorno 01 febbraio 2014 10:52, Fabrizio Carrai
fabrizio.car...@gmail.com ha scritto:

Al momento mancano solo 653 comuni. Vi metto a disposizione il
risultato della query [1] alla data attuale. Il file .OSM potete caricarlo
direttamente su JOSM. Attenzione: sono circa 70 MB.

A presto
*---*
*FabC*

[1]
https://www.dropbox.com/s/nzn1zr7t0ryct4h/2014-02-01%20Comuni%20senza%20admin_centre%20%28Italia%29.osm

Il giorno 31 gennaio 2014 14:31, Aury88 spacedrive...@gmail.com ha
scritto:

Perfetto!
Grandi!!!

anche in lombardia manca qualche comune... magari mi ci metto io
questa
sera ad aggiungere gli ultimi.
ho visto che invece Sardegna e Valle d'Aosta non sono messe
benissimoc'è
qualcuno in quelle zone?

-
Ciao,
Aury
--
View this message in context:
http://gis.19327.n5.nabble.com/ruolo-admin-centre-assente-per-molte-amministrazioni-tp5793505p5794888.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

--
*Fabrizio*

--
*Fabrizio*
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: R: R: ruolo admin_centre assente per molte amministrazioni

Mi hanno incuriosito i nomi delle 4 relazioni il cui nome iniziava con
Pfarrei, Parrocchia.

15Pfarrei Brenner2062524
http://www.openstreetmap.org/relation/2062524http://www.openstreetmap.org/node/
16Pfarrei Ehrenburg2060598
http://www.openstreetmap.org/relation/2060598http://www.openstreetmap.org/node/
17Pfarrei St. Sigmund2060600
http://www.openstreetmap.org/relation/2060600http://www.openstreetmap.org/node/
18Pfarrei Kiens2060599 http://www.openstreetmap.org/relation/2060599

Le 4 relazioni sono si con admin_level=8 ma
boundary=religious_administration e non administrative. Correggo comunque
la query considerando solo boundary=admnistrative.

Quindi siamo a quota *16*.

P.S. Non ho controllato quanto sia diffuso il
boundary=religious_administration, ma segnalo comunque che anche queste
relazioni non hanno l' admin_centre.


--
*FabC*


Il giorno 16 febbraio 2014 11:50, Fabrizio Carrai fabrizio.car...@gmail.com
 ha scritto:

 Come al solito in poche ore il problema si dimezza : ora siamo agli
 ultimi *20* comuni!

 Ho rigenerato la tabella [1], allargando la ricerca a tutti i place, con
 qualunque valore, con lo stesso nome della relazione municipale. Come
 sospettavo alcuni place non erano stati identificati dalla precedente query
 perchè non city, town, village o hamlet (sembravano quelli più corretti),
 ma locality (Ronciglione, Viterbo, corretto in village) o suburb.
 I riferimenti sulla colonna di destra sono i nodi place che hanno lo
 stesso nome presente nella relazione.

 Secondo voi è corretto avere un suburb come admin_centre comunale ?
 Dalla definizione sulla pagina wiki, sembra di si, anche se più comune
 all'estero.


 A presto!

 --
 *FabC*


 [1] https://www.dropbox.com/s/dnd7c5g7o6gm82o/comuni_no_admin_centre.html
 [2] http://wiki.openstreetmap.org/wiki/IT:Key:place



___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: R: R: ruolo admin_centre assente per molte amministrazioni

2014-02-16 Per discussione Samuele Battarra

In data domenica 16 febbraio 2014 11:50:43, Fabrizio Carrai ha scritto:
 Come al solito in poche ore il problema si dimezza : ora siamo agli
 ultimi *20* comuni!
 

Per quanto riguarda Poggio Torriana è un nuovo comune nato dalla fusione di 
Poggio Berni e Torriana, ho provato a cercare informazioni su quale sia il 
nuovo municipio, l'unico documento che ho trovato è questo [1] dove si parla 
di sede legale, secondo voi e valida/utilizzabile come informazione?

[1] http://www.urponline.provincia.rimini.it/accessible.php?idinfo=2673

-- 
Samuele Battarra
batta...@email.it

signature.asc
Description: This is a digitally signed message part.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: R: R: ruolo admin_centre assente per molte amministrazioni

2014-02-16 Per discussione Aury88

non saprei rispondere alla tua domandami sembra strano...suburb mi sembra
serva ad indicare un quartiere di una città e per quanto questa possa essere
il luogo in cui vi è la sede amministrativa del comune non è comunque il
quartiere l'entità che gestisce il comune ma la città...boh. non saprei
proprio

Ps ho trovato tramite overpass un paio di comuni che venivano indicati senza
admin_centre perchè questo ruolo era applicato non ad un place, ma al
municipio. la tua querry riconosce questi casi come privi di admin_centre o
no? 



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/ruolo-admin-centre-assente-per-molte-amministrazioni-tp5793505p5796527.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Programma di borse di studio Wikimania 2014

2014-02-16 Per discussione Francesca Valentina

ciao ragazzi, ma le domande vanno presentate in italiano o in inglese? il
form è in entrambe le lingue.

F


Il giorno 11 febbraio 2014 22:06, Maurizio Napolitano
napoo...@gmail.comha scritto:

  Ciao ragazzi, pensate che possa candidare la mappa sardsos come
 progetto o è un po' OT ?

 Candida candida!

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: R: R: ruolo admin_centre assente per molte amministrazioni

Penso che ci vorrà ancora un pò di tempo per avere una situazione chiara
(sicuramente per i non-locali).
Informazioni simili le ho trovate qui:

http://fusione.vallemarecchia.it/poggio-torriana-operativo-dal-1-gennaio-2014-le-prime-informazioni-di-servizio-per-i-cittadini-e-aziende/

La frase finale che indica due Municipi è rappresentativa e non ci aiuta
a capire quale nodo definire come admin_centre.

La cosa che non mi è chiara è che la Sede Legale indica (giustamente)
Poggio Torriana: ma dove è ?!

Stessa situazione per il Comune di Figline ed Incisa Valdarno:

http://www.comunefiv.it/

Comune di Figline e Incisa Valdarno
Piazza del Municipio, 5 - 50064 Figline e Incisa Valdarno (FI)

Ci saranno da aggiungere nuovi nodi place ? Dove ?

--
*FabC*



Il giorno 16 febbraio 2014 13:28, Samuele Battarra batta...@email.it ha
scritto:

 In data domenica 16 febbraio 2014 11:50:43, Fabrizio Carrai ha scritto:
  Come al solito in poche ore il problema si dimezza : ora siamo agli
  ultimi *20* comuni!
 

 Per quanto riguarda Poggio Torriana è un nuovo comune nato dalla fusione di
 Poggio Berni e Torriana, ho provato a cercare informazioni su quale sia il
 nuovo municipio, l'unico documento che ho trovato è questo [1] dove si
 parla
 di sede legale, secondo voi e valida/utilizzabile come informazione?

 [1] http://www.urponline.provincia.rimini.it/accessible.php?idinfo=2673

 --
 Samuele Battarra
 batta...@email.it
 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it




-- 
*Fabrizio*
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] manette per vigili urbani

2014-02-16 Per discussione matteo ruffoni

Mia moglie carmen usa le mappe di OSM per dei progetti a scuola, i bambini
le hanno fatto notare che le stazioni dei vigili urbani ha come logo le
manette

non sarebbe meglio un cappello da vigile?
ciao matteo
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] manette per vigili urbani

2014-02-16 Per discussione Gianluca Boero


Il 16/02/2014 21:22, matteo ruffoni ha scritto:
Mia moglie carmen usa le mappe di OSM per dei progetti a scuola, i 
bambini le hanno fatto notare che le stazioni dei vigili urbani ha 
come logo le manette


non sarebbe meglio un cappello da vigile?
ciao matteo



I vigili Urbani (se polizia municipale) sono Police.
Tutte le stazioni di Polizia dai Carabinieri alla GDF hanno questa icona 
a prescindere da cosa sono.



--
Gianluca Boero

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] manette per vigili urbani

2014-02-16 Per discussione matteo ruffoni

Il giorno 16 febbraio 2014 21:59, Gianluca Boero
gianlucabo...@alice.itha scritto:

  Il 16/02/2014 21:22, matteo ruffoni ha scritto:

  Mia moglie carmen usa le mappe di OSM per dei progetti a scuola, i
 bambini le hanno fatto notare che le stazioni dei vigili urbani ha come
 logo le manette

  non sarebbe meglio un cappello da vigile?
 ciao matteo


  I vigili Urbani (se polizia municipale) sono Police.
 Tutte le stazioni di Polizia dai Carabinieri alla GDF hanno questa icona a
 prescindere da cosa sono.


 grazie riferisco immediatamente
ciao

 --
 Gianluca Boero


 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: R: R: ruolo admin_centre assente per molte amministrazioni

Il giorno 16 febbraio 2014 14:16, Aury88 spacedrive...@gmail.com ha
scritto:

[...]


 Ps ho trovato tramite overpass un paio di comuni che venivano indicati
 senza
 admin_centre perchè questo ruolo era applicato non ad un place, ma al
 municipio. la tua querry riconosce questi casi come privi di admin_centre o
 no?


La query (di cui ricordo che l'autore originale è Alberto Nogaro, il suo
contributo è stato fondamentale ) seleziona le relazioni che non hanno
elementi con ruolo admin_centre. Gli eventuali tag del nodo (place o
building) non sono rilevanti. Magari Alberto può confermare.

--
*FabC*
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] manette per vigili urbani

2014-02-16 Per discussione Gianluca Boero


Il 16/02/2014 22:12, matteo ruffoni ha scritto:


I vigili Urbani (se polizia municipale) sono Police.

Tutte le stazioni di Polizia dai Carabinieri alla GDF hanno questa
icona a prescindere da cosa sono.


grazie riferisco immediatamente
ciao

http://wiki.openstreetmap.org/wiki/IT:Tag:amenity%3Dpolice

ti segnalo questa pagina come approfondimento.

Inoltre su
http://wiki.openstreetmap.org/wiki/IT:Map_Features#Amenity_.28strutture_di_servizio.29
sotto altro trovi l'icona da te descritta alla riga amenity?police

--
Gianluca Boero

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] manette per vigili urbani

2014-02-16 Per discussione Fabri

On dom 16 feb 2014 21:22:25 CET, matteo ruffoni mattruff...@gmail.com wrote:

 Mia moglie carmen usa le mappe di OSM per dei progetti a scuola, i
 bambini le hanno fatto notare che le stazioni dei vigili urbani ha come
 logo le manette
 
 non sarebbe meglio un cappello da vigile?
 ciao matteo

sarebbe bello ma si dovrebbe estendere il già ampio parco dei tag di osm con 
dei nuovi,uno per arma,e ognuno con un icona diversa. oppure riuscire a farlo 
renderizzare diversamente in base a un tag aggiuntivo come ad esempio 
police:type= ma dubito si faccia anche perchè l' avere tutte queste diverse 
tipologie di forze dell'ordine è una cosa solo italiana e non utile al resto 
del mondo.


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] American Red Cross OpenStreetMap Damage Assessment Review Typhoon Haiyan (Yolanda) Interim Report

2014-02-16 Per discussione Fabri

American Red Cross OpenStreetMap Damage Assessment Review Typhoon Haiyan 
(Yolanda) Interim Report


http://americanredcross.github.io/OSM-Assessment/

interessante riepilogo.

soprattutto quando si dice

These results reflect three key factors:

1. The resolution of existing satellite imagery sources is too low to
   reliably differentiate between destroyed and merely damaged buildings.


mi domando perchè gli USA oltre a mandare qualche C-130 con le derrate 
alimentari, non invii anche i droni con cui fotografa in 3D l'iraq e poi 
vende le immagini alla Apple che ci fa le mappe iOS.



___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-gb-westmidlands] Closure of NPTG-Viewer

2014-02-16 Per discussione Rob Nickerson

All,

In the next few days we will be moving the mappa-merica.org domain on to
our new Wordpress based site (blog post to follow).

Part of this switch will involve the switching off of the NPTG-Viewer - a
tool to compare place information in OpenStreetMap with localities in the
National Public Transport Gazetteer (NPTG).

Please take the time to review your local area before this service is
closed.

http://mappa-mercia.org/nptg-viewer/

Regards,
RobJN
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-se] Ny URL för Ekonomiska kartan TMS

2014-02-16 Per discussione Joakim Fors

Hej,

Förhoppningsvis åtgärdat nu. Lite segt kan det dock vara innan rutorna cacheats,

/Joakim

On 15 feb 2014, at 23:25, Tomas Marklund tomasmarklun...@gmail.com wrote:

 Hej!
 
 Har med stort nöje tittat på ekonomiska kartan i JOSM utan problem sen 
 föregående mail kom den 23:e jan. Nu verkar det dock ha strejkat...
 
 Fel: Server returned HTTP response code: 500 for URL...
 
 Någon som vet nåt mer i ärendet?
 
 /Tomas, Karlskoga
 
 
 Den 23 januari 2014 00:18 skrev Joakim Fors joa...@fo.rs:
 Hejsan!
 
 TMS URL:en för Ekonomiska kartan har ändrat. Den nya URLen (för JOSM i alla 
 fall) är: 
 http://mapproxy.openstreetmap.se/tms/1.0.0/ek_EPSG3857/{zoom}/{x}/{-y}.png
 
 Har inte riktigt kört in den ännu så kan hända att det buggar lite och kastar 
 felmeddelanden ibland.
 
 /Joakim
 ___
 Talk-se mailing list
 Talk-se@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-se
 
 ___
 Talk-se mailing list
 Talk-se@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-se


___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

[Talk-es] Alguien quiere cambiar de nombre un barrio...

2014-02-16 Per discussione David Marín Carreño

Hola a todos.

Haciendo un repaso a las líneas de bus de la EMT de Madrid veo que hay
un intento combinado entre OSM y la Wikipedia de variar el nombre del
barrio madrileño de Manoteras, cambiándolo por El Lince.

Esto se ha realizado, al menos, en las líneas  7, 129 y alguna otra
que todavía no he visto.

El usuario que subió los cambios es un tal xaviyoli. También ha creado
paradas que no existen, así como líneas de autobús de las que no hay
ninguna referencia en la web de la EMT.

Me ha dejado completamente extrañado, y realmente no sé muy bien qué
hacer. Hizo más cambios en rutas, pero no tengo ninguna manera fiable
de determinar en qué consisten (la herramienta de historial para rutas
no es muy visual...)

¿Alguien me puede echar un cable? No sé muy bien qué hacer...

--
David Marín Carreño dav...@gmail.com
Saludo a la NSA que me estará viendo - Best regards to the NSA workers
who are reading this mail

___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Alguien quiere cambiar de nombre un barrio...

2014-02-16 Per discussione Óscar Zorrilla Alonso

Hola,

Ivan ya denunció el tema en Noviembre,
https://twitter.com/RealIvanSanchez/status/403887618716602369
Algunas ediciones fueron revertidas, no se hasta donde.
De todos modos al usuario en cuestión se le preguntó por mensaje privado y 
tampoco contestaba.
Un saludo

--- Mensaje Original ---

Desde: David Marín Carreño dav...@gmail.com
Enviado: 16 de febrero de 2014 11:40
Para: Discusión en Español de OpenStreetMap Talk-es@openstreetmap.org
Asunto: [Talk-es] Alguien quiere cambiar de nombre un barrio...

Hola a todos.

Haciendo un repaso a las líneas de bus de la EMT de Madrid veo que hay
un intento combinado entre OSM y la Wikipedia de variar el nombre del
barrio madrileño de Manoteras, cambiándolo por El Lince.

Esto se ha realizado, al menos, en las líneas  7, 129 y alguna otra
que todavía no he visto.

El usuario que subió los cambios es un tal xaviyoli. También ha creado
paradas que no existen, así como líneas de autobús de las que no hay
ninguna referencia en la web de la EMT.

Me ha dejado completamente extrañado, y realmente no sé muy bien qué
hacer. Hizo más cambios en rutas, pero no tengo ninguna manera fiable
de determinar en qué consisten (la herramienta de historial para rutas
no es muy visual...)

¿Alguien me puede echar un cable? No sé muy bien qué hacer...

--
David Marín Carreño dav...@gmail.com
Saludo a la NSA que me estará viendo - Best regards to the NSA workers
who are reading this mail

___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Alguien quiere cambiar de nombre un barrio...

2014-02-16 Per discussione David Marín Carreño

Pues ha hecho unos cuantos destrozos en líneas de autobuses inventadas
y en no inventadas...
Las últimas ediciones ya no parecen tan sangrantes, aunque debería
haber alguna manera de monitorizarle...
--
David Marín Carreño dav...@gmail.com
Saludo a la NSA que me estará viendo - Best regards to the NSA workers
who are reading this mail


El día 16 de febrero de 2014, 16:36, Óscar Zorrilla Alonso
oscar_zorri...@hotmail.com escribió:
 Hola,

 Ivan ya denunció el tema en Noviembre,
 https://twitter.com/RealIvanSanchez/status/403887618716602369
 Algunas ediciones fueron revertidas, no se hasta donde.
 De todos modos al usuario en cuestión se le preguntó por mensaje privado y 
 tampoco contestaba.
 Un saludo

 --- Mensaje Original ---

 Desde: David Marín Carreño dav...@gmail.com
 Enviado: 16 de febrero de 2014 11:40
 Para: Discusión en Español de OpenStreetMap Talk-es@openstreetmap.org
 Asunto: [Talk-es] Alguien quiere cambiar de nombre un barrio...

 Hola a todos.

 Haciendo un repaso a las líneas de bus de la EMT de Madrid veo que hay
 un intento combinado entre OSM y la Wikipedia de variar el nombre del
 barrio madrileño de Manoteras, cambiándolo por El Lince.

 Esto se ha realizado, al menos, en las líneas  7, 129 y alguna otra
 que todavía no he visto.

 El usuario que subió los cambios es un tal xaviyoli. También ha creado
 paradas que no existen, así como líneas de autobús de las que no hay
 ninguna referencia en la web de la EMT.

 Me ha dejado completamente extrañado, y realmente no sé muy bien qué
 hacer. Hizo más cambios en rutas, pero no tengo ninguna manera fiable
 de determinar en qué consisten (la herramienta de historial para rutas
 no es muy visual...)

 ¿Alguien me puede echar un cable? No sé muy bien qué hacer...

 --
 David Marín Carreño dav...@gmail.com
 Saludo a la NSA que me estará viendo - Best regards to the NSA workers
 who are reading this mail

 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-es

 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-es

___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-ca] Cours géomatiques à distance, débute demain

2014-02-16 Per discussione Pierre Béland

encore le temps de s'inscrire

 
Pierre 




- Mail transféré -
De : frmoine frmo...@gmail.com
À : talk...@openstreetmap.org 
Envoyé le : Dimanche 16 février 2014 14h43
Objet : Re: [Talk-ht] Cours a distance Geomatique
 
Bonjour,

Suite à des demandes complémentaires d'information sur le cours de geomatique 

Le cours commence demain il faut appuyer sur le bouton join us en dessous de 
la video de presentation.

Cela demande du travail du
 soir, vous pouvez suivre tout ou partie du cours, il y aura d'autre dans le 
futur.
Il est possible de charger les videos lorsque vous avez un acces internet et 
les regarder chez vous hors connection.

Cordialement, FredM

/https://www.coursera.org/course/geomatique/

1. Introduction à la géomatique: principes et techniques,
    représentation/acquisition/gestion
2. Bases de géodésie: unités, références géodésiques, géoïde, systèmes
    de coordonnées, projections
3. Cartographie: types de cartes, sémiologie, modes de représentation
4. Nivellement géométrique: système altimétrique, contrôle du niveau et
   
 cheminement
5. Lever topométrique: théodolite, principe d'orientation, mesures
    d'angles, lever polaire
6. Mesures de distances: mesure électronique, réduction des distances
7. Localisation par satellites: principe du GPS, modes de localisation,
    sources d'erreurs
8. Modèle numérique d'altitudes: représentation de l'altimétrie,
    géomorphométrie, produits dérivés



Il y en a plus de cours ici

http://www.scoop.it/t/moocfrancophone

apres il y a des cours en anglais

http://www.mooc-list.com/university-entity/stanford-university

https://www.udacity.com/

http://www.codecademy.com/

Si cela peut servir,

Cordialement FredM___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

2014-02-16 Per discussione hanoj

  - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově
  přidaných AM přidat, ?
 
 source:position se nemaže, v případě přidávání nových bodů se přidává.

*** spíše source:loc než source:position
http://taginfo.openstreetmap.org/keys/source:position#combinations
http://taginfo.openstreetmap.org/keys/source:loc#combinations

hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

2014-02-16 Per discussione Dalibor Jelínek

Ahoj,

jo, to asi je lespi.

 

Takze navthuji najit u adresniho bodu

source:position

source:pos

a prendat obsah do 

source:loc

a tagy smazat.

 

a pokud nejsou, tak source:loc nastavit na cuzk:ruian.

 

Zdravi,

Dalibor

 

 

From: hanoj [mailto:eha...@gmail.com] 
Sent: Sunday, February 16, 2014 9:37 AM
To: OpenStreetMap Czech Republic
Subject: Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

 

  - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově
  přidaných AM přidat, ?
 
 source:position se nemaže, v případě přidávání nových bodů se přidává.

*** spíše source:loc než source:position
http://taginfo.openstreetmap.org/keys/source:position#combinations
http://taginfo.openstreetmap.org/keys/source:loc#combinations

 

hanoj 

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

Dne 16.2.2014 09:37, hanoj napsal(a):
  - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově
  přidaných AM přidat, ?
 
 source:position se nemaže, v případě přidávání nových bodů se přidává.
 
 *** spíše source:loc než source:position
 http://taginfo.openstreetmap.org/keys/source:position#combinations
 http://taginfo.openstreetmap.org/keys/source:loc#combinations
 
 hanoj

Ahoj,

nebylo by lepší ty source tagy dát přímo na changeset (což je v
současnosti doporučovaný postup pro importy)?
Obzvláště u toho source:position, resp. source:loc bych se celkem bál,
že při editaci lidi posunou bod, ale zapomenou změnit/odmazat tag.

V ČR je stejně jen jeden zdroj pro tyhle data, takže není potřeba na
každém bodu explicitně uvádět, že fakt pochází z RUIANu a ne odněkud jinud.

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

Ahoj,

může se stát, že některá adresní entita bude mít source:loc i source:position 
či source:pos zároveň. Co mám dělat pak? Prostým přejmenováním tagu vytvořím 
duplicitu. A který z nich si mám vybrat a použít jeho hodnotu pro source:loc? 
Když bude takových případů pár, tak to opravím ručně, nicméně může se stát, že 
narazím na lokalitu, kde bude takových 10.000 a do toho stavu bych se fakt 
nechtěl dostat.

Dne Ne 16. února 2014 11:06:57, Dalibor Jelínek napsal(a):

 Ahoj,
 
 jo, to asi je lespi.
 
 
 
 Takze navthuji najit u adresniho bodu
 
 source:position
 
 source:pos
 
 a prendat obsah do
 
 source:loc
 
 a tagy smazat.
 
 
 
 a pokud nejsou, tak source:loc nastavit na cuzk:ruian.
 
 
 
 Zdravi,
 
 Dalibor
 
 
 
 
 
 From: hanoj [mailto:eha...@gmail.com]
 Sent: Sunday, February 16, 2014 9:37 AM
 To: OpenStreetMap Czech Republic
 Subject: Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace
 
   - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově
   přidaných AM přidat, ?
  
  source:position se nemaže, v případě přidávání nových bodů se přidává.
 
 *** spíše source:loc než source:position
 http://taginfo.openstreetmap.org/keys/source:position#combinations
 http://taginfo.openstreetmap.org/keys/source:loc#combinations
 
 
 
 hanoj
--
Petr


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Adresy z RUIAN

Dne 15.2.2014 22:39, Pavel Machek napsal(a):
Za podpasovku sorry, ale proste to dle wiki vypada, ze v addr:city ma
byt jmeno posty, ktere se nemusi nutne shodovat s tim kde to je. Ze
Vam to prijde reduntantni s PSC... no to asi ano, ale chudak
zahranicni uzivatel asi nema po ruce databazi mest odpovidajicich k
PSC... coz je duvod proc mame addr:city.

Pavel

Ahoj,

já teda tu anglickou stránku [1] chápu tak, že tam má být to, co se píše
do kolonky město na obálku dopisu. A to může a nemusí být shodné s
městem, pod které adresní místo administrativně/územně spadá, ale zrovna
tak to může a nemusí být shodné se jménem pošty, která dané místo
obsluhuje. Problém je, že v ČR je to strašný maglajz.

Česká pošta má sice nějaké doporučené vzory psaní adres [2], ale moc
moudrý z toho nejsem. Přijde mi, že tam termín obec používají dost
volně a skutečně se tváří jako, že chtějí hlavně jméno adresní pošty.
Důsledné aplikování těch pravidel vede v mnoha případech k naprostým
kravinám.

Myslím, že bude lepší se přidržet toho tvaru, co zobrazuje RUIAN, t.j.
držet addr:city=Název obce.

Zdraví,
Petr Morávek aka Xificurk

[1] http://wiki.openstreetmap.org/wiki/Addr
[2]
http://www.ceskaposta.cz/cz/nastroje/uzitecne-informace/doporucene-vzory-postovnich-adres/doporucene-vzory-psani-postovnich-adres-id1078/

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

Ahoj,

Dne Ne 16. února 2014 11:28:27, Petr Morávek [Xificurk] napsal(a):

 nebylo by lepší ty source tagy dát přímo na changeset (což je v
 současnosti doporučovaný postup pro importy)?
 Obzvláště u toho source:position, resp. source:loc bych se celkem bál,
 že při editaci lidi posunou bod, ale zapomenou změnit/odmazat tag.
 
 V ČR je stejně jen jeden zdroj pro tyhle data, takže není potřeba na
 každém bodu explicitně uvádět, že fakt pochází z RUIANu a ne odněkud jinud.

Polohu neměním, tedy zdrojem polohy není RUIAN (pokud jím nebyl už v původní 
adrese). Zdrojem polohy je RUIAN pouze u nově přidávaných bodů. To vše právě 
proto, že s bodem mohl někdo šoupnout a posunout ho na lepší polohu - nad 
vchod, namísto původní, méně vhodné polohy.

--
Petr


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

Ahoj,

jj, i v CZ:

 source:position |   45821
 source:loc  | 1113248
 source:locality |   1


Dne Ne 16. února 2014 09:37:12, hanoj napsal(a):

   - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově
   přidaných AM přidat, ?
  
  source:position se nemaže, v případě přidávání nových bodů se přidává.
 
 *** spíše source:loc než source:position
 http://taginfo.openstreetmap.org/keys/source:position#combinations
 http://taginfo.openstreetmap.org/keys/source:loc#combinations
 
 hanoj

--
Petr

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

Dne 16.2.2014 12:09, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne Ne 16. února 2014 11:28:27, Petr Morávek [Xificurk] napsal(a):
 
 nebylo by lepší ty source tagy dát přímo na changeset (což je v
 současnosti doporučovaný postup pro importy)?
 Obzvláště u toho source:position, resp. source:loc bych se celkem bál,
 že při editaci lidi posunou bod, ale zapomenou změnit/odmazat tag.

 V ČR je stejně jen jeden zdroj pro tyhle data, takže není potřeba na
 každém bodu explicitně uvádět, že fakt pochází z RUIANu a ne odněkud jinud.
 
 Polohu neměním, tedy zdrojem polohy není RUIAN (pokud jím nebyl už v původní 
 adrese). Zdrojem polohy je RUIAN pouze u nově přidávaných bodů. To vše právě 
 proto, že s bodem mohl někdo šoupnout a posunout ho na lepší polohu - nad 
 vchod, namísto původní, méně vhodné polohy.
 
 --
 Petr

Aha, tak to jsem z té ukázky moc nepochopil - tam mají všechny body
source:position=cuzk:ruian. To by asi mít neměly, vzhledem k tomu, že
již existují a neposouváš je, ne?

Ale stále platí výše uvedená otázka... V principu by všechny adresní
body v ČR měly svým obsahem i pozicí být odvozeny od RUIAN. Jakékoliv
odchylky od stavu RUIANu budou buď opravy chyb (doufejme, že jich v
databázi moc není), malá pošoupnutí adresního místa na lepší místo
(např. blíže k vchodu/schránce), příp. doplnění nějakých POI tagů.

Otázkou tedy je, zda by nebylo vhodnější tyhle globální tagy dát přímo
na changesety importu (jak doporučují import guidelines), na
jednotlivých bodech by se pak už přidávat nemusely - co se s tím bodem
během importu přesně dělalo, se uvidí v jeho historii.

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

Ahoj,

Dne Ne 16. února 2014 12:29:08, Petr Morávek [Xificurk] napsal(a):

 Aha, tak to jsem z té ukázky moc nepochopil - tam mají všechny body
 source:position=cuzk:ruian. To by asi mít neměly, vzhledem k tomu, že
 již existují a neposouváš je, ne?

Všechny mají source:addr=cuzk:ruian. source:position=cuzk:ruian mají jen nově 
přidané. 9 se nově přidává, 111 se upravuje. Ať koukám, jak koukám, vidím to 
tak, jak píšu. Nezaměnil jsi to se source:addr?

 
 Ale stále platí výše uvedená otázka... V principu by všechny adresní
 body v ČR měly svým obsahem i pozicí být odvozeny od RUIAN. Jakékoliv
 odchylky od stavu RUIANu budou buď opravy chyb (doufejme, že jich v
 databázi moc není), malá pošoupnutí adresního místa na lepší místo
 (např. blíže k vchodu/schránce), příp. doplnění nějakých POI tagů.

Jestli to správně chápu, pak by to prakticky znamenalo zrušení informace o 
zdroji polohy pro všechny body a zavedení předpokladu, že vše pochází od CUZK, 
není-li uvedeno jinak. V praxi to tak je (pouze ty, které jsou zastoupeny více 
než 100x):

 cuzk:km| 1155200
 uhul:ortofoto  | 353
 uhul:ortofoto, cuzk:km | 287
 ruian  |2900

 
 Otázkou tedy je, zda by nebylo vhodnější tyhle globální tagy dát přímo
 na changesety importu (jak doporučují import guidelines), na
 jednotlivých bodech by se pak už přidávat nemusely - co se s tím bodem
 během importu přesně dělalo, se uvidí v jeho historii.

Jaká konkrétní hodnota source:loc by se tedy měla dávat na changeset? Mně to 
vychází na cuzk:km, ovšem záeží na lokalitě. V okolí Vyškova to bude 99% 
RUIAN, protože tam prostě skoro žádné adresy nejsou. V Praze to bude cuzk:km.

--
Petr


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Adresy z RUIAN - 2. rekapitulace

Dne 15.2.2014 22:23, Václav Řehák napsal(a):
 
 Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě
 zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj
 ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl.
 
 
 A nemůžeme to vzít opačně? Opravdu ti ta duplicita addr:country vadí na
 tolik, že má smysl kvůli tomu zdržovat celý import? 
 
 Obecná zásada bývá nedělat duplicity, ale proč? Aby nevznikaly rozpory
 mezi neaktualizovanými verzemi těch dat. Zrovna u RUIANu si nemyslím, že
 by to byl problém, když většina těch dat bude importována/udržována
 automaticky.
 
 Jinak řečeno, pořád chceš příklady, co se rozbije, když to odstraníme.
 Máš nějaký příklad, co se rozbije, když to tam necháme/přidáme? Těch pár
 MB opravdu není argument ve světě OSM, kde se importují jednotlivé
 stromy v parku a další (pro mě až nesmyslné) detaily.
 
 O is_in nemluvím, tam je to asi opravdu nejasné, k čemu má sloužit a i
 to rozsynchronizování si dovedu představit o dost realističtěji.
 
 V.

Ahoj,

však o addr:country už jsem psal dříve:
 Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je
 nějaký nesmysl).

Asi jsem to pak zbytečně zamotal tím, že jsem začal tak nějak
addr:country a is_in házet do jednoho pytle - to proto, že se objevily
názory, že oba tagy jsou užitečné a je žádoucí je všude ponechat a
doplnit, ale zatím nikdo neukázal, kde/jak/proč jsou užitečné.

is_in má oproti addr:country jeden zásadní problém - není jasné, co by
tam mělo být, a tak není ani možné jednoduše zkontrolovat, jestli
současný obsah na existujících bodech je blábol, nebo správná hodnota. A
asi těžko vymyslíme Ten Správný Formát(TM), dokud nebude jasné k
čemu/kde se to používá.

Nepřidávání a zároveň nemazání addr:country má jeden pozitivní vedlejší
efekt - pokud na tu hodnotu něco přeci jen spoléhá, tak:
a) to bude i po importu fungovat ve stejné míře jako doteď
b) je slušná šance, že si po importu někdo všimne (a ozve se), že
software XYZ nefunguje úplně všude, protože ten tag někde chybí. Jakmile
bude na stole konkrétní problém, tak bude rozhodování řádově snažší -
buď doplníme tag na zbylé body, nebo se napíše patch, který to zvládne
vyřešit i bez addr:country.

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

Ahoj,

procházím si těch 9 nově přidaných bodů. Milady Horákové 34 - ukázně pitomě 
umístěného bodu uprostřed baráku. Vsadím se, že Haškova 2 má v RUIAN stejnou 
pozici.

Milady Horákové 135 - vůbec neleží na ulici Milady Horákové, ale věřme, že 
barák má opravdu adresu Milady Horákové 135.

Většina těch nových bodů je umístěna nevhodně uprostřed baráku. Milady 
Horákové 98 je taky úplně jinde, rozhodně ne na ulici Milady Horákové, ovšem 
vchod tam může být.


Dne Ne 16. února 2014 12:29:08, Petr Morávek [Xificurk] napsal(a):

  Polohu neměním, tedy zdrojem polohy není RUIAN (pokud jím nebyl už v
  původní  adrese). Zdrojem polohy je RUIAN pouze u nově přidávaných bodů.
  To vše právě proto, že s bodem mohl někdo šoupnout a posunout ho na lepší
  polohu - nad vchod, namísto původní, méně vhodné polohy.

--
Petr


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

Dne 16.2.2014 13:00, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne Ne 16. února 2014 12:29:08, Petr Morávek [Xificurk] napsal(a):
 
 Aha, tak to jsem z té ukázky moc nepochopil - tam mají všechny body
 source:position=cuzk:ruian. To by asi mít neměly, vzhledem k tomu, že
 již existují a neposouváš je, ne?
 
 Všechny mají source:addr=cuzk:ruian. source:position=cuzk:ruian mají jen nově 
 přidané. 9 se nově přidává, 111 se upravuje. Ať koukám, jak koukám, vidím to 
 tak, jak píšu. Nezaměnil jsi to se source:addr?

Aha, moje chyba - já si proklikal jen pár náhodných bodů v západní části
a naprosto špatně z toho vyvodil, že to mají všechny.


 Ale stále platí výše uvedená otázka... V principu by všechny adresní
 body v ČR měly svým obsahem i pozicí být odvozeny od RUIAN. Jakékoliv
 odchylky od stavu RUIANu budou buď opravy chyb (doufejme, že jich v
 databázi moc není), malá pošoupnutí adresního místa na lepší místo
 (např. blíže k vchodu/schránce), příp. doplnění nějakých POI tagů.
 
 Jestli to správně chápu, pak by to prakticky znamenalo zrušení informace o 
 zdroji polohy pro všechny body a zavedení předpokladu, že vše pochází od 
 CUZK, 
 není-li uvedeno jinak. V praxi to tak je (pouze ty, které jsou zastoupeny 
 více 
 než 100x):
 
  cuzk:km| 1155200
  uhul:ortofoto  | 353
  uhul:ortofoto, cuzk:km | 287
  ruian  |2900
 

 Otázkou tedy je, zda by nebylo vhodnější tyhle globální tagy dát přímo
 na changesety importu (jak doporučují import guidelines), na
 jednotlivých bodech by se pak už přidávat nemusely - co se s tím bodem
 během importu přesně dělalo, se uvidí v jeho historii.
 
 Jaká konkrétní hodnota source:loc by se tedy měla dávat na changeset? Mně to 
 vychází na cuzk:km, ovšem záeží na lokalitě. V okolí Vyškova to bude 99% 
 RUIAN, protože tam prostě skoro žádné adresy nejsou. V Praze to bude cuzk:km.
 
 --
 Petr

Na tom changesetu by to podle mě nebylo potřeba rozlišovat (jestli se
mění/doplňuje adresa, nebo i pozice je vidět přímo z jeho obsahu),
použil bych něco jako:
source=cuzk:ruian
url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU
import=yes
bot=yes
comment=???

V historii každého bodu pak bude např.:
v1: import RUIAN
v2: user123 změnil o pár mětrů pozici
v3: user456 přidal shop=*
...

Tím pádem na všech vytvořených nebo zkontrolovaných bodech by nebylo
potřeba source:addr, source:loc by se nechalo jen pokud obsahuje nějakou
jinou než s RUIANem související hodnotu, např. 'uhul:ortofoto'.

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace