Re: [Talk-de] HTTPS auf overpass-api.de

2015-03-26 Diskussionsfäden Richard Z.
On Thu, Mar 26, 2015 at 07:24:18PM +0100, Roland Olbricht wrote:

 Im Gegensatz dazu verbreitet sich mit Certificate Pinning [6] ein Verfahren,
 das inhärent große Anbieter bevorzugt: man muss sich wieder mit dem
 Browser-Hersteller gutstellen, damit er für die eigene Seite nur die
 Zertifikate eines einzelnen Anbieters akzeptiert. In der Praxis wird das
 heißen, eine Bürokratie zu durchlaufen, Geld auf den Tisch zu legen oder
 eine Kombination aus beidem. Wie aussichtsreich das für die Seiten im
 OSM-Umfeld ist, kann man an dem Umgang mit CACert absehen.

Certificate pinning geht wohl auf verschiedene Arten.

Die einzige sichere Methode des Cert-pinnings funktioniert glücklicherweise
für Jedermann und gratis: man besorgt sich den public key des Servers,
verifiziert diesen manuel über einen sicheren Kanal und benutzt Programme
die manuelles Certificate pinning unterstützten.
Auf Anhieb fällt mir curl --pinnedpubkey key ein.

Vorteil - man benutzt von vornherein ein selbstsigniertes Zertifikat
welches nichts kostet.

Im Firefox geht es im Prinzip auch (NICHT NACHMACHEN): einfach *alle* 
root-Zertifikate entfernen - jedesmal wenn Firefox ein neues https 
Zertifikat sieht wird man gefragt ob man dieses akzeptieren möchte, 
kann den fingerprint vergleichen
usw. Funktioniert in der Praxis leider überhaupt so gut - Filterlisten-
abonments vom adblocker und AJAX requests gehen meistens schief oder
erfordern sehr hohen manuellen Aufwand.

Trotzdem würde ich jedem Raten sich die Liste der im Browser installierten
Root-zertifikate anzuschauen und radikal zu kürzen - insbesondere vor 
Aulsandsreisen. Jede dieser root-ca kann einem jederzeit eine falsches 
Zertifikat für jede beliebige Domain einspielen und in vielen Asiatischen
Ländern würde ich fest damit rechnen, daß dies von den nationalen root-cas
auch flächendeckend gemacht wird. Auch eine bekannte Fluggeselschaft wurde 
unlängst auch dabei ertappt wie sie  bein in-flight Netzverbindungen 
gefälschte Zertifikate eingesetzt hat um den HTTPS Verkehr über proxies 
umzuleiten.

Richard



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


Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

2015-02-21 Diskussionsfäden Richard Z.
On Thu, Feb 19, 2015 at 11:31:55AM +0100, Martin Vonwald wrote:
 Hi!
 
 Am 19. Februar 2015 um 10:46 schrieb Eifelhunde eifelhu...@gmx.de:
 
   Sehe ich weniger problematisch, oder werden kurvenreiche Strecken auch
   berücksichtigt?
   Häufig sind doch diese nicht beschränkt, erlauben aber wegen der vielen
   Kurven nur geringe Geschwindigkeiten
 
  ??? es gilt in jedem Land ein generelles Maxspeed (in D außer
  Autobahnen) Ich versteh die Anmerkung nicht, es besteht doch nicht die
  Pflicht so schnell zu fahren - selbst wenn Schilder die Geschwindigkeit
  weiter beschränken ist die Geschwindigkeit keine Pflicht
 
 
 Kein professioneller Router geht davon aus, dass man die maximal erlaubte
 Geschwindigkeit auch tatsächlich fahren kann. Je nach Verlauf der Straße
 werden deutlich niedrigere Geschwindigkeiten angenommen. Auf einer völlig
 geraden Autobahn im ebenen Gebiet nimmt ein guter Router eine
 Geschwindigkeit nahe der erlaubten an, idR ca. 5%-10% darunter. Auf einer
 Passstraße, wo sich eine Serpentine an die nächste reiht, interessiert
 einen professionellen Router die maximal erlaubte Geschwindigkeit nur noch
 am Rande und es werden so Geschwindigkeiten z.B. im Bereich von 20-50km/h
 unterstellt, selbst wenn dort 100km/h erlaubt ist.
 
 Diese Geschwindigkeiten werden dann für die Routenfindung verwendet.

egal ob das anhand der Geometrie oder tags passiert, solche Heuristiken 
funktionieren bestenfalls sehr grob. Die Faktoren die man mappen müßte sind 
einfach zu viel und wären im Endeffekt sowieso subjektiv: Sichbeinträchtigugn 
in den Kurven, Straßenrandbeschaffenheit, herumschleichende Touristenautos,
Fußgänger/Radfahrer auf der Straße, parkende Autos am Straßenrand, rush hour
u.v.A.

Enwteder irgendeine der Average speed per way Datenbanken wird dauerhaft
wiederbelebt oder etwas wie 
http://wiki.openstreetmap.org/wiki/Proposed_features/Practical_maxspeed

Richard


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


Re: [Talk-de] Wehr - Schleuse

2015-01-06 Diskussionsfäden Richard Z.
On Tue, Jan 06, 2015 at 10:22:59AM +0100, Volker Schmidt wrote:
 Ich habe in waterway=sluice_gate benutzt.

bitte keine falsche Scheu das auch mal im wiki zu Dokumentieren.

Im wiki steht nur  
http://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate
wo das tagging ganz anders aussieht?

Richard

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


[Talk-de] 663 Bäume mit identischer Internetaddresse..

2014-12-21 Diskussionsfäden Richard Z.
Hi,

sieht fast nach einem spam-Versuch aus? 

http://taginfo.openstreetmap.org/tags/?key=contact%3Awebsitevalue=http%3A%2F%2Fwww.ruheforst-vogelsberg.de%2Findex.php%3Fseite%3DKonzept%26h%3D2#overview

Richard

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


Re: [Talk-de] Bettelampeln / Anforderungsampeln

2014-10-31 Diskussionsfäden Richard Z.
On Fri, Oct 31, 2014 at 11:33:26AM +0100, DarkAngel wrote:
 
  Hi,
  gibt es eigentlich Tags für Bettelampeln d.h. Fuß/Radfahrer Ampeln
  die nur auf Anforderung grün werden?
 
 
 Die Dinger heißen Bedarfsampel und damit finden man sie auch unter
 http://wiki.openstreetmap.org/wiki/DE:Key:crossing
 
 Über den Rest kann man sich streiten, ich finde sie sinnvoller als bei
 Rot zu warten obwohl weit und breit kein anderer zu sehen ist. Würden
 mehr Ampeln nach Bedarf geschaltet würde der Verkehr auch flüssiger
 funktionieren.

soso, die Autofahrer könnten auch mal einen Knopf drücken und warten,
wie wäre das zur Abwechslung?

Richard

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


Re: [Talk-de] Unbenutzbare Wanderwege - was tun?

2014-10-18 Diskussionsfäden Richard Z.
On Thu, Sep 25, 2014 at 03:28:39PM +0200, Norbert Wenzel wrote:
 On 09/25/2014 01:03 PM, thsMD wrote:
  Noch eine Zusatzfrage: Welche Attribute verwendet man, wenn Radfahren auf
  dem Weg explizit nicht verboten ist (kein Schild), ich aber der Meinung bin,
  dass dort keiner mit seinem Rad langfahren möchte?
 
 Da ich von entsprechendem Gelände ausgeh würd ich mtb:scale[0] setzen.
 Praktisch unfahrbar bedeutet hier 6, wobei die Grenze für unfahrbar
 wirklich sehr hoch liegt.

es gibt noch andere Gründe warum man einen Weg nicht Radfahren möchte,
mtb:scale ist da eher ungeeignet:

https://wiki.openstreetmap.org/wiki/Talk:Mountain_biking#How_to_map_ways_that_are_possible_but_really_no_fun_or_places_where_to_dismount_for_technical_.28not_legal_reasons.29.3F


Richard

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


Re: [Talk-de] Anforderungen des API verletzt - Fehler

2014-08-31 Diskussionsfäden Richard Z.
On Sun, Aug 31, 2014 at 10:17:07PM +0200, Andreas Schmidt wrote:
 hallo Liste,
 
 ich bin gerade in Brasilien am mappen.
 Da komme ich in Gegenden, wo noch kein Mapper war und zeichne u.a. lange
 Stra0en und noch längere Flüsse.
 
 Jetzt habe ich erstmals eine Meldung von JOSM, von der ich nicht weiß,
 was ich falsch gemacht habe und wie man es richtig macht:
 
 [Anforderungen des API verletzt]
 2.089 Punkte in Linie 285966444 überschreitet die maximal erlaubte
 Anzahl von 2.000 Punkten.
 
 http://abload.de/img/osm2000c4qgq.png
 
 Ich kann die aktuelle JOSM-Sitzung nicht hochladen. :-(

den Weg mit P splittten - sofern Du weißt welcher Weg der Verursacher 
ist.

Nochwas.. Deutsche Fehlermeldungen sind zwar schön aber Englische sind sehr
viel praktischer weil man sie viel besser googeln kann.

Richard

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


Re: [Talk-de] Baum der Woche: Kastanie

2014-04-15 Diskussionsfäden Richard Z.
On Tue, Apr 15, 2014 at 09:54:19AM +0200, Falk Zscheile wrote:
 Am 15. April 2014 09:37 schrieb tumsi tu...@gmx.de:
 
  zu taggen. Vielleicht gibt es dann im Herbst eine
  Kastaniensammelkarte?
 
 
  Sollten wir nicht auch die Bärlauchfelder im Wald mappen, damit man auch in
  unbekannteren Gegenden schnell mal ein paar Blätter für die Küche sammeln
  kann?
 
 
 :-)
 
 Oh, das ist ein extrem schwieriges Thema. Möglicherweise brauchen
 wir dann neben dem surface-Tag auch noch ein
 vegetation-Tag, dass dann auch noch nach Bewuchshöhe differenzieren
 muss.

ich habe da schon einige Ideen und werde mich dran machen wenn ich mal
Zeit habe.

Richard


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


Re: [Talk-de] Baum der Woche: Kastanie

2014-04-14 Diskussionsfäden Richard Z.
On Sun, Apr 13, 2014 at 12:49:17PM +0200, Ralf GESELLENSETTER wrote:
 Der milde März hat dazu geführt, dass bereits jetzt viele
 Kastanienbäume ihre fünffingrigen Blätterfächer entfalten
 und sogar ihre ersten Blütenkerzen entfachen...
 
 Auf diese Weise sollte es auch botanischen Laien leicht
 fallen, hie und da einige
 
 natural=tree
 species=Aesculus␣hippocastanum
 species:de=Rosskastanie
 
 zu taggen. Vielleicht gibt es dann im Herbst eine
 Kastaniensammelkarte?

Vielleicht kommt jemand in Carisolo vorbei und kann und die 
Bäume und Amenities im Castagnetto mappen? Ich bin im Moment
weit weg.

http://www.openstreetmap.org/relation/3583513

Richard

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


Re: [Talk-de] 3D: Wie Gebäude am Hang taggen?

2014-03-21 Diskussionsfäden Richard Z.
On Mon, Mar 17, 2014 at 04:19:06PM +0100, Martin Koppenhoefer wrote:
 Am 17. März 2014 13:44 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 
  Gibt es denn wenigstens einen Renderer, der bereits irgendwelche
  Geländedaten mit einbezieht?
 
 
 
 bei den bisher frei verfügbaren Quellen wie SRTM und Aster gibt es
 jedenfalls sicher keine Hoffnung, dass damit solche Details wie ein halb
 eingegrabenes Gebäude wiedergegeben werden könnten (Zu geringe Auflösung).
 Es gibt aber durchaus Renderer, die diese Quellen miteinbeziehen, aber das
 hilft eher bei der Orientierung im großmaßstäblicheren Einsatz, nicht bei
 der Ansicht des einzelnen Gebäudes.

sollte man da vielleicht mit ele=* nachhelfen? Aber was genau würde man
mit ele taggen? Eingänge?

Richard


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


Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-14 Diskussionsfäden Richard Z.
On Fri, Mar 14, 2014 at 11:23:18AM +0100, Andreas Neumann wrote:
 Am 14.03.2014 08:56, schrieb Andreas Schmidt:
  [...] Die Herren Hobbyschlachter [...]
 
 Ich verbitte mir eine solche Ausdrucksweise in öffentlichen
 Diskussionen. Man mag zur Jagd stehen wie man will, aber man sollte
 auch Menschen, deren Hobby man ablehnt, mit Respekt begegnen. Du
 willst ja auch, dass uns Mappern Respekt entgegen gebracht wird.

wir sind die Hobbymapper und stolz darauf! Wenn andere Probleme
mit ihrem Image haben ist das nicht unser Problem.

Richard

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


Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-13 Diskussionsfäden Richard Z.
On Thu, Mar 13, 2014 at 12:51:22PM +0100, Falk Zscheile wrote:

 Worauf die betreffende Person aber vermutlich hinaus will: Radikale
 Tierschützer nutzen die Daten unter Umständen, um die jagdlichen
 Einrichtungen zu beschädigen. Die Beschädigung ist eine Straftat (§
 303 StGB). Für einem Mapper aber durch Erfassung der Daten eine
 Beihilfe (§ 27 StGB) zur Sachbeschädigung zu konstruieren, halte ich
 für sehr weit hergeholt.

wäre mir nicht so sicher mit den Tierschützern - mindestens genauso oft 
kommt es wohl vor, daß da Konkurenz am Werk war.

Nun ist so ein Hochsitz in der Regel eine Art lnadmark, wenn man die 
löscht oder zerstört kann die Orientierung erschwert sein.

Richard

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


Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

2014-03-13 Diskussionsfäden Richard Z.
On Thu, Mar 13, 2014 at 01:32:40PM +0100, Falk Zscheile wrote:
 Am 13. März 2014 13:20 schrieb Richard Z. ricoz@gmail.com:
  On Thu, Mar 13, 2014 at 12:51:22PM +0100, Falk Zscheile wrote:
 
  Worauf die betreffende Person aber vermutlich hinaus will: Radikale
  Tierschützer nutzen die Daten unter Umständen, um die jagdlichen
  Einrichtungen zu beschädigen. Die Beschädigung ist eine Straftat (§
  303 StGB). Für einem Mapper aber durch Erfassung der Daten eine
  Beihilfe (§ 27 StGB) zur Sachbeschädigung zu konstruieren, halte ich
  für sehr weit hergeholt.
 
  wäre mir nicht so sicher mit den Tierschützern - mindestens genauso oft
  kommt es wohl vor, daß da Konkurenz am Werk war.
 
 Die meisten Wilderer haben einen Jagdschein, aber dass sich Jäger die
 Hochsitze gegenseitig zersägen, davon habe ich noch nichts gehört.

ich habe auch nichts spezifisches über Hochsitze gehört dafür aber ganz
andere Geschichten, da wäre ein angesägter Hochsitz ein Kavaliersdelikt
dagegen.

  Nun ist so ein Hochsitz in der Regel eine Art lnadmark, wenn man die
  löscht oder zerstört kann die Orientierung erschwert sein.
 
 Sicher, aber wenns dem lieben Frieden dient  kann man zumindest einmal
 darüber nachdenken, ob man dem Jäger einen gefallen tun möchte. 

Die könnten mal an ihrem Image werkeln. Es scheint solche zu geben die 
gerne mal Kletterhaken u.Ä. beschädigen.. bin nicht übertrieben geneigt 
so jemanden einen Gefallen zu tun.

Richard

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


Re: [Talk-de] Natural Wood = Forest Landuse

2014-03-02 Diskussionsfäden Richard Z.
On Sat, Mar 01, 2014 at 05:15:43PM +0100, Falk Zscheile wrote:

 Kurzum ich sehe einen langfristigen Reformbedarf.

+1


 Ich höre schon die Stimmen auf allen Kanälen: Mein Wald wird nicht mehr
 gerendert, weil ihn irgendein nichtsnutziger, unwissender, bösartiger
 und gemeiner User von landuse=forest zu natural=forest geändert hat.

ohnehin nicht so die durchgreifende Reform.. wenn schon dann richtig.

Ich denke in die Richtung

vegetation:soil - soil microbiology
vegetation:low - gras/blueberries/low bush types
vegetation:high - trees and high bushes

Richard

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


Re: [Talk-de] Vulkane und natural=crater

2014-02-26 Diskussionsfäden Richard Z.
On Tue, Feb 25, 2014 at 10:46:39PM +0100, Martin Koppenhoefer wrote:
 Am 25. Februar 2014 21:08 schrieb Richard Z. ricoz@gmail.com:
 
  So ein ausgedehntes Lavafeld halte ich sehr wohl für ein geografisches
  Feature
 
 
 
 +1
 natural=lava_field ?

war auch mein erster Gedanke, aber wo es schon seit Ewigkeiten natural=lava 
mit exakt der gleichen Bedeutung im wiki gibt bin ich eher geneigt das lava 
zu übernehmen als auf lava_field zu ändern?

  Was macht man mit flüssigem Lava? Sind zum Teil richtige Flüsse die auch
  gemappt werden könnten, und z.T. unterirdisch (lava pipes).

 lavaway als key? ;-)

sowas habe ich gedacht. Oder man versucht die Material-Flüsse zu generalisieren 
- es 
gibt noch allerlei was in der Natur fliessen kann, mir fallen gerade Gletscher, 
Asfalt,
Erdrutsche ein.

Richard


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


Re: [Talk-de] Vulkane und natural=crater

2014-02-26 Diskussionsfäden Richard Z.
On Tue, Feb 25, 2014 at 10:29:28PM +0100, Christoph Hormann wrote:
 On Tuesday 25 February 2014, Richard Z. wrote:
  
   natural=lava halte ich weniger für einen guten tag, weil es kein
   geografisches Feature sondern ein Material ist. Auch halte ich es
   für schwierig, das abzugrenzen (alle Erstarrrungsgesteine sind im
   Prinzip Lava, oder?). Tendeziell wäre m.E. landcover=lava besser
   als natural, mit den vg. Einschränkungen.
 
  So ein ausgedehntes Lavafeld halte ich sehr wohl für ein
  geografisches Feature und landcover würde ich auch nicht für
  geologische Features verwenden wollen.
 
 Generell gilt denke ich beim Tagging: nur, weil es irgendwo etwas gibt, 
 das sich recht zweifelsfrei und sinnvoll mit einem bestimmten Tag 
 beschreiben ließe bedeutet das nicht, dass dieses Tag auch tatsächlich 
 nützlich ist.
 
 Wenn Du nämlich nicht irgendwelche willkürlichen Alters- oder 
 Größengrenzen ziehen möchtest würdest Du am Ende teilweise Gebiete von 
 Millionen Quadratkilometern Größe so taggen (z.B. weite Teile 
 Sibiriens).
 
 Ein erstarrter aber junger Lavastrom ließe sich schlicht und einfach als 
 natural=bare_rock, ggf. mit Zusatztags mappen.  Für ältere, bereits 
 bewachsene Lavaströme, wo man primär dann den Bewuchs mappt, würde sich 
 etwas wie geological=lava_flow anbieten.

Erstarrte Lavaströme unterscheiden sich recht stark von bare_rock und
unterteilen sich auch noch in weitere Untertypen. Die sichtbare Konsistenz 
variiert zwichen Lava-geröll und eben bare_rock. Trotzdem haben sie auch
Gemeinsamkeiten die ein zusammenfassendes Tag m.E. rechtfertigen. 

 Vergleichbares gilt denke ich auch für Krater - das ist im Allgemeinen 
 zunächst erst einmal natural=cliff|ridge.  Es gibt nämlich auch oft 
 Fälle in vulkanischen Gebieten, wo die Mechanismen der Entstehung 
 kraterförmiger Strukturen garnicht so eindeutig feststellbar sind.

+1

  Was macht man mit flüssigem Lava? Sind zum Teil richtige Flüsse die
  auch gemappt werden könnten, und z.T. unterirdisch (lava pipes).
 
 Ein noch flüssiger Lavastrom lässt sich kaum sinnvoll mappen, da er 
 seine Form und Ausdehnung permanent ändert.  Das einzig sinnvolle 
 Mapping flüssiger Lava wäre bei Lavaseen - erfasst ist das wohl derzeit 
 nur beim Nyiragongo:

Ich kenne das Phänomen vom Kilauea, daß die Lavaströme zum Teil über
viele Jahre völlig stabil verlaufen, meist unterirdisch. Wenn sich mal
was ändert sind es meistwenige  Meter pro Monat.

Das ist dann sicherlich stabil genug um gemappt zu werden und auch 
sehr wichtig, als Toristenatraktion und Gefahrenstelle.

Sofern sich jemand darum kümmern will hätte ich auch nichts dagegen wenn 
auch Lavaströme gemappt werden die sich jeden Monat um einige Meter 
weiterschieben.

Richard


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


[Talk-de] Vulkane und natural=crater

2014-02-25 Diskussionsfäden Richard Z.
Hi,

in http://wiki.openstreetmap.org/wiki/DE:How_to_map_a steht was von
natural=crater.  Ich nehme an, damit sollte der Kraterrand gezeichnet 
werden? Im wiki finde ich leider keine Beschreibung.. kann sich jemand
erinnern? Ist schon einige male benutzt worden, aber keine Ahnung wo,
jedenfalls nicht auf der Etna, in Hawaii oder Japan.

Wäre das sinnvoll das so zu machen? Oder sollte man mit natural=cliff
bzw je nach Aussehen natural=ridge oder natural=arete arbeiten? 
Sollte man diese dann zusätzlich mit volcanic=yes o.Ä. taggen?

Es gibt auch noch natural=volcano, die Beschreibung möchte ich gern 
harmonisieren - wenn ich denn wüsste wie.
http://wiki.openstreetmap.org/wiki/Approved_features/Tag:natural%3Dvolcano

Richard

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


Re: [Talk-de] Vulkane und natural=crater

2014-02-25 Diskussionsfäden Richard Z.
On Tue, Feb 25, 2014 at 02:23:32PM +0100, Martin Koppenhoefer wrote:

 Natural=volcano ist m.E. ein allgemeiner tag für jegliche Art von Vulkan,

genaugenommen - laut dem verabschiedeten proposal - für die Vulkanmitte.
Das ist auch die größte Schwachstelle diese uralt-proposals, Kraterrand und
alles andere muß irgendwie anders gemappt werden.

 Was m.E. Sinn macht bei Kratern ist das taggen des Kraterrands (bisher 4x
 getaggt: natural=crater_rim) als lineares Feature (halte ich einerseits für
 signifikativ und andererseits für gut aus Luftbildern individuierbar,
 zumindest bei bestimmten Vulkantypen).

Kraterrand zu mappen find ich auch sehr wichtig. Wir haben bereits Tags die
das Aussehen sehr gut beschreiben können (natural=cliff,ridge), wäre die Frage
ob es nicht besser ist diese zu verwenden und eventuel mit zusätzlichen 
Attributen zu versehen. natural=crater_rim sagt erstmal gar nichts darüber
wie der Kraterrand aussieht und müsste dafür auch erstmal extra-attribute
spendiert bekommen.


  Evtl. wäre natural=crater dann
 entweder ein node oder eine area, die den gesamten Krater umschließt (d.h.
 ab da wo sich das Gelände erhebt) wenn man auch die sog. Kompressionszone
 (bei Atombombenexplosionen und Impakt-Kratern) miteinschließen will (ob das
 so sinnvoll ist, weiss ich nicht).

Wäre eine Idee. Es gibt auch natural=lava, laut wiki für schon erstarrtes aber
flüssiges/fliessendes könnte man noch ergänzen.
Eigentlich sollten Lavaströme auch noch eine Flußrichtung haben.

Richard

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


Re: [Talk-de] Vulkane und natural=crater

2014-02-25 Diskussionsfäden Richard Z.
On Tue, Feb 25, 2014 at 11:52:12AM +0100, ubahnverleih wrote:
 hiermit kannst du jedenfalls erst mal schauen wo es benutzt wurde: 
 http://overpass-turbo.eu/s/2Cq

autsch - da scheint jemand jeden einzelnen Bombeneinschlagkrater in der
Wüste von Nevada gemappt zu haben:(

Richard

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


Re: [Talk-de] Vulkane und natural=crater

2014-02-25 Diskussionsfäden Richard Z.
On Tue, Feb 25, 2014 at 04:03:12PM +0100, Martin Koppenhoefer wrote:
 Am 25. Februar 2014 15:54 schrieb Richard Z. ricoz@gmail.com:
 
  autsch - da scheint jemand jeden einzelnen Bombeneinschlagkrater in der
  Wüste von Nevada gemappt zu haben:(
 
 
 
 na und? Wieso :(  ? Sehe das Problem nicht, im Gegenteil. Dass Krater
 alleine nicht ausreicht, um nur Vulkane zu finden, war ja auch aus dieser
 Diskussion hier schon klar (Impakt- und Bombenkrater).

ich sehe das als nicht ganz ideal wenn Atombombencrater mit natural=crater
getaggt sind. Unter natural stelle ich mir anderes vor. Übrigens kennt das
deutsche Wiki auch man_made=crater, historic=bomb_crater und beides wäre
besser gewesen.

Richard

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


Re: [Talk-de] Vulkane und natural=crater

2014-02-25 Diskussionsfäden Richard Z.
On Tue, Feb 25, 2014 at 03:51:54PM +0100, Martin Koppenhoefer wrote:
 Am 25. Februar 2014 14:50 schrieb Richard Z. ricoz@gmail.com:
 
  Wäre eine Idee. Es gibt auch natural=lava, laut wiki für schon erstarrtes
  aber
  flüssiges/fliessendes könnte man noch ergänzen.
  Eigentlich sollten Lavaströme auch noch eine Flußrichtung haben.
 
 
 
 natural=lava halte ich weniger für einen guten tag, weil es kein
 geografisches Feature sondern ein Material ist. Auch halte ich es für
 schwierig, das abzugrenzen (alle Erstarrrungsgesteine sind im Prinzip Lava,
 oder?). Tendeziell wäre m.E. landcover=lava besser als natural, mit den vg.
 Einschränkungen.

So ein ausgedehntes Lavafeld halte ich sehr wohl für ein geografisches Feature
und landcover würde ich auch nicht für geologische Features verwenden wollen.

Was macht man mit flüssigem Lava? Sind zum Teil richtige Flüsse die auch 
gemappt werden könnten, und z.T. unterirdisch (lava pipes).

Übrigens, hat schon mal jemand an einem geologischen Schichtenmodell für OSM
getüftelt?


Richard

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


Re: [Talk-de] Vertikale/horizontale Linienbündel

2014-02-18 Diskussionsfäden Richard Z.
On Wed, Feb 12, 2014 at 11:57:13AM +0100, Wolfgang Hinsch wrote:

  Macht es Sinn, dafür eine Relation vbundle zu ersinnen?
  Damit könnte man zwar (zusätzlich zum layer) eine Lagebeziehung
  (über/unter) zwischen den einzelnen Strängen herstellen,
  müsste aber jeweils einen eigenen Streckenzug (way) erstellen.
  Bei Verfeinerungen ist so etwas anfällig. Das Rendern
  ist ohnehin problematisch.
 
 Ich würde den Bündel/Relationsansatz ganz schnell wieder vergessen. Für
 jede Etage/Höhenlage einen Layer vergeben und den Filter von JOSM
 benutzen. Damit kann man jederzeit einstellen, dass man nur die Objekte
 von Layer xx sehen will 
 (Filter hinzufügen
  Layer=3
  Filter invertieren)

für Etagen gibt es level, layer würde hier nicht funktionieren.

Wenn man sich die wikipage für level anschaut sind da auch einige Proposals
verlinkt die auch mit Relationen funktionieren.
Persönlich halte ich die Relationen für die meisten Situationen für
etwas zu kompliziert.

Richard

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


Re: [Talk-de] Luftbild-Versatz - Schachtdeckel

2014-02-11 Diskussionsfäden Richard Z.
On Tue, Feb 11, 2014 at 07:31:55AM +0100, bkmap wrote:
 Am 10.02.2014 21:14, schrieb Dirk Sohler:
  Markus schrieb:
  *lach* - und was bedeutetperfekt? ;-)
  
  Bei einem GPS-Empfänger mit ’nem Arsch voller Satelliten und mit RTCM
  bedeutet „perfekt“ eine Abweichung im Zentimeterbereich.
 
 Zentimeterbereich? Mal eine kleine Anmerkung: Wir verschieben uns mit
 ganz Europa jedes Jahr ca. 2,5 cm ;-)

das muß natürlich auch korrigiert werden:)

Gute Daten scheint es für viele Orte zu geben:
http://www.wanderreitkarte.de/forum/thread.php?board=4thema=4

wäre gut wenn sie auch genutzt würden.

Richard

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


Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-08 Diskussionsfäden Richard Z.
On Fri, Feb 07, 2014 at 02:34:58PM +, Sven Geggus wrote:
 hike39 ho...@hike.de wrote:
 
  Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
  OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert
  werden?
 
 Das Problem ist nicht die Onlinenutzung, das Problem ist der Massenhafte
 Kacheldownload, dennd er zerstört das Konzept des on demand rendering.

Wobei das on demand rendering für genau für die möglichen Anwendungen von
Locus usw völlig untauglich und unnötig ist. Meistens wollen die Leute
Touri-Karten die sie anderswo viel besser kriegen.

Es wird Zeit, daß die Vektor-basierten Karten mehr genutzt werden und 
on-demand nur da wo es wirklich sinnvoll ist.

Mapsforge, Navit, openandromaps.org, wanderreitkarte.de - wozu die ganze 
Mühe der Entwickler?

Richard

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


Re: [Talk-de] Luftbild-Versatz - Automatik

2014-02-06 Diskussionsfäden Richard Z.
On Thu, Feb 06, 2014 at 07:19:45AM +0100, Markus wrote:
 Hallo André,
 
 Dank Wochenrückblick ist Deine Versatz-DB wieder in Erinnerung gerückt:
 http://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
 
 Der entscheidende Schritt wäre m.E.,
 wenn jemand das *Plugin in JOSM als default* einpflegen könnte,
 und zwar so, dass es automatisch anspringt,
 und automatisch den optimalen Versatz anwendet,
 sobald jemand Bing als Hintergrundbild lädt.

ich habe inzwischen ein JOSM Ticket eröffnet, würde vorschlagen hier 
kommentieren und abstimmen:

https://josm.openstreetmap.de/ticket/9630


Richard

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


Re: [Talk-de] Luftbild-Versatz

2014-01-30 Diskussionsfäden Richard Z.
On Thu, Jan 30, 2014 at 12:29:45AM +0100, Garry wrote:
 Am 29.01.2014 11:52, schrieb Richard Z.:
 Flughäfen und Hubschrauberlandeplätze haben diverse Punkte mit genau 
 bekannter Position
 die sehr gut sichtbar sind - weiß jemand ob die Koordinaten Lizenrechtlich 
 unbedenklich
 wären?
 Für den Flughafenbereich mag das was bringen - ansonsten sollte man
 mindestens drei Punkte  mit möglichst großem Abstand im Umkreis von
 Größenordnung 100m haben um eine Aussage
 über die Qualität des  Luftbilds an der aktuellen Position treffen
 zu können.

im Flughafenbereich hat man genau das - idR sind von jeder Landebahn mehrere
Punkte ganz genau referenziert und auch gut von oben zu identifizieren. 
Leuchtfeuer 
gibt es auch, leider sind die Sat-bilder tagsüber gemacht aber das eine oder 
andere
kann man vielleicht trotzdem identifizieren.

Vielleicht haben wir Glück und viele Sportflugplätze geben uns die Daten
frei?

Richard

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


Re: [Talk-de] Luftbild-Versatz

2014-01-30 Diskussionsfäden Richard Z.
On Thu, Jan 30, 2014 at 11:16:55AM +0100, Martin Koppenhoefer wrote:
 Am 27. Januar 2014 18:46 schrieb Volker Schmidt vosc...@gmail.com:
 
  Offset ist nicht das einzige Problem mit Bing.
 
  Sobald das Gelaende huegelig wird, kommt auch ein nicht-uniformer
  Parallaxenfehler hinzu.
  Je steiler der Hang, desto groesser der Fehler, grob gesagt.
  Andere Luftbilder sind hauefig deutlich besser als Bing unter diesem
  Aspekt.
  Und wenn eine gerade Strasse ueber ein tieferes Tal fuehrt, wird sie bei
  Bing verbogen.
  Bing Bilder sind keine oder keine guten Orthofotos. Und dagegen hilft kein
  offset.

das JOSM plugin sieht anscheinend sogar die Möglichkeit komplexer 
Transformationen 
vor, es müßte nur jemand nutzen.

  Insbesondere im unebenen Gelände
 hat man schon auf sehr kurze Entfernungen (wenige Meter) Abweichungen des
 offset von einer Position zur anderen, denen man durch offset-Speichern und
 sharen nicht beikommen kann.

das ist in Extremfällen wirklich so.. ich habe auf Bing Bereiche gesehen wo
das Gelände offenbar fast Waagrecht fotografiert wurde und anhand eines
Geländemodells zum Bild von oben umgerechnet wurde. Aber auch in solchen Fällen 
sind die offsets besser als gar nichts.

Richard

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


Re: [Talk-de] Luftbild-Versatz

2014-01-29 Diskussionsfäden Richard Z.
Flughäfen und Hubschrauberlandeplätze haben diverse Punkte mit genau bekannter 
Position
die sehr gut sichtbar sind - weiß jemand ob die Koordinaten Lizenrechtlich 
unbedenklich 
wären?

Richard

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


Re: [Talk-de] Luftbild-Versatz

2014-01-28 Diskussionsfäden Richard Z.
On Tue, Jan 28, 2014 at 12:15:44PM +0100, Caronna wrote:

 Landvermessungspunkte? Stimmen zu 100% (fallls es 100% überhaupt in
 diesem Bereich gibt, schließlich wandert auch die Erdkruste)
 Triangulationspunkte gibt es überall, und nur die sind verläßlich -
 sollten also eingetragen werden (gibts dafür ein Tag?)

die Idee hatte ich auch schon, allerdings sind diese Punkte nicht immer
leicht zu erkennen in Luftbildern. Ein Tag habe ich im wiki auch nicht 
gefunden, wäre aber schnell gemacht.

In manchen Gebieten stehen echte otrhophotos zur Verfügung, z.B. Italien
oder Österreich (und damit auch Randbereiche von Bayern) - diese eignen sich 
recht gut um den Versatz von Bing auf ein erträgliches Maß zu korrigieren.

Ich wäre auf jeden Fall dafür, JOSM anzupassen damit der Durschnittsmapper 
auf das Problem zumindest aufmerksam gemacht wird, stelle ich mir etwa so vor:
Beim aktivieren von Imagery/Bing-ähnliche kommt ein Dialog 
möchten sie den Versatz 
  manuel korrigieren
  Korrekturfaktor aus der Datenbank downloaden
  jetzt ignorieren
  Dialog nie wieder anzeigen

Richard

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


Re: [Talk-de] Luftbild-Versatz

2014-01-28 Diskussionsfäden Richard Z.
On Tue, Jan 28, 2014 at 02:30:06PM +0100, Caronna wrote:
 Am 28.01.2014 12:44, schrieb Richard Z.:
 Ich wäre auf jeden Fall dafür, JOSM anzupassen damit der Durschnittsmapper
 auf das Problem zumindest aufmerksam gemacht wird, stelle ich mir etwa so 
 vor:
 Beim aktivieren von Imagery/Bing-ähnliche kommt ein Dialog
 möchten sie den Versatz
manuel korrigieren
Korrekturfaktor aus der Datenbank downloaden
jetzt ignorieren
Dialog nie wieder anzeigen
 
 
 bei mir gibts keine Daten :(
 
schnell mal anlegen :) Keine Angst wenn da immer noch 2-3 meter Fehler
drin wären, jeder der sie downloadet muß damit rechnen und kann neue
Daten hochladen.

Richard


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


Re: [Talk-de] Deutsche Ortsnamen in Osteuropa

2014-01-24 Diskussionsfäden Richard Z.
On Fri, Jan 24, 2014 at 06:23:56PM +0100, malenki wrote:
 On  21.01.2014 19:24, Alex Barth wrote:
 
  Hier sind drei entsprechende Veränderungen die ich in Gegenden die ich
  selbst kenne vorgenommen habe:
  
  ## Český Krumlov (Krumau)
  
  - http://www.openstreetmap.org/node/1599136536/history
  -
  http://openstreetmap.de/karte.html?zoom=13lat=48.80904lon=14.32547layers=B000TT
 
 Den name:de ein offenbar tschechischer Mapper eingetragen.

das wäre zwar politisch korrekt aber deswegen nicht unbedingt
qualifiziert, woher soll ein tschechischer Mapper wissen ob
sich ein nennenswerter Teil der Deutschen noch an diesen Namen 
erinnern.

Ich würde aber bei grenznahen Orten die nicht völlig unbedeutend 
sind name eher lassen und dazu zähle ich auch Český Krumlov.

Richard

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


Re: [Talk-de] Deutsche Ortsnamen in Osteuropa

2014-01-24 Diskussionsfäden Richard Z.
On Fri, Jan 24, 2014 at 07:38:49PM +0100, Mark Obrembalski wrote:
 On 24.01.2014 19:10, Richard Z. wrote:
 
 Den name:de ein offenbar tschechischer Mapper eingetragen.
 
 das wäre zwar politisch korrekt aber deswegen nicht unbedingt
 qualifiziert, woher soll ein tschechischer Mapper wissen ob
 sich ein nennenswerter Teil der Deutschen noch an diesen Namen
 erinnern.
 
 Vielleicht, weil er dort wohnt und ständig auf deutschsprachige
 (relevant sind ja nicht die Deutschen, sondern die Sprecher des
 Deutschen, Österreich ist da sowohl historisch als auch (in
 Südböhmen) vom Tourismus her eher bedeutender) Touristen trifft, die
 seine Stadt unter dem Namen kennen.

durchaus möglich, und in diesem Fall ist das Ergebnis auch richtig. 

Aber für die anderen 10-Tausende Orte in Osteuropa die auch einen
deutschen Namen haben wird das so nicht funktionieren.
Diese Einträge stammen aus irgendwelchen Listen bei Wikipedia wo es 
weitgehend irrelevant ist ob der Name heute noch gebräuchlich ist und 
oft auch ein halbes Dutzend Namen in lokalen Dialekten gelistet sind.

Wenn nun ein ukrainischer Mapper einen deutschen Namen den er bei
Wikipedia gefunden für ein 200-Seelen Ort irgendwo inmitten der Ukraine
einträgt wird das bei der Orientierung vor Ort selten hilfreich.

Richard

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


Re: [Talk-de] Deutsche Ortsnamen in Osteuropa

2014-01-23 Diskussionsfäden Richard Z.
On Wed, Jan 22, 2014 at 10:42:43PM +0100, Heinz-Jürgen Oertel wrote:
 Hallo,
 
 Am Mittwoch, 22. Januar 2014, 08:11:32 schrieb Alex Barth:
  Also im grossen und ganzen ist der Tenor der Kommentare so lassen wie's
  ist da eine Veraenderung nach allgemeinen Regeln zu Faellen fuehren wuerde
  in denen gebraeuchliche Namen entfernt wuerden.
 
 Und den allgemeinen Tenor finde ich auch richtig.
 
  Aber ist es nicht so, dass die jetzigen name:de Ortsnamen in
  Osteuropaeischen Laendern so anachronistisch wirken
 
 Ganz Osteuropa wurde jahrhundertelang von Deutschen besiedelt.

ja und ganz Sachsen und Mecklenburg war früher von Slawen besiedelt und 
lange davor von diversen anderen Völkern. Troztdem macht es keinen Sinn 
irgendwelche Namen zu verwenden die heute für den meisten Leuten 
unbekannt sind.


Richard

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


Re: [Talk-de] Deutsche Ortsnamen in Osteuropa

2014-01-23 Diskussionsfäden Richard Z.
On Thu, Jan 23, 2014 at 09:41:46AM +0100, tumsi wrote:

 Klar, in Fällen, in denen mittlerweile auch im deutschen ein anderer
 Name geläufig ist, sollte der alte deutsche Name mit old_name:de
 umgetaggt werden.

+1

Richard

---
Name and OpenPGP keys available from pgp key servers


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


Re: [Talk-de] Deutsche Ortsnamen in Osteuropa

2014-01-23 Diskussionsfäden Richard Z.
On Thu, Jan 23, 2014 at 01:32:48PM +0100, Martin Koppenhoefer wrote:

 
 es geht ja nicht um den name tag sondern um den Namen in einer anderen
 Sprache als der heute üblichen, und da macht es sehr viel Sinn, das zu
 taggen, da man damit Zugang zu älteren Karten erhält, den man sonst nicht
 hätte. Hier geht es ja nicht um prähistorische Zeit (wie überwiegend bei
 den Slawen in Deutschland), sondern um die letzten hundert Jahre, also eine
 Zeit, aus der es sogar noch Überlebende gibt. Wo es noch nennenswerte
 slawische Besiedlung in Deutschland gibt, sind auch deren Namen in
 Gebraucht (z.B. Sorben).

würde ich nicht an existierende Minderheiten festmachen wollen und auch nicht
an Jahrhunderten.

Sofern die Karten nützlich sein sollen geht es einfach darum wieviele Leute aus 
XX den Ort unter einem bestimmten Namen kennen. Für alles andere gibt es 
alt_name
oder old_name.

Es geht hier um 10-Tausende von meist kleinen Orten die ganz sicher einen 
deutschen 
namen haben. Bei 90% davon kann man davon ausgehen, daß nur ein verschwindend 
kleiner
Bruchteil der heutigen Bevölkerung diesen Namen kennt - nicht einmal ein 
nennesnwerter
Teil der Bevölkerung die den 2. Weltkrieg erlebt haben wird die jeweils gekannt 
haben.

Richard

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


Re: [Talk-de] Deutsche Ortsnamen in Osteuropa

2014-01-22 Diskussionsfäden Richard Z.
On Wed, Jan 22, 2014 at 11:03:11AM +, Sven Geggus wrote:
 Alex Barth a...@mapbox.com wrote:
 
  Ich würde gerne eine breit angelegte Aufräumaktion vorschlagen, bei der wir
  alle name:de keys in old_name:de verwandeln.
 
 Ehrlich gesagt finde ich das Problem nicht so leicht beantwortbar.

+1

 
 Es gibt durchaus Städte, bei denen im Deustchen Sprachgebrauch der deutsche
 name auch heute noch üblich ist. Bei Stettin zum Beispiel oder bei Sankt
 Petersburg.
 
 Würdest Du wirklich für die größeren Städte wie Kronstadt, Temeschburg oder
 Hermannstadt den deutschen Namen aus name:de löschen wollen?

auf old_name verschieben. Temeschburg klingt ohnehin nicht so deutsch. 
Herrmannstadt ist noch weitgehend gebräuchlich aber inzwischen fallen auch dort 
Turistenhorden ein die nicht die geringste Ahnung von der Geschichte haben.
Kronstadt... das war doch einmal? 

Ich will nicht Wikipedia bemühen nur weil ich die Sprache irrtümlich auf
Deutsch gestellt habe. Vor allem im Ausland nicht.

name:lc sollte m.E. für wirklich gängige Namen benutzt werden, andere old_name
oder alt_name.
* Rom, Mailand..
* fast jeder aus .lc weiß wo das ist (außer L.M. :)
* #1 bei google site:.lc

Es ist aber auch sehr wichtig, daß old_name, alt_name u.Ä. so gut wie möglich
unterstützt und ausgewertet werden.

Das Problem gibt es nicht nur bei lc=de, ich hatte neulich eine ähnliche Frage 
wegen hsb:Bamberg/Babin in der ml gestellt, hat sich dann so erledigt:

 http://www.openstreetmap.org/changeset/20043021


Richard


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


[Talk-de] JOSM upload: timeout und Unexpected precondition failed reply from server

2014-01-20 Diskussionsfäden Richard Z.
Hi,

ich habe hier relativ oft Probleme bei Uploads sehe das hier:


INFO: Test 'Untagged, empty and one node ways' completed in 95 ms
INFO: Test 'Opening hours syntax' completed in 2 ms
INFO: Test 'Turnrestrictions' completed in 0 ms
PUT http://api.openstreetmap.org/api/0.6/changeset/create... INFO: OK
POST http://api.openstreetmap.org/api/0.6/changeset/20101734/upload... INFO: 
GET http://api.openstreetmap.org/api/0.6/user/details
INFO: Read from server failed: Timeout
INFO: Waiting 10 seconds ... 
INFO: OK - trying again.
INFO: Starting retry 1 of 5.
POST http://api.openstreetmap.org/api/0.6/changeset/20101734/upload... INFO: 
Unexpected precondition failed reply from server
INFO: Waiting 10 seconds ... 
INFO: OK - trying again.
.
.
.

- alle 5 retries:( Dabei habe chunks auf 200 Objekte begrenzt und achte sowieso
daurauf nicht zu viel auf einmal upzuloaden.

Irgendeine Idee woran das liegt?

Richard


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


[Talk-de] DE:Tag:waterway=weir - Problem mit zweideutiger Übersetzung

2014-01-15 Diskussionsfäden Richard Z.
Hi,

mir ist jetzt schon ein paarmal aufgefallen, daß Mapper etwas mit
waterway=weir getaggt haben was ich eigentlich mit waterway=dam
mappen würde - weil (außer im Katastrophenfall) nie Wasser 
drüberfließt.

Habe nachgefragt - und es hat sich herausgestellt, daß die Deutsche 
Wikiseite ein kleines aber tückisches Missverständniß birgt:

https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dweir
https://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Dweir

Das Englische Water can still flow over the top, wird ins Deutsche 
übersetzt als Das Wasser kann durchaus weiterhin drüber hinweg fließen

Das Problem - so wie ich das lese ist die Intention der Englischen Seite 
eigentlich so etwas wie
im Unterschied zu einem Dam fließt das Wasser weiterhin regelmäßig über 
das Wehr.

Bei einem Damm würde das Wasser z.B. durch einen Tunnel abfließen oder über 
einen kleinen Wehr.

Das wird in der Deutschen Version nicht so ganz klar..

Wäre das eine gute Idee das im wiki so zu ändern?

Richard

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


Re: [Talk-de] DE:Tag:waterway=weir - Problem mit zweideutiger Übersetzung

2014-01-15 Diskussionsfäden Richard Z.
Hi,

ich fasse meine Antwort auf mehrere Beiträge hier zusammen.

  Warum nicht einfach noch ein paar Fotos als Beispiel mit auf die
  Wikiseite? Dann kann sich der Mapper schon das aussuchen was am besten zu
  seinem Bauwerk passt.
 

sowohl englische wie auch deutsche wikiSeiten auf OSM haben Fotos die
eigentlich nicht irreführend sind und vermutlich seit längerer Zeit
von den meisten Mappern als Orientierung verwendet werden:

https://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Dweir
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dweir

die anderen Beispiele die  gerbacht wurden:
- http://commons.wikimedia.org/wiki/File:Tainter_Gate.jpg
ist für mich ein Wehr, allerdings als Beispiel unnötig kompliziert. 
Genaugenommen ist das ein Bauwerk als mehreren Wehren und sonstigen 
Bauteilen.

- http://commons.wikimedia.org/wiki/File:Schweinfurt_Walzenwehr_1.jpg
wäre gut als Beispiel.

http://upload.wikimedia.org/wikipedia/de/8/89/Selbstgebauter_Staudamm.JPG
- würde ich nicht mappen.

http://de.wikipedia.org/wiki/Talsperre
Da sehe ich deutliche Unterschiede zur OSM Praxis. Eine Talsperre ist ein 
komplexes Bauwerk das oft aus mehreren Dämmen und Wehren besteht - und dem
zugehörigen Wasser.
Wir haben die Einzelelemente dam,weir,landuse=reservoir die wir zusammensetzen. 
Andererseits kümmert es uns kein bisschen ob ein Damm Teil einer Talsperre ist 
oder die Begrenzung von einem kanal, Schleuse oder sonstwas und ober höher als
5 m ist. Zumindest steht in unserer Definition nichts von 5 metern Höhe.

 sein können. Ob etwas ein Wehr oder Damm ist (bzw. als was die Kombination
 gilt), erkennt man normalerweise am Namen. Lasst uns lieber mal einen tag
 für die Fischtreppen erfinden, oder gibt es den schon?
 http://de.wikipedia.org/wiki/Fischweg

einen Fischweg haben wir natürlich schon:
https://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Dfish_pass

- ist bereits auf beiden wikiseiten vermerkt:)

Ob man den Unterschied am Namen erkennt ist fraglich, oft hat man komplexere 
Bauten die zwar einen Namen haben aber trotzdem viele Komponenten die einzeln 
gemappt werden sollten. Oft ist man im Ausland oder kennt den Namen nicht. 


Ich denke es ist besser zu versuchen sich genau an die Defintion in
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dweir zu halten.

Vergleiche mit
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddam
A dam normally does not have water flowing over the top of it.

Zusammenfassend - für mich ist das so:

Ein Damm ist so konstruiert oder beschaffen, daß in der Regel kein Wasser
drüberfließt - alles andere wäre bei einem Damm eine mittlere oder größere
Katastrophe. Dämme können man_made oder natürlich sein. Bin nicht sicher 
ob ein Biberdamm in die Kategorie beaver_made gehört?.

Ein Wehr ist so kontruiert, daß Wasser drüberfließen kann (und in der Regel 
tut es das auch zummindest regelmäßig). Ein Wehr ist per Definition immer 
man_made, ansonsten wäre es eher ein Wasserfall oder eine Stromschnelle.

Oft hat man komplexe Bauwerke mit einem Damm, und kleineren Abschnitt der 
als Wehr konstruiert ist (Notüberlauf usw).

Wenn das nicht so eindeutig ist sollten wir noch ein Paar Meinungen auf 
englischen Listen sammeln.


Richard


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


Re: [Talk-de] Bamberg = hsb:Babin?

2014-01-15 Diskussionsfäden Richard Z.
On Mon, Jan 13, 2014 at 10:00:29PM +0100, Richard Z. wrote:
 Hi,
 
 das hier ist mir neulich aufgefallen - 
   http://www.openstreetmap.org/node/1646638496/history

ein Update, einer der Mapper aus der Umgebung von Bamberg hat sich
erinnert und die Datenbank obersorbischer Exonyme gefunden:

http://www.serbski-institut.de/cms/os/396/Geografiske-mjena-hornjoserbsce/?dbsearchreq=dbsearchtype=2dbsearch=Bambergdbssearch=pytanje

Hier ist Babin als Alternativname aufgeführt.

Richard

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


[Talk-de] Bamberg = hsb:Babin?

2014-01-13 Diskussionsfäden Richard Z.
Hi,

das hier ist mir neulich aufgefallen - 
  http://www.openstreetmap.org/node/1646638496/history

als Obersorbischer name für Bamberg ist hier Babin eingetragen
was laut meinem Sprachgefühl und einem Online-Wörterbuch falsch
wäre. Babin hat laut Wörterbuch irgendwas mit Hebammen oder
alten Weibern zu tun. Bin trotzdem vorsichtig es so einfach
ohne Rückfrage zu löschen.

Die History ist leider wenig hilfreich weil der hsb:Babin anscheinend
vor der Lizenzänderung eingetragen wurde und damit nicht sichtbar ist 
wie es hingekommen ist:(

Kann sich jemand zufällig erinnern oder hat eine Idee?

Richard

---
Name and OpenPGP keys available from pgp key servers


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


Re: [Talk-de] JOSM mit BS Opensuse 13.1 -Zugriff auf Windows-Verzeichnis einer externer Festplatte mit USB-Anschluss

2014-01-12 Diskussionsfäden Richard Z.

On Sun, Jan 12, 2014 at 06:05:50PM +0100, Dieter Jasper wrote:

Hallo,
mit JOSM (latetest Vers. 6673) wird die externe Festplatte bei
'Datei öffnen' nicht angezeigt obwohl sie mit dem Dateimanager
Dolphin ausgewählt werden kann.
Wer kann helfen?


mit Dolphin auswählen heißt die Festplatte wird gemountet, vermutlich
ist JOSM nicht darauf programmiert nicht gemountete Datenträger anzuzeigen.

Entweder mit Dolphin auswählen, damit wird sie gemountet oder in kde 
system-settings removable devices die FP auf autmount ändern. Persönlich 
würde ich keine echte Festplatte automounten, mit USB/SD mag das noch 
vernünfitg sein aber bei Festplatten will ich schon genau wissen was sich

da im Hintergrund tut.


Richard


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


Re: [Talk-de] IPv6 defekt?

2014-01-10 Diskussionsfäden Richard Z.
On Fri, Jan 10, 2014 at 02:30:19PM +0100, Martin Koppenhoefer wrote:
 Am 10. Januar 2014 12:02 schrieb Sven Geggus li...@fuchsschwanzdomain.de:
 
  Das schlimmste was passieren kann ist doch, dass jemand böse Dinge unter
  fremder Identität tut, weil er vorher Logindaten abgeschnorchelt hat.

Was sollte eigentlich noch Schlimmeres passieren?
Böse emails unterr Deiner Identität schreiben oder Daten auf dem Server und 
im wiki unter Deiner Identität ändern kann schon für genug Ärger sorgen.


Richard

---
Name and OpenPGP keys available from pgp key servers


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


Re: [Talk-de] IPv6 defekt?

2014-01-10 Diskussionsfäden Richard Z.
On Fri, Jan 10, 2014 at 03:51:33PM +, Sven Geggus wrote:
 Richard Z. ricoz@gmail.com wrote:
 
  Was sollte eigentlich noch Schlimmeres passieren?
  Böse emails unterr Deiner Identität schreiben oder Daten auf dem Server und 
  im wiki unter Deiner Identität ändern kann schon für genug Ärger sorgen.
 
 Leute jetzt aber mal ehrlich, das ist doch eine eher theoretische Gefahr.
 
 Natürlich kann man auf dem Netzwerk das Passwort mitsniffen, aber für einen
 Angriff auf spezifische Menschen ist doch das völlig ungeeignet, wenn man
 nicht gerade die NSA ist.

Es muß hier nicht um einen gezielten Angriff auf einen spezifischen Menschen
gehen. Jemand will vielleicht Werbung ins OSM reinschmuggeln, eine Straße
die für Lärmbelestigung sorgt mit einem Fahrverbot belegen, Konkurenz von der
Landkarte verschwinden lassen - wenn man sich die Identität von einem bewährten 
Mapper ausborgt ist die Chance besser, daß es längere Zeit nicht auffällt.

Und es gibt noch andere mögliche Motive, ein Witzbold will die 
Indisch-Pakistanische Grenze verschieben oder ganz einfach OSM schädigen.

Praktische Durchführung ist trivial, die notwendigen Tools gibt es fertig
konfektioniert zum Download. In weiten Teilen der Welt sind fast alle Hotspots 
unverschlüsselt und wer hat sich da nicht schon mal eingeloggt? Das kuriose
- man braucht zwar oft ein Passwort um sich in so ein WIFI einzuloggen aber
sniffen kann man ohne.
Wie viele OSM Events benutzen eigentlich unverschlüsselte Hotspots und 
leicht anzuzapfende Ehternetkabel und Switches?

Richard


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


Re: [Talk-de] Schienenkreuze und Weichen

2013-12-30 Diskussionsfäden Richard Z.
On Mon, Dec 30, 2013 at 01:26:41PM +0100, Andreas Neumann wrote:
 Moin,
 
 Bei der Schienen ist mir ein kleines Dilemma aufgefallen. Beispiel an
 diesem Straßenbahn-Schienenkreuz http://osm.org/go/0MAe~EE4F
 
 Es sind in diesem Fall zwei Gleise mit Richtungsverkehr. Komme ich von
 norden und will nach Osten, befahre ich erstmal eine Weiche. An dieser
 Stelle sind die Schienen-Ways miteinander verbunden. Dann kreuze ich die
 Gegenspur. Und hier liegt mein Dilemma. Diese kreuzenden Wege sind meist
 auch verbunden. Wie kann man am dümmsten an solchen
 Schienenwegkreuzungen ohne Abbiegemöglichkeit sagen, dass man nur gerade
 aus kann.
 - Eine Lösung wäre jedesmal Abbiegerelationen anzulegen, was ich aber
 für zu kompliziert halte.
 - Möglichkeit zwei wäre, die sich kreuzenden Wege nicht mit einem Node
 zu verbinden. Dann könnte aber Nutzer XY kommen und den Node setzen.


 - Die dritte Möglichkeit sehe ich in einem Tag für den Node (hier wäre
 ich dankbar, wenn ein Eisenbahner vllt. einen Fachbegriffen fallen
 lassen könnte, da ich nicht weiß, wie die Kreuze im Fachjargon heißen.

ist denke ich die korrekteste Lösung und erreicht eine genauere Beschreibung 
der 
Kreuzung. Für mögliche Tag-namen siehe
 https://en.wikipedia.org/wiki/Level_junction
- diamond_crossing bietet sich an, auch wenn es nicht wirklich diamond-shape
ist wenn die Wege rechtwinklig sind.

Der Versuchung gleich noch double_slip und single_slip einzführen würde ich 
vorerst widerstehen, es ist wohl einfacher die extra Abbiegemöglichkeiten durch 
extra Verbindungen darzustellen.
Weichen könnte man eventuel mit einem railway_junction markieren, da gibt es
einige weitere mögliche routingrelevante Qualifier wie z.B. Rückfallweiche.

Richard

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