[Talk-de] Reit- und Wanderkarte - Jahresrückbli ck
erlauben soll. Auch wenn P2 inzwischen offiziell ist, betrachte ich das noch als im Experimentierstadium. Die Reit- und Wanderkarte hatte von Anfang an die Vision, OSM einem breiten Kreis von Reitern, Wanderern und anderen Interessenten näher zu bringen und ohne große Lernkurve nutzbar zu machen - zumindest so sie über eine Breitbandverbindung verfügen. Diesem Ziel konnte sie ein wenig näher kommen und außerhalb von OSM mehr Bekanntheit erlangen. Besonders hilfreich war ein Artikel im Wanderreitmagazin.de. Inzwischen wird sie ernsthaft von ein paar Wanderseiten für die Anzeige von Tourenvorschlägen oder Unterkünften genutzt. Zum Abschluß des Jahres wurde praktisch in letzter Minute noch eine Zusammenarbeit mit der Handysoftware a...@map angestoßen, die hoffentlich noch mehr Interessenten gewinnen wird. Vom Feedback des letzten Jahres her denke ich, daß viele Nutzer dann auch schnell zu Mappern werden, wenn ihnen etwas fehlt - man muß nur die technischen Hürden nicht zu hoch legen. Soweit der Rückblick auf die Entstehungsgeschichte. Schaun' wir mal was noch alles kommt. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unbeantwortete Fragen im OSM-Forum
Hallo! Am 09.01.2010 20:48, schrieb Tobias Knerr: Gleichzeitig darf das gerne als Diskussionsanstoß dienen, wie man am besten mit unseren gespaltenen Kommunikationsmedien umgeht. Ich verfolge derzeit 9 OSM Mailinglisten, das Wiki und das Forum, aber irgendwann wurde es mir auch zuviel, vor allem wenn mich nur gezielt ein Thread interessiert. Bei weiteren Spezial-Mailinglisten habe ich dann angefangen, nabble zu benutzen. Nabble bietet Zugriff auf Mailinglisten in Form eines Forums. Dabei bleibt es jedem Nutzer überlassen, ober es als Mails oder als Forum lesen/bearbeiten will. osgeo.org hat dort einen ganzen Baum von Themen und deren Mailinglisten eingetragen, der exakt genauso aussieht wie man das von einem größeren Forum erwartet. Nur die Anmeldeprozedur ist komplizierter, das ist die von der Mailingliste. Die Listen von osgeo.org findet Ihr als Beispiel hier: http://n2.nabble.com/OSGeo-org-f1803224.html Daher die Frage an Euch: Wäre es möglich, daß sich die OSMF bei Nabble einen Baum von Mailinglisten einrichtet analog osgeo? Dann könnte sich jeder entscheiden, ob er Mail- oder Forenansicht haben will und die viel bejammerte Trennung ist hinfällig. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Noexit tag an nodes und ways
Hi! Am 04.01.2010 11:48, schrieb Dieter Jasper: Ich denke es ist ausreichend, nur den Endnode zu taggen. +1 Sehe ich genauso. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Fwd: Re: Not-properly-Open-but-called-Open
Hi! Am 02.01.2010 00:23, schrieb Frederik Ramm: We cannot, and do not want to, trademark the words open, free and the like, but I think we could be a little bit more assertive about whom we consider to be a kindred spirit and who is doing his own thing, and apply the tiniest amount of pressure for people to upgrade from (b) to (a). I think many of us will be surprised how many cool OSM projects actually fall into the (b) category. Before we talk about putting projects in categories - this would assume that there is an agreement on what those terms mean and what is the right direction to move into. But as far as I got it from previous discussions, opinions are very much divided here, too. So what does open mean: - everything is available to look at? - everything may be copied and re-used? - everybody may participate and change things? - all of that? And what does free mean: - generally available? - free of restrictions on usage? - free of cost? - available in an open format? - a combination of that? In my personal opinion, PD is free, while OSM is already non-free as it puts severe restrictions on the usage of the data. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Countering Google's propaganda
Hi! Am 31.12.2009 14:29, schrieb Anthony: Maybe, but while the supply of people willing to become mappers is limited, it isn't fixed. I took a quick look at GMM, and it looks to me like it's not a bad introductory class for potential OSM contributors. GMM doesn't offer anywhere near as many features as OSM, and given their business model it seems unlikely to me that they ever will. And then, even if they do, there would be nothing stopping someone from contributing to OSM and then importing their contributions additionally into GMM. I believe that GMM can be a serious competition to OSM if it is simpler to use, easier to learn and thus more inviting to the casual newcomer. With GMM you have one way of mapping a simple item e.g. a bicycle track. Everybody can do it in ten minutes, no questions arise. With OSM you have two major tools, a huge load of tags, a wiki, a forum, several mailing lists, three different answers to the question, long discussions, pages of contradictory documentation, plenty of old discussions and after working through all this, you realize that the question has not been resolved yet. I can see how many people would prefer the simple way offered by Google. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Countering Google's propaganda
Hi! Am 01.01.2010 15:48, schrieb Anthony: Only if you care. If you want simple, you click edit on potlatch, you draw the way, you click on the car until it turns into a bicycle, and you select cycle track. Then those of us on the mailing list write 1000 emails about whether or not you were right, but you probably don't even notice it. Not at first. But you note later, when your edit has been changed into something that you don't understand or someone sends you a notice to do it some other way. :-( bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] wirtschaftswege - access=no
Hi! Am 31.12.2009 09:54, schrieb Frederik Ramm: Bei den Englaendern gibt es da ja das Konzept eines right of way. Wenn ich als Aussenseiter das richtig interpretiere, bleibt bei denen unter Umstaenden, selbst wenn der physische Weg laengst weg ist, noch so eine rechtliche Huelse uebrig, das Echo eines frueher mal existenten Weges, das Dich auch heute noch berechtigt, dich dort zu bewegen - selbst wenn Dich das durch einen privaten Gemuesegarten fuehrt. Das gibt es auch bei uns. Das Katasteramt verwaltet die Wege und Zufahrten zu Grundstücken. Solange sich alle einig sind, werden in der Praxis Wege häufig umverlegt, aber wenn's hart auf hart kommt, hat man auf den registrierten Zufahrtswegen Wegerecht - und nur da - und auch die Verpflichtung sie zu benutzen und die Grundstücke von dieser Seite zu befahren. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Blue Sea 1: Garmin Karten
Hi! Am 31.12.2009 16:19, schrieb Chris-Hein Lunkhusen: Übersicht wüsste ich nicht, meine Blue Map Deutschland (Userpage Chris66) hat noch Meerespolygone und die Topo Deutschland (http://topo.geofabrik.de/) eventuell auch. Ja, die Wanderkarte hat die Meere auch blau. Ansonsten gibt es seit heute in mkgmap eine weitere Option um SeaPolygons zu generieren, da der Weg über Multipolygone keine guten Resultate gebracht hat. Das neue Verfahren malt das Festland über eine blaue Grundfläche. Das wird noch ein wenig dauern. Leider funktioniert dieses Verfahren momentan ebenso unzuverlässig wie sein Vorgänger. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] How to manage GPX files?
Hi! Am 30.12.2009 08:18, schrieb Maarten Deen: Is it just me or is there a limit to the size of the Java VM you can enter in Windows XP? I've had on separate occasions had to lower the limit to something like 1300 because it just wouldn't run. There is a limit, though it depends heavily on your machine. Absolute maximum on a 32bit Windows is 1600MB, a value that works on most machines is 1200MB. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] ClosedCycleMap (was: Re: Cross-renderer tag support, now with OSMdoc!)
Hi! Am 20.12.2009 03:58, schrieb John Smith: Most of them might not have the technical skills or the inclination since someone else has already made something good enough Technical skills and inclination are not enough. You also need considerable server side muscle to create a dedicated map. The standards for acceptance by the casual user have grown enourmously. A year ago, the main maps were re-rendered once a week and that was cool. Now they are updated daily/minutely and somehow people expect that from _every_ map. Weekly updates are now considered lame. And less than full world-wide coverage is lame, too. :-[ Most people are not aware of the server power required to do this. It ain't cheap, and getting support on a sponsored/community server takes time and effort, too. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Neue Garmin-Version der Wanderkarte ver fügbar
Am 20.12.2009 09:14, schrieb hansdorfff: in der Webseitenversion kann ich nur bis Zoomlevel 15 heranzoomen. Ist das Absicht? Die Webversion geht nur bis Zoomlevel 15, da sie offline auf meinem Desktoprechner gerendert wird. Mehr ist ohne Renderserver nicht drin. Abhilfe ist in Arbeit. Und wie ist das in der Garmin-Version? Da gibt es keine Grenze. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Garmin-Version der Wanderkarte verf ügbar
Hi! Am 15.12.2009 08:24, schrieb Andreas Pothe: Die Reit- und Wanderkarte für Deutschland, Österreich, Schweiz und Norditalien ist in einer neuen Version mit den Daten vom 8.12. verfügbar. Und wo findet man die? Hm, war wohl schon etwas spät gestern. Die Karte findet man unter topo.geofabrik.de. Und die kleine Karte zum Testen liegt natürlich entsprechend unter topo.geofabrik.de/Test_gmapsupp.zip. Aber das Datum war wenigstens richtig. :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Composer V0.8 verfügbar
Hallo! Das Tool OSM Composer steht jetzt in der Version V0.8 zum Download bereit. Diese Version stellt einen größeren Sprung als üblich dar - es wurden einige Teile der Engine neu geschrieben - und hat daher ein wenig auf sich warten lassen. Wesentliche Neuerungen in V0.8: * Intelligente Aufteilung der Karte in Kacheln unter Berücksichtigung der Höhenlinien * Größenabhängige Renderregeln für Weglängen und Polygongrößen * Kurze Wegstücke auf einer Route werden zusammengefaßt und mit Wandermarkierungen versehen * Verbesserte Höhenlinien: korrekt positioniert, mit Splines abgerundet, Ausblenden von Artefakten * Beimischung von festen, zusätzlichen Daten wie z.B. Seepolygone möglich * Eigene Parameter für mkgmap möglich - für die Experimentierfreudigen * Vorschauicons für farbige Linien und Flächen * Verarbeitung kann pausiert werden * Deutlich höhere Geschwindigkeit bei geringerem Speicherbedarf Die vollständige Liste der Änderungen und den Download findet Ihr im Wiki: http://wiki.openstreetmap.org/wiki/DE:OSM_Composer#Download bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue Garmin-Version der Wanderkarte ver fügbar
Hallo! Die Reit- und Wanderkarte für Deutschland, Österreich, Schweiz und Norditalien ist in einer neuen Version mit den Daten vom 8.12. verfügbar. Die Karte ist jetzt nicht mehr als transparent markiert, da das Probleme im Zusammenspiel mit Routen nach sich gezogen hat. Falls Ihr Probleme hattet, probiert doch bitte mal aus, ob sie jetzt auf Eurem Gerät besser dargestellt wird. Eine kleine Datei von Tübingen zum Test findet Ihr hier: http://www.geofabrik.de/Test_gmapsupp.zip. Mit fast 1 GB dürfte die Karte langsam auch Maximalgröße erreicht haben, ich beabsichtige die gmapsupp.img in Zukunft in mehrere Karten zu spalten und nur die Mapsource-Version am Stück zu lassen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] REF-defintion bei Wanderwegen
Hi! bei den Fernwanderwegen gibt es das Tag REF - ich würde gerne auch eines für die Jakobswege haben. Kann man das selber vorschlagen oder werden diese in Anlehung an irgendetwas vergeben ??? Soweit ich das verstanden habe, kommt das REF-Tag eher von den Straßen her und ist für offizielle Abkürzungen vorgesehen, A3 oder B17 bei Straßen, X29 oder MD für Wanderrouten. Allerdings ist es nicht für selbsterfundene Abkürzungen gedacht, die man auf Wandertafeln, Schildern und anderen Veröffentlichungen nicht wiederfindet. Ich selber bin da leidenschaftslos - ich verwende die Refs nicht und konzentriere mich auf die graphischen Symbole. Ich möchte aber darauf hinweisen, daß es eine Fraktion gibt, die es bereits für falsch hält, beim Namen einen beschreibenden Text einzugeben, der nicht offiziell verankert ist. Das dürfte dann für das Erfinden von Refs erst recht gelten. bye Nop -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Opinion poll about the new licence Odbl 1.0
Hi! Pieren schrieb: Therefore, I would like to know what you, the contributor, thinks today about the transition to Odbl 1.0 licence in this opinion poll: http://doodle.com/feqszqirqqxi4r7w It is good that there is a general poll of opinion. This is something the OSMF should have organized. I have translated the call to German and put it on the talk-de. I am very interested in the outcome and am looking forward to see what the actual numbers say. One the request to those people questioning the poll (in true community style) or suggesting more options. Please leave the poll alone, it may not be perfect and may not have your personal preferred option, but it corresponds to the intended options of the real vote and the major realistic outcomes. It is a very good chance to get an overview over the opinion of the active people so please just cast your vote as best as you can. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] Unverbindliche Umfrage zum Lizenzwechsel
Hi! Der User Pieren hat auf der talk-Liste eine allgemeine Umfrage gestartet, um zu sehen, wie die Community über den Lizenzwechsel denkt. Die Umfrage ist zu finden unter http://doodle.com/feqszqirqqxi4r7w Die Optionen entsprechen ungefähr denen der für Februar geplanten Abstimmung aller User. Von Links nach Rechts: - Ja, ich werde die neue Odbl Lizenz akzeptieren - Ja, und ich betrachte alle meine Daten sowieso als Public Domain - Nein, ich werde die neue Odbl Lizenz nicht akzeptieren, erst nachdem sie überarbeitet wurde - Nein, ich werde die neue Odbl Lizenz nicht akzeptieren und will CC-BY-SA2.0 beibehalten - Ich weiß noch nicht, denn ich verstehe die neue Lizenz und die möglichen Konsequenzen noch nicht. Ich finde es gut, daß mal jemand die Stimmung prüft, wenn es schon die OSMF nicht tut. Gebt bitte Eure Meinung kund. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unverbindliche Umfrage zum Lizenzwechsel
Hi! Mirko Küster schrieb: Ich finde es gut, daß mal jemand die Stimmung prüft, wenn es schon die OSMF nicht tut. Gebt bitte Eure Meinung kund. Problem ist nur das wir dort die Meinungzu sehen bekommen die wir ohnehin schon über die bekannten Kanäle zu hören bekommen haben, da die Existenz dieser Umfrage eben genau nur darüber bekannt wird und freiwillig ist. Zudem noch mit Name. Die 99% der stillen User erreichst du nur wenn die Frage aller Fragen direkt auf der Seite erscheint, geheim ist und man nicht drumherum kommt. Erst dann wird es wirklich interesannt. Bei der Abstimmung nimmt, wenn es hoch kommt, vielleicht 1% teil. Darum steht auch unverbindlich als allererstes in der Überschrift. Spannend bleibt es in jedem Fall, aber vielleicht gar nicht so spannend, denn viele Leute mit aktivem Interesse reden hier grade mit - und Leute ohne lizenzpolitisches Interesse werden nach meiner Ansicht dem Wechsel mit hoher Wahrscheinlichkeit zustimmen ohne ihn genau zu lesen und weitermappen. Die Abstimmung ist übrigens anonym - Du kannst einen beliebigen Namen eintragen. Macht aber IMHO wenig Sinn, hier öffentlich mitzudiskutieren und dann ein Geheimnis aus seiner Meinung machen zu wollen. Also nochmal: Es ist das Beste was wir grade haben - nutzen wir es. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unverbindliche Umfrage zum Lizenzwechsel
Hallo! Markus schrieb: Die Antwort mit dem Public Domain ist unklar. Wir haben ja 3 Alternativen: * CC-by-SA * Odbl * PD (und weiss nicht/egal/keine von den dreien) Nein, eine PD Variante steht momentan nicht zur Debatte. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unverbindliche Umfrage zum Lizenzwechsel
Hi! Matthias Versen schrieb: Es fehlt : Ich akzeptiere die neue Lizenz aber bin gegen einen Wechsel Es handelt sich um die Übersetzung einer bereits laufenden Abstimmung. Es ist relativ sinnfrei über Änderungswünsche zu diskutieren. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM highway=* und Radwege
Hi! Sebastian Klein schrieb: Nop wrote: Es ist übrigens nicht nötig, den Stil runterzuladen - du hast ihn bereits in der josm.jar unter styles\standard\elemstyles.xml und kannst ihn mit jedem Zip-Programm herausholen. Doch, es ist nötig, denn der Stil in der josm.jar wird ja eh schon automatisch benutzt. Es macht also keinen Sinn ihn zu extrahieren und dann erneut zu laden. :) Natürlich muß man ihn zwischendurch noch ändern. :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM highway=* und Radwege
Hi! Sebastian Klein schrieb: Ja, den aktuellen Stil hier runterladen: http://josm.openstreetmap.de/export/2574/trunk/styles/standard/elemstyles.xml Es ist übrigens nicht nötig, den Stil runterzuladen - du hast ihn bereits in der josm.jar unter styles\standard\elemstyles.xml und kannst ihn mit jedem Zip-Programm herausholen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Jakobswege: HIKING oder PILGRIMGE in den Relationen
Hallo! Dazu mein üblicher Kommentar: Wanderwege werden mit foot oder hiking getaggt. Wenn ein Pilgerweg zufällig auch ein Wanderweg ist, kann er als solcher getaggt werden. Eine Pilgerroute dagegen ist ein allgemeinerer Begriff und sagt nichts über das Verkehrsmittel aus. Es kann ein Wanderweg sein, muß aber nicht. Pilgerrouten können genausogut Autobahnen beinhalten. Gerade echte historische Pilgerrouten führen heutzutage oft über große Straßen und durch häßliche Industrieviertel und sind alles andere als Wanderwege. Von daher können die beiden Tags nicht einfach gleichgesetzt werden. Das eigentliche Problem sehe ich darin, daß Pilgerweg als eigener Routentyp definiert wurde. Mit dem Tagging route=hiking pilgrimage=yes wären unsere Jakobswege IMHO korrekt beschrieben, erscheinen auf den Karten und könnten eindeutig erkannt werden. bye Nop -- Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen Debütalbum One Moment in Time. http://portal.gmx.net/de/go/musik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jakobswege: HIKING oder PILGRIMGE in den Relationen
Hi! Andre Joost schrieb: Nop schrieb: Eine Pilgerroute dagegen ist ein allgemeinerer Begriff und sagt nichts über das Verkehrsmittel aus. Es kann ein Wanderweg sein, muß aber nicht. Pilgerrouten können genausogut Autobahnen beinhalten. Also alle mir bekannten, ausgeschilderten Jakobswege *sind* Wanderwege. Dann sollten sie auch so getaggt werden. :-) Gerade echte historische Pilgerrouten führen heutzutage oft über große Straßen und durch häßliche Industrieviertel und sind alles andere als Wanderwege. Der Jakobsweg in Dortmund nutzt m.E. die schönsten Straßen, um die Pilger nicht zu vergraulen ;-) Um große Straßen kommt man für durchegenhdes Routing gelegentlich nicht vorbei, das hält sich aber in Grenzen. Ich beziehe mich dabei auf die Aussage von Leuten, die den Jakobswegen schon bis nach Santiago di Compostella gefolgt sind. Hier in Deutschland sind das vielleicht eher Wanderwege, die hübschen, aber nicht den historischen Routen folgen. Die historische Route selbst dagegen ist heute oft nicht mehr sehr einladend. Die Erzählungen klangen auf jeden Fall eher enttäuscht. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapnik und relationen
Hi! Stephan Olbrich schrieb: gibt es irgendwo eine Anleitung, wie ich mapnik dazu bewegen kann Relationen zu rendern? (Und was ich alles beim Import der Daten in die Datenbank beachten muss, etc.) Meines Wissens gar nicht. Manche Relationen wie Multipolygone wertet osm2pgsql beim Import aus, aber in der DB landen Relationen nicht. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapnik und relationen
Hi! Stephan Olbrich schrieb: Wie machst Du das mit Deiner Wanderkarte? Die Relationen werden von OSM Composer ausgewertet, in Geometrie umgesetzt und die wird in die Mapnik-DB importiert. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Path vs footway vs cycleway vs...
Hi! Cartinus schrieb: On Sunday 29 November 2009 01:34:19 Nop wrote: 2) AFAIK the only attempt at a neutral display of the different opinions is here: http://wiki.openstreetmap.org/wiki/Consolidation_footway_cycleway_path That page is far from neutral, because the only solutions it offers are doing something with the path tag. It is an attempt. If you find something missing or have another suggestion for a solution, why don't you add it? bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path vs footway vs cycleway vs...
Hi! Cartinus schrieb: If you negate the existence of a problem that has been widely confirmed, you're not likely to contribute to a solution. Except that I am far from alone with my opinion. See e.g. Richards explanation somewhere at the start of this thread and the widespread opposition the path tag gets. EVERY contradictory interpretation has a substantial number of followers - that IS the problem. Richards view works only in the UK and fails terribly in Germany and other countries. But sorry, I really am fed up with the pointless discussions on this matter, so I'll refrain from plucking apart the details. It has all been said before. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path vs footway vs cycleway vs...
Hi! Cartinus schrieb: On Sunday 29 November 2009 22:53:58 Nop wrote: Richards view works only in the UK and fails terribly in Germany and other countries. Richards view works in a lot more countries than the UK. You can see it even works in Germany by just looking at how Germany is currently mapped. Fuzzy logic is flexible and extensible, that's why it works. Let me apply your logic to a different use case. Just imagine that in my country there is a law that generally allows bicycles to use a one-way road in both directions. So I would define one-way as mainly or exclusively intended for use in one direction, bicycles may use both and I claim that this is sufficient. If you have a more rigid law where one-way is strictly for all vehicles, it does not matter, fuzzy logic is good. Right? I don't think so. But again, it is a waste of time to discuss whether there is a problem at all when we have chaotic and contradictory tagging for very basic use cases. That is a problem. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path vs footway vs cycleway vs...
Hi! Steve Bennett schrieb: Before you go, do you think there is potential at least to have consistency within each country? It would be possible to solve the problem for each country. It would also be possible to solve the problem generically for the whole planet. The real problem is that many people claim that there is no problem or that they have already solved it and everybody should just do as they do. Several of the approaches would work on their own if they were completed to cover all use cases - but not with other interpretations using the same tags in different ways thrown in between. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path vs footway vs cycleway vs...
Hi! Roy Wallace schrieb: The newbie reading these conflicting responses either 1) becomes confused, or 2) begins to think that best practice is to invent your own meaning for existing tags and then pass this secret knowledge on to only the newbies who ask via email. This is not a good outcome. The newbie - who usually assumes that there is a simple and straightforward answer to the simple question how to I tag a footway - becomes confused - and frustrated that such a basic thing is unsolved and not looking like it's going to be solved one of these years. To the newcomer, this is somewhere between unexpected and crazy. So if consistency is the goal, you cannot rely on various personal opinions that exist only in people's minds and in email discussions from time to time (which no doubt only a small proportion of mappers ever read). You must write it down for reference. And if what's written down has flaws, they must be fixed. No help there. The major contractiory interpretations of the tags around this topic are all documented in the wiki in contradictory ways. It just depends on which page you find first and what conlusions you derive from rather fuzzy definitions. Note also that by the wiki serving as a reference I do not mean that the wiki page for, say, footway must give only the one true definition. It should 1) document the usage of tags as they occur in the database, 2) detail any ongoing controversy and 3) if a consensus exists, give a clear recommendation on how the tag should be used by new mappers. 1) The same tags are used with up to 5 different meanings - usually one wiki page only states one interpretation, but there are many different pages. 2) AFAIK the only attempt at a neutral display of the different opinions is here: http://wiki.openstreetmap.org/wiki/Consolidation_footway_cycleway_path 3) There has never been anything approaching a consensus. Not even close. The discussion has been going around in circles since I first thought there had to be a simple answer to a simple question. Which is about a year. :-) bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] Besondere Gefahrenstellen im Straßenv erkehr
Hi! Ich kennzeichne Gefahrenstellen (allerdings eher Gefahren für Fußgänger und Radler) mit dem Tag hazard. Das war laut Tagwatch am häufigsten dafür in Gebrauch. Hab' damals auch ein Proposal dafür formuliert: http://wiki.openstreetmap.org/wiki/Proposed_features/Hazard_warning bye Nop -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tags an Relations vs. Tags am Way
Hi! Es wird empfohlen, bei Multipolygon-Relationen bevorzugt Tags an der Relation zu setzen und nicht an den einzelnen Ways. Da die meisten Tools sowas noch nicht auswerten können, werden häufig auch zusätzlich die Tags direkt an den Ways gesetzt. Daß man bei solchen Konstrukten schnell die Übersicht verliert, zeigt eine Auswertung, die ich mal in den Lauf von Composer nebenbei eingebaut habe. Sie zeigt die Inkonsistenzen auf, die dabei in kurzer Zeit bereits entstanden sind. Die Liste beinhaltet die Ways nach folgenden Kritierien: - Multipolygon-Relationen in D/A/CH - Es sind Tags an der Relation gesetzt - Es gibt dieselben Tags auch direkt am Objekt - Der Inhalt der Tags an Relation und Way stimmt nicht überein Damit ist nicht mehr klar, was eigentlich gemeint ist bzw. welches Tag ein Tool letztendlich auswertet. bye Nop Conflicting relation tag CLC:code for way 42376705 Conflicting relation tag CLC:code for way 42463894 Conflicting relation tag CLC:code for way 43903898 Conflicting relation tag CLC:id for way 42376705 Conflicting relation tag CLC:id for way 42463894 Conflicting relation tag amenity for way 39685961 Conflicting relation tag amenity for way 39685962 Conflicting relation tag building for way 24595410 Conflicting relation tag building for way 33188113 Conflicting relation tag denomination for way 39671759 Conflicting relation tag landuse for way 25776616 Conflicting relation tag landuse for way 26519445 Conflicting relation tag landuse for way 27606108 Conflicting relation tag landuse for way 27774699 Conflicting relation tag landuse for way 28197648 Conflicting relation tag landuse for way 28462598 Conflicting relation tag landuse for way 30737036 Conflicting relation tag landuse for way 32977366 Conflicting relation tag landuse for way 35089567 Conflicting relation tag landuse for way 35089572 Conflicting relation tag landuse for way 35421524 Conflicting relation tag landuse for way 35797769 Conflicting relation tag landuse for way 39301364 Conflicting relation tag landuse for way 39301371 Conflicting relation tag landuse for way 42317300 Conflicting relation tag name for way 10054545 Conflicting relation tag name for way 13007353 Conflicting relation tag name for way 13207715 Conflicting relation tag name for way 13858691 Conflicting relation tag name for way 15241539 Conflicting relation tag name for way 15587527 Conflicting relation tag name for way 15805019 Conflicting relation tag name for way 15975049 Conflicting relation tag name for way 15976893 Conflicting relation tag name for way 17704533 Conflicting relation tag name for way 18650301 Conflicting relation tag name for way 18825494 Conflicting relation tag name for way 19428440 Conflicting relation tag name for way 21155836 Conflicting relation tag name for way 22737653 Conflicting relation tag name for way 22754798 Conflicting relation tag name for way 23065583 Conflicting relation tag name for way 23118578 Conflicting relation tag name for way 23213319 Conflicting relation tag name for way 23288215 Conflicting relation tag name for way 23321484 Conflicting relation tag name for way 2332 Conflicting relation tag name for way 23450045 Conflicting relation tag name for way 23837585 Conflicting relation tag name for way 24013646 Conflicting relation tag name for way 24238761 Conflicting relation tag name for way 24262321 Conflicting relation tag name for way 24378138 Conflicting relation tag name for way 24591269 Conflicting relation tag name for way 24694668 Conflicting relation tag name for way 24795974 Conflicting relation tag name for way 24938759 Conflicting relation tag name for way 25196339 Conflicting relation tag name for way 25533205 Conflicting relation tag name for way 25645566 Conflicting relation tag name for way 25791579 Conflicting relation tag name for way 25823946 Conflicting relation tag name for way 26419086 Conflicting relation tag name for way 26443912 Conflicting relation tag name for way 26519445 Conflicting relation tag name for way 26658759 Conflicting relation tag name for way 27066777 Conflicting relation tag name for way 27107749 Conflicting relation tag name for way 27145914 Conflicting relation tag name for way 27633228 Conflicting relation tag name for way 27633269 Conflicting relation tag name for way 27774699 Conflicting relation tag name for way 27774699 Conflicting relation tag name for way 27917646 Conflicting relation tag name for way 27917816 Conflicting relation tag name for way 28005571 Conflicting relation tag name for way 28197648 Conflicting relation tag name for way 28197648 Conflicting relation tag name for way 28359908 Conflicting relation tag name for way 28383739 Conflicting relation tag name for way 28465351 Conflicting relation tag name for way 28475228 Conflicting relation tag name for way 28520237 Conflicting relation tag name for way 28659446 Conflicting relation tag name for way 28692974 Conflicting relation tag name for way 28801457 Conflicting
Re: [Talk-de] Wanderwege-Overlay Hillshading
Hi! Karl Eichwalder schrieb: Das Relief (topo) ist auch sehr schon und nutzlich. Es sollte, finde ich, nur etwas kontrasreicher sein. Ich wurde fur die Linien ein Schwarz-Braun nehmen und die Hohenangaben unbedingt richtig tiefschwarz anzeigen; wenn das stort, kann man den Layer ja temporar abschalten. Nachdem die Relieflayers von der Uni Bonn bzw. von mir erzeugt werden, ist deren Design festgelegt. Ich find's zudem nicht ganz optimal, dass durch diesen Layer ein Grauschleier uber die gesamte Karte gelegt wird. Ist das technisch bedingt? Ja. Wenn Du mehrere Layers einfach übereinanderlegst und transparent machst, addieren sich deren Farben immer in Richtung Grau. Dadurch wird der Gesamteindruck blasser. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der?Geofabrik
Hi! Sven Geggus schrieb: Mit welchen Parametern bzw. welcher areas.list werden denn die Tiles erzeugt? Dynamisch nach Vorgabe des Tilesplitters. Klappt also nicht. Man kann ihn dohc auch zwingen, eine vorhandene areas.list zu nutzen. Könnte man die nicht entsprechend präparieren? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Anfängerfehler - Frankengebirgsweg ge löscht
Hallo! Da wurden versehentlich alle Members aus der Relation des Frankengebirgswegs gelöscht. http://www.openstreetmap.org/browse/relation/54807 Könnte das bitte jemand auf die vorhergehende Version zurückdrehen? danke Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Topo-Layer der Geofabrik
Hi! Colin Marquardt schrieb: Ich arbeite im Moment an einer leicht anderen Art des Hillshadings - da steckt die Information im Alpha-Kanal, und der Browser multipliziert einem das zusammen. Damit kann man jede flache Karte mit Hillshading versehen. Das Hillshading seht sehr schön aus. Woher nimmst Du die Höhendaten und wie gehst Du mit dem leidigen Lizenzproblem um? Ich finde keinen Hinweis auf der Karte. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Topo-Layer der Geofabrik
Hallo! Colin Marquardt schrieb: Das sind die rohen SRTM-Daten der NASA (kein CGIAR), aufbereitet wie in http://wiki.openstreetmap.org/wiki/HikingBikingMaps beschrieben, dann die GeoTIFFs mit Mapnik eingelesen und als Tiles rausgeschrieben: Danke für die Info. Das mit dem RasterSymbolizer in Mapnik funktioniert ja erstaunlich gut zu funktionierten. Brauchst Du dafür eigentlich ein riesiges Bitmap oder läßt sich das in Tiles aufteilen? Ich bin nur beim dem Satz Ziel ist eine weltweite Abdeckung gestolpert, nachdem die NASA Rohdaten für die Hochgebirge nicht zu gebrauchen sind. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] pfoten-weg mal wieder
Hallo! Frederik Ramm schrieb: Ich habe den Benutzer jetzt mal fuer 12h gesperrt mit der Bitte, uns zu erklaeren, wie es zu dieser offensichtlichen Softwarefehlfunktion kommt. Gab es eigentlich eine Reaktion in irgendeiner Form? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Fwd: Seamark/Marine-Tagging-Proposal open for Voting
Zur Info: Original-Nachricht Datum: Wed, 11 Nov 2009 13:15:14 +0100 Von: Mario Salvini salv...@t-online.de An: talk@openstreetmap.org Betreff: [OSM-talk] Seamark/Marine-Tagging-Proposal open for Voting http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging. Let's vote or continue discussing critical details. Best Regard Mario ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- DSL-Preisknaller: DSL Komplettpakete von GMX schon für 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] Topo-Layer der Geofabrik
Hi! Evtl. kannst du den Topo-Layer von http://topo.geofabrik.de/ verwenden. Die dürfte nicht passen. Die Relief-Layer der Uni Bonn ist transparent und liegt über der gesamten Karte. Das Relief von der Wanderkarte ist undurchsichtig und liegt unter der Karte, damit Straßen, POIs usw. nicht mit Reliefschatten überdeckt werden. bye Nop -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fwd: [OSM-talk] Seamark/Marine-Tagging-Proposal open for Voting
Zur Info: Original-Nachricht Datum: Wed, 11 Nov 2009 13:15:14 +0100 Von: Mario Salvini salv...@t-online.de An: t...@openstreetmap.org Betreff: [OSM-talk] Seamark/Marine-Tagging-Proposal open for Voting http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging. Let's vote or continue discussing critical details. Best Regard Mario ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- DSL-Preisknaller: DSL Komplettpakete von GMX schon für 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Topo-Layer der Geofabrik
Hallo! Sarah Hoffmann schrieb: Insofern würde ich mich freuen, wenn ich die Tiles als alternativen Relief-Layer anbieten könnte. Was meinen du und Frederik (als Serverbetreiber) dazu? Wäre das okay? Klar kannst Du die verwenden, aber berücksichtige bitte bei der Attribution auch die abweichende Lizenz der Layer durch Verwendung von NC-CGIAR Daten. bye Nop PS: Mir ist gerade aufgefallen, daß die Layer der Uni Bonn die gleiche Datengrundlage und Lizenz benutzt, es fehlt aber ein Hinweis darauf auf Deiner Karte und der von CIAT geforderte Attributionstext ist auch nirgendwo zu finden. Die Mischlizenz, unter der Deine Karte steht ist derzeit nicht einfach zu erkennen, bitte stell' das doch noch klar. Momentan würde man als Leser eher annehmen, das ist alles CC-BY-SA und leicht einen Lizenzverstoß gegen die CIAT NC-Lizenz begehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Hi! Und so soll das dann denmächst, für alle SeeZeichen aussehen? da blickt doch zum 1. Keiner mehr auf Dauer durch und zum 2. is der Pflegeaufwand enorm, weil doppelt so groß. Yep, ist unübersichtlich, aber wenn Ihr Euch nicht auf ein gemeinsames Tagging-Schema einigen könnt, dann gibt es eben erst mal zwei Sätze an Tags. Der Aufwand steigt dabei nicht, es kann sich ja jeder raussuchen, welchen Satz er pflegt oder ob er beide nimmt. Auf jeden Fall kein Grund, einfach Tags wegzulöschen, die andere Leute pflegen und benutzen wollen. Du willst schließlich auch nicht, daß man zum Aufräumen Deine Version der Tags löscht, oder? Ignorier sie einfach und alles ist in Ordnung. Wenn jetzt einer auf die Idee käme allen Ways mit highway= ein neues System einzuführen ala way:street=primary und das überall einpflegen würde, ansonsten aber identische Values nehmen würde, wäre das dann auch allerseits verständlich und akzeptiert, oder würde man sich über die völlig unnötige Redundanz wundern? Man würde sich wundern - und die Tags ignorieren. Übrigens ein gutes Beispiel, es gibt solche alternativen Highway-Tags tatsächlich. Schau mal in Tagwatch, da wirst Du zahlreiche Tags nach dem Schema highway:plan.at:* finden. Sie gehören zu einem Import, mit dem die meisten Mapper nix am Hut haben, aber stören die normalen highways nicht, alle ignorieren sie und erstaunlicherweise gibt es überhaupt kein Problem mit denen. bye Nop -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Hi! Genießt nun das seamark:-Schema einen Sonderstatus? Nein, die seamark:-Tags sind genau wie alle anderen auch. Es sollten grundsätzlich keine unbekannten Tags ohne Rückfrage einfach gelöscht werden. Und erst recht nicht, wenn Dir bewußt ist, daß sie jemand pflegt, benutzt und rendert. Ein solches Verhalten wird je nach Geschmack als schlechter Stil, Edit War oder Vandalismus verstanden. Das gilt für alle Tags, auch für solche für die Du selbst lieber eine Alternative benutzt. Dort, wo deren traditionellen Testbereiche liegen (Häfen Rostock, Kiel, Fehmarn), ändere ich die Daten i.d.R. nicht. Eben weil ich weiß, daß dort getestet wird. Z.B. auf Fehmarn haben wir unsere Tonnen sogar gelöscht, um Platz zu machen :-) Deine Haltung verstehe ich nicht. Es ist nicht nötig Platz zu machen. Es gibt keine Konflikte. Werte aus, was Deinem Tagging-Schema entspricht und ignoriere alles, was Deinem Tagging-Schema nicht entspricht. So einfach ist das. Ansonsten glaube ich aber, daß ein Standard anzustreben ist. Und da gehört ein wenig Datenpflege dazu. Du wirst keinen Standard durchsetzen können, indem Du täglich alles weglöscht, was nicht Deinem Standard entspricht. bye Nop -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Hi! Mario Salvini schrieb: es geht doch garnicht darum ob was gelöscht wird, oder nicht. Doch. Es geht ausschließlich um das Löschen von fremden Daten. Es geht mehr darum, gemeinsam OSM voranzutreiben. In der OSM-Wiki gibts ein Proposal, was genau dass versucht (mit einiger Beteiligung aus Skandinavien, Deutschland und USA). Leute von OseamM beteiligen sich , trotz mehrfachem Bitten, bis jetzt leider nicht daran, wobei Sie echt gute Unterstützung geben könnten. Dafür wird es wohl Gründe geben, aber das tut alles nichts zur Sache. Es geht einzig und allein darum, daß jeder ein alternatives Tagging-Schema ausprobieren darf, wenn er dabei nichts Bestehendes kaputt macht. Egal ob es da schon was gibt und egal was im Wiki steht und egal warum er es benutzen will. Alternativen Ansätzen täglich ihre Tags zu löschen ist eine merkwürdige Auffassung von gemeinsam OSM voranzutreiben. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relevanzregeln für OpenStreetMap?
Hallo allerseits! IMHO kann man die Wikipedia mit OSM nur schlecht vergleichen. In einem Wikipedia-Artikel muß sich jeder Leser/Sucher durch den gesamten Text kämpfen, weniger relevante Inhalte erschweren also die Benutzung und senken die Qualität. Bei OSM dagegen ist der Datenbestand nicht direkt sichtbar, sondern wird erst durch Renderer oder Tools aufbereitet. Dabei fallen nicht explizit angeforderte Informationen meistens automatisch weg. Ein zusätzlicher, irrelevanter Inhalt stört also grundsätzlich nicht - nur mißverständlich oder falsch eingetragene Dinge belasten das Projekt. Außerdem haben wir da noch den chaotisch-statistischen Ansatz von OSM: Wenn Du einen neuen Vorschlag hast, verwende ihn einfach mal und wenn die Idee gut war, wird es sich schon durchsetzen. Das verträgt sich nicht wirklich mit Relevanzregeln, jeder neue Vorschlag dürfte der Mehrheit, die nicht damit arbeitet, erst mal als unbedeutend erscheinen. Zu guter letzt haben wir es bisher nicht geschafft, uns auf das Tagging von Basiselementen wie Radwegen zu einigen, da möchte ich nicht wirklch versuchen einen Konsens für Relevanzregeln auszudiskutieren. :-) Wie wäre es mit Erst fragen, dann löschen? D.h. im Zweifelsfall wird erst einmal derjenige kontaktiert, der die Daten eingetragen hat. nun, so mache ich es eigentlich immer, wenn mir seltsame Enträge über den Weg laufen. Wie lange sollte ich auf eine Antwort warten? Einen Tag? Eine Woche? Bis Weihnachten? Ich denke auch, eine Frist von 3-4 Wochen sollte angemessen sein, um übliche Urlaube und Offlinezeiten zu erlauben. Wenn danach jemand scheinbar gar nicht mehr aktiv ist, muß schließlich jemand anders übernehmen und aufräumen. Wie würdet Ihr eigentlich damit umgehen, wenn jemand heute schon etwas übereifrig Dinge als nicht relevant löscht, die andere Leute eingetragen haben und auch durchaus benutzen wollen? Also ich meine natürlich wenn anschreiben nichts bringt. bye Nop -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Hi! Jan Jesse schrieb: Das gegenwärtige Tagging-Schema ist nebenbei nicht Produkt der FreieTonne, es wurde im Wiki entwickelt, und wir haben es übernommen. Weil eben kein anderes da war. Die Diskussion dazu war transatlantisch und wie ich meine, erfolgreich. Zumindest haben wir ein Ergebnis. Erst mal vorangeschickt: Ich würde mich freuen, wenn es für alles einen eindeutigen und klar geregelten Weg gäbe, wie es in OSM zu taggen ist. Aber ich habe inzwischen verstanden, daß dem nicht so ist und daß OSM nicht so funktioniert. Nur weil Du Dein Schema für gut, ausreichend und erfolgreich hältst, ist das kein Grund, daß sich jemand anders nicht für eine Alternative entscheiden darf, insbesondere wenn diese Alternative sich nicht mit Deinem Schema überschneidet und daher völlig neutral danebensteht. OpenSeamap hat auch ein Ergebnis, und der hauptsächliche Grund, daß dieses Ergebnis in OSM noch nicht wirklich sichtbar ist, liegt daran daß die dafür nötigen Tags innerhalb eines Tages von freietonne_db gelöscht werden. Ich habe jeden Eintrag händisch geprüft, und keine Information gelöscht. Das mache ich fast täglich, und es sollte in Ordnung gehen. Wir führen übrigens auch die History zu jedem Eintrag, eliminieren Dopplungen usw. Jeder mag prüfen, ob das so geht. Du hast mit diesen Tags wesentliche Informationen gelöscht, die von OpenSeamap benötigt werden. Wie schon von anderen gesagt und im Relevanzthread diskutiert gibt es keinen Grund, bei OSM Tags zu löschen, nur weil Du sie für redundant hältst. Und spätestens mit dieser Maildiskussion weißt Du jetzt auch, daß sie nicht redundant sind, sondern definitiv benötigt und ausgewertet werden. Die Tags ohne Rückfrage mit dem Ersteller zu löschen gilt bei OSM als sehr schlechter Stil. Was Du da machst, ist keine Qualitätskontrolle, sondern ein destruktiver Eingriff in ein von anderen Leuten aufgebautes Tagging Schema. Wenn dieses Schema umständllich/unhandlich oder sonst irgendwie ungeeignet sein sollte, dann wird es sich nicht lange halten und/oder geändert werden. Aber das ist dann Sache von den Leuten, die es betreiben. Die Philosophie von OSM gestattet es auf jeden Fall jedem, mit neuen Tags zu experimentieren, zumindest solange er bestehende Daten nicht überschreibt. Ich fände es wirklich sehr schade, wenn die Energie beider Projekte in Grabenkämpfe über den einzig richtigen Weg verpuffen würde! Da bin ich ganz bei Dir. Und wir sind nicht auf der Suche nach dem einzig richtigen Weg. Aber wir entwickeln uns. Unser erstes Tagging-Schema war das von Markus. Da kam die Diskussion um Sprechende Tags auf, und wir haben das neue Schema von Olaf benutzt. Daraus hat sich schließlich im Wiki das derzeitige Schema entwickelt. Und die FreieTonne hat das jeweils nur übernommen, sich angepaßt. Dann laß die seamark:-Tags einfach in Ruhe und beide Projekte können sich entwickeln und vielleicht auch noch was voneinander lernen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Projection for processed_p.shp?
Hi! I am trying to convert an excerpt from the processed_p.shp for mapnik coastline rendering back to .osm with shp-to-osm.jar. This application requires a .prj projection file, but there is none included with the shape files. Does anyone have a matching .prj file for the processed_p shapes or does know how to create one? I'm completely lost there. thanks Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] OSM Composer sucht Unterstützung
Hallo! OSM Composer soll die Hürde für das Gestalten und Erstellen eigener (Garmin) Karten verringern. Die Zielgruppe sind normale Anwender ohne tiefen technischen Hintergrund, Kommandozeilenbegeisterung und viel, viel Zeit zum Rumprobieren. Das Mittel ist eine konsistente graphische Oberfläche, die sich um die ganzen fitzeligen Details kümmert. Bisher wurde OSM Composer hauptsächlich in Richtung auf mein eigenes Interesse Wanderkarte und mit dem Feedback aus der Community entwickelt. Jetzt wollte ich mal rumfragen, ob jemand Lust hätte, konkret mit daran zu arbeiten, Composer für weitere Anwendungsgebiete zu öffnen. Dabei gäbe es auch einige interessante Dinge, für die keine Programmierkenntnisse erforderlich sind, das wäre also kein Hindernis. Konkret dachte ich an Themen wie: - Alternative Kartenstile: Composer kommt standardmäßig konfiguriert für eine Topo-Wanderkarte. Vielleicht hätte jemand Lust, alternative Regelsätze zu pflegen, die man dann als Ausgangsbasis für andere Karten verwenden kann. Z.B. eine Straßenkarte. - Bessere Benutzeroberfläche: Die Listendarstellung in Composer ist zwar übersichtlicher als Befehlsdateien, aber das Zusammenstellen eines Kartendesigns ist immer noch eine reichlich komplexe Aufgabe. Vielleicht hat jemand eine Idee, wie man die Benutzeroberfläche für solche Aufgaben angenehmer gestalten kann, so daß mehr Übersicht entsteht und Regeln leichter editiert werden können? - Unterstützung für Routing: Fehlt in Composer komplett, da es für meine Zwecke nicht erforderlich ist und ich mich da nicht auskenne. Es könnte aber interessant sein, auch Routinginfos in einer graphischen Oberfläche zu konfigurieren und mkgmap damit zu steuern. Damit könnte auch dieses Thema deutlich einfacher werden - aber zuerst müßte es mal jemand austüfteln. Oder hast Du vielleicht noch andere Ideen, was Du gerne damit anstellen würdest? Nop -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Guenther Meyer schrieb: - Und wie stellst Du dann drei Läden in einem Haus dar? siehe martin. Dann mußt Du Dich erst mal mit den Leuten auseinandersetzen, die Deine Listen lieber für diesen Fall (unterschiedlich Läden an einem Ort) einsetzen, und sie überzeugen Deine Interpretation zu verwenden. - Wie stellst Du es dar, wenn die Postfiliale andere Öffnungszeiten hat (durchaus üblich)? den vorschlag dazu gabs auch schon mal vor ein paar wochen. Soweit ich mich erinnern kann, paßte der aber nicht in Dein Konzept. Die Frage war schon mit Bedacht gestellt. Erklär das doch mal. das beispiel erscheint mir unsinnig. die tracktypes sind recht klar definiert. man sollte sich aufgrund der dokumentation durchaus fuer eins davon entscheiden koennen. Das Besipiel stammt von TagWatch und kommt dort öfters vor. :-) nur weil listen fuer viele dinge eine einfache und praktische loesung darstellen, heisst das nicht, das sie fuer jedes tag sinnvoll sind! Siehst Du, genau das ist das Problem. Dur redest nicht von einer halbwegs allgemeinen Lösung, sondern von Einzelfallregelungen, die dann für jedes Tag, jeden Use Case und jede Tagkombination anders aussehen können. Das ist weder eine allgemein anwendbare Lösung noch technisch mit vernünftigem Aufwand umzusetzen. Ein Programm, daß auf einen ; stößt weiß ohne ausimplementierten Spezialfallkatalog nicht, was es damit anfangen soll. Das verstehe ich unter nicht so einfach. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Es ist einfach müssig, Tagging-Schemen aufgrund irgendwelcher Software- Anforderungen auszuwählen. Dafür gibt es viel zu viele Anwendungs- möglichkeiten der OSM-Daten, die alle anders funktionieren. Die Software muss sich da einfach an das existierende anpassen. Es wäre vermutlich recht einfach, osm2psql so umzuprogrammieren, dass es mit recyling:...-Tags zurechtkommt, aber genauso hat der OSM-Composer nicht die geringsten Probleme damit, das osmc:symbol-Tag zu verstehen, dass mit Doppelpunkt-getrennten Werten daherkommt. Das ist aber nur deshalb einfach, weil es eine genau definierte Syntax hat und nur für ein einziges Tag für genau einen Anwendungsfall dient. Es ist auch Absicht, daß hier nicht das ; verwendet wird, da es sich nicht um eine Listendarstellung handelt sondern z.B. die Reihenfolge und die Anzahl eine wichtige Rolle spielen. Ich halte es für ausgesprochen kontraproduktiv, wenn Programme wie osm2pgsql eine Ausnahmebehandlung für einzelne Tags - und die auch noch für nationale Spezialfälle - implementieren würden, nur weil es schlichtweg kein Konzept dafür gibt, wie Mehrfachwerte konsistent notiert werden können. Da sehe ich es als Voraussetzung, erst mal an einem deutlich universelleren Taggingschema für Mehrfachwerte zu arbeiten, das mehr als einen Anwendungsfall gleichzeitig berücksichtigt, und vor allem Bedeutung, Anwendungsfälle, Regeln für unpassende Anwendungsfälle und Auswerteregeln im Wiki zu dokumentieren. Da stehen wir aber noch total am Anfang. bye Nop -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Composer V0.8rc1 verfügbar
Hallo! Nach längerer Stille gibt es eine neue Version 0.8 von Composer, die einiges an Neuerungen bringt. Nachdem ein großer Teil der Engine von grundauf umgeschrieben wurde und einige neue Funktionen hinzugekommen sind, nenne ich diese Version erst mal Release Candidate 1. Sie funktioniert zwar hier bei mir einwandfrei, aber es würde mich wundern, wenn sich da nicht noch ein ungeplantes Feature findet. Die wesentlichen Änderungen sind: * Intelligente Aufteilung der Karte in Kacheln (unter Berücksichtigung der Höhenlinien) * Kurze Wegstücke auf einer Route werden zusammengefaßt und ebenfalls mit Wandermarkierungen versehen * Verbesserte Höhenlinien (korrekt positioniert, weniger Artefakte, mit Splines abgerundet) * Speicherbedarf bei Kartenerstellung deutlich geringer * Höhere Geschwindigkeit und Ausnutzung von Doppelkernen durch Multithreading * Unterstützung für MapSource auf 64bit Windows * Verarbeitung kann pausiert werden Mehr Infos und den Download findet Ihr unter [url]http://wiki.openstreetmap.org/wiki/DE:OSM_Composer#OSM_Composer_installieren[/url] Die Tools im Starthilfeset wurden ebenfalls aufgefrischt. Über Euer Feedback zur 0.8rc1 würde ich mich natürlich freuen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Suggestion for JOSM
Hi! Richard Fairhurst schrieb: Potlatch enables you to convert a GPS track to a way by clicking Edit beside the track (in the GPS Traces listing), then selecting Convert track to ways when Potlatch loads. There is no option _not_ to simplify the track on import; it runs Douglas-Peucker over it, and I would commend this forced simplification to the JOSM devs. Ways are automatically split after an interval of n seconds. It is good that simplification is forced. But of course, it will still stupidly add a large zig-zag caused by bad reception to the map. (I have seen beginners manually add such zig-zags before they learn that GPS isn't perfect, but at least they usually learn) How does it take care of crossing other ways without a junction point? bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] Update der Wanderkarte
Hi! Die Garmin-Version der Reit- und Wanderkarte wurde nach einigen technischen Umstellungen endlich mal wieder upgedated. Sie steht wie immer in einer Version für Mapsource und einer direkt für das Gerät zur Verfügung. Was gibt's Neues: - Kartenabdeckung Deutschland/Österreich/Schweiz sowie Norditalien mit Tirol und Gardasee. - Daten vom 25.10.09 - aufbereitete, abgerundete Höhenlinien - bessere Aufteilung in Kacheln, dadurch weniger Einzelkacheln - mehr Wandermarkierungen, auch auf Wegen die vorher zu kurz für die Darstellung waren Daneben hat die Online-Karte jetzt einen Routeneditor, mit dem Routen geplant und als GPX direkt auf den Garmin aufgespielt werden können. Download unter topo.geofabrik.de. bye Nop -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Guenther Meyer schrieb: ich hab das ganze durchaus mal durchgespielt, und denke schon, dass man da zu einem brauchbaren ergebnis kommen kann. nur weil du dir das nicht vorstellen kannst, muss das nicht so sein. Dann stell Deine konsistente Lösung doch mal vor, das ist sicherlich von allgemeinem Interesse. Bisher haben wir nichts Konkretes von Dir gehört. amenity=bakery;postoffice;flowershop opening_hours=Mo-Fr 8:00-19:00;Sa 9:00-16:00 Ist das jetzt: - ein Gebäude mit drei Läden? - ein Laden mit drei Angeboten? - zu wem gehören die Öffnungszeiten? - warum kommt Schmarrn raus, wenn ich das ; bei opening_hours genauso verarbeite wie das ; bei amenity? so wie's da steht? ein laden wo man blumen und brot kaufen kann, und auch postgeschaefte erledigen kann. und dazu die oeffnungszeiten dieses ladens. wo ist das problem? - Und wie stellst Du dann drei Läden in einem Haus dar? - Wie stellst Du es dar, wenn die Postfiliale andere Öffnungszeiten hat (durchaus üblich)? - wie willst Du unterscheiden zwischen einem ; das eine Liste trennt wie beim ersten Tag und einem ; das keine Liste darstellt wie bei den Öffnungszeiten? - und wohin ist eigentlich das Beispiel mit tracktype verschwunden? Da hätte mich Deine Antwort schon interessiert. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Suggestion for JOSM
Hi! Shalabh schrieb: Given my limited understanding of mapping and even more limited understanding of computing, I think it would be better if JOSM assumed the trails to be correct and drew nodes on it on its own. This is possible combining several features. However, it is a bad idea, most ways added this way are in horrible state and need correction. - way too many nodes. The API does not return more than 5 nodes in one request, so many tracks with 1500 nodes each quickly make it impossible to download a sizable area - the GPs is inaccurate. If you just stupidly add the track, all the mismeasurements are added to the DB. While drawing the way, you can smooth out the obvious zigzags of errors and deviations of known bad reception. Also, as the distance of nodes (usually 1m) is way smaller than the basic error of the GPS, it makes no sense to add this sort of misleading pseudo-accuracy - those ways are then unconnected to all other ways. It is very difficult and tedious to create the proper connections - most people who take this easy way don't connect and simplify the way properly, you will often find ways that are simply created over existing, manually edited versions of the same way. So in practice this doesn't work out. If you process your track properly, it is quite some work either way, but using the track directly encourages quick and sloppy adding of bad geometry. It has been suggested several times, that the possibility to do this indirectly be removed from JOSM altogether and having corrected many bad direct uploads I am rather in favour of this. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Guenther Meyer schrieb: Listen wurden noch nie irgendwo ausgewertet - und das hat seinen Grund. nur weil es nicht ausgewertet wird soll es nicht benutzt werden?!? unsinn. es gibt nunmal listen in osm, das ist fakt! Nein. Weil es nicht funktioniert, wird es von keinem Programm ausgewertet und sollte auch nicht benutzt werden. ich weiss nicht, warum's andere programme nicht machen; zumindest bei gpsdrive ist es so, dass noch keiner die zeit dazu hatte, bzw. die prioritaeten im moment woanders liegen. geplant ist es aber... Und sobald es an der Reihe ist und Du es versuchst, wirst Du verstehen: - daß es nur für bestimmte Tags klar und einfach ist was gemeint ist - nur solange genau ein Tag eine Liste enthält, bei mehr als einem ist nicht klar was das bedeuten soll - daß verschiedene Leute das ; mit verschiedenen Bedeutungen einsetzen und Du es deshalb nichts Sinnvolles rauskommt. Hast Du eigentlich jemals in Tagwatch nachgesehen, wie solche Listen überall verwendet werden bevor Du Die Behauptung aufstellst, das sei alles ganz einfach? Wenn jemand anders einen Node sauber und funktionstüchtig eingetragen hat und Du kommst, machst eine Liste aus einigen Tags und sorgst dafür, daß der Node von keinem Tool und keinem Renderer mehr erkannt wird, so würde ich das durchaus auch als kaputtmachen bezeichen. informationen hinzufuegen und dafuer eine bereits bestehende und oft genutzte methode benutzen nennst du kaputtmachen. ja ne, is klar... Ja. Objekte, die einwandrei verarbeitet werden in einen Zustand zu bringen, in dem sie nicht mehr verarbeitet werden können, nenne ich kaputtmachen. Dabei ist es egal, wieviele andere kaputte Objekte es schon gibt. relationen sind schoen und gut - fuer manche dinge. bei anderen bringen sie nur unnoetige komplexitaet rein. es ist EIN laden, also reicht ein node. einfacher geht's nicht. Nein, reicht nicht, weil der logische Zusammenhang zwischen mehreren Tags verloren geht. was geht denn verloren?!? amenity=bakery;postoffice;flowershop opening_hours=Mo-Fr 8:00-19:00;Sa 9:00-16:00 Ist das jetzt: - ein Gebäude mit drei Läden? - ein Laden mit drei Angeboten? - zu wem gehören die Öffnungszeiten? - warum kommt Schmarrn raus, wenn ich das ; bei opening_hours genauso verarbeite wie das ; bei amenity? Oder was ist das: tracktype=grade4; grade3? Das ist ein leidiges Problem, zu dem es mehrere unterschiedliche Lösungsansätze gibt, z.B. auch den Array-ähnliche Tagstrukturen einzuführen. ja, die gibt es. zumindest ich bevorzuge die einfachste loesung, die mich zum ziel bringt. und das ist in diesem fall nicht die relation. Ich bevorzuge die Lösung, die nicht nur im allereinfachsten Fall für ein paar ausgesuchte Tags funktioniert. :-) Wenn es einen Konsens dazu gibt, dann den von allen Tools und allen Renderern, daß das keine gute Idee ist und nicht ausgewertet wird. Möglcherweise wissen die Entwickler ja, warum sie sich in dem Punkt ausnahmsweise alle einig sind. :-) im osm gibt es einige dinge die nicht ueberall implementiert sind. zumindest was dieses thema angeht, koennte ich mich nicht dran erinnern, dass das diese schreibweise irgendwann mal von einem entwickler negativ bewertet wurde. Nicht von einem Entwickler. Von *ALLEN* Entwicklern. Aber vermutlich sind die wohl alle nur zu dumm dazu... :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Garmin eTrex Vista Hcx
Hi! Shalabh schrieb: Would just like to figure out if any of you have had the same issue with this model or any other Garmin GPS. I have a similar Issue with the Garmin Vista HCx. Occasionally I observe, that the GPS position is way off the known road/path I am on. The satellite accuracy is high +-5m. When I switch the device off and on again, it positions me right where I am supposed to be. So it seems to accumulate some sort of error in its internal calculations and needs the occational reset when it is going wrong with great confidence bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Guenther Meyer schrieb: Am Donnerstag 29 Oktober 2009 23:50:21 schrieb Karl Eichwalder: Guenther Meyer d@sordidmusic.com writes: dann muessen das die anwendungen eben lernen. Es ist nicht ganz trivial, wenn auf einmal listen in bestimmten feldern auftauchen. Wenn man so etwas nicht vorab festlegt, sollte man als mapper nicht die alten daten kaputtmachen, sondern zumindest fuer eine uebergangszeit ein passendes tag verwenden, z.b.: wer macht denn was kaputt? listen gabs in osm schon fast immer. ich kann mich auch nicht daran erinnern, dass jemand mal festgelegt hat, dass es pro key nur einen wert geben darf... Listen wurden noch nie irgendwo ausgewertet - und das hat seinen Grund. Wenn jemand anders einen Node sauber und funktionstüchtig eingetragen hat und Du kommst, machst eine Liste aus einigen Tags und sorgst dafür, daß der Node von keinem Tool und keinem Renderer mehr erkannt wird, so würde ich das durchaus auch als kaputtmachen bezeichen. relationen sind schoen und gut - fuer manche dinge. bei anderen bringen sie nur unnoetige komplexitaet rein. es ist EIN laden, also reicht ein node. einfacher geht's nicht. Nein, reicht nicht, weil der logische Zusammenhang zwischen mehreren Tags verloren geht. Das ist ein leidiges Problem, zu dem es mehrere unterschiedliche Lösungsansätze gibt, z.B. auch den Array-ähnliche Tagstrukturen einzuführen. Aber mehrere eindeutige Nodes zu setzen erscheint mir als die vielversprechendste. Dann sind die Daten eindeutig und schlimmstenfalls muß man beim Rendern Objekte zusammenfassen. technisch sehe ich da ueberhaupt keine probleme... Seelig sind... bitte programmier erst mal selber was, bevor du hier mit dummen spruechen kommst! einen string an einem trennzeichen aufsplitten ist sowas von trivial, die resultierenden daten weiterzuverarbeiten ebenso... Vielleicht solltest Du nicht beleidigend werden - vor allem weil er recht hat. :-) Den String selber aufzsplitten, ist kein Thema. Aber damit ist die Sache noch lange nicht erledigt. - Du mußt jedes Objekt duplizieren, für jeden Eintrag in Deiner Liste einen. Das ist viel komplizierter als einfach eine Folge von Objekten zu verarbeiten, was heute alle Tools tun. - Wenn die Kopien die gleiche ID behalten, funktioierne die meisten Mechanismen in Tools nicht mehr, da sich OSM auf eindeutige IDs geeinigt hat. Wenn sie eine unterschiedlcihe ID bekommen, funktionieren Referenzen nicht mehr - Es ist nicht klar, ob sich andere Tags dann auf alle Einträge in der Liste beziehen oder nur auf einen - Wenn mehrere Listen an einem Objekt auftauchen, ist nicht klar ob das dann alternative Werte sein sollen oder eigenständige Listen, die ausmultipliziert werden müssen. Es gibt keine Festlegung über Längenunterschied oder Reihenfolgen - wenn das Objekt von einem Way oder einer Relation referenziert wird, ist nicht klar ob das für alle Kopien gilt oder ob nur bestimmte gemeint sind bzw. es ist nicht möglich, einzelne Listeneinträge einzeln zu referenzieren. Soweit mal die Spitze des Eisbergs. Wenn Du's tatsächlich probierst, dürftest Du noch auf einige interessante Detailproblem stoßen. vor allem ist das semikolon als trenner schon lange in osm vorhanden, es gibt sogar einen gewissen konsens dazu. das es bisher nicht so oft benutzt wurde, mag vielleicht auch daran liegen, dass es vor api 0.6 nicht so die notwendigkeit gab. Wenn es einen Konsens dazu gibt, dann den von allen Tools und allen Renderern, daß das keine gute Idee ist und nicht ausgewertet wird. Möglcherweise wissen die Entwickler ja, warum sie sich in dem Punkt ausnahmsweise alle einig sind. :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Die Wanderkarte wird interaktiv
Hallo! Der Website der Reit- und Wanderkarte wurde um ein paar neue Möglichkeiten erweitert, die die Verwendbarkeit in der Praxis deutlich verbessern sollten. Also zumindest sobald das Wetter dann auch wieder zum Wandern einlädt. :-) Karte editieren Als kleinere Hilfe bietet die Karte jetzt einen direkten Link zum Editieren des aktuellen Kartenausschnitts in Potlatch. Ebenso enthält sie einen Link, der den aktuellen Ausschnitt in JOSM lädt (über das Remote-Plugin). Routen planen Die Karte wurde mit einem Routenplaner integriert. Es können jetzt Routen direkt auf der Karte gezeichnet und bearbeitet werden. Die Routenlänge wird ständig angezeigt. Ein Speichern und Laden von Routen oder Tracks im GPX-Format ist möglich, so daß die Route aufs GPS-Gerät geladen oder mit anderen Programmen ausgetauscht werden kann. Vielen Dank an Harald Kirsch für den Editor. Das Ganze funktioniert soweit, aber es ist noch ganz frisch und wurde bisher nur unter Firefox 3.5 ausprobiert (IE funktioniert nicht). Der letzte Feinschliff fehlt noch und es gibt mit Sicherheit noch einiges zu verbessern. Ihr findet das Ganze wie immer unter http://topo.geofabrik.de Über Euer Feedback zu Problemen, Erfolgen und Verbesserungen würde ich mich freuen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die Wanderkarte wird interaktiv
Hi! Sven Geggus schrieb: Hattest Du immer schon Schnellzugloks an Straßenbahnen? http://topo.geofabrik.de/?lon=8.4715lat=48.9958zoom=15 Nur wenn sie als Eisenbahn-Haltepunkte getaggt sind. :-) Ich finde keinen Fehler. Alle Nodes die ich in dem Ausschnitt geprüft habe, sind als railway=halt getaggt und sollten lat Wiki Eisenbahn sein. Straßenbahn wäre railway=tram_stop sein. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die Wanderkarte wird interaktiv
Hi! Sven Geggus schrieb: Hattest Du immer schon Schnellzugloks an Straßenbahnen? http://topo.geofabrik.de/?lon=8.4715lat=48.9958zoom=15 Nur wenn sie als Eisenbahn-Haltepunkte getaggt sind. :-) Ich finde keinen Fehler. Alle Nodes die ich in dem Ausschnitt geprüft habe, sind als railway=halt getaggt und sollten lat Wiki Eisenbahn sein. Straßenbahn wäre railway=tram_stop sein. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] megalith=dolmen ???
Hi! Jan Tappenbeck schrieb: Nun habe ich gerade in Spanien 2 davon kartiert und stelle mir die Frage ob wir das nicht in megalith=dolmen ändern sollen - von denen wird wohl kaum einer Grosssteingrab verstehen. Dolmen finde ich da deutlich besser. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Mentoren hier?
Hi! Martin Koppenhoefer schrieb: Am 19. Oktober 2009 21:48 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Spätestens bei bz2 hast du dann auf chat/mail/forum dumme Kommentare in der Art dusseliger Windowsbenutzer, da kann ja nicht mal bz2. 1. http://www.google.de/#q=bz2 2. http://de.wikipedia.org/wiki/Bzip2 3. http://gnuwin32.sourceforge.net/packages/bzip2.htm mit einer Googleanfrage (3 Buchstaben) und 2 clicks hat man das eigentlich erschlagen... Ich habe den Eindruck, Du nimmst grundsätzlich Deinen Wissensstand als Maßstab und kannst Dich einfach nicht in die Situation eines Anfängers versetzen, für den diese Antwort völlig unbrauchbar ist. Jemand ohne großen technischen Hintergrund und täglichen Internetaufenthalt kann mit Deiner Antwort überhaupt nichts anfangen. Es geht darum es ganz normalen Leuten einfach zu machen. Im Sinne von *EINFACH* und *VERSTÄNDLICH*. Für normalsterbliche Anwender. Leute die in ihrem Leben niemals die Kommandozeile von ihrem Windows benutzt haben. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Installer (war: OSM Mentoren hier?)
Hi! Ulf Lamping schrieb: Nop schrieb: So könnte ich mir einen Installer vorstellen: Ok, wenn's um fertige Karten geht, paßt natürlich ein Installer besser. Aber so ein Ding wie Du es beschreibst, sollte man z.B. mit NSIS und sendmap in ein paar Tagen fertig haben, mit Ausnahme des Backups, an die Daten auf dem Gerät kommt man so leicht nicht ran. Dann müßte man nur noch den passenden Kartensatz aktuell halten. Müßte nur jemand in die Hand nehmen. bye Nop PS: Nein, ich bin mit der Entwicklung für meine Karte und den OSM Composer vollauf beschäftigt. :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gratulation!
Hi! Frederik Ramm schrieb: Man kann es auch einfach andersrum sagen: Deine Programme und Deine Ideen basieren auf Annahmen, die fuer OSM unzutreffend sind. Deine Programme und Deine Ideen sind fuer OSM ungeeignet. Ist aber gar nicht so verkehrt, immer wieder darauf hinzuweisen. Schließlich entwickelt sich OSM auch weiter und vielleicht paßt es irgendwann dann besser zusammen. Die wilde Sturm- und Drang-Zeit bei OSM, in der jeder Weiße Fleck, der gefüllt wurde gut war, egal wie, dürfte vorbei sein. Man ist sich zwar nicht so recht einig, ob es einer gezielten Entwicklung bedarf oder ob es sich schon alles irgendwie von selbst ergeben wird, aber von einer gewissen Entwicklung geht glaube ich jeder aus. Ebenso ist man sich nicht einig ob OSM ein Spielprojekt ist, das die nächsten 10 Jahre keine professionelle Anwendung unterstützen muß oder ob man der Welt eine echte Alternative zu teuren, proprietären Karten bieten will - aber wenn letzteres das Ziel ist, dann muß man sich definitiv mit den kommerziellen Systemen vergleichen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gratulation!
Hi! Garry schrieb: Es ist nicht der Stand der Technik sondern die Uneinigkeit die bei diesem Problem stört! +1 Exakt das. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Installer (war: OSM Mentoren hier?)
Hallo! Ulf Lamping schrieb: Na ja, den grundlegenden Installer hab ich an einem Abend (oder so) wohl zusammengeschrieben. Eine Auflistung der fertigen OSM Karten, in einem Datenformat mit denen der Installer klarkommt sollte man auch noch hinkriegen können. Man kann ja klein anfangen und schauen ob die Kartenersteller mitziehen. Stimmt. Man müßte unbedingt mindestens einen Kartenersteller mit ins Boot nehmen um sicherzustellen, daß der Installer auch immer Karten findet. Wenn das Serverseitig ständig umgeschmissen wird und der Installer öfters ins Leere greift, dann ist er für den Anwender keine Hilfe sondern nur ein weiteres Ärgernis. Problematisch sehe ich die automatische Erkennung und passende Behandlung der vielen, vielen verschiedenen Garmin Geräte (+ evtl. MapSource) und deren Eigenheiten: - Hat das Gerät Massenspeicher- und/oder sendmap Modus - Kann man das automatisch erkennen (mit NSIS Mitteln)? - Kann man (normal, mini, micro) SD-Card, SDHC oder garnichts reinstecken? - Hängt das (SD/SDHC) auch noch von der Firmware ab? Da würde ich den einfachen Weg gehen und den User sein Gerät einfach in einer Liste auswählen lassen. Das sollte er eigentlich auf die Reihe bringen. Interessant ist eigentlich erst mal nur, ob es eine Grenze bei der Speicherkapazität gibt - die sonstigen Unterschiede zwischen den Garmin Geräten auszuwerten fällt unter Luxusfeature. sendmap ist anscheinend kein open source, das muß man wieder getrennt installieren und ist nur für nicht kommerziellen Gebrauch. Sendmap ist kein Open Source - ich finde aber keine Lizenzeinschränkung gegen Weiterverbreitung, da steht nur Free. Selbst wenn sollte es einem Installer nicht schwerfallen, das auch noch runterzuladen und aufzurufen. Daß es nur für nicht-kommerzielle Anwendung ist, stellt für mich keine praktische Einschränkung dar. Die Zielgruppe für so einen Installer dürfte zu 99% aus privaten Hobbyanwendern bestehen und kann es somit ohne weiteres benutzen. Von den ganzen Fragen später: Warum geht das bei mir nicht mal ganz abgesehen :-) Naja, Support für einen Installer dürfte leichter sein als Support für einen Wust von unverständlichen Kommandozeilentools. :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Installer (war: OSM Mentoren hier?)
Hi! Carsten Schwede schrieb: Na vielleicht wollt ihr mich haben, meine Pfade und die Kachelnamen sind seit ewigen Zeiten konstant, und ich habe die ganze Welt im Angebot. :-) Genau so jemand bräuchte man. Ich persönlich würde mit sendmap eher vorsichtig sein, was das freie Verwenden angeht. Fragt doch einfach mal den Ersteller von QLandkarte (Oliver), der macht das schliesslich auch, und es kommt in die Karten auf dem GPS nicht diese komische Copyrightmeldung von sendmap. Wäre natürlich schöner. Aber da gibt es den Upload nicht als eigenständiges, kleines Tool, oder? Achja, wäre toll, wenn das Ganze auch noch Plattformübergreifend wäre (Java?), damit alle was davon haben, es gibt nämlich wider allen Gerüchten sogar Linuxuser, die nicht die Kommandozeile mit der Muttermilch eingesaugt haben. ;-D Hm, da beißt sich die Katze jetzt in den Schwanz. Für mich ist Java selbstverständlich vorhanden und ich könnte einen Installer in Java brauchen. Für den typischen unbedarften Windows-Nutzer braucht man einen Windows-Installer, um Java erst mal zu installieren. Und ich nehme an in der Zielgruppe der nichtprogrammierenden GPS-Besitzer finden sich überwiegend Windows-Nutzer. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gratulation!
Hi! Mirko Küster schrieb: Ist doch auch oft nur hausgemacht. Eine sehr schöne Darstellung der Geschichte. Es fehlt nur noch der Hinweis, daß das keine kontinuierliche Entwicklung ist, sondern daß es aus jeder der historischen Stufen Leute gibt, die der Neuerung widersprechen, an einem alten Schema festhalten, da es ihrer Meinung nach völlig ausreichend ist, und es so weiter verwenden. Aber ich stimme Dir völlig zu, in dem Chaos macht es keinen Spaß und keinen Sinn, sorgfältig zu arbeiten. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pfoten weg von unseren Daten
Hi! Garry schrieb: Nach einer Sperre seines aktuellen Accounts ist er es wieder. Genau das ist der Sinn, daß eine Accountsperre die Tätigkeit eines Vandalen länger als die 5 Minuten beeinträchtigt, die es braucht einen neuen Account anzulegen. Dem kann er auch entgegenwirken wenn er sich von vorneherein mehrere Accounts zulegt... Seufz. Nein, kann er nicht, wenn die Regel lautet, daß jeder dieser Accounts eine gewisse Menge an sinnvollen/unauffälligen Edits haben muß, bevor er erweiterte Rechte bekommt. War alles im ursprünglichen Vorschlag. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Mentoren hier?
Hi! Ulf Lamping schrieb: Irgendwann mal werden wir einen (Windows ...) Installer haben, der abfragt welchen Bereich (D, Euro, ...) man haben möchte, den runterlädt und ohne allzu große Rückfragen auf dem Garmin installiert. So ähnlich wie der POI Uploader von Garmin. Das würde ich dann als könnte einfacher nicht sein bezeichnen :-) Hm, so was ähnliches gibt es schon. OSM Composer erfordert nur einen Click um eine eigene Garminkarte zu produzieren. Ok, die Gegend muß man noch selber eintragen, aber vorgefertigte Gegenden könnte man ihm auch noch mitgeben wenn das alles ist. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pfoten weg von unseren Daten
Hi! Martin Koppenhoefer schrieb: Das konkrete Ziel war urspruenglich, vermuteten bzw. zum Teil erwiesenen Vandalismus von pfotenweg zu unterbinden. Der ist kein Anfaenger, d.h., die Massnahmen wuerden bei ihm auch gar nicht wirken. Nach einer Sperre seines aktuellen Accounts ist er es wieder. Genau das ist der Sinn, daß eine Accountsperre die Tätigkeit eines Vandalen länger als die 5 Minuten beeinträchtigt, die es braucht einen neuen Account anzulegen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderungs-Einschränkungen für Neua nfänger
Hi! C. Brause schrieb: Wie groß ist die Zahl der neu dazukommenden Mapper eigentlich? Bestünde nicht vllt die Möglichkeit, dass nach einem bestimmten (rel. kurzen) Zeitraum von erfahrenen Mappern geguckt werden kann, was ein neuer Mapper so angestellt hat um zu prüfen, was er so gemacht hat? Dazu bräuchte man die Möglichkeit, aus allen Beiträgen des neuen Benutzers einen räumlichen Mittelpunkt zu bestimmen, um zur Kontrolle einen Mapper in der Gegend zu finden. Das klingt wahrscheinlich wieder einfacher, als es ist. Aber mich interessiert eure Meinung auch zur Umsetzbarkeit. Ein Mentorsystem wäre natürlich ein tolle Sache. Ich fürchte nur daß Du bei Weitem nicht genug freiwillige Korrekturleser für alle neuen Beiträge auftreiben wirst. Achso, und gibt es eigentlich ne Möglichkeit sich eine Art Übersichtskarte anzeigen zu lassen, wo man alles gemappt hat? Würd mich mal interessieren. Sowas kannst Du Dir hier anzeigen lassen: http://www.itoworld.com/product/osm bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gratulation!
Hi! Tirkon schrieb: Ich weiß um die (teilweise noch schlummernden) Vorteile von OSM z.B. für Radfahrer und Fußgänger oder wen auch immer. Da rennst Du bei mir offene Türen ein. Aber ohne Straßen-Grundnetz sind die OSM Potentiale nur sehr viel weniger wert oder unmöglich. Die Entwicklung von OSM in den Großstädten hat es vorgeführt: Erst kamen die Straßen, dann das Weitere. Und auf dem Lande: Wo heute keine Straßen sind, gibt es weder Fußwege noch Anderes. Mit der Straßennavi und dem Routing auf OSM-Daten kann man schon ganz gut leben. Das Problem bei Fußgänger- und Fahrradrouting ist nicht, daß die Daten *fehlen* - die Abdeckung ist in den Ballungsgebieten schon recht gut - sondern daß sie wild durcheinander mit unterschiedlicher Semantik eingetragen sind, weil es seit Jahr und Tag keine Einigung gibt, wie Rad- und Fußwege gemappt werden sollen. Daher ist auch kein sinnvolles Routing möglich. Bei den Konkurrenten gibt es das Problem nicht, da ist für jeden Weg festgelegt wie er attributiert wird. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderungs-Einschränkungen für Neuanfänger
Hallo! Ulf Lamping schrieb: Man muss sehr vorsichtig sein, um hier nicht ein falsches Image zu erzeugen, naemlich das eines elitaeren Clubs, in dem Neuankoemmlinge sich erstmal beweisen muessen. (Wir koennten das ja wie in einer studentischen Burschenschaft organisieren - die neuen heissen Fuechse und muessen erstmal ein Jahr lang die GPS-Geraete der Etablierten putzen und den Batteriewechsel vollziehen.) Es ist doch eigentlich genau andersrum. Bis vor nicht allzu langer Zeit *waren* wir ein elitärer Haufen. Nämlich der Geek, der sich speziell für offene Themen interessierte und in der Lage war den Softwareschlamassel zu bedienen, den wir am Anfang hatten :-) Dem kann ich nur zustimmen. Das was die interessierten Nicht-Geeks nach meiner Erfahrung abschreckt, sind schwer verständliche Software, unvollständige Abläufe zum Selberbasteln, fehlende und veraltete Anleitungen - und auch das Fehlen von einfachen Regeln, wie etwas zu taggen ist (bedingt durch die Uneinigkeit bei OSM darüber). Ich glaube nicht, daß ein paar Sicherheitsregeln, die 95% der Einsteiger bei seiner Tätigkeit nicht mal bemerkt, negativ aufstößt. Das scheint mir ungefär so wie die BY-SA-Lizenz - eigentlich eine enorme Einschränkung, aber man kann sehr lange bei OSM mitarbeiten ohne das jemals wahrzunehmen. Meiner Ansicht nach überwiegt da die erschreckende Erkenntnis, wenn man mal realisiert hat, daß alles was man bei OSM mühevoll und engagiert einträgt, jederzeit zerstört werden kann und daß man sich dann halt selber drum kümmern darf, es zu restaurieren oder nochmal zu machen. Und noch ein paar mal wenn man Pech hat. Ich halte seit dieser Erkenntnis auch ein Backup meiner Edits. Aber ich bin einer der Freaks, die eigene Karten und Tools bauen und sich das mal eben hinprogrammieren. Womit wir wieder bei elitär sind: die Freaks können ihren Kram sichern, der Normaluser ist aufgeschmissen und darf's nochmal von Hand eintragen. Nun wird die Software langsam immer besser, die Bekanntheit steigt und ein immer größerer Teil der Bevölkerung beginnt OSM überhaupt zur Kenntnis zu nehmen. Damit kommen halt leider auch automatisch immer mehr Deppen, die nur kaputt machen wollen ... Mir kommt das ein wenig so vor, wie die eMail vor der Ankunft des allgemeinen Internets. Die Kommunikation ging über Mailboxnetze und für die Konfiguration eines Fido-Points hat ein Freak schon mal einen ganzen Tag gebraucht. Mail war nicht allgemein bekannt und die Online-Gemeinde war durch die technischen Hürden sehr überschaubar. SPAM-Filter, Virenscanner und Firewalls waren damals tatsächlich noch unnötig. Hat sich aber alles ein wenig geändert, seit AOL jedem regelmäßig einen selbstinstallierenden Mailclient zugeschickt hat. :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderungs-Einschränkungen für Neuanfänger
Hi! Markus schrieb: *Destruktivität* ist immer eine Folge von persönlich erlebter Verletzung. Wenn eine solche Verletzung bei der Arbeit in OSM erfolgte, wäre es hilfreich, den zugrunde liegenden Vorgang zu analysieren und den Konflikt zu lösen. Wenn eine solche Verletzung woanders erfolgte (Chef, Vermieter, Partner, etc), dann hilft es manchmal, dem Betroffenen zu helfen, die zwei Bereiche zu trennen, damit er seinen Frust nicht auf OSM überträgt. Dann gelingt es vielleicht auch, ihn wieder zu produktiver Arbeit zu animieren. Das ist sicher richtig und ein sehr humaner und ehrenvoller Ansatz. Man kann solchen Leuten sicher helfen. Zusätzlich zu technischen Schutzmaßnahmen für unsere Daten, auch für die Leute die auf Gesprächsangebote nicht eingehen. Kontrolle und Sanktionen verschärfen das Problem meistens. Der Destruktive erfährt subjektiv dadurch eine weitere Verletzung und rüstet auf, indem er seine Methoden verfeinert oder grössere Geschütze auffährt. Daraus entwickelt sich eine Eskalations-Spirale, die Feindbilder zementiert und Lösungen verhindert. Politische Beispiele gibt es zuhauf. Das sehe ich anders. Ich denke die meisten Leute, die destruktiv agieren, suchen sich einen Weg ihren Frust auf einfache Art und Weise abzulassen, ein leichtes Opfer sozusagen. Sobald es schwierig, aufwändig, arbeitsintensiv oder gefährlich für diejenigen wird, werden die Meisten auf irgendein anderes Medium ausweichen, wo sie schnell und einfach zum Ziel kommen. Sie wollen ja nicht ein bestimmtes politisches Ziel erreichen wie OSM ist böse und muß aufgehalten werden!. Unter Kontrolle leiden auch alle friedlichen und konstruktiven Menschen. Sie vergiftet auch das soziale Klima. Politische Beispiele gibt es auch dafür zuhauf. *Selbsterfüllende Prophezeiung* kann dazu führen, dass vermehrtes (aufgeregtes) Sprechen über etwas dazu führt, dass das was man eigentlich vermeiden will mit grösserer Wahrscheinlichkeit auftritt. Beispielsweise weil die Aufmerksamkeit selektiv geschärft wird, und assoziativ mit dem Thema dann simple Fehler als Vandalismus fehlinterpretiert werden. Fehler sind kein Vandalismus. Fehler erkennt man an der Reaktion des Verursachers, seiner Bereitschaft zu lernen und es besser zu machen. Vandalismus definiert sich für mich durch fortgesetzte Zerstörung trotz besseren Wissens und keine oder provokative Reaktion auf Hinweise. Ich sehe da wenig Verwechslungsgefahr. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderungs-Einschränkungen für Neuanfänger
Hi! Martin Koppenhoefer schrieb: Mit zunehmender Datendichte und beteiligten Datensammlern werden hingegen zunehmend ideologische Auseinandersetzungen auftreten: - was nun wichtig ist und unbedingt erfasst werden muss kein Problem, jeder erfasst das, was ihm wichtig vorkommt. Autoregulierend. Das ist nicht ganz so einfach. Es ist z.B. nicht klar, ob unterirdische Dinge gemappt werden sollen/dürfen. (U-Bahnen ja, Bäche manchmal?, Kanäle nein???) Die interferieren aber durchaus mit der Erfassung, Darstellung und Prüfung der oberirdischen Features. Schau Dir mal die LHC-Autobahn an. [1]. - ob etwas in einer bestimmten Weise erfasst werden darf, damit der Renderer das dann auch anzeigt (oder eben gerade nicht anzeigt) ist schon geklärt: wir taggen nicht für die Renderer/Router, etc., d.h. tags sollen nur so verwendet werden dass sie das bedeuten, was sie bedeuten, nicht damit eine Anwendung trotzdem oder gerade erst recht funktioniert, obwohl das tag eigentlich was anderes bedeutet (bekanntestes Beispiel: layer). Das stimmt so nicht. Es gibt definitiv mehrere Fraktionen. - Wir taggen nicht für den Renderer - Wir taggen nicht für den Renderer-Extremisten, die auch hochkomplexe Konstrukte entwerfen, die ohne enormen technischen Aufwand gar nicht gerendert werden können - Ich will meine Daten auch auf der Karte sehen Diese Fraktion ist ziemlich groß. Das kannst Du allein schon an den regelmäßigen Fragen sehen Ich habe letzte Woche XXX eingetragen. Warum sehe ich es noch nicht auf der YYY Karte? Also definitiv keine einfache Antwort hier. Und der LHC wurde definitiv nicht für den Renderer getaggt - sondern so daß er erst mal alle bestehenden Karten versaut. Keine gute Idee finde ich. - wann (geschachtelte) Relationen sinnvolle Modellierungen sind s.o.: jeder taggt, was ihm wichtig ist, und widerspricht damit möglichst nicht dem Wiki. Reines Chaos ohne technische Verwertbarkeit. Diese Frage muß definitiv erst noch beantwortet werden. Dafür werden wir mittelfristig Entscheidungsstrukturen festlegen müssen. aha. Und warum? Um das Chaos einzudämmen und auswertbare Daten zu erhalten. Das Jeder-macht-was-er-will Prinzip war gut, um einen Grundstock an Daten schnell aufzubauen, aber langsam ist da ein Anschlag erreicht. Wenn Du die Qualität der Daten verbessern willst, mußt Du schwierigen Themen auch irgendwann mal eine Richtung geben. Derzeit rühren wir nur um und hoffen daß sich was draus entwickelt - wobei bei bestimmten Themen seit einem Jahr keine Bewegung stattgefunden hat. Aber vielleicht sind wir uns ja noch nicht mal darin einig, _daß_ wir die Qualität der Daten verbessern wollen. Und im Vorfeld auch die Editoren. Nein. Die erleichtern höchstens die Eingabe von bestimmten Dingen (presets), aber man kann grundsätzlich immer alles eingeben, weder die Wichtigkeit von features, noch die Art, wie bestimmte Dinge repräsentiert werden, noch die Lagegenauigkeit, noch die Anwendungsgebiete von Relationen werden von den Editoren ex- oder implizit bestimmt. (Ausnahme Lagegenauigkeit z.T. in Potlatch, weil man da nur limitierte Zoomstufen hat, so dass genaues Eingeben sowieso nicht geht *scnr*). Was Markus da schreibt stimmt. Die breite Masse an Mappern und insbesondere an Neueinsteigern will einfach nur Mappen. Nicht über Tags nachdenken, diskutieren und streiten. Am besten auch keine Tags im Wiki nachschlagen und von Hand eintippen. Sie werden im Editor auf den Menüpunkt/Icon klicken, der dem Objekt, daß sie eintragen, entspricht. Der Editor setzt dann das Tag und viele Mapper interessieren sich gar nicht dafür welches Tag das am Ende ist. Umgekehrt, wenn der Editor (oder ein plugin) dem Mapper sagt, etwas sei falsch, dann wird er das akzeptieren und ändern. Damit haben die Editoren eine enorme Macht über das Tagging. Die große Mehrheit der Mapper wird verwenden was auch immer in den Editor Presets steht. Egal ob logisch oder unlogisch, aktuell oder veraltet, mainstream oder exotisch. Persönlich wünsche ich mir: - dass ich in JOSM nicht aus Versehen eine Grenze anfassen kann m.E. ein überbewertetes Thema. Kann man ruhig machen (Freiwillige Selbstbeschränkung für bestimmte Objekte einführen), aber wenn jemand sich so sehr davor fürchtet, aus Versehen und unbemerkt Grenzen zu verschieben, dann sollte er m.E. am Besten gar nichts mappen. Der wird ja auch sonst alles mögliche verschieben und zerstören. Entweder man hat das Editieren halbwegs im Griff, ist aufmerksam und nutzt ggf. Strg+Z, oder man sollte die Finger davon lassen ;-) Dir ist schon klar, daß Du mit dieser Aussage das Mappen dem elitären Kreis ausgebildeter OSM-Kartographen vorbehältst, die bereits den vollen Durchblick über all die kryptischen bunten und gestrichelten Linien haben? :-) Stimme Markus völlig zu. Wenn wir viele Leute für OSM gewinnen wollen, brauchen wir möglichst viele Hilfestellung für bekannte Probleme dieser Art. bye Nop [1] http
[Talk-de] Pfoten weg von unseren Daten
Hallo! Ulf Möller schrieb zum Thema pfoten-weg: Am 2. Oktober hat er einen großen Teil von Schäftlarn (http://osm.org/go/0JANdIOP) gelöscht und neu angelegt, d.h. die Versionsgeschichte fehlt jetzt. Michael Bemmerl schrieb zum Thema pfoten-weg: Jedenfalls hat auch dieser User Objekte ohne Änderung (siehe z.B. die Chronik von Node 323267288 [2]) hochgeladen Frank Jäger schrieb zum Thema pfoten-weg: Er duldet niemand anderes als letzten Autor in den von ihm besetzten Gebieten! Das ist doch mal ein Fall von eindeutigem und fortgesetztem Vandalismus und ein gutes Fallbeispiel für die Frage: Wie kann man sowas in Zukunft unterbinden? Eine einfache Sperre des Accounts kann einen amoklaufenden Bot vorübergehend einbremsen, ist aber für so einen engagierten Übeltäter ziemlich sinnlos, der hat eine Minute später einen neuen. Ich denke, um etwas zu bewirken, müßten neu angelegte Accounts erst mal für eine bestimmte Zeit mit Einschränkungen belegt sein. Das hätte eine doppelte Schutzwirkung: - echte Neueinsteiger werden davon abgehalten, aus Unwissenheit größeren Schaden anzurichten. Ich selber erinnere mich nur zu gut, wie ich anfangs versehentlich einiges ramponiert habe - Vandalen können sich nicht einfach einen neuen Account besorgen und massenhaft Daten beschädigen Die Einschränkungen sollten einem echten Neueinsteiger das normale Mappen erlauben. Solche Einschränkungen könnten sein: - Beschränkung auf eine Gegend. Kaum ein Einsteiger wird gleich über den ganzen Globus verteilt mappen müssen. - Beschränkung auf eine bestimmte Anzahl Änderungen und Löschungen pro Tag. Massenänderungen sind zum Einsteiger-Mappen nicht notwendig. Neuanlegen sollte nicht eingeschränkt werden, da es leicht rückgängig zu machen ist. Nach einer bestimmten Zeit (z.B. 4 Wochen) und einer bestimmten Menge an Edits sollten die Beschränkungen dann wegfallen. Dabei gehe ich davon aus, daß böswillige/unsinnige Edits vor Ablauf der Zeitspanne auffallen würden. Ein normaler Neueinsteiger sollte von solchen Beschränkungen nichts merken, solange er nicht einen groben Fehler macht. Ein Vandale wäre zumindest gezwungen, nach einer Accountsperrung für eine Weile einen braven Mapper zu simulieren, bevor er wieder uneingeschränkten Zugriff erhält. Es wäre auch zu überlegen, ob nicht eine generelle Obergrenze für alle User sinnvoll wäre. Ich kenne jetzt z.B. keine sinnvolle Anwendung, bei der ich eine Million Ways löschen müßte. Daneben wäre auch noch eine technische Schutzmaßnahme sinnvoll: Wenn ein unverändertes Objekt zum akutellen Stand wieder hochgeladen wird, könnte das die API erkennen und einfach ignorieren. Soweit meine Gedanken. Oder wird an dem Thema vielleicht schon irgendwo gearbeitet? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pfoten weg von unseren Daten
Hallo! Simon Kokolakis schrieb: Es bremst vor allem Neueinsteiger und Interessierte, bzw. lässt sie vielleicht schon beim ersten OSM Besuch die Lust daran verlieren. Könntest Du das bitte erklären? Bei welchen typischen Tätigkeiten eines Neueinsteigers würde er denn solche Einschränkungen überhaupt bemerken? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pfoten weg von unseren Daten
Hi! Frederik Ramm schrieb: Das Problem mit pfoten-weg ist aber gerade, dass offensichtlicher Vandalismus meines Erachtens nicht vorliegt. Er nervt, er muellt die Datenbank zu, er verschlechtert irgendwo Daten, weil seiner Ansicht nach seine Version richtig ist - aber all das sind Sachen, die meines Erachtens nicht ausreichen, um ihn gleich rauszuwerfen - man muesste ihm erst offiziell schreiben und genau sagen, was er kuenftig zu unterlassen hat, und dann koennte man ihn rauswerfen, wenn ers trotzdem macht. Ok, nachdem es mir nicht darum geht, die Einordnung dieses konkreten Falles zu diskutieren, stellen wir uns vor, wir haben bereits drei Runden geduldiger Erklärungen hinter uns und User XXX löscht erneut ein ganzes Stadtviertel um es als created_by=XXX wieder hochzuladen und verziert es mit einer Reihe nichtexistenter Industriegebiete. Ein engagierter Uebeltaeter legt sich auch 100 Accounts auf Vorrat an, um Deine Neu-User-Edit-Beschraenkung zu umgehen. Wenn jeder der 100 Accounts wie vorgeschlagen erst nach einer bestimmten Anzahl unauffälliger/sinnvoller Edits unbeschränkt wird, dann würde es nichts bringen, welche auf Vorrat anzulegen. Deine Ideen sind nicht unbedingt ganz schlecht, aber man muss sehr vorsichtig sein mit sowas, sonst geht es uns wie mit der Luftsicherheit: Jeder neue Fall von (versuchtem) Flugzeugterrorismus macht das Fliegen fuer die 99,9% der unbescholtenen Fluggaeste noch nerviger, als es eh schon ist. Man muss also bei der Einfuehrung von OSM-Sicherheitsmassnahmen sehr gut nachdenken, um Leuten keine Steine in den Weg zu legen. Schreibst Du ja auch:; Ein normaler Neueinsteiger sollte von solchen Beschränkungen nichts merken, solange er nicht einen groben Fehler macht. Genau. Ich denke aber trotzdem, man kann (im Gegensatz zu den Belästigungen im Flugverkehr) die Einschränkungen so sinnvoll fassen, daß ein neuer Mapper sie in 99% der Fälle überhaupt nicht bemerkt, außer wenn er versehentlich Berlin von der Karte löscht. Der wird neue Wege hinzufügen, Tags und Wege korrigieren - aber keine Stadtviertel löschen, Kontinente verschieben oder 1 Tags auf einmal ändern. Man muss auch bedenken, dass ein Neueinsteiger ja auch ein neuer Account sein kann, den ein erfahrener User sich gerade fuer einen Import angelegt hat oder so. Wenn Massenimporte sowieso angemeldet und freigegeben werden müssen - wie Du weiter unten beschreibst - dann tritt dieser Sonderfall nicht ein. Für das manuelle Arbeiten sollte jeder User mit einem Account auskommen, oder? Und für automatisierte Bots und Massenimporte gelten dann sowieso Einzelfallregeln. Es wäre auch zu überlegen, ob nicht eine generelle Obergrenze für alle User sinnvoll wäre. Ich kenne jetzt z.B. keine sinnvolle Anwendung, bei der ich eine Million Ways löschen müßte. Ich denke, dass es eine Bot-Policy geben wird, aehnlich der existierenden Code of Conduct, nur dass diese Policy dann zwingend wird und jeder, der sich nicht dran haelt, kriegt seinen Bot-Account weggenommen. Vermutlich wird das ganze aber ausgeweitet auf large volume edits, also auch, wenn Du ohne Bot eine Million Ways loeschen willst, musst Du das *vorher* erklaeren und nicht erst auf Nachfrage hinterher ;-) Das ist natürlich noch besser. Soweit meine Gedanken. Oder wird an dem Thema vielleicht schon irgendwo gearbeitet? Die Data Working Group schlaegt sich mit den nervigsten Faellen rum und sieht sich auch zustaendig bei der Ausarbeitung solcher Regeln. Auf meinen Vorschlag hin ist gerade das sehr sinnvolle block-Feature eingefuehrt worden, bei dem man bestimmten Benutzern den Account so lange blockieren kann, bis sie eine an sie gesandte Nachricht lesen. Damit kann man jemand einen Schuss vor den Bug geben oder jemanden z.B. auf einen Fehler in einem Bot aufmerksam machen oder so, und derjenige wird aber nur minimal gestoert - er braucht ja nur auf gelesen zu klicken und schon kann er weitermachen. Wenn er dann unveraendert weitermacht, hat man auch genug Grund, ihn rauszuwerfen. Das ist ein guter Anfang. Nur rauswerfen kann man ihn derzeit technisch halt nicht, egal was er danach anstellt. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ein-Punkt-Wege
Hallo! Bei der Aufbereitung von OSM-Daten ist mir aufgefallen, daß es zahlreiche Ways im Datenbestand gibt, die nur aus einem einzelnen Node bestehen. Gibt es eigentlich sinnvolle Anwendungen für solche Ein-Punkt-Ways oder sind das Fehler, die gelöscht werden sollten? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] view blocks received?
Hi! Lars Francke schrieb: I'm sure someone else will be able to better answer this question but it seems as if moderators and administrators are able to block certain users from using the API. Actually, could someone explain how this is supposed to protect against vandalism? It appears that if an account is blocked, a vandal can simply create any number of alternate accounts and continue his work - probably much faster than anybody can hand out blocks. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Immer noch Probleme mit der TYP-Datei
Hi! Carsten Schwede schrieb: Dagegen finde ich es äußerst sinnvoll, die OSM-Lizenz anzupassen, wenn sie sinnvolle und legitime Anwendungen verbietet. Wie z.B. alle rein nicht-kommerziellen Verwendungen. Warum sollte denn die kommerzielle Nutzung ausgeschlossen sein? Die Frage lautet: Warum sollte denn eine nicht-kommerzielle Nutzung ausgeschlossen sein? Das ist heute so und verhindert die Zusammenarbeit mit allen Nicht-Kommerziellen Projekten. Davon gibt es eine Menge und OSM schießt sich mit seiner Anti-Kooperationslizenz da gehörig ins Knie. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Immer noch Probleme mit der TYP-Datei
Hi! Carsten Schwede schrieb: Wird echt mal Zeit für die neue Lizenz. Für cgpsmapper vielleicht. Stanislaw ist nicht wirklich kooperativ, ich finde es jedenfalls nicht sehr sinnvoll die Lizenz von OSM an ein Tool (oder mehrere) anzupassen. An der Lizenz von cgpsMapper ist nichts auszusetzen. Er stellt es kostenlos zur Verfügung und es soll kostenlos bleiben. Dagegen finde ich es äußerst sinnvoll, die OSM-Lizenz anzupassen, wenn sie sinnvolle und legitime Anwendungen verbietet. Wie z.B. alle rein nicht-kommerziellen Verwendungen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen in JOSM 2176
Hi! Georg Feddern schrieb: malenki schrieb: Wenn ich die Elemente im Relationseditor auswähle, darf ich für jede Selektion, von der ich wissen will, wo sie liegt, einmal Knöpfchen drücken -.- Diese Handhabung finde ich umständlich. Es war ein Vorzug des (alten) Relationseditors, sofort zu sehen, was man ausgewählt hat und wo das Element liegt. Um eine neue Funktionalität hinzufügen zu können, muss manchmal eine alte aufgegeben werden. Erst die Zukunft wird zeigen, was häufiger benötigt wird. Ich kann mich Malenki nur anschließen. Die Funktion, ein Relationsmember durch einfache Selektion in der Karte zu Highlighten, habe ich ständig benutzt, um eine Übersicht zu bekommen, was was ist, ob alles zusammenpaßt oder irgendwo etwas fehlt. Dafür noch jedesmal einen zweiten Knopf drücken zu müssen ist grausam umständlich. Die Reihenfolge von Relationen händisch sortiert habe ich dagegen noch nie, da sie für die Verarbeitung von Relationen wie Multipolygonen völlig egal ist. Von daher wurde hier mein 100% Use case massiv verschlechtert und dafür ein _für mich_ überflüssiger Use Case vereinfacht. Ich finde es ungeschickt, so eine langjährige Funktionalität mal eben auszubauen bzw. massiv zu erschweren. Es ist übrigens überhaupt nicht nötig, hier über entweder/oder zu diskutieren. Mit einer Checkbox/Radiobutton direkte Auswahl könnte man auch ganz einfach zwischen den beiden Betriebsarten hin- und herschalten und beide Möglichkeiten optimal nutzen. Wie wär's denn damit? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Immer noch Probleme mit der TYP-Datei
Hi! Jan Tappenbeck schrieb: Seit einigen Monaten bearbeite ich meine TYP-Dateien für die Karten mit dem Online-Editor [1] und habe jetzt das Problem das ich beim Hinzufügen eines neuen POI einen internal Error bekommen. Herunterladen klappt dann nicht mehr. Ich würde Dir empfehlen, die TYP-Datei nicht in dem Online-Editor zu bearbeiten, sondern in einer Text-Datei und dann mit cgpsMapper zu compilieren. So weißt Du, daß sie immer frisch ist und nicht irgendwelche Altlasten von zu oft editieren mit sich schleppt. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Keine Wanderkarte mehr nach Garmin Firmware update
Hallo! Nur eine Warnung zur Info: Mit der neusten Firmware für Garmin-Geräte funktioniert die Wanderkarte nicht mehr. Grund ist, daß die Wandersymbole aus mehreren Icons zusammengesetzt werden und Garmin jetzt die Zeichenreihenfolge verändert hat, so daß der Hintergrund über den Vordergrund gemalt wird. Betroffen sind mindestens Nüvi, Orgeon und Colorado Geräte. Weiß jemand ob das im neusten Update für etrex auch geändert ist? Ich werd's mit meinem wunderbar funktionierenden Gerät nicht ausprobieren. :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seebruecke = Pier ?
Heiko Eckenreiter schrieb: Die International Hydrographic Organization (IHO), die hinsichtlich nautischer Kartografie die Standards definiert, sagt: Pier, Jetty: A long, narrow structure extending into the water to afford a berthing place for vessels, to serve as a promenade, etc. (IHO Dictionary, S-32, 5th Edition, 3833) Ich würde mich auch der Definition der IHO anschließen und keine Unterscheidung einer Seebrücke machen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Composer V0.76
Hi! OSM Composer steht in der Version 0.76 zum Download bereit. http://wiki.openstreetmap.org/wiki/DE:OSM_Composer#Download Neu in Version V0.76 * Generieren eines JOSM-Layouts passend zu den Renderregeln in Composer * Automatisches Erzeugen einer Ersetzungsregel um ein Icon auf eine Fläche zu setzen * Trennung der Renderregeln von POIs und Wegmarkierungen * Typ-File mit Großbuchstaben (für Linux) * Nach Erstellen der Karte kann eine Batchdatei aufgerufen werden * Ausführen von mehreren Jobs hintereinander möglich * Link auf die Anleitung eingebaut * Behoben: Invertierte Waldgebiete an Schnittkanten * Behoben: Routen werden bei Verwendung ganzer OSM-Dateien nicht gelesen bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Changes to Key:access wiki page
Hi! Christiaan Welvaart schrieb: I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. It is a good thing that you try to complete and clarify the page. However I must protest the way of doing it: Change the access tag page and only start a discussion on a single mailing list afterwards is not a good way to do this: - some of your best practices may not be quite as universally applicable as you think - some of your changes require discussion - which just started. But for everybody looking at the wiki, it appears your changes are approved recommendations - you are completely circumventing the proposal process, and everybody who is interested in feature changes and is watching the proposal page in order to be informed is simply excluded from the discussion. So in short: Regardless of the content: You should have created your version of the page as a seperate copy, maybe on the discussion page, announced it as a proposal and only changed the main access tag page _after_ some discussion and refinement. I believe even well-meant edits that change the meaning of established feature pages without prior discussion and bypassing everybody watching the proposals are creating chaos and are responsible for some of the confusion we are having about apparently simple tags like footway. So please, don't do it. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] traffic auf der Mailing List (+1)
Hi! Michael Bemmerl schrieb: Jedenfalls scheint auch Island eine OSM-Hochburg zu sein! ;-) Natürlich. Island hat nur eine einzige Fernstraße, da muß das Mapping muß schon sorgfältig diskutiert werden. :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Composer Beschriftungen auf Garmin
Hi! Bodo Meissner schrieb: kann man einstellen, ob man bei bestimmten Objekten die Namen im Garmin angezeigt haben möchte? Und wo der Name bezogen auf das Symbol sein soll? Leider nein. Nach meinem Wissensstand gibt es keinen Weg, die Anzeige von Text im Garmin zu beeinflussen, Textgröße und Positionierung sind für die IDs fest eingebaut. Die einzige Möglichkeit ist es, eine ID zu verwenden, die den eigenen Erwartungen möglichst nahe kommt. Das kann man entweder durch rumprobieren rausfinden oder indem man mit mkgmap die Testkarte mit allen IDs baut und nach einem möglichst passenden Objekt sucht. Bei einem Berg (Poggio della Pagana auf Insel Giglio) ist mir aufgefallen, daß einmal der Name in Großbuchstaben rechts oberhalb des Symbols dargestellt wird und (scheinbar abhängig vom Zoomlevel) zusätzlich ein Kästchen mit dem Namen in Groß-Klein-Schreibung. So einen Effekt habe ich bisher noch nicht beobachtet, würde aber anhand des Verhaltens vermuten, daß da zwei Objekte übereinander liegen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
Hi! elchtrei...@gmx.net schrieb: ich finde es schade, daß in der Reit und Wanderkarte die Restaurants untergehen, wenn die Eigenschaft an einem Gebäude dran hängt. Beispiel ist die Auer Alm, die ist korrekt eingetragen (mit Gebäude) aber leider nicht sichtbar: http://topo.geofabrik.de/?zoom=15lat=47.68901lon=11.67314layers=BT Hier ist eine Alm, welche nicht als Gebäude, nur als Punkt makiert ist, die taucht in der Karte auf: http://topo.geofabrik.de/?zoom=15lat=47.69749lon=11.71578layers=BT Du mußt das nicht schade finden, Du kannst Erweiterungen einfach vorschlagen. :-) Das gleiche Problem besteht bei Spielplätzen, wenn die als Area und nicht als Punkt eingetragen sind. Hast Du dafür ein Beispiel? Spielplätze sollten mit einem eigenen Muster gefüllt werden. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Proliferation of path vs. footway
Hi! Hatto von Hatzfeld schrieb: I appreciate Nop's proposal - but why replace designated by official? I do not see that designated has been used in the past with a meaning differing from what official would be used for in future. Or did I miss anything in this discussion? Yes. :-) Designated is linked to footway/cycleway and there are about 5 different interpretations on what it means, all of them documented somewhere in the Wiki. Official is new and has only one meaning. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
Hi! Hatto von Hatzfeld schrieb: Official is new and has only one meaning. From Map features: official is used for ways dedicated to a certain mode of travel by law. Usually indicated by a traffic sign. I really do not see where the use of designated has differed from this definition. Which of the 5 definitions of designated do you mean? :-) Just read this topic from the beginning and you should understand. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] Farben in JOSM
Hi! GPX-Tracks In JOSM kann man die Farbe für einen GPX-Track einstellen und die merkt er sich sogar. Kann man auch eine Standard-Farbe für GPX-Tracks einstellen, mit der jeder unbekannte Track nach dem Laden eingefärbt wird anstatt dem Grauwert? Hintergrundfarbe In einem JOSM Stil können die Farben für alle möglichen Objekte eingestellt werden. Ist es auch möglich, die Hintergrundfarbe und die für selektierte Elemente per Stil einzustellen? Die gehören ja eigentlich dazu. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Proliferation of path vs. footway
Hi! Nick Whitelegg schrieb: I would prefer that designated does not infer exclusively designated, so that it's possible to have bicycle=designated as well as foot=designated on a shared pathway (signed with a picture of a person and a picture of a bicycle). Agree here. UK bridleways for instance should have foot=designated; horse=designated; bicycle=designated as all three have equal right. It would be a mistake to assume the horse rights are greater than foot/bicycle; they are not. I would similarly guess the shared foot/cycleways in Germany would be similar, i.e. foot=designated; bicycle=designated. Yes, this would work out. And a German bridleway would be horse=dsignated, foot=no, bicycle=no. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
Hi! This discussion seems to be going the same way as it always does - in circles. :-) So I'd like to try again for a more general statement and summary. The need for change First of all, we would need to agree that there actually is a problem and that we need to (re)define something to clarify it. There have again been many mails along the line It is easy and can all be done following existing definitions - if it is done my way. But this is simply not true, the wiki _is_ contradicting itself. The Fuzziness If I summarize all different, contradicitory positions mentioned, what is the meaning if we see footway or cycleway today if we don't know who has tagged it according to which interpretation? highway=cycleway : road-signed or waymarked or suitable/allowed for bicycles or intended for bicycles or intended for mixed use with primary use bicycle bicycle=designated : the same as highway=cycleway by wiki definition highway=footway : road-signed or waymarked or suitable/allowed for pedestrians or intended for pedestrians or intended for mixed use with primary use pedestrians foot=designated : the same as highway=footway by wiki definition In theory, bridleway has the same problems, but it seems that so far nobody has cared about bridleways and so there are not as many contradicting interpretations attached. Conclusion If you don't really care about foot/cycleways or if you are in a country where the rules of traffic generally allow mixed use, this is ok. If you want to tag the strict use cases of legal dedication in Germany or France, this is insufficient. The basic problem is also apparent: A good definition should be unambigous and not include the word or. :-) Solution attempts Finally, I cannot resist the temptation anymore and have to present the two possible solutions I have arrived at. Both are minimum impact solutions and only take into account the currently known use cases. Proposal #1: Unjoin designated Get rid of the idea that cycleway is the same thing as bicycle=designated. Accept that foot/cycleway is fuzzy. Redefine designated to be only used for legally dedicated ways. Likewise seperate foot=designated from footway. This way, foot/cycleway can be used for the lenient use cases like today, but designated can be used to tag the strict use cases. Proposal #2: Introduce offical dedication Leave old tags as they are and accept that foot/cycleway and designated are as fuzzy as described above. Clarify that these tags only give information on possible use, but not about the legal situation. Introduce a new tag biclyce/foot=official to tag the strict use case of road-signed ways or corresponding legal dedication. This way, nothing needs to be changed in existing fuzzy tagging, but real foot/cycleways are simply tagged by adding an official or changing designated to official if appropriate. And again: I believe that these two ways would work as a solution and that they would cause little impact. But I will be happy with any complete and workable solution. In any way we would still have to come to an agreement and implement it the same way in renderers and editors - which seem near impossible. bye Nop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
