Re: [Talk-de] Offizieller Satz von OSM Diensten
Hallo Kai. Am 22.09.2011 02:09, schrieb Kai Krueger: > Eine Demonstrationsseite mit dem Aktuellen Stand findet man im uebrigen > unter http://openstreetbugs.dev.openstreetmap.org/ Danke für das Feedback. Wo wäre der geeignete Ort um Kommentare und Anregungen zu dieser Zwischenversion abzuladen? :) Gruß, Bernd -- Ein Finanzgenie ist ein Mann, der sein Geld schneller verdient, als seine Frau es ausgeben kann. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik-Kacheln
Carsten Schönert schrieb: >> >> ja, eine generelle Netzüberlastung (Wahlen) wäre eine mögliche Ursache. > > Das glaubt Ihr in heutigen Zeiten und einer Infrastruktur in > Zentraleuropa doch nicht wirklich? :-) Siehe TTL Zeiten. > > Diese Effekt habe ich seit einigen Monaten schon, und das unabhängig von > meinen kleinen privaten DSL Anschluss oder auf der Arbeit bei einem > 155MB ATM Anschluss. > Wenn du zu viele Kacheln pro Zeiteinheit abrufst, wirst du serverseitig ausgebremst. -- Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Turn restriction Probleme in Baden-Württemberg
Hallo, beim Korrigieren des Rechtecks mit Restrictions um Bremen herum fand ich folgende Meldung zu den Relationen 77021 und 77022: "sorry, 'via' ways are not supported - ignoring restriction". Laut Wiki [1] (Anmerkungen) ist aber bei no_u_turn ausdrücklich ein Weg als via-Rolle erlaubt. [1]: http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Anmerkungen Franz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Am 21.09.2011 21:58, schrieb Stefan Keller: Liebe Leute Also ich blicke nicht mehr durch wer was gesagt hat und sagen will. Im Kern geht es um drei Baustellen: 1) die Erfassung von landuse (Bodennutzung) allgemein - bessere Strukturierung der tag-values nach ISIC, etc. - beliebige Flächen/größe/ zulassen (MICROmapping und normalos) - Bedingung: Datenhaltung von Flächen als multipolygons - Ergebnis: Flächennetzwerk der Bodennutzungen - Flächen/charakterisierung/, also Definition im Wiki überarbeiten - "überwiegende", bzw. "vorrangige" Nutzung - Nutzungserfassung vor Ort (oder äquivalent) 2) die Bedeutung von landuse=residential im Speziellen - darf da nun ein /Gebiets/name dran? - eigentlich erfasst landuse nur die Bodennutzung, und damit Bodennutzungsgrenzen - Wohngebiete sind aber dadurch charakterisiert, dass sie einen Namen tragen und der Grenzverlauf amtlich dokumentiert ist -> in einem strengen Sinne sind Wohngebietsgrenzen boundary=administrative (Verwaltungsgrenzen) 3) place-tag Verwendung auf nodes zurückfahren - alle geografischen Orte haben eine unbestimmte Lage (node = ausdehnungslos) Flächen, die in einem bestimmten Kontext zu einem Ort stehen, haben i.d.R. kontextbezogene Namen, z.B. Gemeindefläche, Siedlungsfläche. Ob die Grenzen dieser Fläche, oder die Gesamtfläche rudimentär als "closed way" erfasst wird, spielt keine Rolle bei der Feststellung, dass ein kontextbezogener Tag vergeben werden sollte. Gemeindefläche -> boundary=administrative, Siedlungsfläche -> ??? (boundary=settlement oder landuse=settlement oder settlement=*, etc. möglich - Hauptsache, da taucht kein place auf) Als Nebeneffekt von 1) und 2) wird erhofft, dass Debatten über "richtiges Mappen" von Flächen, á la "closed ways", "overlapping ways" und "geklebte ways" verschwinden. Multipolygone bieten dazu einen blendenden Ansatz, aber die Editoren unterstützen sie noch nicht gut genug, um damit Flächen genauso simpel zu erfassen, wie das derzeit mit closed/overlapping ways gemacht wird. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offizieller Satz von OSM Diensten
Frederik Ramm wrote: > >> Ein kleines bisschen skandalös finde ich das schon, dass es dieser >> Service nach wie vor nicht auf die OSM-Hauptseite geschafft hat. :) > > Da gibt es ja schon seit geraumer Zeit den Plan, OSB nicht nur auf die > Hauptseite zu bringen, sondern auch betriebsmaessig in die OSM-Datenbank > und das Rails-Frontend zu integrieren. Kai Krueger hat daran gearbeitet, > aber irgendwie hat das Feature es nie in die Produktion geschafft. > Den Plan gibt es nach wie vor, und auch den Code gibt es weitestgehends dazu. ( http://git.openstreetmap.org/rails.git/shortlog/refs/heads/openstreetbugs ). Im Moment befindet sich das ganze im Code review und Tom Hughes sorgt dafuer das der Code auch annehmlich wird. Irgendwann wenn er mit dem Code review fertig ist wird es dann auf der Hauptseite aktiviert. Allerdings dauert das schon eine ganze Weile und ich kann leider nicht Vorhersagen wann es genau geschehen wird. Eine Demonstrationsseite mit dem Aktuellen Stand findet man im uebrigen unter http://openstreetbugs.dev.openstreetmap.org/ Kai -- View this message in context: http://gis.638310.n2.nabble.com/Offizieller-Satz-von-OSM-Diensten-tp6813349p6818391.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 22.09.2011 00:39, schrieb Martin Koppenhoefer: stimmt so nicht ganz, bei den cities ist jede 4. erfasst gem. Taginfo. "Grenzen" erfasst place nicht, sondern das "Begrenzte" (wobei das hier ausdrücklich nicht politisch gemeint ist) diese Differenzierung ist unnötig! Im Wiki steht sinnvollerweise dazu: "Der Schlüssel place kann auch auf Flächen angewendet werden (Area), die der Ausdehnung des Ortes entsprechen. genau, meine Rede, steht auch von Anfang an so im Wiki. Bravo, Martin, Glückwunsch - eben beschwerst Du dich noch darüber, wie Dinge aus dem Kontext gerissen werden, nun tust Du es selbst. Stefan stellt in seiner mail ausdrücklich fest, wie meine Wenigkeit auch, dass Orte punkthaft erfasst werden. Man darf also fragen, ob "sinnvollerweise" nicht ironischen Gebrauch in seiner mail hat. Aber da müssten wir ja erstmal Ironie auseinanderlegen, das dauert dann das nächste Jahr.. Zu letzterem könnte boundary=settlement ein Vorschlag sein, der es sich ev. loht zu diskutieren. könnte man evtl. machen, ist m.E. aber nicht nötig, eine Fläche reicht eigentlich, wozu die Grenze nochmal extra taggen? Ob Fläche, oder Flächengrenze macht keinen Unterschied. Auch diese Aussage beweißt einmal mehr, dass Du die Datenhaltungsmail nicht verstanden hast, wenn sie überhaupt gelesen wurde.. Es sind nur unterschiedliche Darstellungsformen ein und desselben, wobei die Grenzerfassung deshalb Vorteile hat, weil dadurch große Flächengrenzen in Segmente zerlegt, wiederverwendet und, je nach Bedarf, geladen oder nicht geladen werden können. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene Karten rendern
Am 21.09.2011 08:34, schrieb Andreas Labres: Also mich tät interessieren, wie man sich ein Benutzungsverbot auf einem path im Wald vorstellen muss... http://drangmeister.net/osm/20110522T134507s.jpg Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 21. September 2011 21:58 schrieb Stefan Keller : > Offensichtlich seid ihr euch über den - im Titel erwähnten - Gebrauch > von "landuse=residential" einig. Auch das Wiki scheint mir stimmig zu > sein, dass es sich nämlich um die tatsächlich bebauten Flächen > handelt, wie sie jeder im Luftbild/Orthophoto erkennen kann, und > nichts mit dem (auch unbebauten und administrativ abgegrenzten) > Gemeindegebiet zu tun hat. leider ist das Wiki nicht stimmig, weil es bestimmt, dass auch für das Wohnen geplante Flächen als residential zu taggen sind. Das würde ich nicht im landuse tag taggen, sondern diesen nur für die tatsächlich Nutzung benutzen. > Dann scheint (von Martin?) place ins Spiel gebracht worden sein, was > meine Verwirrung dann vollständig gemacht hat. Christians Aussagen und > Vorschläge zur Güte mit "boundary=settlement" scheinen mir jedenfalls > sinnvoll wie auch seine Feststellung bzw. Vorschlag: Place habe ich für Wohngebiete ins Spiel gebracht, also Teile von Siedlungen, nicht für die Bodennutzung (landuse). > Place würde ich in diesem Zusammenhang auch 'raushalten, denn es > handelt sich offensichtlich um Ortsnamen(-grenzen). Orte werden z.Zt. > punkthaft erfasst (Taginfo listet kaum Flächen). stimmt so nicht ganz, bei den cities ist jede 4. erfasst gem. Taginfo. "Grenzen" erfasst place nicht, sondern das "Begrenzte" (wobei das hier ausdrücklich nicht politisch gemeint ist). > Im Wiki steht > sinnvollerweise dazu: "Der Schlüssel place kann auch auf Flächen > angewendet werden (Area), die der Ausdehnung des Ortes entsprechen. genau, meine Rede, steht auch von Anfang an so im Wiki. > Zu letzterem könnte boundary=settlement ein Vorschlag sein, der es > sich ev. loht zu diskutieren. könnte man evtl. machen, ist m.E. aber nicht nötig, eine Fläche reicht eigentlich, wozu die Grenze nochmal extra taggen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene Karten rendern
Hallo Andreas, Also mich tät interessieren, wie man sich ein Benutzungsverbot auf einem path im Wald vorstellen muss... IMO: entweder ist dort ein Zaun o.ä. oder das Verbot wird ziemlich wirkungslos sein... das "wirkungslos" muss jeder selber entscheiden. Ich kenne ich Bereich Stuttgart auch Wege, welche IIRC mit einem grünen quadratischen Schild markiert sind (sinngemäß: Forstweg) auf dem steht (auch mit entsprechenden Symbolen) dass man da nicht rein darf (weder Fußgänger noch Radfahrer noch Reiter noch Fahrzeug). Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Liebe Leute Also ich blicke nicht mehr durch wer was gesagt hat und sagen will. Offensichtlich seid ihr euch über den - im Titel erwähnten - Gebrauch von "landuse=residential" einig. Auch das Wiki scheint mir stimmig zu sein, dass es sich nämlich um die tatsächlich bebauten Flächen handelt, wie sie jeder im Luftbild/Orthophoto erkennen kann, und nichts mit dem (auch unbebauten und administrativ abgegrenzten) Gemeindegebiet zu tun hat. Interessant scheint mir dort höchstens die Abtrennung von Strassenn(-flächen), was in der Schweizer Liste jüngst zu einem ähnlichen Streitgespräch geführt hat. Dann scheint (von Martin?) place ins Spiel gebracht worden sein, was meine Verwirrung dann vollständig gemacht hat. Christians Aussagen und Vorschläge zur Güte mit "boundary=settlement" scheinen mir jedenfalls sinnvoll wie auch seine Feststellung bzw. Vorschlag: > (...) __Orte__ als place, nicht __Siedlungen__ > Und genau deswegen macht ein place-polygon insbesondere für Dich keinen Sinn: > weil es nicht _Ortsgrenzen_ sind, die Du taggst, sondern _Siedlungsgrenzen_ . Place würde ich in diesem Zusammenhang auch 'raushalten, denn es handelt sich offensichtlich um Ortsnamen(-grenzen). Orte werden z.Zt. punkthaft erfasst (Taginfo listet kaum Flächen). Im Wiki steht sinnvollerweise dazu: "Der Schlüssel place kann auch auf Flächen angewendet werden (Area), die der Ausdehnung des Ortes entsprechen. Eventuell fallen diese mit politischen Grenzen zusammen. Siehe Key:boundary für weitere Informationen.". Zu letzterem könnte boundary=settlement ein Vorschlag sein, der es sich ev. loht zu diskutieren. Taginfo und XAPI (http://jxapi.openstreetmap.org/xapi/api/0.6/*%5Bboundary=settlement%5D ) finden jedenfalls noch keinen einzigen Eintrag dazu. Stefan Am 21. September 2011 02:19 schrieb Christian Müller : > Am 20.09.2011 15:50, schrieb Martin Koppenhoefer: >> >> Am 20. September 2011 15:35 schrieb Christian Müller: >>> >>> * Siedlungsfläche != place-polygon (das ist nicht _dasselbe_, schon >>> am >>> 08.09. habe ich versucht, Dir das aufzuzeigen) >>> * Die Siedlungsfläche ist implizit über entsprechende Flächennutzungen >>> der Gemeindefläche erfasst. >> >> Siedlungsfläche, wie ich es gemeint habe (und wie ich gehofft hatte, >> dass es im Kontext verständlich sei, da ich das zig mal konsistent >> verwendet habe), betrifft die räumliche Ausdehnung der menschlichen >> Ansiedlung. > > Ja, von mir aus - und selbst dann ist es nur _eine_ weitere Fläche des Ortes > unter vielen. Darum geht es vorrangig. > > >>> Deine nächste Aktion war, die durch externe Quellen belegte Definition >>> der >>> 'Siedlungsfläche' anzufechten >> >> "Deine Siedlungsfläche" steht hingegen im Kontext >> Flächenverbrauch/Flächenversiegelung. Darum ging es mir nie, und wenn >> man das sinnvoll erheben wollte, müsste man möglichst feingranular die >> Oberflächenausbildung (versickerungsfähig oder nicht und bis zu >> welchem Grad) erfassen. Alternativ kann man auch einfach eine grobe >> Schätzung über die Flächennutzung anstellen. Interessiert mich aber >> höchstens am Rande. Es bringt nichts, Wörter aus ihrem Zusammenhang zu >> reissen, "wer googlet besser" zu spielen, und dann ohne den Kontext zu >> erkennen und die Informationen einzuordnen "externe Quellen" >> anzuführen, die ein anderes Thema behandeln, wo aber der Wortlaut >> vorkommt. > > Wieso? Das haben wir doch bis jetzt sehr erfolgreich gespielt. Ich finde, > wir sind, seitdem Du mit der Toponamastik damit begonnen hast ;-), recht > weit gekommen. Du kannst das, was Du dabei gelernt hast, nun verleugnen > oder annehmen. > > Davon abgesehen bringt es auch nichts, wenn Du Wörter aus allen anderen > Kontexten reißt, und für deinen Kontext allein beanspruchst.. > > Wir sind an einem Punkt, wo wir beide den Fakt anerkennen können, dass > _viele_ Flächen des Ortes, je nach Sinn und Kontext, definiert werden > können. Dabei gibt es keine Fläche, die irgendeinen Vorrang gegenüber > anderen hat. Es macht also keinen Sinn, _eine_ dieser vielen Ortsflächen, > als /DIE/ Ortsfläche zu küren, welche das Prädikat "place" verdient. > > Ich habe /dein/ Verständnis einer Siedlung nie grundsätzlich anfechten > wollen. Mir geht es nur darum, dass durch die Tags, die Du verwendest, für > _alle_ verständlich bleibt, was damit gemeint ist und zwar ohne erst einen > Monat lang Diskussionen führen zu müssen. > > Allg. Tag-Bedeutungen, die OSM im Kern braucht, können nicht von einer > Person, oder einem Kreis von Personen "gehijackt" werden, welche das Tag > dann in einen speziellen Kontext führen. > > /place/ war in OSM immer _viel_ mehr als nur ein key mit welchem settlements > erfasst werden. > > Wenn Du (und andere) Siedlungsgrenzen erfassen wollen/müssen, dann bitte > unter neuem, aussagekräftigem Tag. Besetze boundary=settlement oder > ähnliches, aber nicht place.. > > Die Siedlungsgrenzen, ob nach /deiner/ Definition oder nicht, sind für OSM > nützliche Daten, schonmal allein, weil sie Dich intere
Re: [Talk-de] Seltsamer Mapnik-Effekt
Hallo Dimitri! Am 21.09.2011 18:30, schrieb Dimitri Junker: Melde es den Mapnik Machern Vielen Dank für die Rückmeldung! Meintest du "Melde das bitte den Mapnik-Entwicklern" oder "Ich melde es den Mapnik-Entwicklern"? Sorry, dass ich nachfragen muss. Gruß, Philip ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seltsamer Mapnik-Effekt
Hallo, >Ich kann ein client-seitiges Caching zu fast 100% ausschließe ich zu 100%, war gerade erstmal dort und sehe den Fehler. Melde es den Mapnik Machern Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Seltsamer Mapnik-Effekt
Hallo zusammen! Ich habe vor ein paar Wochen einem Gebäude in Leverkusen das name-Tag verpasst. Interessanterweise verhält sich Mapnik beim Rendern sehr seltsam. http://osm.org/go/0GDrkHBJ Rathaus Galerie Leverkusen, östlich von den Luminaden Leverkusen. Das Gebäude ist auf der Grenze von zwei Kacheln. Auf der Zoomstufe 16 wird auf einer Kachel der Name gerendert, auf der anderen Kachel jedoch nicht. Ich habe bereits mehrere Male die Kachel-Grafiken als dirty markiert und ein paar Stunden gewartet (ja, der Status wurde aktualisiert). Jedoch taucht der Effekt immer noch auf. Ich kann ein client-seitiges Caching zu fast 100% ausschließen, weil ich auf verschiedenen Browsern (auch im Private-Browsing-Modus), auf verschiedenen Betriebssystemen in verschiedenen Netzen diesen Effekt sehe. Ich vermute nicht, dass das Tagging falsch ist, da es ja sonst auf beiden Kacheln nicht angezeigt würde. Weiß jemand, was ich gegen die abgeschnittene Schrift machen kann? Beste Grüße, Philip ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik-Kacheln
Hallo, On 09/21/11 13:32, Carsten Moeller wrote: Also, die ersten Aufrufe laufen flüssig und je mehr man navigiert wird's immer langsamer - bis am Ende gar nix mehr kommt. Der Tileserver hat eine Sperre gegen Bulk-Downloads, die u.U. auch anschlaegt, wenn jemand sehr viel auf der Karte rumsurft. Dann kommt die IP-Adresse in einen sogenannten "delay pool" und bekommt Tiles langsamer ausgeliefert. Es ist eher ungewoehnlich, dass das bei "normalem" Gebrauch passiert, kann aber schon mal passieren, gerade wenn die ganze Firma ueber den gleichen DSL-Anschluss surft. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik-Kacheln
Hallo Markus, genau das Phänomen stelle ich auch gerade fest. Also, die ersten Aufrufe laufen flüssig und je mehr man navigiert wird's immer langsamer - bis am Ende gar nix mehr kommt. Versuche gerade inne Firma die Leute von OSM zu überzeugen. Hab auf der OpenLayers-Karte jetzt schnell noch ein paar Google-Layer hinzugefügt, damit der ShowCase am Ende nicht nach hinten losgeht. Gruß, Carsten. osm2po.de Am 19.09.2011 00:30, schrieb Markus: Hallo Holger, ping /t tile.openstreetmap.org liefert bei mit Zeiten von 29..31 ms (min 28ms, max 68ms, med 30ms, verloren 0,4%) was ist TTL? bei mir: TTL=53 Hallo Rolf, ja, eine generelle Netzüberlastung (Wahlen) wäre eine mögliche Ursache. Ich habe aber den Eindruck, dass die Kacheln beim ersten Aufruf wesentlich flüssiger geladen werden, und die "Ladehemmung" zunimmt bei häufigem Scrollen. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene Karten rendern
On Wed, Sep 21, 2011 at 08:34:22AM +0200, Andreas Labres wrote: > > Also mich tät interessieren, wie man sich ein Benutzungsverbot auf einem path > im > Wald vorstellen muss... > > IMO: entweder ist dort ein Zaun o.ä. oder das Verbot wird ziemlich wirkungslos > sein... Das ist wie beim Schwarzfahren in öffentlichen Verkehrsmitteln: Wer erwischt wird zahlt - im Fall des Nationalparks sind das 25Euro. Laut Nationalparkgesetzt dürfen nur ausgewiesene Wanderwege benutzt werden und der besagte (sowie andere) gehören nicht zu diesen. Es gibt (seltene) Exkursionen mit Rangern unter Berücksichtigung eines wissenschaftlichen Interesses. Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offizieller Satz von OSM Diensten
Dem kann ich zumindest teilweise zustimmen. Ich bastle momentan an einem Portal und binde dafür Osmosis im Code ein. Hier vermisse ich bisher eine Dokumentation der dahintersteckenden Library. Das Wiki dokumentiert zwar sehr schön und vollständig die Verwendung von osmosis als Kommandozeilentool; die Einbindung in andere (Java)-Projekte ist aber nicht beschrieben. Mit der Hilfe von Jan und seinem JXAPI-Code war das dann gar nicht so schwer, sich da durchzufuchsen; eine Dokumentation, welche Befehler aus der Kommandozeilen-Nutzung zu welchen Klassen im Java-Code passen, fehlt aber trotzdem; die muss man sich im Einzelnen zusammensuchen. Ich denke, wir haben viele Teile von Software im OSM-Ökosystem, die gut funktionieren. Auch hier gilt mal wieder: man muss sie finden. Manches ist im OSM-SVN, andere wollen aber Git benutzen und hosten deshalb anderswo. Wieder andere Projekte liegen bei sourceforge, in der Code-Verwaltung von Wiki(p|m)edia oder wo auch immer sonst noch. Das ist nicht unbedingt ein Nachteil, aber es erfordert immer wieder Aufwand und manchmal eine Portion Glück, die richtigen Komponenten zu finden, um das Neuerfinden des Rades verhindern zu können. Die "Library"-Idee könnte ich mir aber z.B. als eine Wiki-Seite vorstellen, die eine Liste von Aufgaben enthält, und dafür jeweils existierende Komponenten vorstellt. Die allerdings übersichtlich und aktuell zu halten, ist eben auch wieder nicht ohne Investition von Zeit und Aufwand möglich. Gruß Peter Am 21.09.2011 09:48, schrieb Adrian Stabiszewski: Hi! Die Idee mit den offiziellen Diensten ist reizvoll, leider auf freiwilliger Basis kaum umzusetzen. Als leidenschaftlicher Entwickler habe ich den Amenity Editor und den Relation Analyzer online gestellt. Beide Projekte entstanden aus der Idee etwas Neues zu lernen und etwas Nützliches zu schaffen. Für mich ist das eine Programmierübung in meiner Freizeit, für die anderen werden das unersetzliche Werkzeuge ;) Ich möchte hier jedoch einen anderen Ansatz anbieten. Beim Entwickeln vom AE und RA sind mir viele Ähnlichkeiten aufgefallen, die sich weiter zu einer netten Library zusammenführen lassen. Beispiele hierfür sind der Zugriff auf den OSM Server (upload+download), das Parsen von (relativ kleinen) OSM XML Dateien und das Producer-Consumer Pattern zum Verarbeiten von großen OSM XML Dateien (planet.osm). Diese Funktionen sind nicht trivial und bereiten immer wieder Einstiegshürden für Entwickler. Wenn wir eine Library hätten, die diese Funktionen sauber kapselt, dann würden vielleicht mehr Entwickler an OSM Open Source Projekten mitarbeiten. Natürlich könnte die Library weitere Funktionen enthalten, wie Routing-Algorithmen oder Import/Export von verschiedenen Geo-Formaten (beides im RA bereits implementiert). Ein weiteres Argument für eine Library wäre, dass ein Entwickler leichter ein anderes Projekt verstehen kann, da er bereits bekannte Muster und Funktionen wiederfindet. Dies würde dann auf Dauer zu einer besseren Wartbarkeit von Tools führen, weil mehr Entwickler überhaupt in der Lage sind ein Projekt zu verstehen. Es gibt bereits einige Tools, die in Java geschrieben sind (Josm, osmosis), die vielleicht weitere Funktionen für eine solche Library beitragen könnten. Vielleicht wäre das was für "Winter of Code" ;) Viele Grüße, Adrian. -Ursprüngliche Nachricht- Von: talk-de-requ...@openstreetmap.org [mailto:talk-de- requ...@openstreetmap.org] Gesendet: Mittwoch, 21. September 2011 00:32 An: talk-de@openstreetmap.org Betreff: Talk-de Digest, Vol 62, Issue 66 Send Talk-de mailing list submissions to talk-de@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-de or, via email, send a message with subject or body 'help' to talk-de-requ...@openstreetmap.org You can reach the person managing the list at talk-de-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Talk-de digest..." Today's Topics: 1. Offizieller Satz von OSM Diensten (Andreas Tille) 2. Re: Offizieller Satz von OSM Diensten (Frederik Ramm) 3. Re: Offizieller Satz von OSM Diensten (Andreas Tille) 4. Re: landuse=road War:[viel Text zu landuse-handling..] (Christian M?ller) -- Message: 1 Date: Tue, 20 Sep 2011 21:04:00 +0200 From: Andreas Tille To: OSM-de Subject: [Talk-de] Offizieller Satz von OSM Diensten Message-ID:<20110920190400.gd24...@an3as.eu> Content-Type: text/plain; charset=iso-8859-1 Hallo, die Diskussion entz?ndete sich aktuell zwar am Relation Analyzer ist aber irgendwie ins generelle abgedriftet und daher w?rde ich mir gern einmal Klarheit verschaffen wollen. Ich halte es f?r f?rderlich, wenn im OSM Projekt ein stabiler Satz von Werkzeugen etabliert wird, die fest sozusagen "offiziell" zum OSM Projekt geh?ren und auf die m
Re: [Talk-de] Eigene Karten rendern
On 2011-09-21 08:34, Andreas Labres wrote: On 20.09.11 20:55, Andreas Tille wrote: Was lange währt ... Nun habe ich erstmal das Ticket aufgemacht: http://trac.openstreetmap.org/ticket/4015 Danke für den Hinweis Also mich tät interessieren, wie man sich ein Benutzungsverbot auf einem path im Wald vorstellen muss... IMO: entweder ist dort ein Zaun o.ä. oder das Verbot wird ziemlich wirkungslos sein... Praktisch weiß ich nicht, aber im Nationalpark Hochharz gibt es auch ein paar Tracks, die nur für Ranger freigegeben sind - Schutz der Natur. IMHO sind die entsprechend mit Barrieren abgesichert. Servus, Andreas MfG, Lars Schimmer -- - TU Graz, Institut für ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offizieller Satz von OSM Diensten
Hi! Die Idee mit den offiziellen Diensten ist reizvoll, leider auf freiwilliger Basis kaum umzusetzen. Als leidenschaftlicher Entwickler habe ich den Amenity Editor und den Relation Analyzer online gestellt. Beide Projekte entstanden aus der Idee etwas Neues zu lernen und etwas Nützliches zu schaffen. Für mich ist das eine Programmierübung in meiner Freizeit, für die anderen werden das unersetzliche Werkzeuge ;) Ich möchte hier jedoch einen anderen Ansatz anbieten. Beim Entwickeln vom AE und RA sind mir viele Ähnlichkeiten aufgefallen, die sich weiter zu einer netten Library zusammenführen lassen. Beispiele hierfür sind der Zugriff auf den OSM Server (upload+download), das Parsen von (relativ kleinen) OSM XML Dateien und das Producer-Consumer Pattern zum Verarbeiten von großen OSM XML Dateien (planet.osm). Diese Funktionen sind nicht trivial und bereiten immer wieder Einstiegshürden für Entwickler. Wenn wir eine Library hätten, die diese Funktionen sauber kapselt, dann würden vielleicht mehr Entwickler an OSM Open Source Projekten mitarbeiten. Natürlich könnte die Library weitere Funktionen enthalten, wie Routing-Algorithmen oder Import/Export von verschiedenen Geo-Formaten (beides im RA bereits implementiert). Ein weiteres Argument für eine Library wäre, dass ein Entwickler leichter ein anderes Projekt verstehen kann, da er bereits bekannte Muster und Funktionen wiederfindet. Dies würde dann auf Dauer zu einer besseren Wartbarkeit von Tools führen, weil mehr Entwickler überhaupt in der Lage sind ein Projekt zu verstehen. Es gibt bereits einige Tools, die in Java geschrieben sind (Josm, osmosis), die vielleicht weitere Funktionen für eine solche Library beitragen könnten. Vielleicht wäre das was für "Winter of Code" ;) Viele Grüße, Adrian. > -Ursprüngliche Nachricht- > Von: talk-de-requ...@openstreetmap.org [mailto:talk-de- > requ...@openstreetmap.org] > Gesendet: Mittwoch, 21. September 2011 00:32 > An: talk-de@openstreetmap.org > Betreff: Talk-de Digest, Vol 62, Issue 66 > > Send Talk-de mailing list submissions to > talk-de@openstreetmap.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openstreetmap.org/listinfo/talk-de > or, via email, send a message with subject or body 'help' to > talk-de-requ...@openstreetmap.org > > You can reach the person managing the list at > talk-de-ow...@openstreetmap.org > > When replying, please edit your Subject line so it is more specific than "Re: > Contents of Talk-de digest..." > > > Today's Topics: > >1. Offizieller Satz von OSM Diensten (Andreas Tille) >2. Re: Offizieller Satz von OSM Diensten (Frederik Ramm) >3. Re: Offizieller Satz von OSM Diensten (Andreas Tille) >4. Re: landuse=road War:[viel Text zu landuse-handling..] > (Christian M?ller) > > > -- > > Message: 1 > Date: Tue, 20 Sep 2011 21:04:00 +0200 > From: Andreas Tille > To: OSM-de > Subject: [Talk-de] Offizieller Satz von OSM Diensten > Message-ID: <20110920190400.gd24...@an3as.eu> > Content-Type: text/plain; charset=iso-8859-1 > > Hallo, > > die Diskussion entz?ndete sich aktuell zwar am Relation Analyzer ist aber > irgendwie ins generelle abgedriftet und daher w?rde ich mir gern einmal > Klarheit verschaffen wollen. > > Ich halte es f?r f?rderlich, wenn im OSM Projekt ein stabiler Satz von > Werkzeugen etabliert wird, die fest sozusagen "offiziell" zum OSM Projekt > geh?ren und auf die man dann auch verweisen kann. Ich sehe das deshalb > f?r notwendig an, weil meiner Meinung nach ein Gro?teil der Nutzer eine > gewisse Konsistenz und Stabilit?t sch?tzt und bei ernst zu nehmenden > Projekten erwartet (und IMHO auch erwarten darf). > > Zu diesen Werkzeugen w?re ich nat?rlich in erster Linie einen Standard > Renderer von Karten f?r das Web, einen Editor, eine Karte f?r GPS Ger?te, > aber auch solche Sachen wie den RA und weitere n?tzliche Tools z?hlen. Mir > ist auch bewu?t, da? es zu den oben genannten Dingen *immer* mehrere > L?sungen gibt, und das das auch von vielen als Vorteil angesehen wird. Das > wird z.B. an Diskussionen ?ber Renderer[1] oder die diversen Threads ?ber > die AIO in diesem Jahr deutlich. > > Mir ist durchaus bekannt, da? es keine optimale "eine f?r alles L?sung" > geben kann und da? es m?glicherweise sogar mehrere L?sungen geben mu? > - doch dann sollten diese L?sungen auch einem bestimmten Satz von > Qualit?tskriterien gen?gen, der verl??lich auch durch diese Alternativen > eingehalten wird. > > In meinen Augen sollten folgende Punkte Bestandteil dieser > Qualit?tskriterien sein: > > 1. Gehosted / downloadbar unter der Domain openstreetmap.org > 2. Zugeh?rige Komponente auf http://trac.openstreetmap.org/ > 3. Version Control System unter openstreetmap.org, damit sich > ein Entwicklerteam bilden kann > 4. Zugeh?rige Mailingliste unter openstreetmap.org > > In meinen Augen ist eine solche Forma
