Re: [Talk-de] Kostenlose OSMF-Mitgliedschaft für Aktive - Craftmapper in die OSMF ;)

[mmd]

Am 20.08.20 um 10:17 schrieb Frederik Ramm:
> ist das Spezial-Formular für "Mapper mit mindestens 42 Mappingtagen im
> letzten Jahr". Details zum Programm hier:
> https://join.osmfoundation.org/active-contributor-membership -


Wie Martijn van Exel schon auf Twitter schrieb: "Perhaps the most
significant part of this story is the recognition of non-mapping
contributions to the project."

Also, ihr 0-Tage Mapper da draußen, für euch gibt's auch eine Option,
wenn ihr das Projekt auf andere Weise vorwärts gebracht habt:

https://join.osmfoundation.org/active-contributor-membership/application-form-for-active-contributor-membership-other/

-- 



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

Re: [Talk-de] OSM-Wiki wer ist der Admin

[mmd]

Am 10.10.19 um 17:04 schrieb Markus:
> Wer kann im OSM-Wiki die Erweiterung zur Darstellung von Formeln
> installieren?
> 

Bringe deinen Vorschlag am besten auf der Seite
https://wiki.openstreetmap.org/wiki/Talk:Wiki zunächst zur Diskussion
ein. Alles weitere ergibt sich dann.

-- 




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

Re: [Talk-de] Frage zu OSM-IDs

[mmd]

Am 10.10.19 um 14:52 schrieb Tom Pfeifer:
> Insbesondere wird ein Element nicht physisch gelöscht, sondern in seinem
> XML-Code das Attribut 'visible' auf 'false' gesetzt. Es wird quasi nur
> unsichtbar. Daher ist es möglich Löschungen rückgängig zu machen, also
> zu revertieren.
> 

Zu jedem Objekt gibt es auf der Datenbank einige Tabellen für die
aktuelle Version eines Objekts sowie separat davon Tabellen für
historische Objektversionen.

Beim Löschen eines Objekts werden abhängig vom Objekttyp nicht nur das
"visible" Flag auf "false" gesetzt, sondern zusätzlich auch seine Tags,
ggfs. auch Way oder Relation members gelöscht. Von dieser neuen
Objektversion wird zusätzlich eine Kopie in der Historie abgelegt.

Die Möglichkeit für einen Revert wird dadurch erreicht, dass man eine
ältere Objektversion von der API anfordert und dieses Objekt erneut mit
einer neuen (aktuellen) Versionsnummer hochlädt. Die API selbst hat
generell keine Information darüber, dass es sich um einen Revert handelt.

Redactions sind nochmal ein Sonderfall, da man hier einzelne historische
Objektversionen nicht mehr von der API abrufen kann und somit auch den
alten Stand nicht wiederherstellen kann.

-- 







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

Re: [Talk-de] Besorgt über den iD-Editor

[mmd]

Am 29.03.19 um 22:55 schrieb Christoph Hormann:
> On Friday 29 March 2019, mmd wrote:
>>

> Ich nehme jetzt mal an, dass das bedeuten soll, dass Quincy für Critigen 
> arbeitet.  

Ja, das ist die Einschätzung, zu der ich gelangt bin. Dieses Unternehmen
war auch im letzten Jahr auf der SotM US in Detroit mit einem Vortrag
vertreten, ist also zumindest im OSM Umfeld nicht gänzlich unbekannt:
https://2018.stateofthemap.us/program/the-map-quality-measurement-initiative-a-heat-map-approach-to-visualize-gaps-in-map-quality.html

> Das scheint ein IT-Consulting-Unternehmen zu sein 
> (https://www.critigen.com/) welches Quincy sicher nicht Vollzeit an iD 
> arbeiten lässt, weil OSM für sie Unternehmens-intern oder ihre 
> umfangreichen OSM-basierten Dienstleistungen, die sie auf ihrer 
> Webseite anbieten, so wichtig ist. ;-)

Ich denke, es ist klar, dass das Unternehmen einen recht ausgeprägten
GIS-Footprint hat und nicht nur "IT-Consulting" im klassischen Sinn macht.

> 
> Nein, es sollte für Jeden offensichtlich sein, dass Quincy das im Rahmen 
> eines Projektes für einen externen Geldgeber macht, der anonym bleiben 
> soll.

Das muss nicht unbedingt so sein, vielleicht sieht man OSM (neben den
ganzen ESRI-Themen) einfach als strategisch wichtig an und möchte sich
entsprechend positionieren. Q. arbeitet ja primär an UI/Usability
Themen, sowie dem Validator - alles Themen, die auch seit Jahren von der
Community stark nachgefragt werden.

> 
>>> Schon rein aus Sicherheits- und Haftungs-Überlegungen würde ich
>>> vorschlagen, die iD-Instanz auf osm.org umgehend auf die letzte
>>> Version zurückzusetzen, bevor diese Person commit-Rechte im
>>> iD-Repository erhalten hat.
>>
>> Ich wüsste nicht warum. Weder Quincy noch Bryan können den Code
>> direkt auf osm.org deployen. Jeder einzelne Pull Request hat eine
>> umfangreiche Dokumentation aller Änderungen, die sich jeder anschauen
>> und im Zweifelsfall entsprechend intervenieren kann.
> 
> Das kann jeder sehen, wie er möchte.  Wenn ich da in einer 
> Entscheidungs-Position in der OSMF wäre, wäre meine Frage:  Wer hat die 
> Verantwortung.  Die Sysadmins würden sich sicher sehr freuen, wenn sie 
> erfahren, dass sie das sind.  

Ich bin mir im Moment nicht einmal sicher, ob sich die OSMF mit der
Thematik überhaupt beschäftigt, und wenn ja, welche konkreten
Aktivitäten sich daraus ergeben würden.

> 
> Was glaubst Du wie groß das Geschrei wäre, wenn - rein theoretisch - 
> irgendwann herauskäme, dass das ein von der russischen/chinesischen 
> Regierung finanziertes Projekt bei Critigen ist...
> 

Interessante Vorstellung, für meinen Geschmack aber zu viel
Verschwörungstheorie ;)

-- 





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

Re: [Talk-de] Besorgt über den iD-Editor

[mmd]

Am 29.03.19 um 23:36 schrieb Simon Poole:
> 
> Die Transparenz besteht wohl mehr darin, dass es klar ist das kein
> Dritter (der nicht Vollzeit daran arbeitet), auch nur einen Hauch einer
> Chance hat die Änderungen nachzuvollziehen, siehe
> https://github.com/openstreetmap/iD/compare/v2.14.3...master (348
> commits seit dem letzten Release im Februar).
> 

Gut, eine typische Vorgehensweise wäre, sich in der überaus
detaillierten Übersicht, die ich eingangs verlinkt hatte, zunächst einen
Überblick zu verschaffen und dann ganz gezielt in einzelne Pull Requests
zu verzweigen, für die man sich interessiert. Dort finden sich alle
Diskussionen zum Thema, so dass man das ganze auch sinnvoll im Kontext
einordnen kann und mehr über die Motivation der Änderung erfahren kann.
Meistens finden sich dort auch erklärende Bilder oder Animationen. Dass
eine Liste aller Commits ohne weitere Infos unhandlich ist, möchte ich
gar nicht in Abrede stellen.

Alle Änderungen werden auch permanent auf
http://preview.ideditor.com/master/ veröffentlicht (also mehrere Wochen
bevor sie auf osm.org landen), so dass jeder die Möglichkeit hat, früh
Rückmeldung zu geben.

Als kleiner Trost: die Tage hatte ich im Slack #id Channel gelesen, dass
2.15 die letzte Version für den Moment wird. Danach wird es größere
Umbauten geben, die mehrere Monate andauern werden und dann als neue
Version 3 veröffentlicht werden (Link:
https://osmus.slack.com/archives/CBK3JLUJU/p1553791249003600)

-- 



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

Re: [Talk-de] Besorgt über den iD-Editor

[mmd]

Am 29.03.19 um 21:13 schrieb Christoph Hormann:
> Insbesondere die Tatsache, 
> dass da jemand das Projekt mit leitet, der für diese Arbeit von 
> jemandem anonym bezahlt wird, geht meiner Meinung nach überhaupt nicht.  

Frederik hatte das ohne weitere Belege in den Raum geworfen, allerdings
hat Quincy das sehr wohl in seinem LinkedIn-Profil aufgeführt. Umgekehrt
gilt das auch: https://twitter.com/osmquality

> Schon rein aus Sicherheits- und Haftungs-Überlegungen würde ich 
> vorschlagen, die iD-Instanz auf osm.org umgehend auf die letzte Version 
> zurückzusetzen, bevor diese Person commit-Rechte im iD-Repository 
> erhalten hat.

Ich wüsste nicht warum. Weder Quincy noch Bryan können den Code direkt
auf osm.org deployen. Jeder einzelne Pull Request hat eine umfangreiche
Dokumentation aller Änderungen, die sich jeder anschauen und im
Zweifelsfall entsprechend intervenieren kann. Mehr Transparenz geht nicht.

Beispiel: https://github.com/openstreetmap/openstreetmap-website/pull/2159


-- 



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

Re: [Talk-de] Straßensuche auf openstreetmap.org

[mmd]

Am 19.01.19 um 09:36 schrieb Sarah Hoffmann:
> Hallo,
> 
> On Sat, Jan 19, 2019 at 08:32:33AM +0100, Martin Trautmann wrote:
>> welche bessere Suchmethode empfehlt ihr, als direkt auf
>> openstreetmap.org ins Suchfeld den Straßennamen einzugeben?
>>
>> Konkret suche ich jede Dorfstraße in der Gemeinde Mansfeld.
>>
>> Schafft ihr es, alle zehn (oder mehr) zu finden, dazu noch die vordere,
>> hintere, obere und untere?
> 
> Für Anfragen der Art "Finde mir alle..." eignet sich Overpass
> im Allgemeinen besser. Hier ist, was ich mal auf die schnelle
> mit Overpass Turbo zusammenklicken konnte:
> 
> https://overpass-turbo.eu/s/FlF
> 

Groß-/Kleinschreibung ignorieren liefert noch ein paar weitere Treffer:
https://overpass-turbo.eu/s/FlL

-- 




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

Re: [Talk-de] Hat der Renderer Probleme?

[mmd]

Am 04.01.19 um 11:48 schrieb Manuel Reimer:

> 
> Ich habe gestern am Nachmittag einige Änderungen gemacht und einige
> davon sind bis heute nicht gerendert.
> 
> Das ging in der Vergangenheit definitiv mal schneller...
> 
> Wird aktuell besonders viel gemappt oder hat der Renderer ein Problem?
> 

Das ist ein bekanntes Problem an der Rendering-Infrastruktur, an dem die
Sysadmins kontinuierlich arbeiten und Verbesserungen vornehmen.

Wer sich für Details interessiert kann gerne das entsprechende
Operations Ticket verfolgen:
https://github.com/openstreetmap/operations/issues/257

Mehr Infos als das was dort steht habe ich auch nicht ;)

-- 



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

Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung

[mmd]

Am 25.12.18 um 16:55 schrieb sepp1...@posteo.de:
> 
> Dank Andreas und mmd habe ich Karten gefunden, die das darstellen -
> unkompliziert und ohne Theater - das wären m.M.n. brauchbare Vorbilder
> für zukünftige Antworten von Dir?!

Kurzer Hinweis in eigener Sache: ich bin nicht damit einverstanden, dass
meine Beiträge hier dazu benutzt werden, anderen Beitragenden eine
bestimmte Form der Kommunikation nahezulegen oder in diesem Zusammenhang
als Vorbild genannt werden. Bitte in Zukunft davon Abstand nehmen. Danke.

-- 


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

Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung

[mmd]

Am 25.12.18 um 15:21 schrieb Andreas Frey:
> Hallo Sepp, 
> falls Du eine spezialisierte Karte mit Höhenbeschränkungen benötigst könnte 
> ich Dir http://maperitive.net  empfehlen. Das läuft 
> auf dem PC und Du kannst dir Deine eigene frei konfigurierte Karte erstellen. 
> Es sollte ein leichtes sein Die von Dir gewünschten Höhenbeschränkungen damit 
> zu visualisieren. 
> 
> Grüße, 

Oder hier:
http://maxheight.bplaced.net/overpass/map.html?zoom=16=50.93688=6.96337=B000TFFF=T=line=70

FÜr Garmin gibt's noch:
https://wiki.openstreetmap.org/wiki/OSM_Transport_Karte

-- 



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

Re: [Talk-de] Gutachten [war: Re: POIs - Details - Gerichtsurteil ]

[mmd]

Am 09.11.18 um 09:23 schrieb sepp1...@posteo.de:
> Bspw. dieses Gremium im Rahmen einer Positionierung zur Umsetzung und
> Anwendung der OSM-Grundsätze und letztendlich FOSSGIS als Betreiber und
> rechtlich Verantwortlicher.
> 

Da dieser Punkt schon mehrfach von dir in diesem Faden angesprochen
wurde, würde mich mal interessieren, wie du zu dieser Einschätzung
kommst, dass FOSSGIS hier als Betreiber und rechtlich Verantwortlicher
zuständig wäre. Dir ist schon klar, dass OSMF und FOSSGIS e.V. (in der
Rolle als "OSMF - Local Chapter Germany") verschiedene Dinge sind?


-- 




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

Re: [Talk-de] Wiki-Eintrag falsch?

[mmd]

Moin

Am 06.10.2018 um 07:45 schrieb sepp1...@posteo.de:

> Aufgrund einer Vielzahl von alten Brückenbögen sind an diesen oft
> mehrere Angaben zur Höhe zu finden, auch durch Z 265. So stehen an den
> Bogenrändern im Lot über dem Fahrbahnrand oft deutlich geringere
> Angaben, als in der Fahrbahnmitte. Vllt. sollte der Wert maxheight:
> mehrfach für ein Objekt erfassbar sein, maxheight:*, maxheight_1:* oder
> besser noch maxheigth_left:/_right:/_center: in Abhängigkeit zum
> gezeichneten Straßenrichtungsverlauf? Damit ließen sich auch Brücken
> schräg zum darunter liegenden Fahrbahnniveau eindeutig mit Höhenangaben
> versehen, das wäre gerade für die gebirgigen Regionen sicher hoch
> interessant, auch auf internationaler Ebene? So wären auch alte
> Tunnelröhren sehr gut für den Verkehr darstellbar.
> 

Das Thema maxheight wurde übrigens vor Jahren bereits ausgiebigst im
Forum diskutiert. Es gibt sogar eine Karte, die sich mit dem Thema
beschäftigt (räusper). Vielleicht schaust du auch mal in die alte
Diskussion rein:

https://forum.openstreetmap.org/viewtopic.php?pid=300099#p300099

-- 




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

Re: [Talk-de] kleine Hilfestellung zu Overpass turbo

[mmd]

Am 26.07.2018 um 16:45 schrieb Kevin Hemker:
> Gibt es eine Möglichkeit da dran zu kommen?

In der Regel hat ein Gebäude keinen Namen, also gibt es keine passende
Area auf dem Overpass Server dazu. D.h. momentan geht das leider nicht
mit einer Punkt-in-Area Abfrage. Möglicherweise wird sich das in der
Zukunft noch ändern.

Es steht dir natürlich frei, eine eigene Overpass Instanz aufzusetzen
und dort die Area Creation Regeln entsprechend deiner Anforderungen
anzupassen.

-- 


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

Re: [Talk-de] Bug openstreetmap.org routing. Wer kann verifizieren? Wo melden?

[mmd]

Am 01.07.2018 um 16:59 schrieb Manuel Reimer:
> Hallo,
> [... Probleme mit Routing ...] 
> 
> Kann das jemand bestätigen? Ist das bekannt? Wo kann man das melden?
> 


Das ist ein bekanntes Problem, ich hatte vor ein paar Wochen schon ein
Issue dazu aufgemacht:
https://github.com/openstreetmap/openstreetmap-website/issues/1874


-- 



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

Re: [Talk-de] Overpass-Integration meldet seit kurzem "Bad-Request" ohne Code-Änderung

[mmd]

Am 06.05.2018 um 23:34 schrieb Max Berger:
> 
> Ich hatte heute das gleiche Problem. Bisher wurde das hier akzeptiert:
> 
>  [out:xml][timeout:3000];(node["mountain_pass"="yes"];
>  node["natural"="saddle"];node["natural"="notch"];
>  node["natural"="col"]);out body;>;out meta qt;
> 
> seit 3-7 Tage bekam ich einen Fehler 400 zurück. Lösung war
> ein zusätzlicher ";" hinter "col"] und vor der Klammer
> 
>  [out:xml][timeout:3000];(node["mountain_pass"="yes"];
>  node["natural"="saddle"];node["natural"="notch"];
>  node["natural"="col"];);out body;>;out meta qt;
> 
> Keine Ahnung, ob das schon immer falsch war und akzeptiert wurde,
> Gefunden habe ichs durch Vergleich mit dem Ergebnis des Wizards von
> Overpass Turbo.
> 

Siehe https://github.com/drolbr/Overpass-API/issues/480 : in der
Overpass QL Doku waren die Semikolons schon immer drin, sie wurden
allerdings vom Server bisher nicht ganz so streng kontrolliert. Das hat
sich mit dem neuen Release vor ein paar Tagen allerdings geändert.

-- 



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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 22.04.2018 um 07:30 schrieb "Christian Müller":

> 
>  Änderungen in diesen Kernbereichen laufen zum jetzigen Zeitpunkt stets gegen 
> die Macht der Gewohnheit und zahllose Abhängigkeiten "downstream" an, 
> weswegen Weiterentwicklungen in der API oder der DB-Objektlogik imho am 
> besten in neuen Projekten (Forks) aufgehoben sind.  Dieses Grundkonzept 
> node/way/relation ist in der jetzigen Form doch fast eine "heilige Kuh" und 
> der API-Versionsstand in der Kategorie "never change a running system" 
> (geworden), nicht?

Da bisher alle Forks grandios gescheitert sind, halte ich davon eher
wenig. Ich glaube, jeder teilt aber die Auffassung, dass eine Änderung
am Datenmodell generell eine Sachen von mehreren Jahren ist.

Als Vorteil sehe ich, dass eine Umstellung kein Big Bang sein muss. Es
wäre z.B. möglich, einen speziell aufbereiteten Planet zusätzlich
anzubieten und einzelne Tools schrittweise umzustellen (vor allem
Router/Renderer und ähnliches). Anpassung der Editoren wird ein extrem
spannendes Thema und irgendwann dann die Migration und Umstellung der
API - eben ein Projekt für mehrere Jahre.

-- 



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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 21.04.2018 um 23:20 schrieb Martin Koppenhoefer:
> 
>> On 21. Apr 2018, at 20:51, Christian Müller  wrote:
>>
>> Dennoch experimentierwürdig,

> finde ich unattraktiv, da ginge ja der topologische Zusammenhalt verloren, ob 
> es eine gemeinsame Grenze ist, oder ob die Grenze “zufällig” übereinstimmt, 
> dh. man müsste umständlich herausfinden, welche Grenzen jeweils 
> zusammengehören, für bestimmte Anwendungen (z.B. muss man beim Vereinfachen 
> von Grenzen nur jeweils eine Grenze vereinfachen für beide Nachbarn, würde 
> man jeweils die Grenze unabhängig vereinfachen würde sie danach nicht mehr 
> genau zusammenpassen). Das ist nicht nur irgendein Ausnahmefall sondern die 
> Grundlage für die Vektorkarten.
> 

Ihr müsst einfach mal schauen, welche Datenmengen dahinter stecken.
Momentan schleppen wir 4,4 Milliarden Nodes mit uns herum, davon 3,8
Milliarden Nodes, die nur in irgendwelchen Ways vorkommen, ohne
Verbindung zu anderen Ways und ohne eigene Tags. Die einzige
Nutzinformation ist hier die lat/lon-Information (Metadaten klammere ich
bewusst aus, da sie für Rendering oder Routing keine Rolle spielen).

Schieben wir diese Nodes als Koordinate in den Way und löschen die alten
Nodes, werden wir augenblicklich 85% der Nodes los. Das hat massive
Auswirkungen auf Hardwareanforderungen von Tools, die mit den Daten
arbeiten wollen.

Jedes Tool muss sich momentan einen riesigen Cache aufbauen, der zu der
Node Id die entsprechenden Koordinaten zurück liefert, damit überhaupt
klar ist, wie die Geometrie eines Ways aussieht.

Zum Thema topologischer Zusammenhalt: ich hatte eingangs ja schon
angesprochen, dass wir alternativ "Verbindungs"-knoten zu anderen Ways
weiterhin als Node behalten könnten, so dass überhaupt kein Unterschied
zum jetzigen topologischen Eigenschaften entsteht (wir nennen das
einfach mal "hybrides Modell"). Ebenso könnte sich in einem rein
"Koordinaten"-basierten Modell der Editor um solche Sachen kümmern
(Details offen).

Im schon mehrmals angesprochenen OSM Samstag Workshop wurde das
Topologiethema auch groß und breit diskutiert. Ich denke, da wird es in
der Zukunft wohl noch eine textbasierte Zusammenfassung geben, in der
die Vor/Nachteile der verschiedenen Optionen detailliert beschrieben werden.

-- 



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

[Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 21.04.2018 um 04:04 schrieb "Christian Müller":
>>> Wenn verklebt wird, dann wird x
>>> mal auf /die identen/ Knoten verwiesen, der Knoten (die Koordinate) aber
>>> nur exakt einmal gespeichert.  Geometrisch parallel geführte Linien
>>> erhöhen das Datenaufkommen (und den node-count in der DB) hingegen
>>> drastisch.
>> Das gilt aber auch nur für das aktuelle Datenmodell bzw. der zugehörigen
>> OSM API 0.6. Man kann sich ohne weiteres Alternativen vorstellen, in
>> denen der vermeintliche Vorteil durch Verkleben praktisch keine Rolle
>> mehr spielt, oder schlimmer noch, sich plötzlich ins Gegenteil verkehrt
>> und sogar mehr Platz benötigt.
> Das ist prinzipiell schon vorstellbar, allerdings wäre die Repräsentation
> in der Datenstruktur dann auch ähnlich, mit ähnlichen /Ungenauigkeiten/,
> da wird sich nichts plötzlich ins Gegenteil verkehren.

Mein Punkt bezog sich auf "Geometrisch parallel geführte Linien erhöhen
das Datenaufkommen (und den node-count in der DB) hingegen drastisch.".

Das hängt nun mal vom Datenmodell ab, und ja, es gibt da deutliche
Unterschiede. Daher an dieser Stelle nochmals der Verweis auf die
entsprechende Aufzeichnung vom OSM Samstag.

Soviel vorweg: sobald der "Node" nicht mehr als "Node", sondern nur noch
als Koordinate im Way existiert, bringt Verkleben keinen wirklichen
Vorteil mehr in Bezug auf den Node Count in der DB.

Verkleben wird dann wieder teurer, wenn ich gemeinsam genutzte
Koordinaten dann doch wieder als Node auspräge, um mit dem aktuellen
Modell "kompatibel" zu bleiben.

-- 





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

Re: [Talk-de] Autobahnkilometer.ch

[mmd]

Am 20.04.2018 um 20:23 schrieb Jochen Topf:
> On Fri, Apr 20, 2018 at 07:13:16PM +0200, dktue wrote:
>> ich möchte gerne in der Schweiz die Autobahn-Kilometer pflegen und habe
>> hierfür eine Seite mit Hilfe der Overpass-API erstellt [1] (lange
>> Ladedauer!).

Ich würde mal versuchen, die Autobahnen lokal zu cachen, die ändern sich
normalerweise nicht alle 3 Sekunden. Die Milestones benötigen dann noch
4s (auf Dev-server 1s), wäre also noch ok.

>>
>> Verwundert bin ich über die errechnete Gesamtlänge des Autobahnnetzes,
>> welche laut OSM-Daten derzeit 3817 km beträgt (entspricht ungefähr 1909km
>> bei einfacher Zählung beider Fahrtrichtungen) laut offiziellen Daten jedoch
>> nur 1447 km [3]. Kann jemand diese Differenz von rund 500 km erklären?
> 
> Ich hab das mal auf andere Weise nachvollzogen: Download der Schweiz von
> der Geofbarik, dann
> 
> (das ist ein Beispielprogramm was bei libosmium dabei ist)
> 
> ergibt:
> Length: 3069.67 km
> 

Zum Vergleich noch die Gesamtlänge mit Overpass (erst ab 0.7.55):

way(area:3600051701)[highway=motorway];
make stat num=count(ways),len=sum(length());
out;

Ergibt 3040,91 km und 6563 ways.

-- 




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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 08.04.2018 um 19:37 schrieb "Christian Müller":
>>> Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten,
>>> heute scheinbar nicht mehr so wichtig.
>> Das hat die Datenbank nie kleiner gemacht. Wenn du verklebst haben ALLE
>> Wege die zusätzlichen Knoten. Tausche Anzahl Knoten gegen Anzahl Knoten
>> je Weg. Vorher hatte ich 10 Knoten in 3 Wegen. Jetzt habe ich 30 Knoten,
>> 10 je Weg.
> Oh, das ist eine Milchmädchenrechnung:  Wenn verklebt wird, dann wird x
> mal auf /die identen/ Knoten verwiesen, der Knoten (die Koordinate) aber
> nur exakt einmal gespeichert.  Geometrisch parallel geführte Linien
> erhöhen das Datenaufkommen (und den node-count in der DB) hingegen
> drastisch.

Das gilt aber auch nur für das aktuelle Datenmodell bzw. der zugehörigen
OSM API 0.6. Man kann sich ohne weiteres Alternativen vorstellen, in
denen der vermeintliche Vorteil durch Verkleben praktisch keine Rolle
mehr spielt, oder schlimmer noch, sich plötzlich ins Gegenteil verkehrt
und sogar mehr Platz benötigt.

Ich will das jetzt nicht weiter ausführen, der Thread ist eh schon viel
zu lang. Interessierte können sich gerne dazu die Aufzeichnung
"Evolution des OpenStreetMap-Datenmodells" vom OSM Samstag ansehen.

-- 












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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 05.04.2018 um 11:38 schrieb Florian Lohoff:

> On Wed, Apr 04, 2018 at 07:54:30PM +0200, Michael Reichert wrote:

>> Ich bin sehr daran interessiert, die Abstimmung mit den Füßen
>> auszuwerten, und würde mich freuen, wenn du deinen Code entweder mir zur
>> Verfügung stellen könntest oder gleich als freie Software
>> veröffentlichen könntest. Die Auswertung ist nicht ganz einfach, weil
>> man weder einfach die Objekte noch die Länge noch den Flächeninhalt
>> zählen muss, sondern auch beachten muss, wer was beigetragen hat.

> Was ich mache ist das ich mir für jeden node merke welche Wege attached
> sind. Dann gehe ich alle Wege durch (Nur die lines - also high und
> waterway) und gucke ob an 2 aufeinanderfolgenden nodes jeweils eine
> area mit derselben ID attached ist.

Netter Testfall. Ich habe mal versucht, das ganze soweit möglich mit
Turbo nachzustellen, allerdings mit der vereinfachten Annahme, dass ein
highway=* und landuse=* Way mindestens 2 gemeinsame Knoten haben müssen.
Das mit dem aufeinander folgend lässt sich leider nicht so recht abbilden.

Den Link zur Query habe ich auf folgende Github-Seite ausgelagert, weil
sich in diesem Medium nachträglich kein Post mehr ändern lässt.

https://github.com/drolbr/Overpass-API/issues/467#issuecomment-379536822

-- 





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

Re: [Talk-de] Go Map!! Fehler beim Hochladen

[mmd]

Am 10.03.2018 um 20:28 schrieb Simon Poole:
> 
> 
> Am 10.03.2018 um 19:15 schrieb mmd:
>>
>>> Ich geb zu, dass ich das nicht explizit getestet habe, aber mindestens die 
>>> Doku zu  if-unused hat keinen Bezug zu bereits gelöschten Objekten.
>>>
>> Auch richtig, die Doku ist da nicht ganz präzise, aber die
>> Implementierung ignoriert bereits gelöschte Objekte in diesem Fall und
>> gibt keine Fehlermeldung zurück, wenn ich das richtig interpretiert habe
>> (siehe lib/diff_reader.rb):
>>
>>   if action_attributes["if-unused"]
>> begin
>>   old.delete_with_history!(new, @changeset.user)
>> rescue OSM::APIAlreadyDeletedError, OSM::APIPreconditionFailedError
>>   xml_result["new_id"] = old.id.to_s
>>   xml_result["new_version"] = old.version.to_s
>> end
>>
> Seufzz, dann gilt aber das was ich gesagt habe vermutlich anders rum (es
> ist fast mit Sicherheit nie sinnvoll if-unused in einem interaktiven
> Editor zu setzen),

Dieses if-unused Attribut wurde ursprünglich 2010 implementiert und wird
seitdem in Potlatch 2, iD und möglicherweise auch in Potlatch 1 (?)
genutzt. Für JOSM gibt es ein entsprechendes Ticket, das aber nie
umgesetzt wurde.

https://github.com/openstreetmap/iD/issues/72 hat immerhin eine halbwegs
plausible Begründung, warum man sowas machen will. Es bleibt trotzdem
ein ziemlicher hack.


> denn Node
> 
> 5457758874
> 
> ist noch Mitglied in einem Weg, irgendwas ist also schief, und Gp Map!
> bekommt so keine Fehlermeldung beim hochladen..
> 

Go Map!! hat wohl die Implikationen des Flags nicht ganz korrekt
implementiert. Aus dem diffResult-Ergebnis der API sollte sich aber
zweifelsfrei ermitteln lassen, ob das Löschen geklappt hat oder nicht.
Nur über den Grund (Objekt ist schon gelöscht vs. Objekt wird noch
verwendet) schweigt sich die API aus.

-- 



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

Re: [Talk-de] Go Map!! Fehler beim Hochladen

[mmd]

Am 10.03.2018 um 19:05 schrieb Simon Poole:
> 
> 
> Am 10. März 2018 18:21:56 MEZ schrieb mmd <mmd@gmail.com>:
>> Am 10.03.2018 um 14:07 schrieb Simon Poole:
>>> Zuerst einmal: keine Panik! Leere Aenderungsätze sind unschön aber
>> kein
>>> Beinbruch.
>>
>> und obendrein ein bekanntes Problem:
>> https://github.com/bryceco/GoMap/issues/113
> 
> Das ist das Problem auf das sich der OP bezieht (die Changesets die er 
> erstellt hat).
>>

Ja, genau. Scheint wohl auch andere Nutzer zu betreffen (ich gehe mal
davon aus, dass Helmut nicht als User "mecaro" in Moskau zugange ist. ;)


>>>
>>
>> Das osmChange enthält ja explizit , also sollte
>> der API das völlig egal sein und kein Grund für mögliche
>> Fehlermeldungen
>> sein.
> 
> Ich geb zu, dass ich das nicht explizit getestet habe, aber mindestens die 
> Doku zu  if-unused hat keinen Bezug zu bereits gelöschten Objekten.
> 

Auch richtig, die Doku ist da nicht ganz präzise, aber die
Implementierung ignoriert bereits gelöschte Objekte in diesem Fall und
gibt keine Fehlermeldung zurück, wenn ich das richtig interpretiert habe
(siehe lib/diff_reader.rb):

  if action_attributes["if-unused"]
begin
  old.delete_with_history!(new, @changeset.user)
rescue OSM::APIAlreadyDeletedError, OSM::APIPreconditionFailedError
  xml_result["new_id"] = old.id.to_s
  xml_result["new_version"] = old.version.to_s
end

-- 


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

Re: [Talk-de] Go Map!! Fehler beim Hochladen

[mmd]

Am 10.03.2018 um 14:07 schrieb Simon Poole:
> Zuerst einmal: keine Panik! Leere Aenderungsätze sind unschön aber kein
> Beinbruch.

und obendrin ein bekanntes Problem:
https://github.com/bryceco/GoMap/issues/113

> 
> Was auffällt ist das die Nodes
> 4281597139
> und
> 3314390157
> schon gelöscht sind.
> 

Das osmChange enthält ja explizit , also sollte
der API das völlig egal sein und kein Grund für mögliche Fehlermeldungen
sein.

Allerdings fehlt im osmChange die Changeset id, so dass das XML in
dieser Forum ungültig wäre und von der API abgewiesen würde.

Weil closed source wird dir hier niemand weiterhelfen können. Es bleibt
also nur, das Problem auf Github zu melden und zu hoffen, dass sich der
Autor des Tools irgendwann drum kümmert.

https://github.com/bryceco/GoMap/issues

-- 





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

Re: [Talk-de] Routenplanung mit osrm

[mmd]

Am 08.10.2017 um 15:37 schrieb chris66:
> Am 08.10.2017 um 15:22 schrieb Peter Pointner:
> 
>> derzeit nicht verfügbar ist, da der bislang dafür verwendete
>> OSRM-Demoserver ohne
>> Vorwarnung vom Netz genommen wurde."
> 
> Ja, daran liegt es wohl. Andere Frage ist, wieso der Link dann auf
> openstreetmap.org nicht temporär entfernt wird oder zumindest ein
> passender Hinweis eingeblendet wird.
> 

Diesen Vorschlag gab es auch schon hier:

https://github.com/openstreetmap/openstreetmap-website/pull/1637

Nur tut sich leider recht wenig in der Sache.

-- 




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

Re: [Talk-de] Overpass-Turbo rendert relations nicht korrekt

[mmd]

Am 23.09.2017 um 15:47 schrieb dktue:

> 
> ich habe ein Beispiel [1] gefunden bei dem Overpass anscheinend die
> Polygone, welche durch Grenz-Relations repräsentiert werden, nicht
> korrekt rendert.
> 

Vorab als Anmerkung: Fehlerberichte gehören in den zugehörigen Issue
Tracker, also in diesem Fall
https://github.com/tyrasd/overpass-turbo/issues bzw. besser noch
https://github.com/tyrasd/osmtogeojson/issues/

Da der Fehler nicht mehr auftritt, wenn nur noch Relationen ausgegeben
werden ( http://overpass-turbo.eu/s/rUM ), ist das wahrscheinlich das
gleiches Problem, welches hier schon bechrieben wurde:
https://github.com/tyrasd/osmtogeojson/issues/78

Unterdrückt man die doppelten Elemente, funktioniert die Darstellung
problemlos: http://overpass-turbo.eu/s/rUK

Also: bekanntes Problem.

-- 



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

Re: [Talk-de] landuse=residential an Node

[mmd]

Am 22.09.2017 um 22:28 schrieb mmd:
> Am 22.09.2017 um 22:03 schrieb dktue:
>>
>> Jetzt würde ich gerne nicht-geschlossene ways finden, an denen
>> landuse=residential getaggt ist -- kann mir jemand sagen, wie ich das
>> mit Overpass-Turbo bewerkstelligen kann?
>>
> 
> 
> Dieses Feature ist noch nicht offiziell freigegeben und kommt irgendwann
> mit der nächsten Version:
> 

ich sollte noch ergänzen, dass is_closed() momentan nur für ways
definiert ist. Nicht dass sich da jemand wundert, warum es mit
Relationen nicht funktioniert. Das ist durchaus so beabsichtigt.

-- 



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

Re: [Talk-de] landuse=residential an Node

[mmd]

Am 22.09.2017 um 22:03 schrieb dktue:
> 
> Jetzt würde ich gerne nicht-geschlossene ways finden, an denen
> landuse=residential getaggt ist -- kann mir jemand sagen, wie ich das
> mit Overpass-Turbo bewerkstelligen kann?
> 


Dieses Feature ist noch nicht offiziell freigegeben und kommt irgendwann
mit der nächsten Version:

http://overpass-turbo.eu/s/rTF


-- 



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

Re: [Talk-de] Relation zu Poly-File aus PBF

[mmd]

Am 02.09.2017 um 12:44 schrieb dktue:

> 
> Kennst jemand ein Werkzeug (oder eine Werkzeug-Kette), dass mir aus
> einer lokalen planet-PBF-Datei anhand der Relation-ID ein Poly-File
> schreibt, mit dem ich dann (mit Hilfe von osmconvert) die Regionen
> ausschneide?
> 

Osmium-Tool sollte das alles können, siehe Beispiel mit Paris und
Frankreich:
http://osmcode.org/osmium-tool/manual.html#creating-geographic-extracts


-- 


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

Re: [Talk-de] Adressen ohne Karlsruhe Schema in einer AssociatedStreet-Relation

[mmd]

Hallo,

Am 17.05.2017 um 18:33 schrieb dktue:

> 
> "Finde alle Häuser die in einer AssociatedSteet-Relation enthalten sind
> aber nicht zusätzlich nach Karlsruhe Schema getaggt wurden (in einem
> definierten Gebiet)."
> 

ich war mal so frei und habe "Karlsruher Schema" nur auf die Tags
addr:street und addr:housenumber bezogen - beide dürfen nicht am Haus
dran sein:

[bbox:{{bbox}}];
rel[type=associatedStreet];
way(r:"house")[building][!"addr:street"][!"addr:housenumber"];
out geom;


Als Tipp vielleicht noch: in der Overpass Beispielsammlung gibt es
einige weitere Beispiele für associatedStreet-Relationen:

https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example#Find_useless_associatedStreet-relations

hth

-- 



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

Re: [Talk-de] Overpass-API und Augmented-Diff-Files

[mmd]

Hi,

Am 26.11.2016 um 16:23 schrieb Pascal Neis:

> Am 26.11.16 um 10:47 schrieb mmd:
>>> Als File können diese nicht irgendwo abgerufen werden, oder?
>>
>> Augmented-diffs werden seit einiger Zeit immer nur on-the-fly erzeugt,
>> sind also nicht als File irgendwo abrufbar.
>>
>> Ich hatte mal vor einiger Zeit folgendes Script nach einer Diskussion
>> auf osm dev gebastelt ("OSM API lookups to complement minutely diffs?"
>> vom 15.09.2016). Vielleicht hilft das als Startpunkt:
> 
> danke für deine Antwort. So ähnlich mache ich das momentan bereits.

Ok, prima!

> 
> So richtig happy bin ich mit der Variante aber nicht. Ein File
> wäre deutlich schneller als jedes Mal auf die API zu warten bis
> sie das Diff erzeugt hat. Weiterhin würden dann hoffentlich auch
> keine 429er kommen. Aber ok, für meinen Workflow erstmal egal.
> 

Richtig toll skaliert der heutige Ansatz nicht. Aktuell konsumieren etwa
eine Hand voll Server regelmäßig Augmented diffs, und jeder einzelne
führt praktisch zur gleichen Zeit dieselbe Query aus. Letztlich liefert
aber jede Query idealerweise dasselbe Ergebnis, benötigt aber je nach
Fleiß der Mapper zwischen 5 und 30 Sekunden.

Ich habe mal ein Ticket dazu aufgemacht und einen anderen Ansatz
vorgeschlagen. Bitte entsprechend ergänzen ;)

https://github.com/drolbr/Overpass-API/issues/342

VG/mmd




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

Re: [Talk-de] Overpass-API und Augmented-Diff-Files

[mmd]

Hi,

Am 26.11.2016 um 09:22 schrieb Pascal Neis:

> 
> Arbeitet jemand von euch aktiv bei/an der Overpass-API?

Ja, kann man glaube ich sagen :)

> 
> Habe einen Prototypen für die Untersuchung von OSM Edits
> entwickelt, der u.a. die Augmented Diffs[1] verwendet.
> Leider habe ich mit dem abfragen der "Files" hin und wieder
> ein paar Probleme. Nutzt von euch noch jemand diese Diffs?
> Als File können diese nicht irgendwo abgerufen werden, oder?

Augmented-diffs werden seit einiger Zeit immer nur on-the-fly erzeugt,
sind also nicht als File irgendwo abrufbar.

Ich hatte mal vor einiger Zeit folgendes Script nach einer Diskussion
auf osm dev gebastelt ("OSM API lookups to complement minutely diffs?"
vom 15.09.2016). Vielleicht hilft das als Startpunkt:

http://wiki.openstreetmap.org/wiki/User:Mmd/Augmented_Diff

Besonderheit ist, dass die aktuelle Serverlast via /api/status
ausgewertet wird. Ist dein Quota durch zuviele / zu große Queries
ausgeschöpft, wird einfach eine gewisse Wartezeit eingelegt.

Roland hatte inzwischen das Format nochmal leicht geändert, u.a. mit
einer Information, wie lange ein Script warten muss, bevor weitere
Anfragen verarbeitet werden. Das ist im Script oben allerdings noch
nicht berücksichtigt.

> 
> Die API liefert mir ab und an einen 429er (Too Many Requests).
> Obwohl ich eigentlich nicht so viele Requests hintereinander sende.

Übrigens: es gibt auch eine dedizierte ML:
http://listes.openstreetmap.fr/wws/info/overpass


-- 






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

Re: [Talk-de] Renderfehler Chiemsee - Alz

[mmd]

Am 14.11.2016 um 10:20 schrieb hike39:
> Hallo zusammen,
> 
> gestern habe ich auf 'OSM deutscher Stil' einen Renderfehler bei
> Seebruck am Chiemsee entdeckt. Die Alz wird da beim Abfluss aus dem
> Chiemsee nicht als Fluß dargestellt.
> 
> Bei OSM Standard (Mapnik) ist alles in Ordnung.
> 
> Wen muss man dazu ansprechen?
> 

Das Thema wurde schon ausgiebig im Forum diskutiert:

https://forum.openstreetmap.org/viewtopic.php?id=56204

Beiträge #16, #22, #27 und #32 seien dem interessierten Leser
nahegelegt. Das oben genannte Problem findet sich in anderer Form in #32
wieder, die Ursache ist dieselbe.


-- 




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

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[mmd]

Am 19.06.2016 um 21:51 schrieb Michael Reichert:
> Hallo Sven,
> 
> Am 19.06.2016 um 18:05 schrieb Sven Geggus:
>> Ich lege schlichtweg Wert darauf, dass git blame auf den richtigen Menschen
>> zeigt.  Ist das so schwer zu verstehen?
> 
> Kennst du schon git commit --author "Joe Average "?
> 

In meinem Beispiel [1] ging es mir vor allem darum, dass Author und
Committer ohne weiteres auch 2 verschiedene Personen sein können, vor
allem beim cherry-picking.

Das sieht man z.B. über git log --pretty=full

commit f20766401b6375161691e3681eecbdaa8ec81f66
Author: Matt Heard 
Commit: Tom Hughes 

Fix broken link to Vagrant downloads page


Gisbert würde also weiterhin als Author für seine 3 Symbole geführt
werden und taucht so auch unter git blame auf. Mein User wäre dann
einfach nur der Committer.


[1] news://news.gmane.org:119/nk6hjt$ukp$1...@ger.gmane.org


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

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[mmd]

Am 19.06.2016 um 18:05 schrieb Sven Geggus:
> mmd <mmd@gmail.com> wrote:
> 
>> Dachte, ich mache mich hier etwas nützlich und stelle die Vorschläge von
>> Gisbert als Pull reqeust zur Verfügung, und dann sowas... Sorry, ich bin
>> hier raus.
> 
> Das sollte Dir aber schon klar sein, dass das keine Hilfe ist wenn Du
> anderen Dinge abnimmst die sie selber lernen sollten.

Ok, nachvollziehbar.

> 
> Ich lege schlichtweg Wert darauf, dass git blame auf den richtigen Menschen
> zeigt.  Ist das so schwer zu verstehen?
> 

Schau Dir mal bitte folgenden Commit an:

https://github.com/openstreetmap/openstreetmap-website/commit/f20766401b6375161691e3681eecbdaa8ec81f66

Dort hat TomH etwas stellvertretend für Matt Heard im Projekt OSM
Website committed.

Schauen wir doch mal weiter, was `git blame` für die Datei VAGRANT.md
liefert. Richtig, Zeile 11 stammt von Matt Heard, nicht jedoch von TomH,
der das ganze commited hat.

...
b460deae (Matt Amos  2014-03-08 10:45:51 + 10)
f2076640 (Matt Heard 2016-04-04 10:56:35 +1200 11) Installers are
available for Mac OS X and Windows, please see the [Vagrant project
download page](http://www.vagrantup.com/downloads.html) for more
information.
b460deae (Matt Amos  2014-03-08 10:45:51 + 12)
...


Alles gut.

--




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

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[mmd]

Am 19.06.2016 um 12:36 schrieb mmd:
> Am 19.06.2016 um 00:07 schrieb gmbo:
>> Am 18.06.2016 um 21:35 schrieb Sven Geggus:
>>>>> Habe heute morgen mal mit Incscape versucht die Waldsymbole zu
> 

>>
> 
> Kein Problem, ich hab die 3 Symbole aus deinen 3 Patches per
> Cherry-Picking rausgezogen und in einen neuen Pull request gepackt:
> 
> https://github.com/giggls/openstreetmap-carto-de/pull/2
> 
> Den müsste Sven nur noch commiten.
> 


Sven akzeptiert keine stellvertretenden Pull Requests, und hat diverse
weitere Anmerkungen.

Dachte, ich mache mich hier etwas nützlich und stelle die Vorschläge von
Gisbert als Pull reqeust zur Verfügung, und dann sowas... Sorry, ich bin
hier raus.

-- 




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

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[mmd]

Am 19.06.2016 um 00:07 schrieb gmbo:
> Am 18.06.2016 um 21:35 schrieb Sven Geggus:
>>> >Habe heute morgen mal mit Incscape versucht die Waldsymbole zu

>> So wird das ja dann nix mit nem pull request.
>>
>> Also meine Symbole, die ich schon immer im deutschen Stil verwende und
>> die
>> Christoph als das Comic Sans der Waldsymbole empfindet finden sich hier:
>> https://github.com/giggls/openstreetmap-carto-de/tree/master/symbols-de
> Genau dort habe ich Create new file gemacht, daraufhin hat Github das
> dann bei mir angelegt. Dort sind jetzt nur die 3 Files .
> Warum deine Sachen da nicht drin sind weiß ich nicht.

Ich denke, Du müsstest wohl einen Fork auf Basis von giggls' Branch
machen (also in Github einfach oben rechts auf "Fork" klicken, nachdem
Du den Branch von giggls' aufgerufen hast). Das Ergebnis sieht dann
ungefähr so aus:

https://github.com/mmd-osm/openstreetmap-carto-de/

(oben die Erklärung: forked from giggls/openstreetmap-carto-de)


> 
> Im Moment etwas ratlos, da wieder alles nur englisch erklärt ist und 
> ich damit leider Schwierigkeiten habe.
> 

Kein Problem, ich hab die 3 Symbole aus deinen 3 Patches per
Cherry-Picking rausgezogen und in einen neuen Pull request gepackt:

https://github.com/giggls/openstreetmap-carto-de/pull/2

Den müsste Sven nur noch commiten.

Haben wir hier jemanden, der das halbwegs auf deutsch erklären kann?
Wenn ich mir das hier so durchlese, ist das bestenfalls mittelmäßiges
Denglisch. :)

--




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

Re: [Talk-de] Überwachung von Edits eines Users

[mmd]

Hi,

Am 27.02.2016 um 10:24 schrieb Florian Lohoff:
> On Fri, Feb 26, 2016 at 10:40:05PM +0100, mmd wrote:
>> Hi,
>> Am 26.02.2016 um 09:23 schrieb Michael Reichert:
>>>
>>> Am 26.02.2016 um 08:50 schrieb Dietmar:
>>>> gibt es ein OSM-Tool, bei dem ich einen oder mehrere User angeben kann
>>>> und ich per Mail oder RSS oder sonstwie automatisch informiert werden
>>>> oder auf einem Blick sehen kann, ob die User in den letzten Minuten und
>>>> Stunden aktiv sind?
>>>
>>> Die Bearbeitungen eines bestimmten Users kannst du mit folgendem
>>> RSS-Feed überwachen. Früher, zu Zeiten der alten Website, war der auf
>>> Benutzerseite verlinkt, heute nicht mehr.
>>>
>>> https://www.openstreetmap.org/user/Nakaner/history
>>>
>>
>> Dieser Link führt irgendwie zur normalen OSM-Seite, zumindest kann
>> Firefox dort keinen RSS-Feed erkennen. Ich hätte hier eher so etwas
>> erwartet:
>>
>> http://www.openstreetmap.org/user/Nakaner/history/feed
> 
> Also ich hab sowohl Akregator und QuiteRSS unter Debian/GNU/Linux am
> laufen und die finden da beide einen feed 
> 

gerade nochmal nachgeschaut, in Firefox klappt das auch mit dem
ursprünglichen Link über "Lesezeichen -> Diese Seite abonnieren...".

Alles gut.

-- 



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

Re: [Talk-de] Überwachung von Edits eines Users

[mmd]

Hi,


Am 26.02.2016 um 09:23 schrieb Michael Reichert:
> 
> Am 26.02.2016 um 08:50 schrieb Dietmar:
>> gibt es ein OSM-Tool, bei dem ich einen oder mehrere User angeben kann
>> und ich per Mail oder RSS oder sonstwie automatisch informiert werden
>> oder auf einem Blick sehen kann, ob die User in den letzten Minuten und
>> Stunden aktiv sind?
> 
> Die Bearbeitungen eines bestimmten Users kannst du mit folgendem
> RSS-Feed überwachen. Früher, zu Zeiten der alten Website, war der auf
> Benutzerseite verlinkt, heute nicht mehr.
> 
> https://www.openstreetmap.org/user/Nakaner/history
> 

Dieser Link führt irgendwie zur normalen OSM-Seite, zumindest kann
Firefox dort keinen RSS-Feed erkennen. Ich hätte hier eher so etwas
erwartet:

http://www.openstreetmap.org/user/Nakaner/history/feed

Das war übrigens auch mal Thema im Forum:
http://forum.openstreetmap.org/viewtopic.php?id=25103

-- 





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

Re: [Talk-de] Leerungszeiten von Briefkästen auf deutschepost.de

[mmd]

Am 20.02.2016 um 14:30 schrieb Martin Koppenhoefer:
> 
> 
>> Am 20.02.2016 um 11:30 schrieb Frederik Ramm :
>>
>> Ferner sind selbst "redigierte" Informationen immer noch in unseren
>> historischen Planetfiles enthalten (nicht im aktuellen history planet,
>> aber in älteren Dateien, die eben vor der redaction erzeugt wurden). Wir
>> haben nicht die Technik und nicht den Willen, diese Daten rückwirkend
>> alle zu ändern, aber selbst wenn wir das täten, würden immer noch
>> Mirrors von diesen alten Daten herumschwirren (die dann anders wären als
>> unsere eigenen alten Daten).
> 
> 
> für diese Mirrors müsste man dann diffs herausgegeben und Ansagen machen, 
> dass folgende herausgegebene Dateien das Copyright von X verletzen und nicht 
> unter der ODbL genutzt werden können wenn man die diffs nicht einspielt ;-)
> 


Mit dieser Frage hatte ich mich vor einem Jahr am Rande beschäftigt,
u.a. weil die minutely diffs nichts von einer Redaction mitbekommen und
bestimmte Daten weiterhin in der Overpass API auftauchen.

Damals gab es jedenfalls noch keinen Service, der das "Schwärzen" der
Daten nach außen nachvollziehbar macht.

Hier noch das Ticket: https://github.com/drolbr/Overpass-API/issues/176

-- 




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

Re: [Talk-de] Overpass-Turbo

[mmd]

Hallo,

Am 08.12.2015 um 19:53 schrieb Thorsten Alge:
> Hallo Liste,
> 
> vorhin war Overpass-Turbo zeitweise nicht erreichbar. Das hat sich zwar
> erledigt, aber alle meine gespeicherten Abfragen sind dabei verloren
> gegangen. Weiß jemand, wie die genau gespeichert wurden und ob da noch
> eine Chance besteht, diese wiederherzustellen?

Für den Firefox wurde das neulich im Forum beschrieben:

http://forum.openstreetmap.org/viewtopic.php?id=32224

Vielleicht hilft's ja weiter...





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

Re: [Talk-de] Generierung von SVG mit mapweaver

[mmd]

Hallo,

Am 23.10.2015 um 19:41 schrieb Heinz-Jürgen Oertel:
> Hallo,
> 
> ich hoffe mal wieder auf Hilfe.
> Bei meiner Suche nach einem Tool um eigene Karten
> unter Linux zu erstellen
> bin ich auf Mapweaver von Gary68 gestoßen.
> Ich denke ich habe die aktuelle Version vom svn gezogen.
> 
> Einige Perl Module musste ich nachinstallieren.
> Meine Tests 
> erfolgen im Moment mit einem sehr einfachen style.txt.
> 

das Tool scheint seit etwa 3 Jahren verwaist zu sein, allerdings
funktioniert es hier immer noch unter Ubuntu 14.04, sofern man sich
genau an die Anleitung im Wiki hält [1]. Die "deprecated" Warnungen sind
wohl nicht so schlimm, jedenfalls habe ich diese nicht als
"Fehlermeldung" wahrgenommen. Ein Protokoll des Aufrufs findest Du
weiter unten in dieser Mail.

An der Stelle sei auch explizit die Frage erlaubt, warum Du nicht
einfach den "Teilen" Knopf auf osm.org nutzt und Dir direkt ein SVG
erzeugen lässt. Diese Funktion gab es m.W. vor drei Jahren noch nicht,
würde Dir wahrscheinlich das Leben deutlich einfacher machen.

Im Wiki sind noch ein paar andere Optionen für einen SVG-Export
aufgeführt: [2]. Mapweaver ist dort übrigens nicht mehr erwähnt.

Gruß,
mmd


[1] http://wiki.openstreetmap.org/wiki/Mapweaver
[2]
http://wiki.openstreetmap.org/wiki/SVG#Ways_to_create_an_SVG_map_from_OpenStreetMap


-- 

~/mapweaver$ perl mw.pl -overpass -place=Серпневе -near=Basarabeasca
-lonrad=30 -latrad=30 -size=4096 -ignorelabels
defined(@array) is deprecated at mwMap.pm line 519.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMap.pm line 527.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMap.pm line 536.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMap.pm line 546.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMap.pm line 555.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMulti.pm line 170.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMulti.pm line 171.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMulti.pm line 296.
(Maybe you should just omit the defined()?)

mapweaver 0.48 by gary68

reading config file mwconfig.ini
1 lines read.

reading rule file yourstyle.txt
rules read: 5 nodes, 16 ways, 20 areas, 2 routes and 0 configs

Send Query 1 to overpass server..
place Серпневе found:
lon= 29.0183844
lat= 46.3040235
Send Query 2 to overpass server..
reading osm file...
read: 202589 nodes, 18682 ways and 60 relations.

drawing nodes...
drawing ways/areas...
1380 areas drawn, 4586 omitted because they are too small
1317 area labels total, 1253 omitted because belonging areas were too small
placing way labels...
processing routes...
draw multipolygons...
13 multipolygon areas drawn, 12 not drawn because they were too small.
0 multipolygon labels drawn, 0 not drawn because belonging areas were
too small.
map (34.6 cm x 34.5 cm) fits paper A2


render time (excluding all file operations) 0 hours, 0 minutes and 3 seconds

mapweaver finished after 0 hours, 1 minutes and 26 seconds




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

Re: [Talk-de] Parkplätze Autobahnen ohne u. mit W C

[mmd]

Hallo,

Am 09.10.2015 um 20:14 schrieb Holger Jeromin:

> 
> Evtl sind die Toiletten einzeln und nicht als Attribut auf dem
>  Rastplatz getaggt. Das könnte ein pre preprocessing finden.
>  
> Rastplätze gibt's ja jetzt auch nicht soo viele. 
> 

dafür könnte ich folgende Query anbieten: http://overpass-turbo.eu/s/bVT

Gruß
mmd


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

Re: [Talk-de] Link-Sammlung für OSM-Stände auf Messen, Linuxtagen usw.

[mmd]

Hallo,

Am 14.09.2015 um 11:59 schrieb Michael Reichert:

> 
> Ich bin offen für Hinweise per Mail und habe auch schon per Mail und IRC
> einige erhalten. Schaut aber bitte auf dem unten stehenden Link vorbei,
> damit ich nicht denselben Hinweise mehrfach erhalte. ;-)
> 
>> Es wuerde jedenfalls schon einen gehoerigen Schritt weiter helfen,
>> wenn man die bookmarks.html nicht abspeichern muesste um sie zu
>> oeffnen, sondern wenn der Browser die Datei direkt als HTML rendern
>> wuerde. (Dazu koennte man das git-Repo regelmaessig auschecken und
>> die Datei bookmarks.html an einer merkbaren URL auf einem Webserver
>> ablegen. Falls das niemand von euch umsetzen will, werde ich das
>> selbst machen ... aber dann muss man sich halt nochmal einen neuen
>> Domainname merken.)
> 
> http://michreichert.de/projects/trade-fair-bookmark-collection/bookmarks.html
> 

richte doch einfach einen Branch "gh-pages" ein, dann kriegst Du das
Hosting direkt auf GitHub geschenkt und musst dich nie mehr um das
Updaten deiner Seite kümmern.

Hier mal ein Beispiel für mein geforktes Repository:

http://mmd-osm.github.io/trade-fair-bookmark-collection/bookmarks.html

Gruß,
mmd



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

Re: [Talk-de] Overpass-Turbo

[mmd]

Hallo Thorsten,

Am 25.05.2015 um 14:08 schrieb Thorsten Alge:

 Bei der Abfrage nach den selben Elementen in der Relation Galway erhalte
 ich aber alle Elemete. Auch jene, welche ein name:ga Tag haben. Ich
 verstehe allerdings nicht ganz warum.
 
 [out:json][timeout:25];
 area[name=Galway];
 (
   node(area)[place][name]-
   node(area)[name:ga]
 );
 out body;
 ;
 out skel qt;
 
 Kann mir Jemand einen Hinweis geben?
 

Gerne doch. Im Beispiel oben bezieht sich (area) jeweils auf das
Default-Inputset. Das ist einfach eine nicht näher benannten Menge, die
die gerade zu bearbeitenden Knoten, Wegen, Relationen sowie Areas enthält.

Ausgeschrieben würde das dann so aussehen:

   node(area._)[place][name]- (1)
   node(area._)[name:ga](2)

Schauen wir uns für beide Zeilen einmal an, was jeweils an Elementen als
Eingabe berücksichtigt wird und wie die Ergebnismenge aussieht:

Zeile (1)
-

 Input:  Area Galway, noch aus dem vorhergehenden area[name=Galway];

 Output: Nodes mit [place][name]. Die Area wird nicht übernommen!


(Output ist gleichzeitig Input für die nächste Zeile)


Zeile (2)
-

 Input:  Nodes mit [place][name]

 Output: Da in ._ keine Area enthalten ist, liefert (area._)
 eine leere Menge zurück!

Beheben lässt sich das ganze, indem man die ursprüngliche Area in eine
Variable packt (hier .a) und man sich später wieder darauf bezieht.

[out:json][timeout:25];
area[name=Galway]-.a;
(
  node(area.a)[place][name]; -
  node(area.a)[name:ga];
);
out body;
  ;
out skel qt;

Ich hoffe, das war soweit einigermaßen verständlich. Wenn nicht: ich
habe das Thema schon einmal vorsorglich für die neue Overpass API
Learning Platform vorgeschlagen, die im Rahmen des GSoc 2015 entsteht :)

Gruß,
mmd


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

Re: [Talk-de] Eigene OSM-Karte mit Overpass

[mmd]

Hallo Roland, Harald,

Am 11.05.2015 um 19:01 schrieb Roland Olbricht:
 Es sieht eher danach aus, als wenn Briefkästen dann nicht gefunden 
 werden. Es scheint mir beim Drüberschauen vielleicht doch ein
 Problem der briefkastenkarte.de zu sein, weil das Problem auf der
 Beispielseite des Leaflet-Plugins nicht auftritt.

Ich meine mich zu erinnern, dass diese Leaflet-Beispielseite noch auf
die rambler.ru-Instanz zugreift und dort diese Limitierung (noch)
nicht greift.


Am 11.05.2015 um 21:06 schrieb Harald Hartmann:
 danke für deine generelle Maßnahmen, werde davon sicherlich
 einige noch auf meiner Recycling-Map [1] einbauen, in der ich jetzt
 wie wild umeinander herscrollen musste um einen 429er zu
 provozieren.

Am einfachsten lässt sich der Unterschied z.B. mit Firebug in Firefox
(oder auch den Entwicklertools in Chrome) nachvollziehen: Während
deine Recycling-Karte für die BBox genau eine Abfrage absetzt, teilt
die Briefkastenkarte die BBox in viele kleine Unterabschnitte auf und
setzt für jeden dieser Abschnitte einen eigenen Request ab. Das meinte
ich eingangs mit fluten. Serialisieren würde hier bedeuten, immer
nur genau einen Request gleichzeitig abzusetzen.

 Ich glaube ich baue zusätzlich auch noch ein, dass man während
 eine Abfrage mit Sanduhr bis zum Timeout läuft auch das
 wegscrollen verbietet.

Alternativ wäre auch ein /api/kill_my_queries beim Scrollen der Seite
machbar. Dadurch werden noch ausstehende Queries auf dem Server
einfach abgebrochen.

Gruß,
mmd

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

Re: [Talk-de] Eigene OSM-Karte mit Overpass

[mmd]

Hallo,

Am 09.05.2015 um 22:13 schrieb Benjamin Grimm-Lebsanft:
 Hallo Markus,
 
 ist vielleicht die Briefkastenkarte sowas was du suchst:
 http://briefkastenkarte.de/
 
 Im Blog dazu gibt es auch eine gute Anleitung wie sie gemacht wurde:
 http://blog.briefkastenkarte.de/

leider kann ich diese Karte zur Zeit nur eingeschränkt weiterempfehlen,
da sie die Overpass API regelrecht mit Anfragen flutet.

Mit der neuen Quota-Regel für die Overpass API [2] werden inzwischen
auch etliche Abfragen mit einem Fehler abgewiesen (429 Too Many
Requests). Ob dadurch Briefkästen nicht angezeigt werden oder einfach
eine neue Abfrage abgesetzt wird, habe ich mir allerdings nicht mehr
genau angesehen.

Ich kann mir gut vorstellen, dass die Karte selbst unschuldig ist und
leaflet-layer-overpass [3] im Hintergrund für die vielen Abfragen sorgt.
Das müsste sich vielleicht jemand mal in Ruhe im Gesamtkontext zu Gemüte
führen. Ein Github-Ticket findet sich übrigens unter [1].

Ansonsten würde ich mir auch mal uMap ansehen, die lässt sich bestimmt
auch gut in andere Seiten einbetten.

Gruß,
mmd


[1] https://github.com/dbretschneider/briefkastenkarte.de/issues/8
[2] https://lists.openstreetmap.org/pipermail/talk/2015-April/072661.html
[3] https://github.com/kartenkarsten/leaflet-layer-overpass

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

[Talk-de] Overpass API: Link zur Beispielsammlung im Wiki

[mmd]

Hallo,

in Rolands Vortrag Schatzsuche in OSM [1] kam die Frage nach einer
Beispielsammlung für Overpass API-Abfragen auf.

Im Wiki gibt es dazu bereits eine recht umfassende, bisweilen etwas
unstrukturierte Sammlung [2], in der auch einiges an Beispielen von
stackoverflow, help osm und weiteren Seiten mit eingeflossen ist. Wenn ihr
noch mehr tolle Queries habt, bitte gerne ergänzen!

Übrigens: die neue Seite Overpass API by Example [3] sucht noch
Freiwillige für die Übersetzung.

Gruß,
mmd

[1] https://www.youtube.com/watch?v=VJItOHImN7A
[2] http://wiki.openstreetmap.org/wiki/DE:Overpass_API/Beispielsammlung
[3] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example



--
View this message in context: 
http://gis.19327.n5.nabble.com/Overpass-API-Link-zur-Beispielsammlung-im-Wiki-tp5837888.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] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source

[mmd]

Andreas Schmidt wrote
 also das Beispiel tüschenbroicher mühle kann ich per OSM finden.
 Haben die ARDler was falsch gemacht?

openrouteservice hat offenbar ein Problem mit Umlauten. Mit
Tueschenbroicher Muehle funktioniert die Suche.

Gruß,
mmd





--
View this message in context: 
http://gis.19327.n5.nabble.com/ARD-Ratgeber-Internet-Alternativen-zu-Google-Maps-Open-Source-tp5807193p5807233.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] Daten herunterladen in JOSM

[mmd]

Johannes wrote
 Am 17.04.2014 01:32, schrieb Paul Hartmann:
 Es werden dort allerdings nur TMS-Ebenen unterstützt (und kein WMS).
 
 D.h. die Tiles vom deutschen Stil kann man nicht in den Download-Dialog
 packen, richtig? Gruß Johannes

Doch, das sollte funktionieren. Ich verwende dafür folgende TMS-URL in JOSM
(eintragen unter WMS/TMS - TMS hinzufügen):

tms[18]:http://{switch:a,b,c,d}.tile.openstreetmap.de/tiles/osmde/{zoom}/{x}/{y}.png

Im Download-Dialog lässt sich dieser neue TMS-Layer anschließend auswählen.




--
View this message in context: 
http://gis.19327.n5.nabble.com/Daten-herunterladen-in-JOSM-tp5803437p5803476.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] Daten herunterladen in JOSM

[mmd]

dieterdreist wrote
 Am 17. April 2014 11:40 schrieb mmd lt;

 mmd.osm@

 gt;:
 
 Johannes wrote
  Am 17.04.2014 01:32, schrieb Paul Hartmann:
  Es werden dort allerdings nur TMS-Ebenen unterstützt (und kein WMS).
 
  D.h. die Tiles vom deutschen Stil kann man nicht in den Download-Dialog
  packen, richtig? Gruß Johannes

 Doch, das sollte funktionieren. 
 [...]
 Im Download-Dialog lässt sich dieser neue TMS-Layer anschließend
 auswählen.

 
 soweit ich das sehe ist der Layer bereits unter den voreingestellten, man
 muss ihn nur in den Presets aktivieren, hinzufügen braucht es nicht:
 http://josm.openstreetmap.de/wiki/Maps#OpenStreetMapGermanStyle

Da hast Du Recht. Ich hatte in der langen Liste nur mit dem Länderkenner
DE und Leer gesucht und den passenden Eintrag glatt übersehen. Dass sich
der Eintrag unter EU versteckt, hätte ich wirklich nicht erwartet.

Gruß,
mmd




--
View this message in context: 
http://gis.19327.n5.nabble.com/Daten-herunterladen-in-JOSM-tp5803437p5803504.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] maxheight=none

[mmd]

fly high wrote
 Im Unterschied zu maxspeed=none finde ich bei maxheight den Wert none
 nicht passend.
 
 Auf deutschen Straßen gibt es immer eine Höhenbeschränkung (gesetzlich
 geregelt), zu dem wird hier ein falsches Bild vermittelt.
 
 Ich weiß, dass hier nicht die physikalischen Werte sondern die
 gesetzlichen eingetragen werden.
 
 Ein Wert DE:law oder DE:legal würde meiner Ansicht besser passen.
 
 Wie seht Ihr das ?

Vor einiger Zeit hatte ich den aktuellen Diskussionsstand zu diesem Thema
auf Martin's Diskussionsseite festgehalten [1]. Folgeaktivitäten hatte es
damals m.W. nicht gegeben. Generell sehe ich aber schon die Notwendigkeit,
dieses Thema anzugehen, allein fehlt mir die Zeit für einen
Proposal-Prozess.

Übrigens: maxheight=none bzw. maxheight=default wird aktuell auch von der
OSM Truck QA Map [2] ausgewertet und soll Mappern helfen, noch fehlende
maxheight Tags in den OSM Daten zu finden.

Gruß,
mmd

Links:
[1] http://wiki.openstreetmap.org/wiki/User_talk:Dieterdreist#maxheight
[2] http://maxheight.bplaced.net/overpass/map.html





--
View this message in context: 
http://gis.19327.n5.nabble.com/maxheight-none-tp5801650p5801663.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] QLandkarteGT

[mmd]

Kurzes follow-up: Oliver hat in einem Post [1] recht ausführlich seine
Motivation und Hintergründe der Entscheidung dargestellt, warum er generell
keinen User Agent übertragen möchte, der ihn als QLandkarte GT
identifizierbar macht.

Gruß,
mmd

[1] http://sourceforge.net/p/qlandkartegt/mailman/message/32012564/



--
View this message in context: 
http://gis.19327.n5.nabble.com/QLandkarteGT-tp5796659p5798024.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] Start von JOSM

[mmd]

Chris66 wrote
 Mit javaws (Java webstart) startet man normalerweise Java Applets.
 
 Da JOSM eine eigenständige Java Applikation ist empfiehlt sich da eher
 die manuelle Startmethode.

Java Webstart ist primär für Java Applikationen gedacht [1]. Applets laufen
direkt im Browser, unterstützt durch entsprechende Plugins, jedoch ohne Java
WebStart-Beteiligung. JOSM per Webstart laufen zu lassen passt eigentlich
schon ganz gut; JOSM wird so immer automatisch aktuell gehalten. Für einen
größeren Speicher findet sich unter [2] eine kleine Anleitung. Damit sollte
der OutOfMemory-Fehler nicht mehr auftreten.

Übrigens: im gleichen Thread sind auch unzählige andere Varianten zu finden,
wie JOSM automatisch aktuell gehalten werden kann.


[1] http://www.java.com/en/download/faq/java_webstart.xml
[2] http://forum.openstreetmap.org/viewtopic.php?pid=239145#p239145




--
View this message in context: 
http://gis.19327.n5.nabble.com/Start-von-JOSM-tp5793463p5793576.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] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)

[mmd]

Hallo,

vor etwa 1,5 Jahren hatte ich diese Idee schon einmal im Forum als
Proof-of-Concept vorgestellt. Den Ansatz finde ich nach wie vor gut und
interessant, allerdings ist die technische Umsetzung nicht gerade trivial,
da man sich z.B. dediziert um das Splitten der Wege kümmern muss. 

Leider gibt es das passende Video nicht mehr. Es war mal eine angepasste
OSRM-Seite mit einem Button Route erstellen. Im Hintergrund lief eine
modifizierte OSRM-Instanz mit aktueller Datenbasis. Neue Relationen wurden
direkt per Javascript erzeugt (ok, es war ein Proof of concept).

In der Zwischenzeit wurde die im Video live erzeugte Relation wieder
gelöscht, der im folgenden Forum-Thread genannte Changeset existiert
zumindest noch. Auch einige Kommentare anderer Mapper zum Ansatz Relationen
per OSRM erzeugen sind evtl. interessant.

http://forum.openstreetmap.org/viewtopic.php?id=17011

Aus Zeitmangel hatte ich die Idee damals nicht weiter verfolgt.

Gruß,
mmd



--
View this message in context: 
http://gis.19327.n5.nabble.com/Routenplaner-OSRM-als-OPNV-Editor-der-Weisheit-letzter-Schluss-tp5790487p5790489.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] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)

[mmd]

Hallo,

ja, genau, den Ansatz hatte ich auch genutzt, allerdings gab es damals noch
keine Lua-Anbindung, daher musste es eine C++ Anpassung sein (siehe
http://wiki.openstreetmap.org/wiki/User:Mmd/RelationDemo). Heute würde ich
das auch per Lua machen. Die zusätzlichen Infos wie die Way-Id blähen die
OSRM-DB zwar etwas auf, aber dafür kann man mit dem Ergebnis recht gut
weiterarbeiten.

Ich hatte damals an eine reine Web-Anwendung gedacht, mit der man neben
neuen Relationen auch existierende Relationen einfach durch Drag-und-Drop
anpassen kann. Also genau so, wie man heute auf osrm.at eine Route mit
Start/Ziel und Zwischenpunkten zusammenbaut. Passt das Ergebnis, sollte
automatisch die Relation in der OSM-DB aktualisiert werden können. Alle
Split-Operationen (die Du wie geschrieben in JOSM händisch machen würdest)
würden dann automatisch im Hintergrund erfolgen.

Für den Update-Fall müsste man zunächst aus den bestehenden Wegen in der
Relation eine möglichst minimale Menge an Zwischenpunkten generieren, so
dass OSRM wieder ein Routingergebnis entsprechend der Relation erzeugt
(sofern dies überhaupt noch möglich ist).

Gruß,
mmd





--
View this message in context: 
http://gis.19327.n5.nabble.com/Routenplaner-OSRM-als-OPNV-Editor-der-Weisheit-letzter-Schluss-tp5790487p5790516.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