Re: [OSM-talk] anonymous edits
On Thu, May 26, 2011 at 10:09 PM, Frederik Ramm frede...@remote.org wrote: Hi, Martijn van Exel wrote: That is exactly why I started this thread - to see how (un)acceptable it is to do (semi) anonymous edits. An important reason against anonymous edits is accountability. We want to be able to contact someone and ask them: Why did you add that? What did you mean by it? Etc. That was my initial thought when the idea came up. Of course you can trace an edit back to a twitter user, but that's one step away from a community member. It's not 100% anonymous, but at least someone who came to the OpenStreetMap web site and made an account (however little effort that takes) at least had a look at OpenStreetMap. But then consider this. We have 400k+ community members of whom, if the ratio has not changed, about 80% never made any edits. Of the 20% remaining, about 80%% is inactive (no editing in the last two months) leaving only about 6% of those 400k+ active mappers. This tells me two things: 1. We need more ways to engage new mappers, to retain them once they show an interest in OSM. The proposed twitter scheme could be one of them. 2. 'Having an OSM account' does not really tell me anything about the involvement of that particular person. Or of their ability to be contacted / held accountable, for that matter. The one thing I do see as a real issue is the legal one. All twitter POI contributions would be added through one account - at least initially, see below. This account has to be made by a real person and that person is legally bound to the license and CT. Will this person or legal entity need permission from the people actually using the twitter scheme to be in conformance with the license / CT? How does Wheelmap.org handle this, if at all? In order not to burden the mapper, your twitter bot would somehow have to establish bidirectional communiactions between mappers and twitter-ers. If you think you cannot expect the twitter-er to set up an OSM account, then in the same vein you cannot expect the mapper to set up a twitter account. You must make sure that a message sent by a mapper to your twitter bot actually reaches the twitter-er who is the source of the data. This is probably not easy. I can see that happening. After a few additions, the scraper application may send a tweet encouraging the user to create an account. He would then be pointed to a web site that 1. would associate his twitter account with the application through twitter's oauth; 2. guide the user through the steps of creating an OSM account; 3. associate the OSM account to the application and to the twitter account. From then on the application could post the POI additions through the user's account, and allow for more edits. And we would have attracted one more user that already showed an interest in making real contributions. I was surprised to see the wheelmap construct but I'm sure that was discussed here before it was implemented. Was it? Don't geht the wheelmap visitor thing wrong; the *only* thing that this visitor can do is to set one specific tag to one of three specific values on an already-existing object of a certain type. So, no free-form tagging, no creation of new objects - almost zero risk of vandalism or copyright violation. But even there we have already had problems where an unknown wheelmap visitor changed something that others found worthy of discussion. Fair enough, that is fairly well constrained. On the other hand, it is also 'more anonymous' in that there is no way the edit can be traced back to a real person, whereas the contributions through the twitter scheme could at least be traced back to a user account. [...] Best, -- Martijn van Exel http://about.me/mvexel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] anonymous edits
Hi, On 05/27/2011 08:06 AM, Martijn van Exel wrote: The one thing I do see as a real issue I don't think that the requirement of being able to contact someone (without first setting up a twitter account) is not real! is the legal one. All twitter POI contributions would be added through one account - at least initially, see below. This account has to be made by a real person and that person is legally bound to the license and CT. Will this person or legal entity need permission from the people actually using the twitter scheme to be in conformance with the license / CT? How does Wheelmap.org handle this, if at all? In contrast to your proposed twitter scheme, wheelmap anonymous edits can only be made through their site where I'm sure they will have some sort of statement that says by submitting your data you agree...; this is more difficult since you cannot do a by using the so-and-so hashtag you agree I can see that happening. After a few additions, the scraper application may send a tweet encouraging the user to create an account. That sounds like a plan. Personally I'd never bother to try adding POIs through twitter but there might be people who do. Don't geht the wheelmap visitor thing wrong; the *only* thing that this visitor can do is to set one specific tag to one of three specific values on [...] Fair enough, that is fairly well constrained. On the other hand, it is also 'more anonymous' in that there is no way the edit can be traced back to a real person, whereas the contributions through the twitter scheme could at least be traced back to a user account. Yes. And I'm not really supportive of the wheelmap visitor; if others come along saying if wheelmap can do that then I can do it too, I'd vote for disallowing any smallest anonymous edit, including wheelmap, rather than seeing this proliferate. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] anonymous edits
Martijn, I'm going to re-arange the sentences here to make it easier to respond. On Thu, May 26, 2011 at 1:51 PM, Martijn van Exel m...@rtijn.org wrote: Hi all, Consider the following applicaton scheme: * a twitter user sends a geo-located tweet containing a specified hashtag, say #addosm and key-value pairs like amenity:pub;name:Red Devil;smoking:yes This would be an easy way to add POIs on the go, and could be an interface for mobile applications to post new POIs. I see technical issues here. First, it seems like you'd only be able to add nodes. This would be pretty sloppy, offer no mechanism for checking existing nodes, etc. Secondly, if you have a smart phone with twitter and geo-coding, why aren't you using a real POI collector app? * a twitter scraper picks up the tweet, archives it and posts a new point using the twitter coordinate and the decoded k-v pairs, plus an additional tag source:twitter[@twitteruser] or something like that. This is okay, in my opinion if you've pre-authenticated this web application to do edits on your user behalf, ie used OAuth. This would not be totally anonymous but it's close. Why should it be anonymous? Let's image such a web application. It looks for twitter feeds and does what you suggest. I think it must be per user. And if it's per user, then it can accept OAuth and act on the user's behalf. And if it does that, then it doesn't need to be anonymous. What do you think, is this acceptable? If it's taking random user data from Twitter, no way. If it's taking data from users who have authorized it to do so, I think it's still a bad idea for technical reasons, but I see no issue with it from that standpoint. A similar level of anonymity is reached by WheelMap.org that allows anonymous OSM edits through their web site via the OSM account wheelmap_visitor[2]. This pattern has been tried before in OSM and is generally considered a problem. WheelMap.org takes huge precautions but even that, I think, isn't enough. We're making it increasingly easy to have users sign up to OSM. We have OAuth for external editors, and we'll likely have OpenID soon for external authentication. If you see a way to simplify signup further, then you should be trying to code it up and show it to people. As your link points out, OSM had anonymous edits, and got rid of them. Those arguments still hold, and so I think that instead of anonymizing, it's better to focus on ways of getting the data in and out easily. - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] The White House uses OpenStreetMap
This has bee popping up in my social networks since yesterday and I have not seen it echoed here... So there - the White House uses OpenStreetMap : http://www.whitehouse.gov/mapping_service/inventory/524 How is that for an endorsement ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Import from Ushahidi Libya Instance
Mikel I cant see anything in the Contributor Terms which state that if you are only adding non-substantial and non-systematic data then it is OK to import non-compatible data. So one question is, will the import be carried out through an account which has agreed to the CT's, in which case the import would be a breach of the CT's. Secondly, obviously I don't know what licence the original data was licensed under, but I would be worried that you might breaching the terms of that licence by importing the data into OSM if the terms of that licence and the OSM licence are incompatible. Obviuosly the OSM community can give their views on whether importing the data is acceptable to OSM, but we cant give view on whether it would be acceptable to the original licence holder. Regards David - Original Message - From: Mikel Maron To: legal-t...@openstreetmap.org Sent: Thursday, May 26, 2011 3:18 PM Subject: [OSM-legal-talk] Import from Ushahidi Libya Instance You may be aware, UN OCHA has been coordinating a Ushahidi instance to map reports from the the Libya Crisis. http://libyacrisismap.net/. OSM is the base map. They've geocoded about 150 places and POI, and have recruited OSM folks to conflate this list with OpenStreetMap. http://internal.libyacrisismap.net/volunteers/team-geolocation/coordinates-database The issue is that the source for the geocoding is listed, but not always licensed under a license compatible with OSM. Even if locations were derived from non-compatible license sources, my thinking has been that this is non-substantial and non-systematic, and therefore might be permissible to import. Data is only collected based on select needs to geocode reports. The numbers are just over 150. According to the Substantial Guideline of the ODbL, an extract from OSM like this would not trigger the viral terms of the license. http://wiki.openstreetmap.org/wiki/Open_Data_License/Substantial_-_Guideline Question is then twofold. One, we haven't yet adopted the ODbL, so how much could a guideline apply. And two, how does the concept of non-substantial apply to importing data? I think there's a good chance it's ok, in which case all data could be brought in. The alternative would then be to exempt particular POI from conflation, or simply geocode them again using fully clear sources. Thoughts? Mikel == Mikel Maron == +14152835207 @mikel s:mikelmaron -- ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] The White House uses OpenStreetMap
It also uses CloudMade by the way :) http://www.whitehouse.gov/change On Fri, May 27, 2011 at 12:57 PM, Jean-Marc Liotier j...@liotier.org wrote: This has bee popping up in my social networks since yesterday and I have not seen it echoed here... So there - the White House uses OpenStreetMap : http://www.whitehouse.gov/mapping_service/inventory/524 How is that for an endorsement ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Vladimir Agafonkin Front-End Architect, CloudMade +380 93 745 44 61 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The White House uses OpenStreetMap
On Fri, May 27, 2011 at 11:57 AM, Jean-Marc Liotier j...@liotier.org wrote: This has bee popping up in my social networks since yesterday and I have not seen it echoed here... So there - the White House uses OpenStreetMap : http://www.whitehouse.gov/mapping_service/inventory/524 How is that for an endorsement ? The whitehouse.org using Cloudmade osm maps has been announced on this list the 5/3/09 ... Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The White House uses OpenStreetMap
On 27 May 2011 16:27, Vladimir Agafonkin vagafon...@cloudmade.com wrote: It also uses CloudMade by the way :) http://www.whitehouse.gov/change Not completely cloudmade , it uses mapbox at http://www.whitehouse.gov/mapping_service/inventory/14 and uses OSM_mapnik tiles at http://www.whitehouse.gov/mapping_service/inventory/525 Hmm 3 things ! Regards, Pavithran -- pavithran sakamuri http://look-pavi.blogspot.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] poland to open publically-funded data
from slashdot: the polish prime minister announced a bill to ensure all government data will be released as public domain. http://translate.google.com/translate?js=nprev=_thl=plie=UTF-8layout=2eotf=1sl=pltl=enu=http%3A%2F%2Fwww.premier.gov.pl%2Fcentrum_prasowe%2Fwydarzenia%2Fw_kprm_o_rozwoju_internetu%2C6599%2F original, in polish: http://www.premier.gov.pl/centrum_prasowe/wydarzenia/w_kprm_o_rozwoju_internetu,6599/ here's hoping it passes, and includes geo data -- robin http://bumblepuppy.org/blog/?p=237 - government bill to remove basic human rights in NZ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] omtagging motorway_links door It's so funny
2011/5/27 Colin Smale colin.sm...@xs4all.nl: On 27/05/2011 00:12, Floris Looijesteijn wrote: ik snap het nog steeds niet. in dat voorbeeld is het toch ook een secondary_link? hij verbindt toch een secondary (Park Forum) met een andere secondary (Flight Forum)? Het voorbeeld zat toevallig op mijn klembord omdat een andere offline reactie die bevatte. Zoals ik het zie is het een segment van een doorgaande secondary. Als je naar de tags kijkt lees je ook: note=secondary_link ivm verbeterde gesproken navigatie in Garmin Volgens mij heb ik m'n punt nog niet duidelijk gemaakt. Dit hoort toch ook gewoon een secondary_link te zijn? Leuk dat het een gunstig side-effect heeft bij Garmin maar dit is in mijn ogen gewoon 'normaal' getagged zo... Groet, Floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] Kein Micromapping mit landuse
Moin, Wolfgang schrieb: Hallo, Am Donnerstag 26 Mai 2011 19:37:32 schrieb fly: Am 25.05.2011 19:52, schrieb Stephan Wolff: Andere sehen einen Sinn in der Aufteilung von Wohn- und Industriegebiet. Niemand hat etwas dagegen, dass du die Nutzungsart der Grundstücke beschreibst. Aber verwende dazu einen anderen Key als landuse. Der Key ist schon vergeben. +1 auf talk@ gabe es eine Diskussion über private (Vor-)Gärten. Das Ergenis war: landuse=residential als große Fläche erhalten und residential=garden bzw. garden=residential zu verwenden. Gleiches kann ich mir gut für andere landuses vorstellen oder doch gleich landcover verwenden. ...und ich hatte schon gehofft, dieser Blödsinn hätte ein Ende. Was ist Blödsinn daran, physikalischen Zustand (was sehe ich) und Nutzung zu unterscheiden? Dann werden alle Städte gleichmäßig grün, denn auch vor Büros und Fabriken gibt es Gärten. Das wars dann mit der Unterscheidung der Nutzungsarten. Wenn Du Dir Stephans und flys zitierte Bereiche bitte noch einmal durchliest, dann wird Du sehen, dass es dann allein Sache des Renderers wäre, welche Daten bzw. Darstellung (physikalisch oder Nutzung) er malen möchte. Du musst Dir dann halt den richtigen für deinen Zweck aussuchen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse
Hallo, Am Freitag 27 Mai 2011 08:02:11 schrieb Georg Feddern: Moin, Wenn Du Dir Stephans und flys zitierte Bereiche bitte noch einmal durchliest, dann wird Du sehen, dass es dann allein Sache des Renderers wäre, welche Daten bzw. Darstellung (physikalisch oder Nutzung) er malen möchte. Du musst Dir dann halt den richtigen für deinen Zweck aussuchen. Dann kann ich nur hoffen, dass die Gärten auch wirlich einzeln erfasst werden, so wie man sie sieht. Hier hat die Unsitte um sich gegriffen, ganze Straßenzüge zu Gärten umzudefinieren. Gartengebiet mit Häusern. Das gilt dann unabhängig von der Nutzung, und damit praktisch flächendeckend. Welcher Industriebetrieb, der auf sich hält, hat nicht ein paar Bäume vor der Tür und auf dem Hof. Der Informationswert sinkt damit auf den Nullpunkt. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Konzept für Daten, Karte und Renderer
Ich möchte gern mal über quo vadis sprechen... Einerseits lässt unsere Datenbank beliebige Detailliertheit zu (Mikromapping, Einzelgeleise, Vorhausgärten, Parkplätze, Bäume, etc) Andererseits brauchen wir kartografisch sinnvolle Generalisierung, und routentechnische Berechnungseffizienz. Einerseits gibt es das Credo: wir arbeiten nicht für den Renderer, andererseits geschieht genau dies permanent, denn der Benutzer beurteilt Qualität anhand dessen was er sieht. Zunehmend werden komplexe (und auch nicht so komplexe) Zusammenhänge in Relationen abgebildet, die sowohl vom Benutzer als auch vom Renderer nur schwer zu handhaben sind. Fehler werden dadurch drastisch zunehmen. Zunehmend geht die Nutzung von Punkten und Flächen und Namen wirr durcheinander. Vor allem für neue Benutzer (es werden immer mehr :-) ) scheint es m.E dringend erforderlich, ihnen für sie nachvollziehbare Empfehlungen incl. erklärender Begründung an die Hand zu geben. Dabei müssen wir darauf achten, dass wir die Freiheit (die Intelligenz der Masse) bewahren - denn sie ist eine unserer grössten Ressourcen und Qualitäten. Ich könnte mir gut vorstellen, dass wir uns dazu mal treffen und gemeinsam Lösungen suchen: Daten-Spezialisten, Kartografen, Routing-Spezialisten, Generalisten... Wäre das nicht ein Thema für ein nächstes Treffen im Linux-Haus? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
moin moin, bedeutet das wirklich, dass alles, was von amazon über diesen link eingekauft wird, 5% für osm bringt? das würde bei einigen 1000 aktiven os-nutzern in deutschland doch wohl mehr bringen als die läppischen 25 pfund/quartal in uk, oder? nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? ich bin auf jeden fall dabei. Gruss Walter - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6410083.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Am 27.05.2011 09:55, schrieb Walter Nordmann: nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? Am besten auch in die nächsten Wochennotiz Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr. 44
hi marc wäre das was für die nächste auflage? http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6391845.html gruss Walter p.s. es mach immer wieder spass, über den Tellerrand zu blicken, danke - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/OSM-Wochennotiz-Nr-44-tp6391174p6410215.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
On Wed 2011-05-25 (20:35), Stephan Wolff wrote: Erfassung der Einzelgleise soweit möglich. Erstellen einer Relation für jede zweigleisige Strecke, bei der ein Gleis (z.B. das nördlichere) role=master und das Gegengleis und die Querverbindungen role=slave erhalten. Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Für Bahngleise kann gleiches zutreffen (z.B. die S-Bahn-Gleise, die um Bahnbetriebswerke herum geführt werden, Berlin-Grunewald und evtl. -Wannsee). In solchen Fällen kann eine Relation, die auf eine Linie reduziert wird, Verwirrung stiften, wenn andere (von der Linie überlagerte) Details nicht ausgeblendet werden. Anwendungen/Karten, die ein Einzelgleise auswerten, blieben unverändert. Anwendungen/Karten, die Streckendaten nutzen wollen, müssen die Relation auswerten. Linien mit role=master würden als zweigleisige Strecke dargestellt, Linien mit role=slave ignoriert. Der geringe Lagefehler gegenüber der Mittellinie (ca. 3m) wäre oft unerheblich. Das können gut und gern mal mehrere 10 Meter sein. Anfänger-Frage: warum müssen die Gleise unterschiedliche roles haben? Bei public_transport/stop_area geht es anscheinend auch ohne... Gruß, Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo Markus. Inwieweit das ein Thema für ein Treffen von ein paar Stunden oder Tagen sein kann, weiß ich nicht, denn das ist 'ne ganz schön große Kiste, die du da als Thema hinstellst. Nichtsdestotrotz sind die Fragen aber, denke ich, ziemlich richtig. Auf der einen Seite sollten die Daten sauber sein, auf der anderen Seite fordert das für Renderer immer komplexere Gebilde. Auf der einen Seite sollen die Daten handhabbar bleiben, auf der anderen Seite ist es schön, genau das Detail zu finden, das ich wirklich grade brauche. Ich denke, eigentlich fehlt trotz vieler Bemühungen immer noch ein Zwischenschritt in der Pipeline, die das OSM-Universum bildet: (a) Wir haben Mapper, (b) wir haben Daten, die wir Anwendern geben können, (d) es existieren Anwendungen wie Renderer/Karten, Router, Kunstanwendungen, Suchmaschinen und so weiter. c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Ich würde letzteres bevorzugen. Gruß Peter Am 27.05.2011 09:19, schrieb Markus: Ich möchte gern mal über quo vadis sprechen... Einerseits lässt unsere Datenbank beliebige Detailliertheit zu (Mikromapping, Einzelgeleise, Vorhausgärten, Parkplätze, Bäume, etc) Andererseits brauchen wir kartografisch sinnvolle Generalisierung, und routentechnische Berechnungseffizienz. Einerseits gibt es das Credo: wir arbeiten nicht für den Renderer, andererseits geschieht genau dies permanent, denn der Benutzer beurteilt Qualität anhand dessen was er sieht. Zunehmend werden komplexe (und auch nicht so komplexe) Zusammenhänge in Relationen abgebildet, die sowohl vom Benutzer als auch vom Renderer nur schwer zu handhaben sind. Fehler werden dadurch drastisch zunehmen. Zunehmend geht die Nutzung von Punkten und Flächen und Namen wirr durcheinander. Vor allem für neue Benutzer (es werden immer mehr :-) ) scheint es m.E dringend erforderlich, ihnen für sie nachvollziehbare Empfehlungen incl. erklärender Begründung an die Hand zu geben. Dabei müssen wir darauf achten, dass wir die Freiheit (die Intelligenz der Masse) bewahren - denn sie ist eine unserer grössten Ressourcen und Qualitäten. Ich könnte mir gut vorstellen, dass wir uns dazu mal treffen und gemeinsam Lösungen suchen: Daten-Spezialisten, Kartografen, Routing-Spezialisten, Generalisten... Wäre das nicht ein Thema für ein nächstes Treffen im Linux-Haus? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hallo, On 05/27/11 10:04, Henning Scholland wrote: nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? Am besten auch in die nächsten Wochennotiz Mal langsam mit den jungen Pferden. Amazon ist einer von sehr sehr vielen Online-Einkaufslaeden, und es gibt durchaus Gruende, *nicht* bei Amazon zu kaufen. (Ich will niemand meine Ideologie aufschwatzen, aber ich persoenlich bemuehe mich seit der Wikileaks-Affaere aktiv darum, bei alternativen Anbietern einzukaufen, selbst wenn Amazon oft komfortabler ist.) Ich finde, dass wir fuer ein paar Prozent Provision nicht unbedacht Werbung fuer Amazon auf OpenStreetMap machen sollten (und sowohl sticky im Forum als auch Wochennotiz bedeuten ein prominentes Placement auf einer openstreetmap.org/openstreetmap.de-Domain). Wenn ueberhaupt, dann wuerde ich eine Seite im Wiki anlegen: Unternehmen, die OpenStreetMap eine Provision zahlen, wenn man bei ihnen einkauft, und auf diese Seite verlinken. Eine herausgestellte Nennung von Amazon (Hey, Leute, kauft doch alle bei Amazon, das bringt noch 5% fuer OSM) faende ich nicht in Ordnung. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hallo Frederik, (Ich will niemand meine Ideologie aufschwatzen, aber ich persoenlich bemuehe mich seit der Wikileaks-Affaere aktiv darum, bei alternativen Anbietern einzukaufen, selbst wenn Amazon oft komfortabler ist.) Danke! Ich eigentlich auch - scheitere aber manchmal am inneren Schweinehund und kaufe die Brötchen statt beim Bäcker bequemlichkeitshalber beim Supermarkt :-( Gruss, Markus PS: manchmal nutze ich auch G-Maps, weil deren Performanz immer noch besser ist als unsere ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo, Am Freitag 27 Mai 2011 10:52:51 schrieb Peter Wendorff: Hallo Markus. Inwieweit das ein Thema für ein Treffen von ein paar Stunden oder Tagen sein kann, weiß ich nicht, denn das ist 'ne ganz schön große Kiste, die du da als Thema hinstellst. Nichtsdestotrotz sind die Fragen aber, denke ich, ziemlich richtig. Auf der einen Seite sollten die Daten sauber sein, auf der anderen Seite fordert das für Renderer immer komplexere Gebilde. Auf der einen Seite sollen die Daten handhabbar bleiben, auf der anderen Seite ist es schön, genau das Detail zu finden, das ich wirklich grade brauche. Ich denke, eigentlich fehlt trotz vieler Bemühungen immer noch ein Zwischenschritt in der Pipeline, die das OSM-Universum bildet: (a) Wir haben Mapper, (b) wir haben Daten, die wir Anwendern geben können, (d) es existieren Anwendungen wie Renderer/Karten, Router, Kunstanwendungen, Suchmaschinen und so weiter. c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Ich würde letzteres bevorzugen. ich glaube nicht, dass es möglich ist, ein Tool zu schreiben, dass den ständig in Bewegung befindlichen OSM-Way-of-tagging bändigen, verwalten oder aktuell auswerten kann. Dafür sind wir zu dynamisch, und das ist letzen Endes auch gut so, auch wenn einem die eine oder andere Tendenz gegen den Strich geht. Ein solches Tool würde zwangsläufig immer hinterher hinken und niemanden so richtig glücklich machen. Auch die heutigen Tools wie osmosis, osm2postgresql etc. haben (subjektive) Schwachstellen, die dem einen oder anderen Wünche übrig lassen. Für den Standardfall (mal eben) sind sie Klasse, und manche Funktionen geradezu unverzichtbar, aber manchmal muss man eben selbst zur 132-Tasten-Maus greifen. Was wir aus meiner Sicht brauchen, ist endlich eine benutzbare X-Api, mit der es möglich ist, im Vorfeld zu filtern, was man aus der DB braucht. Für eine weltweite Karte aller Eisenbahnverbindungen muss man zur Zeit das Planetfile laden, obwohl man nicht mal 1% davon braucht. Mehrgleisige Strecken mit einer Relation zusammen zu fassen sollte nicht das Problem darstellen. Wer eine Anwendung auf freie Inhalte aufsetzen will, muss neben vielen Vorteilen wie Aktualität und Kostenlosigkeit eben auch ein paar Nachteile wie Nachverarbeitung in Kauf nehmen. Wenn er das nicht will, soll er seine Daten kaufen - bei anderen Anbietern oder bei jemandem, der ihm unsere Daten aufbereitet. Hier ständig ein Protestgeheul für die eigene Anwendung zu starten, nervt auf Dauer etwas (womit ich nicht meinen Vorposter meine). Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hallo, Am Freitag 27 Mai 2011 11:03:01 schrieb Frederik Ramm: Hallo, On 05/27/11 10:04, Henning Scholland wrote: nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? Am besten auch in die nächsten Wochennotiz Mal langsam mit den jungen Pferden. Amazon ist einer von sehr sehr vielen Online-Einkaufslaeden, und es gibt durchaus Gruende, *nicht* bei Amazon zu kaufen. (Ich will niemand meine Ideologie aufschwatzen, aber ich persoenlich bemuehe mich seit der Wikileaks-Affaere aktiv darum, bei alternativen Anbietern einzukaufen, selbst wenn Amazon oft komfortabler ist.) Ich finde, dass wir fuer ein paar Prozent Provision nicht unbedacht Werbung fuer Amazon auf OpenStreetMap machen sollten (und sowohl sticky im Forum als auch Wochennotiz bedeuten ein prominentes Placement auf einer openstreetmap.org/openstreetmap.de-Domain). Wenn ueberhaupt, dann wuerde ich eine Seite im Wiki anlegen: Unternehmen, die OpenStreetMap eine Provision zahlen, wenn man bei ihnen einkauft, und auf diese Seite verlinken. Eine herausgestellte Nennung von Amazon (Hey, Leute, kauft doch alle bei Amazon, das bringt noch 5% fuer OSM) faende ich nicht in Ordnung. +1 Hat schon mal jemand bei alternativen Anbietern gefragt (Thalia fällt mir so auf Anhieb ein)? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Hallo Peter, 'ne ganz schön große Kiste Ich denke, vielleicht ist die Zeit reif für ein paar Gedanken wie wir da etwas mehr Ordnung reinkriegen. Klar geht das nicht in ein paar Tagen - aber ein Anfang wäre damit gemacht. Zwischenschritt in der Pipeline, die das OSM-Universum bildet: Ja, das klingt nach einem seehr guten Plan! Eine noch zu lösende Aufgabe wird es sein, den Prozess so offen zu gestalten, dass es jederzeit möglich bleibt, die Core-DB (bzw. deren Spiegel) auch am Standard-Prozess vorbei beliebig zu nutzen. Ein Standard-Prozess kann aber gefühlt 80..98% aller Aufgaben abdecken. Ich könnte mir das so vorstellen: Mapper E-Verarbeitungsschicht DB A-Verarbeitungsschicht Anwendung Die Daten des Mappers (1) werden von einem intelligenten Editor entgegengenommen und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2). In der Eingangsverarbeitung werden die Daten der verschiedenen Editoren standardisiert aufbereitet und in die Core-DB geschrieben (3). Aus der DB werden in der Ausgangsverarbeitung verschiedene Schichten (standardisierte Views) generiert(4), auf die die Anwendungen zugreifen (5). Eine dieser Views ist ein Spiegel der Daten von 3. Auch die anderen Views kann man beliebig spiegeln, um schnellen Zugriff zu gewährleisten. In der Ein- und Ausgangsvearbeitung gibt es dann: Ansätze: - weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können und damit die Datenbank entsprechend begrenzen, - oder man setzt eben bei den Renderern selbst - oder zwischen Renderern und Datenbank an. Ich würde letzteres bevorzugen. Ich auch. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Mit der Information, dass dies nun möglich ist, zwingt man aber keinen bei Amazon einzukaufen. Die, die aber ohnehin über Amazon Dinge beziehen, würden sich über die Info freuen. Genau dafür ist u.a. die Wochennotiz da. Die Info zurückzuhalten, nur weil man Amazon kritisch gegenüber steht grenzt schon ein wenig an Zensur. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 27.05.2011 10:51, schrieb Steffen Grunewald: Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Bekanntestes Beispiel in D dürfe der Albaufstieg der A8 zwischen Stuttgart und Ulm sein, in bergigen Regionen kommt das öfter mal vor. Das können gut und gern mal mehrere 10 Meter sein. Anfänger-Frage: warum müssen die Gleise unterschiedliche roles haben? Bei public_transport/stop_area geht es anscheinend auch ohne... Man möchte damit wohl die Zugehörigkeit von Gleisen zu einer bestimmten Trasse kenntlich machen ohne ein zusätzliches Way-Element für die Trasse einsetzen zu müssen. Unglückliche Lösung die neue Fehlerquellen schafft da hier willkürlich entgegen der Realität ein Gleis als Master definiert wird. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hallo Henning, Info zurückzuhalten grenzt schon ein wenig an Zensur. In einer gewissen Weise ja ;-) - aber: In der Werbung zählt die Wiederholfrequenz. Jede Namensnennung wirbt. Unabhängig ob Du den Namen noch attributierst (gut/schlecht). Deshalb sehen Firmen ihren Namen gern auf OSM, auf der Website und in der DB. Wenn wir nun einen Namen bevorzugen (dadurch dass wir ihn nennen, andere aber nicht), ist das eine politische Aktion. Bei politischen Aktionen sollten wir genau überlegen was wir wollen. Gruss, Markus Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hallo, On 05/27/11 12:26, Henning Scholland wrote: Mit der Information, dass dies nun möglich ist, zwingt man aber keinen bei Amazon einzukaufen. Die, die aber ohnehin über Amazon Dinge beziehen, würden sich über die Info freuen. Ich sag ja - Wikiseite mit allen Anbietern, die uns Provision zahlen, und gut is. Posting im Forum uebrigens gibts jetzt auch bei amazon.de Provision mit Link auf Webseite. Aber kein prominentes sticky-Posting, ausser wenn man bereit ist, auf Dauer *jeden*, der uns Provision gibt, an diesem Ort zu listen. Genau dafür ist u.a. die Wochennotiz da. Die Info zurückzuhalten, nur weil man Amazon kritisch gegenüber steht grenzt schon ein wenig an Zensur. Nein, Zensur waere, wenn eine staatliche Instanz der freien Presse vorschreibt, was sie zu sagen hat und was nicht. Wenn Amazon morgen Lollies verschenkt (was viele OSMer mit Kindern sicher interessiert) und die Wochennotiz als Pressemedium sich entschliesst, an dieser Werbeaktion nicht teilzunehmen, dann ist das keine Zensur, es grenzt auch nicht an Zensur, nicht mal schon ein wenig - es ist eine ganz normale redaktionelle Entscheidung. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Einrichtungen im Bau
Am 25.05.2011 17:19, schrieb Torsten Leistikow: Garry schrieb am 25.05.2011 11:19: Gehst Du blindlings zu einem fremden *) Museum, Restaurant etc. ohne Dich zuvor über die aktuellen Öffnungszeiten zu informieren nur weil Du eine Adresse davon hast? *) bei nennenswerter Anreise zu einer bewusst gewählten Einrichtungen Ja, manchmal: Letzten Samstag stand ich nach fast 2h Anfahrt vor dem leider wegen Renovierung geschlossenem Dom in Hildesheim. Das aber nur am Rande. Dann halten wir mal fest: Eine Renovierung taucht nicht unbdingt als construction in OSM auf und kann (muss aber nicht) bedeuten dass eine Einrichtung nicht zugänglich ist. Umgekehrt construction kann bedeuten dass es für die vorgesehene Nutzung für eine bestimmte Zeit nicht nutzbar ist, muss aber nicht... (Beispiel Hochhaus an dem oben noch gebaut wird während unten schon die ersten Läden geöffnet haben). Viel entscheidender ist ja, dass ein solches Taggingschema ja universell fuer alle Einrichtungen gelten soll. Und wenn ich im Notfall zum naechsten Krankenhaus will, dann moechte ich bestimmt nicht vor Ort feststellen, dass meine Karte/mein Router leider ein kleines constrution=yes/ruins=yes oder vergleichbar sinnwiderlegendes uebersehen/nicht gekannt hat. Du lebst realitätsfremd wenn Du Dich in solchen wichtigen Angelegenheiten auf ein so unzuverlässiges Medium verlässt. Egal wie gut das Taggingschema ist - Du hast keinerlei Garantie das die Daten zum Zeitpunkt Deiner Nutzung aktuell sind. Und nur weil z.B. das ursprüngliche Gebäude gerade durch einen Neubau ersetzt wird heisst das ja nicht automatisch dass in unmittelbarer Nähe kein Ersatz zur Verfügung steht. Jetzt möchte ich das Navi sehen dass Dich über solche Umstände hinreichend aufklärt... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Einrichtungen im Bau
Am 25.05.2011 17:19, schrieb Claudius: Am 25.05.2011 11:12, Garry: Am 24.05.2011 16:23, schrieb malenki:: start_date=$(Datum der voraussichtlichen Fertigstellung) http://wiki.openstreetmap.org/wiki/Key:start_date Das bezieht sich ja dann wohl eher auf den Anfang der Bauarbeiten Bitte klicke auf den Link und lies dort die erste Zeile. Super - schreibe start und meine Ende... Wieder so ein vermeintlich eindeutiger Key dessen Bedeutung in der Beschreibung umgedreht wird.. :-( Gemeint ist der Beginn der Nutzung bspw. als amenity=museum und nicht der Baubeginn. Insofern finde ich es eindeutig. Gemeint - ich finde es keineswegs eindeutig wenn ich unter construction ein start_date finde und die Fertigstellung gemeint ist. Zumal auch noch mal ein Unterschied zwischen Fertigstellung eines Bauwerks und dessen Nutzungsbeginn gibt. Es gibt Brücken die seit mindestens 25 Jahren fertig sind aber noch nie benutzt wurden... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse
Am 25.05.2011 19:52, schrieb Stephan Wolff: Offizielle Gebietsnamen (Industriegebiet Süd, Waldsiedlung) und ihre Grenzen sind Informationen die für die OSM-Datenbank wichtig sind. Diese Informationen kann man NICHT aus den Einzelflächen ableiten. Innerhalb/am Rande eines Industriegebietes kann es grössere Flächen geben die noch landwirtschaftlich genutzt werden bevor sich ein Industriebetrieb ansiedelt. - das Gesamtgebiet hat einen gemeinsamen Namen, aber unterschiedliche Nutzungsarten. Beides sollte aus den OSM-Daten ersichtlich sein... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 10:52, schrieb Peter Wendorff: c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Eine Lösung könnte auch eine layerorientierte Ausrichtung sein: landuse-Layer (entspricht Flächennutzungsplan) Cover-Layer(beschreibt die vorgefundene Bodenbedeckung) Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne auf verkehrsrechtliche Details einzugehen) Routing-Layer (beschreibt fahrspurdetailiert die Verkehrswege) Building-Layer usw.. Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in den Editoren durch entsprechende Filter erzeugt werden. Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 11:47, schrieb Wolfgang: Hallo, [...] ich glaube nicht, dass es möglich ist, ein Tool zu schreiben, dass den ständig in Bewegung befindlichen OSM-Way-of-tagging bändigen, verwalten oder aktuell auswerten kann. Dafür sind wir zu dynamisch, und das ist letzen Endes auch gut so, auch wenn einem die eine oder andere Tendenz gegen den Strich geht. Ein solches Tool würde zwangsläufig immer hinterher hinken und niemanden so richtig glücklich machen. Dass das Tool eher zurückhinken würde, ist erstmal klar - aber das Problem haben wir momentan auch, verstärkt und verteilt über verschiedene Renderer. Wenn die Entwickler der Render-Engines nicht noch diesen Zwischenschritt aufwändig immer wieder anpassen müssten, könnten Kapazitäten für ein Gemeinsames Tool, das eben diese Aufbereitung vornehmen kann, frei werden. Klar - wenn dann doch jeder sein eigenes Süppchen kocht und Updates lieber lokal in Mapnik oder sonstwo einpflegt, ist nichts gewonnen. Auch die heutigen Tools wie osmosis, osm2postgresql etc. haben (subjektive) Schwachstellen, die dem einen oder anderen Wünche übrig lassen. Für den Standardfall (mal eben) sind sie Klasse, und manche Funktionen geradezu unverzichtbar, aber manchmal muss man eben selbst zur 132-Tasten-Maus greifen. Das ist richtig - aber gerade bei osmosis gibt es doch mittlerweile einige (wenige) Beispiele für Module, die angepasst auf bestimmte Vorgänge sind: Datenbank-schreiben in verschiedenen Formaten z.B. Was wir aus meiner Sicht brauchen, ist endlich eine benutzbare X-Api, mit der es möglich ist, im Vorfeld zu filtern, was man aus der DB braucht. Für eine weltweite Karte aller Eisenbahnverbindungen muss man zur Zeit das Planetfile laden, obwohl man nicht mal 1% davon braucht. Da stimm ich dir voll zu - und sicherlich ist auch (J)XAPI ein Puzzleteil auf dem Vorverarbeitungs-Layer. Mehrgleisige Strecken mit einer Relation zusammen zu fassen sollte nicht das Problem darstellen. Also wenn ich sehe, wie oft Buslinien zerreißen - ich befürchte, das wird bei Bahnstrecken auch nicht viel besser sein (abgesehen davon, dass sie bisher möglicherweise seltener angefasst werden). Das aber führt dazu, dass auch hier wieder Fehlertoleranz verlangt ist - wieder ein schwieriges Thema. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Am 27.05.2011 13:01, schrieb Frederik Ramm: Hallo, On 05/27/11 12:26, Henning Scholland wrote: Mit der Information, dass dies nun möglich ist, zwingt man aber keinen bei Amazon einzukaufen. Die, die aber ohnehin über Amazon Dinge beziehen, würden sich über die Info freuen. Ich sag ja - Wikiseite mit allen Anbietern, die uns Provision zahlen, und gut is. Posting im Forum uebrigens gibts jetzt auch bei amazon.de Provision mit Link auf Webseite. Aber kein prominentes sticky-Posting, ausser wenn man bereit ist, auf Dauer *jeden*, der uns Provision gibt, an diesem Ort zu listen. +1 Bitte nicht noch mehr Werbung. Gibt schon viel zu viel davon im Web ! cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 12:20, schrieb Markus: Hallo Peter, 'ne ganz schön große Kiste Ich denke, vielleicht ist die Zeit reif für ein paar Gedanken wie wir da etwas mehr Ordnung reinkriegen. Klar geht das nicht in ein paar Tagen - aber ein Anfang wäre damit gemacht. Zwischenschritt in der Pipeline, die das OSM-Universum bildet: Ja, das klingt nach einem seehr guten Plan! Eine noch zu lösende Aufgabe wird es sein, den Prozess so offen zu gestalten, dass es jederzeit möglich bleibt, die Core-DB (bzw. deren Spiegel) auch am Standard-Prozess vorbei beliebig zu nutzen. Ein Standard-Prozess kann aber gefühlt 80..98% aller Aufgaben abdecken. Ich könnte mir das so vorstellen: Mapper E-Verarbeitungsschicht DB A-Verarbeitungsschicht Anwendung Da hast du mich falsch verstanden! Ich bin für Mapper DB Verarbeitungsschicht Anwendung Je nach Kapazität auf den Servern kann man zusätzlich noch Mapper DB Verarbeitungsschicht aufbereiteteDB Anwendung einführen, um die Verwendbarkeit noch einfacher zu machen. Ich halte allerdings die Verwendung von Osmosis nicht für zu viel verlangt; nur reinkommen ist erstmal relativ schwierig. Die Daten des Mappers (1) werden von einem intelligenten Editor entgegengenommen und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2). so intelligent kann die Schicht nicht sein, dass dadurch keine Informationen verloren gehen. Außerdem ist einiges in dem Bereich nicht sinnvollerweise bei jedem Upload durchzuführen. In der Eingangsverarbeitung werden die Daten der verschiedenen Editoren standardisiert aufbereitet und in die Core-DB geschrieben (3). Insofern würde ich diesen Schritt weglassen Aus der DB werden in der Ausgangsverarbeitung verschiedene Schichten (standardisierte Views) generiert(4), ...diesen allerdings hereinnehmen; wobei der eben auch auf Seite der Anwendung oder Anwendungsprogrammierung laufen kann - als Bibliothek oder Hilfsprogramm, das einfach nur aufgerufen werden muss. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 13:47, schrieb Garry: Am 27.05.2011 10:52, schrieb Peter Wendorff: c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Eine Lösung könnte auch eine layerorientierte Ausrichtung sein: landuse-Layer (entspricht Flächennutzungsplan) Cover-Layer(beschreibt die vorgefundene Bodenbedeckung) Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne auf verkehrsrechtliche Details einzugehen) Routing-Layer (beschreibt fahrspurdetailiert die Verkehrswege) Building-Layer usw.. Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in den Editoren durch entsprechende Filter erzeugt werden. Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden. Die Idee gabs schon mehrfach. Probleme dabei: 1) Wer definiert die Layer? Einerseits müssen die wegen der Evolution des Taggingschemas irgendwann geändert werden, andererseits müssen sie konstant bleiben, damit die Anwendungen nicht in die Falle tappen 2) Welche layer bietet man an? Routing-Layer: Mit oder ohne Fußwegen? was ist mit Rollstuhl-Routing-Eigenschaften? Adressgenau, oder nur die Fahrwege? Nodes nicht layerübergreifend verwendbar? Bei welchen Layern und warum? Ich befürchte, Gegenbeispiele gibt's da immer - es sei denn, man trennte die layer komplett voneinander, was dann aber schnell zu inkonsistenzen führt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 14:16, schrieb Peter Wendorff: Am 27.05.2011 13:47, schrieb Garry: Am 27.05.2011 10:52, schrieb Peter Wendorff: c hab ich bewusst ausgelassen - da fehlt irgendwie noch was: Eine gut zu verwendende Verarbeitungsschicht, die man Anwendungsentwicklern an die Hand geben kann, ohne dass die erst monatelange Einarbeitungszeit brauchen. Osmosis gehört in diese Kategorie und ist zweifelsohne ein extrem nützliches Tool. Es gibt allerdings auch für osmosis diverse Anwendungen, die immer wieder vorkommen und nützlich wären: - Wie generiere ich aus einem planet oder Gebietsextrakt einen Routinggraphen? Ich bräuchte eine halbwegs passende osmosis-Pipeline und vermutlich ein SQL-Script zur Datenbank-Nachbearbeitung, um einen einfachen Graphen zu erzeugen - das Speziellere Erzeugen für bestimmte Anwendungen, die Bildung von Contraction-Hierarchies oder sonstwas meine ich hier nicht. - Ich hätte gerne ein generalisiertes Eisenbahn-Netz (ja, das wäre genau das collapsing von parallelen Strecken - aber genau darum geht es mir ja: Wieso soll sowas von jedem Renderer extra unterstützt werden?) - Analog zur Generalisierung von Flächen (Häuser zu landuse=residential zusammenfassen und so weiter) Im Grunde gibt es zwei Ansätze, die man da fahren kann: Man kann weiter so taggen, dass die Renderer, die bereits existieren, damit ohne Änderungen umgehen können - und damit die Datenbank entsprechend begrenzen, oder man setzt eben bei den Renderern selbst oder zwischen Renderern und Datenbank an. Eine Lösung könnte auch eine layerorientierte Ausrichtung sein: landuse-Layer (entspricht Flächennutzungsplan) Cover-Layer(beschreibt die vorgefundene Bodenbedeckung) Traffic-way-Layer(beschreibt nur die Verkehrsverbindungen ohne auf verkehrsrechtliche Details einzugehen) Routing-Layer (beschreibt fahrspurdetailiert die Verkehrswege) Building-Layer usw.. Wobei die Layer nicht in der Datenbank auftauchen sollten sondern in den Editoren durch entsprechende Filter erzeugt werden. Bestimmte nodes dürfen dabei nicht layerübergreifend verwendet werden. Die Idee gabs schon mehrfach. Ich weiss.. Probleme dabei: 1) Wer definiert die Layer? Einerseits müssen die wegen der Evolution des Taggingschemas irgendwann geändert werden, andererseits müssen sie konstant bleiben, damit die Anwendungen nicht in die Falle tappen Eine Layerdarstellung in den Editoren ändert zunächst einmal nichts am Tagging-Schema. Mittelfristig soll aber bewirkt werden dass eine saubere Trennung zwischen Bodenbedeckung, landuse(Flächennutzungsplan?), Verkehrswege etc. einzug hält. 2) Welche layer bietet man an? Routing-Layer: Mit oder ohne Fußwegen? was ist mit Rollstuhl-Routing-Eigenschaften? Adressgenau, oder nur die Fahrwege? Im Routing-Layer sollte alles angezeigt werden was routing-relevant ist, gegebenfalls vom user einzelne Elemente ausblendbar die er gerade nicht benötigt, in dem Fall aber mit einer Verriegelung/Warnung wenn sich eine Änderung auf die ausgeblendeten Elemtente auswirken würde(So wie jetzt schon in Josm wenn man etwas ändern möchte was nicht vollständig geladen ist). Nodes nicht layerübergreifend verwendbar? Bei welchen Layern und warum? Ich befürchte, Gegenbeispiele gibt's da immer - es sei denn, man trennte die layer komplett voneinander, was dann aber schnell zu inkonsistenzen führt. Z.B. sollten Verkehrswege keine gemeinsamen nodes mit landuse / Bodenbedeckung haben. Meist stammen die Daten aus unterschiedlichen Quellen mit unterschiedlicher Genauigkeit. Bei gemeinsamen nodes würden eine Positionsänderungen im einen Layer (aus welchen Gründen auch immer) die Daten im anderen Layer beeinflussen und unter Umständen hochgenaue Daten verschlechtern. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Frederik Ramm schrieb am 26.05.2011 22:35: man muss das halt beim Rendern in den Griff kriegen. Solche Aussagen ohne konkrete Vorschlaege (oder auch nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich. Aber jetzt das Mapping-Rad zurueckdrehen, beim Mapping zu stagnieren, bloss weil der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Hier hat ja auch keiner verlangt, das Rad zurueck zu drehen. Letztendlich laeuft es aber darauf hinaus, dass wir frueher keine Unterscheidung fuer unterschiedliche Abstarktionsebenen brauchten, unsere Daten waren fuer sowas einfach noch nicht gut genug. Das mit den Daten hat sich inzwischen geaendert, leider ist aber mit der Datengenauigkeit nicht auch die Strukturtiefe mitgewachsen, so dass inzwischen manchmal die Daten um so schlechter nutzbar geworden sind je genauer sie sind. Wie man auch an den anderen z.Z. aktuellen Diskussionen liest, ist das Problem nicht auf die Bahnstrecken beschraenkt und verlangt wohl deshalb auch nach einer grundsaetzlicheren Loesung. Da es sowas bei OSM ja aber prinzipiell nicht gibt, wurschteln wir uns eben weiter mehr schlecht als recht durch. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Frederik Ramm wrote: Wenn ueberhaupt, dann wuerde ich eine Seite im Wiki anlegen: Unternehmen, die OpenStreetMap eine Provision zahlen, wenn man bei ihnen einkauft, und auf diese Seite verlinken. OK, ein Logo auf der Webseite oder ein Sticky ist doch etwas zuviel des Guten - daher diskussiert man das ja hier, abgesehen davon, dass man das selber ja garnicht einrichten kann. Aber diese ewigen Hinweise der Art: Ich würde da lieber das und das in's Wiki schreiben kann ich nicht mehr lesen. Das kann/sollte der Vorschlagende bitte gefälligst selber machen, wenn er dies als vernünftige Alternative vorschlägt. Ich selber habe heute 5 Stunden lang aktiv gewikit und damit reicht es mir für heute. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6411544.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Nachtrag: die einzige Werbung, die ich auf openstreetmap.de erkennen kann, ist für Strato als Sponsor einiger OSM-Server und ein Buch über openstretmap. Autor: ja wer wohl. - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6411562.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hi, Walter Nordmann schrieb: Nachtrag: die einzige Werbung, die ich auf openstreetmap.de erkennen kann, ist für Strato als Sponsor einiger OSM-Server und ein Buch über openstretmap. Autor: ja wer wohl. OMG, auf http://www.openstreetmap.info/ geht es nur um das Buch !!! Also ob das alles mit rechten Dingen zu geht ;) viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
openstreetmap.info ist auch eindeutig nicht die Seite der deutschen OSM-Community ;) Henning Am 27.05.2011 17:57, schrieb Pascal Neis: Hi, Walter Nordmann schrieb: Nachtrag: die einzige Werbung, die ich auf openstreetmap.de erkennen kann, ist für Strato als Sponsor einiger OSM-Server und ein Buch über openstretmap. Autor: ja wer wohl. OMG, auf http://www.openstreetmap.info/ geht es nur um das Buch !!! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Wenn die Redaktion der Wochennotiz entscheidet, dass das nicht wichtig genug ist, soll sie es halt nicht bringen. Aber der Redaktion zu sagen, dass das da nicht hin soll, weil Amazon böse ist finde ich nicht richtig. Übrigens wurde auch die flattr-Button in der Wochennotiz erwähnt und erklärt. Des weiteren findet sich dort auch ein Twitter-Button. Wenn schon keine Werbung mit Gegenleistung, dann bitte generell keine Werbung. Henning Am 27.05.2011 13:01, schrieb Frederik Ramm: Genau dafür ist u.a. die Wochennotiz da. Die Info zurückzuhalten, nur weil man Amazon kritisch gegenüber steht grenzt schon ein wenig an Zensur. Nein, Zensur waere, wenn eine staatliche Instanz der freien Presse vorschreibt, was sie zu sagen hat und was nicht. Wenn Amazon morgen Lollies verschenkt (was viele OSMer mit Kindern sicher interessiert) und die Wochennotiz als Pressemedium sich entschliesst, an dieser Werbeaktion nicht teilzunehmen, dann ist das keine Zensur, es grenzt auch nicht an Zensur, nicht mal schon ein wenig - es ist eine ganz normale redaktionelle Entscheidung. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Renderer-Zukunft, was: Re: Bahnstrecke vs. Gleis
Am 27.05.2011 17:13, schrieb Torsten Leistikow: Frederik Ramm schrieb am 26.05.2011 22:35: man muss das halt beim Rendern in den Griff kriegen. Solche Aussagen ohne konkrete Vorschlaege (oder auch nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich. Such mal im Wiki nach dem Stichwort Linienbündel Am 26.05.2011 22:35, schrieb Frederik Ramm: und es wirkte etwas seltsam, dass ein einzelner Way, der eine Trasse symbolisierte, sich an einem Bahnhof ploetzlich auffaecherte zu lauter Gleisen und dann hinter dem Bahnhof wieder zu einer Trasse zusammenlief - ziemlich unlogisch, aber ich habe immer angenommen, dass das halt ein voruebergehenden Zustand ist, bis irgendwann mal alle Gleise vollstaendig erfasst sind. Nicht unlogisch, sondenr normal. Das wird auch so gemacht auf Karten, auf denen die Zweigleisigkeit ggü. Eingleisigkeit durch 'nen Querstrich mehr dargestellt wird (bspw. TK50) oder auch nicht (Stadtplan KA 1:20.000). Auch da fächert sich ein Bahnhof durchaus auf in passenden Maßstäben. Aber nicht unbedingt zu voller Gleiszahl, sondern ca. der Hälfte. So war der K'her Hbf auch vorm gleistreuen Mapping. Im Gegensatz zu TK50 und K'her Stadtplan aber mit nach Osten korrekt raus geführten DREI Strecken. Die bei den amtlichen gezeigten Fusionen lassen Eisenbahnfans die Nackenhaare aufstellen ... ;-) Damals schon konnte man beobachten, dass das Auffaechern der Gleise auf den hohen Zoomstufen zwar gut war, auf mittleren Zoomstufen aber haessliche schwarze Flecken im Bahnhofsareal erzeugte. Bei Osmarender habe ich immerhin das Symbol ab einem bestimmten Maßstab gewechselt (wie auch bei Radwegen etc.) Aber vom Optimum ist das natürlich noch weit entfernt... Das ist eine Herausforderung, der man beim Rendern Herr werden kann und muss. Eventuell *kann* man dem Renderer irgendwie helfen, indem man eine Gruppe von Gleisen zu einer Bahntrassen-Relation zusammenfasst und dann neue Funktionalitaeten im Renderer einbaut, die in der Lage sind, solche gruppierten linienfoermigen Objekte geeignet zu vereinfachen. Man muss aber dabei auch den Fall abfangen, dass eine solche Relation fehlen koennte. Deswegen vielleicht eher ein Prozess, der versucht, automagisch das passende zusammenzuwürfeln und nur dort, wo was unpassendes rauskommt, Hinweise geben, was zusammengehört und was nicht ... Das Problem stellt sich ja auch beim Thema separat gemappte Rad- und Gehwege, Straße neben Fluss, aber auch bei Haus neben (mit dem Zoom wachsender) Straße, Sackgasse, die knapp vor Straße endet, ... Da wird man fuer das Standard-Rendering mindestens am osm2pgsql, wenn nicht sogar auch am Mapnik herumdrehen muessen. Das wird nicht leicht, aber danach haben wir eine Karte, die auf allen Zoomleveln besser aussieht als vorher. Ich fürchte, wir müssen langfristig Mapnik, Osmarender Co. ganz wegschmeißen, dann das sind alles keinerlei kartographische Programme, sondern einfachste Umetikettierer, die Null Möglichkeit zur Koordinatenveränderung haben (außer dass sie gelegentlich Kurven durch die Stützpunkte legen statt Geraden, auch nicht immer so doll... aber auch da bleiben die Stützpunktkoordinaten unverändert). Am deutlichsten wird es bei Osmarender, den's auch in einer (lahmen) XSLT-Variante gibt ... Problem ist auch das Ausgabeformat SVG, das in seinen Darstellungsmöglichkeiten limitiert ist, daran scheitert in Osmarender das Rendern einseitiger Radwege. Für alle genannten Probleme müssen aber Koordinaten gerechnet werden für - die Mittellinie (ob nun mit real existentem Objekt wie Tram, ähm, vorm gleistreuen Mapping, oder nur virtuell als Mitte zwischen zwei Fahrbahnen) - alle parallelen maßstabsabhängig (!) auf die Mitte abgestimmten Wege wie Gleise, Fahrbahnen, Radwege - alle Objekte wie Häuser, Bäume, POIs, Sackgassenenden, ... die ggfs. zur Seite geschoben werden müssen - ... Das ist vermutlich zu komplex, um es jedesmal zu machen, sprich: solche Geometrien muss man wohl zwischenspeichern und eine automatische Aktualisierung bei Veränderung der Basisgeometrien organisieren. Etc. Und man muss verstärkt gewisse Sachen wegwerfen und vereinfachen müssen in passenden Zooms wie jetzt schon einige Wegklassen peu a peu in Mapnik In der Zwischenzeit - solang eben die Renderer nicht gut genug sind - muessen wir Rueckschritte hinnehmen. Das ist an vielen anderen Fronten auch so (z.B. einzelne Haeuser, die man auf kleineren Zoomleveln eigentlich lieber als grosse bebaute Flaeche anzeigen will). Aber jetzt das Mapping-Rad zurueckdrehen, beim Mapping zu stagnieren, bloss weil der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Erst wenn genug Leidensdruck durch massenhaft Details aufgebaut ist, wird sich jemand dran setzen, obige Liste abzuarbeiten ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 27.05.2011 12:26, schrieb Garry: Am 27.05.2011 10:51, schrieb Steffen Grunewald: Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Bekanntestes Beispiel in D dürfe der Albaufstieg der A8 zwischen Stuttgart und Ulm sein, in bergigen Regionen kommt das öfter mal vor. Da isses platt wie 'ne Flunder: http://www.openstreetmap.org/?lat=52.7583lon=9.6679zoom=14layers=M Kennt da jemand zufällig den Grund? Unglückliche Lösung die neue Fehlerquellen schafft da hier willkürlich entgegen der Realität ein Gleis als Master definiert wird. +1 Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 09:19, schrieb Markus: Ich möchte gern mal über quo vadis sprechen... Ei, dann hätte das eben bei den Gleisen getippte besser hierher gepasst: Ctrl-C, Ctrl-V: Am 27.05.2011 17:13, schrieb Torsten Leistikow: Frederik Ramm schrieb am 26.05.2011 22:35: man muss das halt beim Rendern in den Griff kriegen. Solche Aussagen ohne konkrete Vorschlaege (oder auch nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich. Such mal im Wiki nach dem Stichwort Linienbündel Am 26.05.2011 22:35, schrieb Frederik Ramm: und es wirkte etwas seltsam, dass ein einzelner Way, der eine Trasse symbolisierte, sich an einem Bahnhof ploetzlich auffaecherte zu lauter Gleisen und dann hinter dem Bahnhof wieder zu einer Trasse zusammenlief - ziemlich unlogisch, aber ich habe immer angenommen, dass das halt ein voruebergehenden Zustand ist, bis irgendwann mal alle Gleise vollstaendig erfasst sind. Nicht unlogisch, sondenr normal. Das wird auch so gemacht auf Karten, auf denen die Zweigleisigkeit ggü. Eingleisigkeit durch 'nen Querstrich mehr dargestellt wird (bspw. TK50) oder auch nicht (Stadtplan KA 1:20.000). Auch da fächert sich ein Bahnhof durchaus auf in passenden Maßstäben. Aber nicht unbedingt zu voller Gleiszahl, sondern ca. der Hälfte. So war der K'her Hbf auch vorm gleistreuen Mapping. Im Gegensatz zu TK50 und K'her Stadtplan aber mit nach Osten korrekt raus geführten DREI Strecken. Die bei den amtlichen gezeigten Fusionen lassen Eisenbahnfans die Nackenhaare aufstellen ... ;-) Damals schon konnte man beobachten, dass das Auffaechern der Gleise auf den hohen Zoomstufen zwar gut war, auf mittleren Zoomstufen aber haessliche schwarze Flecken im Bahnhofsareal erzeugte. Bei Osmarender habe ich immerhin das Symbol ab einem bestimmten Maßstab gewechselt (wie auch bei Radwegen etc.) Aber vom Optimum ist das natürlich noch weit entfernt... Das ist eine Herausforderung, der man beim Rendern Herr werden kann und muss. Eventuell *kann* man dem Renderer irgendwie helfen, indem man eine Gruppe von Gleisen zu einer Bahntrassen-Relation zusammenfasst und dann neue Funktionalitaeten im Renderer einbaut, die in der Lage sind, solche gruppierten linienfoermigen Objekte geeignet zu vereinfachen. Man muss aber dabei auch den Fall abfangen, dass eine solche Relation fehlen koennte. Deswegen vielleicht eher ein Prozess, der versucht, automagisch das passende zusammenzuwürfeln und nur dort, wo was unpassendes rauskommt, Hinweise geben, was zusammengehört und was nicht ... Das Problem stellt sich ja auch beim Thema separat gemappte Rad- und Gehwege, Straße neben Fluss, aber auch bei Haus neben (mit dem Zoom wachsender) Straße, Sackgasse, die knapp vor Straße endet, ... Da wird man fuer das Standard-Rendering mindestens am osm2pgsql, wenn nicht sogar auch am Mapnik herumdrehen muessen. Das wird nicht leicht, aber danach haben wir eine Karte, die auf allen Zoomleveln besser aussieht als vorher. Ich fürchte, wir müssen langfristig Mapnik, Osmarender Co. ganz wegschmeißen, dann das sind alles keinerlei kartographische Programme, sondern einfachste Umetikettierer, die Null Möglichkeit zur Koordinatenveränderung haben (außer dass sie gelegentlich Kurven durch die Stützpunkte legen statt Geraden, auch nicht immer so doll... aber auch da bleiben die Stützpunktkoordinaten unverändert). Am deutlichsten wird es bei Osmarender, den's auch in einer (lahmen) XSLT-Variante gibt ... Problem ist auch das Ausgabeformat SVG, das in seinen Darstellungsmöglichkeiten limitiert ist, daran scheitert in Osmarender das Rendern einseitiger Radwege. Für alle genannten Probleme müssen aber Koordinaten gerechnet werden für - die Mittellinie (ob nun mit real existentem Objekt wie Tram, ähm, vorm gleistreuen Mapping, oder nur virtuell als Mitte zwischen zwei Fahrbahnen) - alle parallelen maßstabsabhängig (!) auf die Mitte abgestimmten Wege wie Gleise, Fahrbahnen, Radwege - alle Objekte wie Häuser, Bäume, POIs, Sackgassenenden, ... die ggfs. zur Seite geschoben werden müssen - ... Das ist vermutlich zu komplex, um es jedesmal zu machen, sprich: solche Geometrien muss man wohl zwischenspeichern und eine automatische Aktualisierung bei Veränderung der Basisgeometrien organisieren. Etc. Und man muss verstärkt gewisse Sachen wegwerfen und vereinfachen müssenin passenden Zooms wie jetzt schon einige Wegklassen peu a peu in Mapnik In der Zwischenzeit - solang eben die Renderer nicht gut genug sind - muessen wir Rueckschritte hinnehmen. Das ist an vielen anderen Fronten auch so (z.B. einzelne Haeuser, die man auf kleineren Zoomleveln eigentlich lieber als grosse bebaute Flaeche anzeigen will). Aber jetzt das Mapping-Rad zurueckdrehen, beim Mapping zu stagnieren, bloss weil der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Erst wenn genug Leidensdruck durch massenhaft Details aufgebaut ist, wird sich jemand dran setzen, obige Liste abzuarbeiten ;-) Gruß Mueck
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 14:07, schrieb Peter Wendorff: Am 27.05.2011 12:20, schrieb Markus: Ich könnte mir das so vorstellen: Mapper E-Verarbeitungsschicht DB ... Da hast du mich falsch verstanden! Ich bin für Mapper DB ... Die Daten des Mappers (1) werden von einem intelligenten Editor entgegengenommen und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2). so intelligent kann die Schicht nicht sein, dass dadurch keine Informationen verloren gehen. Außerdem ist einiges in dem Bereich nicht sinnvollerweise bei jedem Upload durchzuführen. Ich wäre auch vorsichtig, allzu viel in die E-Schicht zu packen. Eins jedoch sollten Editoren -- oder wenn die es nicht machen -- die Eingangschicht der DB machen: Splits und Vereinigungen erkennen und eine saubere Historie auch für diese erzeugen. Das ist nicht nur DER Knackpunkt der Relizenzierung (ohne saubere Historie auch bei Splits und Vereinigungen ist die rechtlich angreifbar), sondern auch ganz generell lästig, wenn man die Entstehungsgeschichte eines Objekts verfolgen möchte, wann und von wem und warum bspw. Tag X drangehängt wurde an die Y-Straße ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 25.05.2011 20:49, schrieb Torsten Leistikow: Stephan Wolff schrieb am 25.05.2011 20:35: Erstellen einer Relation für jede zweigleisige Strecke, bei der ein Gleis (z.B. das nördlichere) role=master und das Gegengleis und die Querverbindungen role=slave erhalten. Wesentlich einfacher und praktikabler waere es, wenn man nur die slave-Gleise (oder alternative nur die master-Gleise) mit einem extra Tag kennzeichnen wuerde, die Relation ist eigentlich ueberfluessig. Als reine Renderinformation könnte man auf die Relation verzichten. Ins Datenmodell von OSM passt es nicht, identische Gleise als physikalische Objekte einmal als master und einmal als slave zu bezeichnen. Die Strecke als Verwaltungsobjekt, das mehrere Gleise zusammenfasst, könnte eher die Zusatzinformation aufnehmen, welche der Mitglieder die Lage der Relation repräsentieren sollen. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 09:19, schrieb Markus: Andererseits brauchen wir kartografisch sinnvolle Generalisierung, und routentechnische Berechnungseffizienz. Beides fängt m.E. mit einem gemeinsamen Schritt an: Zusammenfassen, was zusammen gehört, s.a. Ctrl-C+Ctrl-V-Mail ;-) Linienbündel etc.: Sowohl beim Rendern ( Radweg/Fahrbahn sollen sich nicht überdecken), als auch beim Generalisieren (Straße mit/ohne Radweg) als auch beim Routen (Rafahrer über Fahrbahn oder Radweg) braucht man die Zusammenhänge paralleler Strukturen. Einige Teilaufgaben brauchen paar mehr (Verdrängung Straße contra Fluss), die andere nicht brauchen (oder? Hmmm... nicht zu weit rechts fahren, sonst *platsch* ;-) ), aber der geometrische Ansatz ist derselbe. Das geht alles in Richtung GIS als Zwischenschicht. Oder sowas in der Art. Jedenfalls etwas, das Koordinaten nicht nur umbildet von geographisch/WGS84 in Karten-x/y, sondern richtig analysiert und verändert: Was ist parallel zueinander? Was stößt in einem Winkel darauf? Was endet kurz davor? Und all das darf sich nicht von unsauberem Mapping beeinflussen lassen wie unterschiedlich dichte und verteilte Stützpunkte bei parallelen Fahrbahnen, Unterbrechungen durch Brücken (die tw. versetzt zueinander sind, wenn was in spitzem Winkel gekreuzt wird etc. Oder beim parallelen Radweg fehlt die Brücke ...), ... Und muss dennoch erkennen, ob ein eine Weile paralleler Radweg doch irgendwo abschwenkt ... Und dann: Was gehört davon zusammen, was nicht? Was für Aufgabe A (Verdrängung), B (Rendern), C (Routen), D (...), ...? Und wie speichert man diese Zusammengehörigkeiten ab? Wie hält man die aktuell, wenn jemand die Basisgeonetrie ändert? Und wie steuert man die, wenn die Automagik falsch zusammenstöpselt? Oder nur manuell, aber was, wenn die fehlt? Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Heiko Jacobs schrieb am 27.05.2011 19:32: man muss das halt beim Rendern in den Griff kriegen. Such mal im Wiki nach dem Stichwort Linienbündel Auch das erfordert weitere Information, das kann ein Renderer einfach nicht von sich aus leisten. Die schlechten Erfahrungen mit den Multipolygonen lassen mich ausserdem daran zweifeln, dass solche Konstrukte das Richtige fuer die Masse der Gelegenheitsmapper ist. Was haltet ihr von folgendem Schema fuer Hilfstags aehnlich den Tags speziell fuer Osmarender, d.h. sie sollen nicht das Objekt selber beschreiben sondern eine Hilfestuetze zur Auswertung/Darstellung bieten. - detail_level=minor Ein Objekt, dass nur auf den groessten Zoomstufen angezeigt werden sollte. Auf groeberen Karten kann es bei Bedarf weggelassen werden, da es durch andere Objekte (mit detail_level=main oder detail_level=abstract) ausreichend repraesentiert wird. - detail_level=main Ein Objekt, dass auf allen Zoomstufen angezeigt werden sollte. - detail_level=abstract Ein Objekt, dass nur auf den kleinsten Zoomstufen angezeigt werden sollte. Auf genaueren Karten kann es bei Bedarf weggelassen werden, da es durch andere Objekte (mit detail_level=minor) ersetzt wird. Mit diesem Schema koennte man z.B. eine Strasse als main definieren und die separat erfassten Rad- und Fusswege als minor. Jeder Renderer koennte mit diesen Informationen dann ohne grossen Aufwand selbst entscheiden, ab welcher Zommstufe der Begleitweg dargestellt wird, und ab welchen Zoomstufen es sinnvoller ist, nur die eigentliche Strasse darzustellen. Ein Mapper haette mit diesem Schema die Moeglichkeit, Elemente, die ihm persoenlich unnoetig detailliert erscheinen, als untergeordnet zu markieren oder sogar durch abstraktere Elemente zu ersetzen, ohne dass er dafuer die eigentlichen Tags der Elemente in der Datenbank veraendern muesste. Es geht also keine Information verloren, und ein Mapper, der meint in seinem Revier etwas aufraeumen zu muessen, kollidiert nicht mit einem Detail-Mapper. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 20:02, schrieb Heiko Jacobs: Und dann: Was gehört davon zusammen, was nicht? Was für Aufgabe A (Verdrängung), B (Rendern), ... wobei da ja noch stark der Maßstab reinspielt und die Zeichenregeln des Renderers. In z18 kann man noch fast alles unverändert zeichnen. Wann die Objekte zusammenstoßen und Variationen an den Koordinaten benötigen, ist beim renderer mit dicken Linien früher der Fall als bei dem mit den dünnen ... Das macht das mit dem zwischenspeichern von Hilfsgeometrien nicht einfacher ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Stephan Wolff schrieb am 27.05.2011 19:51: Ins Datenmodell von OSM passt es nicht, identische Gleise als physikalische Objekte einmal als master und einmal als slave zu bezeichnen. Die Strecke als Verwaltungsobjekt, das mehrere Gleise zusammenfasst, könnte eher die Zusatzinformation aufnehmen, welche der Mitglieder die Lage der Relation repräsentieren sollen. Dem Datenmodell ist es vollkommen egal, ob die Information als Tag ans Objekt eingetragen wird, oder ob man dafuer eine Relation darueber baut und die Information dann als Rolle der Mitglieder erfasst. Der Informationsgehalt diesbezueglich ist erstmal voellig identisch. Interessant wird die Relation erst, wenn man wissen will, wer genau der Master zu einem bestimmten Slave ist. Bei der von dir vorgeschlagenen, hierachischen Ordnung der eigentlich gleichrangigen Element ist das aber nicht notwendig, da der Master ja auch ohne die Informationen vom Slave funktionieren soll. Wenn man aber meint, dass man diese Information braucht, dann darf jede Relation nur einen einzigen Master haben. = Man braucht unheimlich viele Kleinstrelationen und das ganze System ist praktisch nicht mehr zu warten. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Von einer solchen Abstufung halte ich nichts. Schließlich soll der Renderer (und der Programmierer dahinter) entschieden wann er was darstellt. Von daher ist es sinnvoller das Objekt besser zu beschreiben Im Falle vom Fußweg/Radweg/Straße bspw. könnte man kennzeichnen, dass der Radweg und der Fußweg zur Straße gehören und nicht einen eigenständigen Weg bilden. Dann kann der Renderer bspw. alle nicht eigenständigen Wege ausblenden. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Henning Scholland schrieb am 27.05.2011 20:28: Von einer solchen Abstufung halte ich nichts. Schließlich soll der Renderer (und der Programmierer dahinter) entschieden wann er was darstellt. Die Entscheidung liegt ja auch weiterhin bei dem Renderer. Er ist ja nicht gezwungen die Hilfstags auszuwerten, und wenn er es tut, dann kann er das ja auch fuer verschiedene Elemente unterschiedlich handhaben. Eine Karte fuer Radfahrer koennte so z.B. Radwege immer darstellen wollen, eine Karte fuer Autofahrer wuerde sich in diesem Falle anders entscheiden, und bei Gleisen wuerde es beiden reichen, nur eins von mehreren parallel darzustellen. Das Tag ist ja keine verbindliche Vorgabe fuer die Renderer, sondern es ist nur ein Hilfmittel, um den Auswerteprogrammen das Weglassen von Objekten zu erleichtern. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Walter Nordmann schrieb: bedeutet das wirklich, dass alles, was von amazon über diesen link eingekauft wird, 5% für osm bringt? Im Prinzip ja, aber es ist mehr drin: http://uakieree.notlong.com das würde bei einigen 1000 aktiven os-nutzern in deutschland doch wohl mehr bringen als die läppischen 25 pfund/quartal in uk, oder? Das könnte man vermuten. Aber lieber läppische 25£ als nix nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? Das will ich die Tage versuchen, unter Spenden unterzubringen sticky im forum? Falls das nicht schon jemand erledigt, versuche ich das demnächst ebenfalls. Aber /bitte/ keine Mails an jeden Nutzer in .de! ich bin auf jeden fall dabei. Sehr schön :) Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
Hi In neuem Thread da es sonst vielleicht untergeht: In 'Arabische Schriftzeichen arg klein?' vom 16.5. tauchte auf das manche Schriftarten relativ zu unserem Alphabet und Ziffern zu klein sind. Ich dachte ich bastel mal was, klein, banaler Test, unoptimiert: Ein 'neuer' Font (aus dem bestehenden Khmer OS abgeleitet) http://666kb.com/i/btur2tqq8zu78vrft.png Mit absichtlich extremer Verkleinerung der Zeichen A-Za-z0-9. Das grau eingerahmte ist in OpenOffice 'händisch' verkleinert, also nur die Lateinischen auf 8pt statt 12pt. Man sieht das hier der angepasste Font bischen unscharf wird, in OO verkleinert sieht besser aus. Ich hab' da nicht mehr lange dran rumgemacht, ist nur Proof of concept, mal sehen ob es einer brauchen kann. Das ganze ist einfach: von 'sudo apt-get install fontforge' bis zum ersten Ergebnis 20 Minuten, kurz vorm Zubettgehen. Da man fontforge auch scripten kann, die auch eine eigene Mailingliste haben die vielleicht helfen, könnte man zum Rendern der entsprechenden Gebiete leicht mehrere angepasste Fonts erstellen. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Frederik Ramm schrieb: On 05/27/11 10:04, Henning Scholland wrote: nur müsste man das etwas mehr publik machen. link auf openstreetmap.de? sticky im forum? Am besten auch in die nächsten Wochennotiz (Ich will niemand meine Ideologie aufschwatzen, aber ich persoenlich bemuehe mich seit der Wikileaks-Affaere aktiv darum, bei alternativen Anbietern einzukaufen, selbst wenn Amazon oft komfortabler ist.) Wenn man wirklich /alle/ Unternehmen meidet, die irgendwann mal Scheiße gebaut haben, kann man sich gleich auf einen Selbstversorgungsbauernhof zurückziehen. (Das ist keine Verteidigung von Amazon) Wer von euch hat infolge der Wikileaks-Ereignisse seine Visa- (und wer wars gleich noch)-Karte zerschnippelt? Wolfskin hat private Webseitenbetreiber wegen Pfotenabdrucken abgemahnt; von Müller (Sachsenmilch) darf man behaupten, dass sie Genmilch verkaufen; Schwalbe hatte auch ein paar Reseller abgemahnt; Schlecker (persönliche Erfahrung) hat absolut miesen Kundenservice bei Reklamationen (eiigentlich nichtexistent); $alle Discounter beuten ihr Personal aus, Jakob Elektronik ersetzt keine spontan durchgebrannten teuren Grafikkarten, Apple ist usw usf. Gibt es eine Liste, die man abonnieren kann? ;) Ich finde, dass wir fuer ein paar Prozent Provision nicht unbedacht Werbung fuer Amazon auf OpenStreetMap machen sollten (und sowohl sticky im Forum als auch Wochennotiz bedeuten ein prominentes Placement auf einer openstreetmap.org/openstreetmap.de-Domain). Totschweigen wäre aber auch nicht schön. Imo. Wenn ueberhaupt, dann wuerde ich eine Seite im Wiki anlegen: Unternehmen, die OpenStreetMap eine Provision zahlen, wenn man bei ihnen einkauft, und auf diese Seite verlinken. So ähnlich gibt es die schon: http://wiki.openstreetmap.org/wiki/Merchandise Eine herausgestellte Nennung von Amazon (Hey, Leute, kauft doch alle bei Amazon, das bringt noch 5% fuer OSM) faende ich nicht in Ordnung. Einen Hinweis: Wenn ihr bei Amazon kaufen wollt: über diesen Link bekommt OSM 5% Provision fände ich persönlich ok. Wer dort nicht kaufen will, tut es nicht. Möglicherweise ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
Hi Im Moment sind das aber nur Konsonanten. Die Vokale werden um die Konsonanten herum geschrieben und machen momentan Probleme. Zudem gibt es für alle Konsonanten 2 Schreibweisen. Also so ähnlich wie bei uns die groß/klein Schreibung. Für solche Tests wären also richtige Wörter sinnvoll. lg, Bernhard On 2011-05-27 22:38, Peter wrote: Hi In neuem Thread da es sonst vielleicht untergeht: In 'Arabische Schriftzeichen arg klein?' vom 16.5. tauchte auf das manche Schriftarten relativ zu unserem Alphabet und Ziffern zu klein sind. Ich dachte ich bastel mal was, klein, banaler Test, unoptimiert: Ein 'neuer' Font (aus dem bestehenden Khmer OS abgeleitet) http://666kb.com/i/btur2tqq8zu78vrft.png Mit absichtlich extremer Verkleinerung der Zeichen A-Za-z0-9. Das grau eingerahmte ist in OpenOffice 'händisch' verkleinert, also nur die Lateinischen auf 8pt statt 12pt. Man sieht das hier der angepasste Font bischen unscharf wird, in OO verkleinert sieht besser aus. Ich hab' da nicht mehr lange dran rumgemacht, ist nur Proof of concept, mal sehen ob es einer brauchen kann. Das ganze ist einfach: von 'sudo apt-get install fontforge' bis zum ersten Ergebnis 20 Minuten, kurz vorm Zubettgehen. Da man fontforge auch scripten kann, die auch eine eigene Mailingliste haben die vielleicht helfen, könnte man zum Rendern der entsprechenden Gebiete leicht mehrere angepasste Fonts erstellen. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Frederik Ramm schrieb: ausser wenn man bereit ist, auf Dauer *jeden*, der uns Provision gibt, an diesem Ort zu listen. +1, es dürfte OSM durchaus nützen Wie es die Forenadmins sehen, kann ich aber nicht beurteilen. malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
n'Abend Am 27.05.2011 22:47, schrieb Bernhard Zwischenbrugger: Im Moment sind das aber nur Konsonanten. Die Vokale werden um die Konsonanten herum geschrieben und machen momentan Probleme. Zudem gibt es für alle Konsonanten 2 Schreibweisen. Also so ähnlich wie bei uns die groß/klein Schreibung. Für solche Tests wären also richtige Wörter sinnvoll. Für mich sind das nur hübsche Symbole:-) Von chinesischen würde ich vielleicht 3 erkennen, höchstens. Die scheinen auch zu klein, mehr macht blos so'n Quark in Fonts? Tests braucht man ansich nicht (LOL), wenn das mit dem 'Khmer OS' geht dann ist es ok, wird genauso gehen. Es ist derselbe Font, nur die von char(33)=='!' bis char(255) oder so verkleinert. Schick' halt einen Text hierher, ich mach Bild. Kann halt sein das durch das skalieren die a-z etc. zu dünn in den Strichen werden. Oder das es vom Konzept nicht hilft. Peter On 2011-05-27 22:38, Peter wrote: Hi In neuem Thread da es sonst vielleicht untergeht: In 'Arabische Schriftzeichen arg klein?' vom 16.5. tauchte auf das manche Schriftarten relativ zu unserem Alphabet und Ziffern zu klein sind. Ich dachte ich bastel mal was, klein, banaler Test, unoptimiert: Ein 'neuer' Font (aus dem bestehenden Khmer OS abgeleitet) http://666kb.com/i/btur2tqq8zu78vrft.png Mit absichtlich extremer Verkleinerung der Zeichen A-Za-z0-9. Das grau eingerahmte ist in OpenOffice 'händisch' verkleinert, also nur die Lateinischen auf 8pt statt 12pt. Man sieht das hier der angepasste Font bischen unscharf wird, in OO verkleinert sieht besser aus. [...] Tofu schmeckt pappig ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
Hi² Am 27.05.2011 22:47, schrieb Bernhard Zwischenbrugger: Im Moment sind das aber nur Konsonanten. Die Vokale werden um die Konsonanten herum geschrieben und machen momentan Probleme. Zudem gibt es für alle Konsonanten 2 Schreibweisen. Also so ähnlich wie bei uns die groß/klein Schreibung. Für solche Tests wären also richtige Wörter sinnvoll. Ich verstehe nun besser. Das Rendering in osm scheint mehr als mies. Bsp: http://www.openstreetmap.org/browse/node/256842008 Im Browser ist der Name schön in der Karte Örks. Hier als Bild falls der Browser des Betrachters es auch nicht packt: http://666kb.com/i/btusu95vydzcmf5pl.png Selbst der kde desktop zeigt den Text besser an (Name taucht in title der osm -html seite auf: also auch in der Fensterleiste) Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Hi, On Fri, 27 May 2011 17:57:53 +0200 Pascal Neis pascal.n...@gmail.com wrote: OMG, auf http://www.openstreetmap.info/ geht es nur um das Buch !!! Da ist sogar ein amazon-Bestell-Link. Pfui! Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
malenki wrote: So ähnlich gibt es die schon: http://wiki.openstreetmap.org/wiki/Merchandise Danke, dass du dich da so reinkniest ;) genau auf diese Liste bin ich früher mal reingefallen und hab sie daher als uninteressant abgelegt. Das waren von einiger Zeit nur klassische Merchandizing-Produkte, also Sachen, die direkt was mit OSM zu tun hatten (Tasse u.ä.) Das es jetzt Firmen gibt, die das völlig ohne OSM-Bezug machen, war mir echt neu. Gruss Walter p.s. eigentlich ist mir nicht so klar, WARUM die das machen - aber ist mir relativ egal, solange die Kasse stimmt. - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/amazon-de-affiliate-fur-OSM-tp6391845p6412677.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kundenparkplatz
Am 24.05.2011 18:15, schrieb Stephan Wolff: Am 24.05.2011 17:06, schrieb Peter: Am 23.05.2011 20:11, schrieb Stephan Wolff: Mir nicht. name=Kunden Rewe ist offensichtlich falsch. Seh' ich nicht das das falsch ist. das mit note/desc. mag ok sein, aber wenn man das nicht in der Karte sieht ist es fast nutzlos. [] OSM ist auch eine Karte, keine Datenhalde. Du hast das Grundprinzip von OSM nicht verstanden. OSM ist eine Datensammlung aus der (unter anderem) verschiedene Karten berechnet werden. Bei Bedarf werden die Regeln zur Kartendarstellung angepasst, nicht die Daten an die erwünschte Darstellung. Ich hab' das schon verstanden. Was 'ne Unterstellung. Nur ist es so wenn 'die hohen Herren' das Werkzeug nicht geeignet bauen (mal harsch daher gesagt:-) dann geht der gemeine Mapper halt hin und macht was daraus was ihm geeignet scheint. So sind die Leute nunmal. Ich habe mal die Parkplätze (nur way) einer Großstadt gesucht: 400 Stück, 20% haben Namen, über den Daumen gepeilt sind die hälfte(!) Kundenparkplätze, an den Namen erkennbar. access=customers haben 2(!) Ergo ist das ganze ein Dokumentationsproblem, oder am Editor (josm bietet weder in access noch in der Vorlage 'Parkplatz' was an) Ich werf' da keinem der tätigen was vor (nur den Meckerern), das sind einfach Kleinigkeiten die vorkommen. Nun warte man bis das Parkplatz proposal erledigt ist, das mit access oder wie auch immer man den Parkplatz an den Laden bindet, dann die Renderer angepasst sind (wird dann name='' oder der zugehörige Laden angezeigt? Besser beides.) Danach kannst du dann hingehen und die geschätzt 5000 name='Laden' löschen:-) Ich werde den einen Kundenparkplatz den ich erfasste dann höchst persönlich korrigieren. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Arabische Schriftzeichen arg klein?
Am 24.05.2011 18:21, schrieb Claudius: Am 21.05.2011 00:31, Peter: Am 16.05.2011 23:37, schrieb Stephan Knauss: On 16.05.2011 22:13, Peter wrote:' ich nicht, Kann es sein das die arabische Schrift in Mapnik Karten etwas klein ist? ja, ist sie. Nicht nur die. Auch die ganzen asiatischen Schriften. Problem ist der Font. Größere Größe einstellen? Das Problem ist, dass der Font alle Schriftzeiche, also lateinische und andere enthält. Man kann nicht die Schriftgröße nur für Teile des Fonts einstellen. Kommt auf die Umgebung an:-) Ich würd'mir das zutrauen in Java zu können, naja mal dahergesagt, würde einfach den Text zerhacken und lateinisches kleiner rendern. Aber das ist evtl. zu einfach gedacht. Eine Lösung könnte sein den Font anzupassen, dazu gibt's einen neuen Thread. Besonders bei den asiatischen Schriften ist dann noch das Problem, dass die Ziffern eine deutlich andere Größe haben als die restliche Schrift. Wusst' ich nicht. Würde ich einfach mal ignorieren, zumindest hierzuland sind Ziffern selten in Namen. Leetspeak ist auch out. Kommt in Straßen- oder Gebietsnamen aber recht häufig vor. Siehe hier: http://osm.org/go/zY1jvR3U Ah. Wenn man nachdenkt kann das natürlich auch anderswo '5th Avenue' auftauchen. Da macht es nix, kommt aber vor. Ich suche für meine Iran-Karte auch schon seit längerem nach einem schöneren, freien Font. Es scheint aber keine freien, auf die Kartendarstellung optimierte, internationalisierte Fonts zu geben. Und als Programmierer kann man sowas schlecht nachrüsten. Och. Man kann oft schon, kommt auf die Energie an die man einsetzen kann. Geht nicht gibt's nicht kann allerdings eine menge Zeit verbrauchen:-( Die 90/10 Lösung kann erstmal reichen bis man vielleicht ein sowieso besseres Gesamtkonzept hat. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Frederik Ramm schrieb: Pascal Neis pascal.n...@gmail.com wrote: OMG, auf http://www.openstreetmap.info/ geht es nur um das Buch !!! Da ist sogar ein amazon-Bestell-Link. Pfui! ...dem der affiliate-Tag fehlt *renn* ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Walter Nordmann schrieb: malenki wrote: So ähnlich gibt es die schon: http://wiki.openstreetmap.org/wiki/Merchandise Danke, dass du dich da so reinkniest ;) Auf der Seite habe ich nur den Zweizeiler für amazon.de ergänzt. Das Layout im Quelltext ist übrigens interessant. genau auf diese Liste bin ich früher mal reingefallen und hab sie daher als uninteressant abgelegt. Das waren von einiger Zeit nur klassische Merchandizing-Produkte, also Sachen, die direkt was mit OSM zu tun hatten (Tasse u.ä.) Man könnte das Cleanup-Team um Hilfe bitten, diese Seite übersichtlich zu sortieren... Das es jetzt Firmen gibt, die das völlig ohne OSM-Bezug machen, war mir echt neu. Wenn man es einrichtet, geht das schon ;) Der britische Amazon-Link dürfte gegen fünf Jahre alt sein. gn8 malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 27.05.2011 19:28, schrieb Heiko Jacobs: Am 27.05.2011 12:26, schrieb Garry: Am 27.05.2011 10:51, schrieb Steffen Grunewald: Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Bekanntestes Beispiel in D dürfe der Albaufstieg der A8 zwischen Stuttgart und Ulm sein, in bergigen Regionen kommt das öfter mal vor. Da isses platt wie 'ne Flunder: http://www.openstreetmap.org/?lat=52.7583lon=9.6679zoom=14layers=M Kennt da jemand zufällig den Grund? Würde auf militärische Gründe tippen, entweder dass mit einer Bombe nicht so leicht beide Fahrbahnen zerstört werden können oder wegen der Tragfähigkeit des Untergrundes.. Vielleicht auch nur dass man später eine zusätzliche Fahrspur einbauen kann ohne mit Natur/Landschaftsschutzgebiten in Konflickt zu geraten. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evtl. Lösung für zu kleine Schrift bei nicht Lateinischem Alphabet
Hallo Peter, On 27.05.2011 23:07, Peter wrote: Tests braucht man ansich nicht (LOL), wenn das mit dem 'Khmer OS' geht dann ist es ok, wird genauso gehen. Es ist derselbe Font, so einfach ist es leider nicht. liegt an der Art wie Mapnik mit den Zeichen umgeht. Es rendert jedes für sich allein stehend. Leider gehen dadurch all die Zeichen kaputt die Kontext brauchen. Und das passiert bei den Khmer Zeichen häufiger. Lässt sich ohne größeren Eingriff in Mapnik nicht korrigieren. Siehe auch den Link vom letzten Mal. Dort gab es die Diskussion bzw. auch den Link auf das trac von Mapnik. http://lists.berlios.de/pipermail/mapnik-devel/2010-September/001245.html http://trac.mapnik.org/wiki/InternationalText Font anpassen ist bei Fonts die unter GPL stehen zumindest kein Lizenzproblem. Besser dürfte es sein wenn solche Sachen leute machen die sich mit Fonts auskennen. Kerning, Hinting und was es da so alles gibt muss schon passen. Für die meisten Schriften hat das aber in der Regel schon jemand gemacht. Man muss den Font nur finden. Für meine thaimap hatte ich loma verwendet und die fontsize generell etwas erhöht. Damit hat die Karte den Muttersprachlertest bestanden. Hat jemand Details wie man pango in mapnik reinbekommt? Damit soll es gerüchteweise auch mit anderen Schriften funktionieren. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Am 27. Mai 2011 13:01 schrieb Frederik Ramm frede...@remote.org: Ich sag ja - Wikiseite mit allen Anbietern, die uns Provision zahlen, und gut is. Posting im Forum uebrigens gibts jetzt auch bei amazon.de Provision mit Link auf Webseite. Aber kein prominentes sticky-Posting, +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Calà del Sasso - steps, path o track?
2011/5/23 Paolo Pozzan pa...@z2z.it: Confermo che non c'è nessun cartello di divieto (o meglio, 2 anni fa non c'era): http://www.flickr.com/photos/paolop/5751611221 Inoltre secondo me highway=steps blocca un eventuale routing per le MTB... Dipende dalle zone comunque. Se non ricordo male, ad esempio in A.A. nessun sentiero e' permesso alle MTB, solo quelli esplicitati. E se non ho capito male ieri sera mi hanno detto che il requisito di transitabilità e' farci stare la MTB di traverso. -- E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.dancetj.net , lorenzetto.l...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Calà del Sasso - steps, path o track?
2011/5/27 niubii f.pelu...@gmail.com: Potrebbe essere una distinzione utile per qualche applicazione di routing. La distinzione ha senso se ha significato :-) Attualmente su OSM bicycle=no vuol dire non è permesso transitare in bici, non non è permesso neppure andare a piedi spingendo la bici Se si vuole introdurre una distinzione tra bicycle=dismount e bicycle=yes, bisogna modificare la maggior parte dei bicycle=no già mappati in bicycle=dismount, perché è questo che in realtà sono. In pratica bicycle=no sparirebbe e rimarrebbe solo a Sirmione nel periodo estivo... Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Calà del Sasso - steps, path o track?
Difatti, a me sembra che un senso ci sia ;-) Openrouteservice calcola il routing per le biciclette soltanto sui percorsi dove non è esplicitamente vietato (bicycle=no) (ipotesi riduttiva, non lo so, immagino che escluda anche casi in cui è implicito che in bici non ci vai, tipo motorways etc). Supponiamo che nel percorso ideale che mi piacerebbe fare ci sia un tratto taggato highway=path bicycle=no Openrouteservice lo utilizzerebbe nel routing? Penso di no, mi farebbe passare da qualche altra parte. I locals, nella stessa ipotesi, sanno che non è vietato in assoluto passare in bicicletta di là; sanno che per quel tratto specifico ci devi andare a piedi e poi rimonti su, quindi non escludono quel percorso dalla possibile lista di opzioni. Probabilmente hai ragione quando scrivi che bisognerebbe modificare tutti i bicycle=no Ciao /niubii/ Il giorno 27 maggio 2011 16:07, Federico Cozzi f.co...@gmail.com ha scritto: 2011/5/27 niubii f.pelu...@gmail.com: Potrebbe essere una distinzione utile per qualche applicazione di routing. La distinzione ha senso se ha significato :-) Attualmente su OSM bicycle=no vuol dire non è permesso transitare in bici, non non è permesso neppure andare a piedi spingendo la bici Se si vuole introdurre una distinzione tra bicycle=dismount e bicycle=yes, bisogna modificare la maggior parte dei bicycle=no già mappati in bicycle=dismount, perché è questo che in realtà sono. In pratica bicycle=no sparirebbe e rimarrebbe solo a Sirmione nel periodo estivo... Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-es] acceder a datos OSM
Hola colisteros Estoy haciendo una investigación sobre calidad y credibilidad de los datos VGI. OSM me ha parecido la mejor iniciativa sobre la que testear estos parámetros de calidad. He estado trasteando por la wiki de OSM y he descargado el planet para incorporarlo a postgis. El planet de OSM no contiene información sobre los metadoatos (usuario, referencia, fecha de creación modificación, cartografía de referencia, etc,). Hay alguna manera de conectarse a la base de datos que contine esta información. Muchas Gracias Pau Aragó Galindo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] acceder a datos OSM
Oye, sólo por curiosidad... ¿Qué significa exactamente VGI? 2011/5/27 Pau Aragó sani...@gmail.com Hola colisteros Estoy haciendo una investigación sobre calidad y credibilidad de los datos VGI. OSM me ha parecido la mejor iniciativa sobre la que testear estos parámetros de calidad. He estado trasteando por la wiki de OSM y he descargado el planet para incorporarlo a postgis. El planet de OSM no contiene información sobre los metadoatos (usuario, referencia, fecha de creación modificación, cartografía de referencia, etc,). Hay alguna manera de conectarse a la base de datos que contine esta información. Muchas Gracias Pau Aragó Galindo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jonay ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] acceder a datos OSM
VGI son la siglas en inglés de Volunteer Geographic Information. Traducido sería algo así como voluntariado Geográfico. Al 27/05/11 12:00, En/na Jonay Santana ha escrit: Oye, sólo por curiosidad... ¿Qué significa exactamente VGI? 2011/5/27 Pau Aragó sani...@gmail.com mailto:sani...@gmail.com Hola colisteros Estoy haciendo una investigación sobre calidad y credibilidad de los datos VGI. OSM me ha parecido la mejor iniciativa sobre la que testear estos parámetros de calidad. He estado trasteando por la wiki de OSM y he descargado el planet para incorporarlo a postgis. El planet de OSM no contiene información sobre los metadoatos (usuario, referencia, fecha de creación modificación, cartografía de referencia, etc,). Hay alguna manera de conectarse a la base de datos que contine esta información. Muchas Gracias Pau Aragó Galindo ___ Talk-es mailing list Talk-es@openstreetmap.org mailto:Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jonay ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-at] Nutzung der Stadt Wien OGD-Daten
Hallo an Alle! Gestern war das erste Open Government Data (OGD) Plattform Treffen der Stadt Wien und dabei war die Nutzung der Daten durch OpenStreetMap kurz ein Thema. Der aktuelle Stand aus Sicht der Stadt Wien ist folgender: - Aus Sicht der Stadt Wien steht der Nutzung der OGD Daten durch OSM grundsätzlich nichts im Wege - Was die durch die CC BY 3.0 [0] geforderte Namensnennung betrifft, würde es der Stadt Wien (eventuell) reichen, wenn die Stadt Wien unter http://www.openstreetmap.org/copyright als Datenquelle genannt wird. - Wir bekommen das (vielleicht) auch in irgendeiner Form schriftlich Beim nächtsten OGD Treffen am 30. Juni 2011 [1] sollen die für das Thema zustängigen JuristInnen teilnehmen, wo wir das Thema im Detail besprechen bzw. eventuell endgültig klären können. Zusätzlich soll bis zum nächsten OGD Treffen der Katalog der verfügbaren Daten weiter ausgebaut werden und es sind in dem Zusammenhang die Worte Hausnummern, Bildkacheln und Orthofotos gefallen. Welche Daten aber in welcher Form freigegeben werden, wird erst wirklich klar sein sobald es soweit ist. cu andreas [0] http://creativecommons.org/licenses/by/3.0/at/deed.de [1] http://data.wien.gv.at/veranstaltungen/index.html ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada : Follow-up (Complement of information)
Hi Pierre, The 30 m contour lines from tiles 031h03 and 031h06 (the shapefiles you gave), potentially connected to Richelieu river, have been imported, and put together in relation: http://www.openstreetmap.org/?relation=1602671 Clearly, it is not enough to estimate the flooded zone, for which some kind of flow analysis would be needed, but maybe it can help in some areas, as you wrote. I used ogr2ogr -where ELEVATION=30 ... to extract the 30m contour line, and ogr2osm.py to convert it to .osm, for Josm. Best wishes, Jean-Guilhem Le 27/05/2011 06:30, Brent Fraser a écrit : Pierre, I can't comment on if the 30m contour solution is suitable, but if you want to extract the 30m contours, you could: 1. Use QGIS to extract 30m contour from *_FO.._1.shp files - load shapefile, Open Attribute Table, click on elevation field name to sort table by elevation value. - select all 30m values, click on Layer - Save selection as vector file. Save shapefile 2. Use converter (one of the ones on http://wiki.openstreetmap.org/wiki/Import/Shapefile) to create .osm files (I haven't tried this) 3. Use Josm to load osm files, tag, and update to OSM Best Regards, Brent Fraser On 5/26/2011 8:46 PM, Pierre Béland wrote: Many osm volunteers have worked in the last two days to correct roads, complete Canvec import and add street names. An other task is to estimate the flooded zone along the Richelieu River and Missisquoi Bay in Lake Champlain. One simple approach to determine the flooded zones would be to use the 30 meter contour line from Canvec data. This would be good at least for Richelieu River. These maps from Natural Resources Dept of Canada shows the 30 meter contour line. For the areas I visited last week with volunteers, this line delimits approximately the flooded zone. On monday 23, water level of the Richelieu river went up to approximately 30.8 meters in Saint-Jean-sur-Richelieu. Would it be a good solution to estimate the flooded zone ? If so, any idea, how we can extract 30 meter contour line from shape files using a tool such as Quantum GIS and convert to OSM ? ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h03_shp.zip ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h03_shp.zip ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h06_shp.zip ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h03_shp.zip Below is an example of Toporama map for Saint-Jean-sur-Richelieu, the wms version of Canvec, where we can see the 30 meter contour line. http://atlas.nrcan.gc. ca/auth/english/maps/topo/map?mapsize=525%20466mapxy=1700511.0503883713%20-122536.87132125527scale=2.00feature_na=Saint-Jean-sur-Richelieusearchstring=saint-jean-sur-richelieulayers=fapfeature%20nodata_ntdb_50k%20north_arrow%20other_features%20roads%20hydrography%20boundary%20builtup%20vegetation%20populated_places%20railway%20power_network%20manmade_features%20designated_areas%20water_features%20water_saturated_soils%20relief%20contours%20toponymy%20contourmap_layer[northarrow]_class[0]_style[0]=ANGLE%20-19.595747561783185urlappend=%26unique_key%3D8dd3e319d1e111d892e2080020a0f4c9%26map.layer[textzoom03]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+TEXT+%22Saint-Jean-sur-Richelieu%22+END%26map.layer[textzoom46]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+TEXT+%22Saint-Jean-sur-Richelieu%22+END%26map.layer[arrowzoom03]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+END http://atlas.nrcan.gc.ca/auth/english/maps/topo/map?mapsize=525%20466mapxy=1700511.0503883713%20-122536.87132125527scale=2.00feature_na=Saint-Jean-sur-Richelieusearchstring=saint-jean-sur-richelieulayers=fapfeature%20nodata_ntdb_50k%20north_arrow%20other_features%20roads%20hydrography%20boundary%20builtup%20vegetation%20populated_places%20railway%20power_network%20manmade_features%20designated_areas%20water_features%20water_saturated_soils%20relief%20contours%20toponymy%20contourmap_layer[northarrow]_class[0]_style[0]=ANGLE%20-19.595747561783185urlappend=%26unique_key%3D8dd3e319d1e111d892e2080020a0f4c9%26map.layer[textzoom03]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+TEXT+%22Saint-Jean-sur-Richelieu%22+END%26map.layer[textzoom46]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+TEXT+%22Saint-Jean-sur-Richelieu%22+END%26map.layer[arrowzoom03]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+END regards /Pierre Béland / *De :* Pierre Béland *Date/heure :* 2011-05-24 18:59:16 *A :* HOT Openstreetmap *Cc :* talk-ca *Sujet :* [HOT] Flooding in Richelieu River, Quebec,Canada : Follow-up (Complement of information) Following are the ways and relation I have produced to document Richelieu River flooding. Affected zones (These will be revised when I obtain
Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up (Complement of information)
Very thanks to Sam Vekemans, Brent Fraser and Jean-Guilhem Cailton for their suggestions and help. Jean-Guilhem Cailton wrote on 201-05-27 The 30 m contour lines from tiles 031h03 and 031h06 (the shapefiles you gave), potentially connected to Richelieu river, have been imported, and put together in relation: http://www.openstreetmap.org/?relation=1602671 Jean-Guilhem, I will use this information for a basis of discussion, and see how it can reflect the flooded zones. Could you easily add to the relation, the 30m elevation for Missisiquoi Bay where Venise-en-Quebec town has been severely affected by floods? regards, Pierre Béland 2011-05-27 De : Jean-Guilhem Cailton Date/heure : 2011-05-27 05:19:54 A : Pierre_Béland Cc : Brent Fraser; HOT Openstreetmap; talk-ca Sujet : Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up (Complement of information) Hi Pierre, The 30 m contour lines from tiles 031h03 and 031h06 (the shapefiles you gave), potentially connected to Richelieu river, have been imported, and put together in relation: http://www.openstreetmap.org/?relation=1602671 Clearly, it is not enough to estimate the flooded zone, for which some kind of flow analysis would be needed, but maybe it can help in some areas, as you wrote. I used ogr2ogr -where ELEVATION=30 ... to extract the 30m contour line, and ogr2osm.py to convert it to .osm, for Josm. Best wishes, Jean-Guilhem Le 27/05/2011 06:30, Brent Fraser a écrit : Pierre, I can't comment on if the 30m contour solution is suitable, but if you want to extract the 30m contours, you could: 1. Use QGIS to extract 30m contour from *_FO.._1.shp files - load shapefile, Open Attribute Table, click on elevation field name to sort table by elevation value. - select all 30m values, click on Layer - Save selection as vector file. Save shapefile 2. Use converter (one of the ones on http://wiki.openstreetmap.org/wiki/Import/Shapefile) to create .osm files (I haven't tried this) 3. Use Josm to load osm files, tag, and update to OSM Best Regards, Brent Fraser On 5/26/2011 8:46 PM, Pierre Béland wrote: Many osm volunteers have worked in the last two days to correct roads, complete Canvec import and add street names. An other task is to estimate the flooded zone along the Richelieu River and Missisquoi Bay in Lake Champlain. One simple approach to determine the flooded zones would be to use the 30 meter contour line from Canvec data. This would be good at least for Richelieu River. These maps from Natural Resources Dept of Canada shows the 30 meter contour line. For the areas I visited last week with volunteers, this line delimits approximately the flooded zone. On monday 23, water level of the Richelieu river went up to approximately 30.8 meters in Saint-Jean-sur-Richelieu. Would it be a good solution to estimate the flooded zone ? If so, any idea, how we can extract 30 meter contour line from shape files using a tool such as Quantum GIS and convert to OSM ? ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h03_shp.zip ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h06_shp.zip Below is an example of Toporama map for Saint-Jean-sur-Richelieu, the wms version of Canvec, where we can see the 30 meter contour line. http://atlas.nrcan.gc. ca/auth/english/maps/topo/map?mapsize=525%20466mapxy=1700511.0503883713%20-122536.87132125527scale=2.00feature_na=Saint-Jean-sur-Richelieusearchstring=saint-jean-sur-richelieulayers=fapfeature%20nodata_ntdb_50k%20north_arrow%20other_features%20roads%20hydrography%20boundary%20builtup%20vegetation%20populated_places%20railway%20power_network%20manmade_features%20designated_areas%20water_features%20water_saturated_soils%20relief%20contours%20toponymy%20contourmap_layer[northarrow]_class[0]_style[0]=ANGLE%20-19.595747561783185urlappend=%26unique_key%3D8dd3e319d1e111d892e2080020a0f4c9%26map.layer[textzoom03]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+TEXT+%22Saint-Jean-sur-Richelieu%22+END%26map.layer[textzoom46]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+TEXT+%22Saint-Jean-sur-Richelieu%22+END%26map.layer[arrowzoom03]%3DFEATURE+POINTS+1699114.16619+-120243.877124+END+END regards Pierre Béland De : Pierre Béland Date/heure : 2011-05-24 18:59:16 A : HOT Openstreetmap Cc : talk-ca Sujet : [HOT] Flooding in Richelieu River, Quebec,Canada : Follow-up (Complement of information) Following are the ways and relation I have produced to document Richelieu River flooding. Affected zones (These will be revised when I obtain more detailed information on streets / areas affected. http://www.openstreetmap.org/browse/way/114705927 http://www.openstreetmap.org/browse/way/114705926 http://www.openstreetmap.org/browse/way/114705928 http://www.openstreetmap.org/browse/way/114706976 Boundary relation that could be used to produce Indexed map of streets with tools
Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up (Complement of information)
Dear Pierre, According to the shapefile data, Lake Champlain, and hence Venise-en-Québec are above the 30 m elevation. The shapefile contains punctual elevations of 31 m in this area (Plage Missisquoi, for example). The next contour line would be the 40 m one, but it does not look like it would be very useful for this. Best regards, Jean-Guilhem Le 27/05/2011 13:12, Pierre Béland a écrit : Very thanks to Sam Vekemans, Brent Fraser and Jean-Guilhem Cailton for their suggestions and help. Jean-Guilhem Cailton wrote on 201-05-27 The 30 m contour lines from tiles 031h03 and 031h06 (the shapefiles you gave), potentially connected to Richelieu river, have been imported, and put together in relation: http://www.openstreetmap.org/?relation=1602671 Jean-Guilhem, I will use this information for a basis of discussion, and see how it can reflect the flooded zones. Could you easily add to the relation, the 30m elevation for Missisiquoi Bay where Venise-en-Quebec town has been severely affected by floods? regards, /Pierre Béland / 2011-05-27 *De :* Jean-Guilhem Cailton *Date/heure :* 2011-05-27 05:19:54 *A :* Pierre_Béland *Cc :* Brent Fraser; HOT Openstreetmap; talk-ca *Sujet :* Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up (Complement of information) Hi Pierre, The 30 m contour lines from tiles 031h03 and 031h06 (the shapefiles you gave), potentially connected to Richelieu river, have been imported, and put together in relation: http://www.openstreetmap.org/?relation=1602671 Clearly, it is not enough to estimate the flooded zone, for which some kind of flow analysis would be needed, but maybe it can help in some areas, as you wrote. I used ogr2ogr -where ELEVATION=30 ... to extract the 30m contour line, and ogr2osm.py to convert it to .osm, for Josm. Best wishes, Jean-Guilhem Le 27/05/2011 06:30, Brent Fraser a écrit : Pierre, I can't comment on if the 30m contour solution is suitable, but if you want to extract the 30m contours, you could: 1. Use QGIS to extract 30m contour from *_FO.._1.shp files - load shapefile, Open Attribute Table, click on elevation field name to sort table by elevation value. - select all 30m values, click on Layer - Save selection as vector file. Save shapefile 2. Use converter (one of the ones on http://wiki.openstreetmap.org/wiki/Import/Shapefile) to create .osm files (I haven't tried this) 3. Use Josm to load osm files, tag, and update to OSM Best Regards, Brent Fraser On 5/26/2011 8:46 PM, Pierre Béland wrote: Many osm volunteers have worked in the last two days to correct roads, complete Canvec import and add street names. An other task is to estimate the flooded zone along the Richelieu River and Missisquoi Bay in Lake Champlain. One simple approach to determine the flooded zones would be to use the 30 meter contour line from Canvec data. This would be good at least for Richelieu River. These maps from Natural Resources Dept of Canada shows the 30 meter contour line. For the areas I visited last week with volunteers, this line delimits approximately the flooded zone. On monday 23, water level of the Richelieu river went up to approximately 30.8 meters in Saint-Jean-sur-Richelieu. Would it be a good solution to estimate the flooded zone ? If so, any idea, how we can extract 30 meter contour line from shape files using a tool such as Quantum GIS and convert to OSM ? ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h03_shp.zip ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h03_shp.zip ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h06_shp.zip ftp://ftp2.cits.rncan.gc.ca/pub/canvec/50k_shp/031/h/canvec_031h03_shp.zip Below is an example of Toporama map for Saint-Jean-sur-Richelieu, the wms version of Canvec, where we can see the 30 meter contour line. http://atlas.nrcan.gc.
Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)
Jean-Guilhem Cailton wrote on 2011-05-27 According to the shapefile data, Lake Champlain, and hence Venise-en-Québec are above the 30 m elevation. The shapefile contains punctual elevations of 31 m in this area (Plage Missisquoi, for example). The next contour line would be the 40 m one, but it does not look like it would be very useful for this. This is exact. The 40 meter contour line is not usefull for us. Thanks Jean-Guilhem. Pierre Béland ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)
Bonjour tous le monde, I have generated a 30m and 31m contour lines for Richelieu river and lake Champlain (using SRTM data). It fits the 30m contour provided by Jean-Guilhem but doesn't seem to fit pretty well the flooded wetland area provided by Pierre. Any idea if this data can be used (usgs licence point of view)? And if it can be usefull? Daniel _ From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] Sent: May-27-11 12:40 To: HOT Openstreetmap Cc: talk-ca Subject: Re: [HOT] [Talk-ca] Flooding in Richelieu River, Quebec,Canada :Follow-up(Complement of information) Jean-Guilhem Cailton wrote on 2011-05-27 According to the shapefile data, Lake Champlain, and hence Venise-en-Québec are above the 30 m elevation. The shapefile contains punctual elevations of 31 m in this area (Plage Missisquoi, for example). The next contour line would be the 40 m one, but it does not look like it would be very useful for this. This is exact. The 40 meter contour line is not usefull for us. Thanks Jean-Guilhem. Pierre Béland ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)
2011/5/27 Daniel Begin jfd...@hotmail.com: Bonjour tous le monde, I have generated a 30m and 31m contour lines for Richelieu river and lake Champlain (using SRTM data). It fits the 30m contour provided by Jean-Guilhem but doesn't seem to fit pretty well the flooded wetland area provided by Pierre. Any idea if this data can be used (usgs licence point of view)? And if it can be usefull? SRTM is USGov-PD. It is probably most-useful as a separate layer to displayed over other / better / different data. That keeps it out of OSM; keeps the origin clear; and make it easy to combine as desired with other data. It would be hacky to publish the 30m, 31m, etc. topo lines as gpx, but it would make mashing them up in OpenLayers or on various other maps pretty easy. Example and tutorial: http://weait.com/content/easy-osm-your-gpx-tracks ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)
Daniel, The SRTM data has 90m cell size, while the CDED (from the Geobase site) has 30m cells (and 1m height resolution) which might rendered better contours. Best Regards, Brent Fraser On 5/27/2011 11:52 AM, Daniel Begin wrote: Bonjour tous le monde, I have generated a 30m and 31m contour lines for Richelieu river and lake Champlain (using SRTM data). It fits the 30m contour provided by Jean-Guilhem but doesn't seem to fit pretty well the flooded wetland area provided by Pierre. Any idea if this data can be used (usgs licence point of view)? And if it can be usefull? Daniel *From:*Pierre Béland [mailto:infosbelas-...@yahoo.fr] *Sent:* May-27-11 12:40 *To:* HOT Openstreetmap *Cc:* talk-ca *Subject:* Re: [HOT] [Talk-ca] Flooding in Richelieu River, Quebec,Canada :Follow-up(Complement of information) Jean-Guilhem Cailton wrote on 2011-05-27 According to the shapefile data, Lake Champlain, and hence Venise-en-Québec are above the 30 m elevation. The shapefile contains punctual elevations of 31 m in this area (Plage Missisquoi, for example). The next contour line would be the 40 m one, but it does not look like it would be very useful for this. This is exact. The 40 meter contour line is not usefull for us. Thanks Jean-Guilhem. Pierre Béland ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] height data
There seems to be considerable interest in flooding recently. The UK has a government site http://maps.environment-agency.gov.uk/wiyby/wiybyController?ep=maptopicslang=_e that shows the risk of flooding for a particular area. How would you obtain / insert height data into OSM? Thanks John ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] height data
On Fri, May 27, 2011 at 2:22 PM, john whelan jwhelan0...@gmail.com wrote: There seems to be considerable interest in flooding recently. The UK has a government site http://maps.environment-agency.gov.uk/wiyby/wiybyController?ep=maptopicslang=_e that shows the risk of flooding for a particular area. How would you obtain / insert height data into OSM? You don't. ;-) Height data is more difficult to acquire accurately. Our consumer-grade GPSr devices are much better at lat and lon than elevation. With no good way to acquire, and update elevation data, we as a community have decided to leave it out of the OSM data base. There are exceptions to this and there are adaptations to this, namely: POI heights. There are occasional heights for point objects like mountain peaks, and communication antennas. They aren't widely used but you can see some of these in the data. We don't see elevation data for every peak or for every communication tower or building. Elevation mash-ups. OpenCycleMap combines OSM vector data with SRTM raster elevation data. The combined information is presented for cyclists, with hill-shading and contour lines. Many other renderings have used similar methods to combine elevation sources with OSM data. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] fwd: Downtown Calgary deletions
Hi AC, You message was held for moderation, perhaps you have subscribed with a different email account? At any rate, I've taken the unusual decision to edit your email because of the content of the reply. Hope you don't mind. -- Forwarded message -- From: A C osm...@hotmail.ca To: talk-ca@openstreetmap.org Date: Fri, 27 May 2011 18:48:15 -0600 Subject: Deletions in Downtown Calgary Hi all, I discovered a bunch of deletions (about 263) in downtown Calgary and traced it back to this changeset: http://www.openstreetmap.org/browse/changeset/7926911 I contacted the user about this, and this is the [message AC sent]: On 2011-05-26 07:41:43 UTC AKC wrote: Hi, It would appear that you have deleted a whole bunch of things from Downtown Calgary, like the Calgary Courts Centre, the James Short Parkade, some buildings, etc... Could you explain why this is? Thanks, AKC [I have deleted the unhelpful response from the author of changeset/7926911] I want to report this on the list and ask for help in reverting the deletions. Dear AC, and all, Contacting the author again seems unlikely to lead to a happy resolution. It would be reasonable to forward your report about this editor to the Data Working Group with a request for reversion, and a permanent block / removal against the account. You can reach DWG at d...@osmfoundation.org Best regards, Richard ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)
Hi all, I've tried to put my boots on the ground without going there !-). I found a pretty clear satellite image of the river at its max level (30-31m) - which doesn't really changed since ... http://earthobservatory.nasa.gov/NaturalHazards/view.php?id=50577 I made few geometric adjustments to the image and compare the result with 30m GeoBase and SRTM contours. Geobase contours gives better results between St-Jean and L'Île aux Noix but from there to the US boundary, neither GeoBase nor SRTM is right. I'm trying to produce a flooded area from DEM data while I'm looking at an image that contains what I'm looking for - the flooded area! Why not mapping from it? I understand the image can be used - http://earthobservatory.nasa.gov/ImageUse/ Any idea on how I can use this GeoTiff image in JOSM? Cheers, Daniel _ From: Daniel Begin [mailto:jfd...@hotmail.com] Sent: May-27-11 15:18 To: 'Brent Fraser' Cc: 'HOT Openstreetmap'; 'talk-ca' Subject: Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec,Canada :Follow-up(Complement of information) Bonjour Brent, Which one is better in this situation, SRTM or GeoBase? I would prefer SRTM for the following reasons... SRTM has 90m cell size but the data in each cell are real elevation - including roof tops and crop height !, Geobase has 30m cell size but the data in each cell is an interpolation between adjacent contour interval from 50K map. So, in flat/low hills areas, SRTM will give a much better idea of the height than Geobase. For example, a 8m hill, standing between elevation 31m and 39m won't be visible in Geobase data. Same reasoning for a steep cliff, and so on... Furthermore, I suspect that using the 30m contour from SRTM might be valid for St-Jean-Sur-Richelieu area but the 31m should probably be used near Lake Champlain. In this case I would quote James Ewen, You need to Put your boots on the ground to decide which one is valid !-) I'm also looking at converting this into .gpx format as proposed Richard Cheers, Daniel _ From: Brent Fraser [mailto:bfra...@geoanalytic.com] Sent: May-27-11 14:19 To: Daniel Begin Cc: 'Pierre Béland'; 'HOT Openstreetmap'; 'talk-ca' Subject: Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information) Daniel, The SRTM data has 90m cell size, while the CDED (from the Geobase site) has 30m cells (and 1m height resolution) which might rendered better contours. Best Regards, Brent Fraser On 5/27/2011 11:52 AM, Daniel Begin wrote: Bonjour tous le monde, I have generated a 30m and 31m contour lines for Richelieu river and lake Champlain (using SRTM data). It fits the 30m contour provided by Jean-Guilhem but doesn't seem to fit pretty well the flooded wetland area provided by Pierre. Any idea if this data can be used (usgs licence point of view)? And if it can be usefull? Daniel _ From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] Sent: May-27-11 12:40 To: HOT Openstreetmap Cc: talk-ca Subject: Re: [HOT] [Talk-ca] Flooding in Richelieu River, Quebec,Canada :Follow-up(Complement of information) Jean-Guilhem Cailton wrote on 2011-05-27 According to the shapefile data, Lake Champlain, and hence Venise-en-Québec are above the 30 m elevation. The shapefile contains punctual elevations of 31 m in this area (Plage Missisquoi, for example). The next contour line would be the 40 m one, but it does not look like it would be very useful for this. This is exact. The 40 meter contour line is not usefull for us. Thanks Jean-Guilhem. Pierre Béland ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-cz] Navigace OSMAnd - odbočování na dálnici
Ahoj, před pár dny jsem začal používat navigaci OSMAnd na Androidu a všiml jsem si zajímavé věci. Po cestě z Prahy do Jihlavy po D1 mi na dvou místech říkala, ať zahnu doleva. V obou případech to bylo na místě odbočky k pumpě. Na zpáteční cestě bylo takové místo jedno. Jedná se o chybu navigace, nebo je na těch místech v OSM něco nevhodně otagováno, co bych mohl opravit? Díky, Marek ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Fwd: [Fwd: Re: APIE - Réutilisation des données publiques - 24/09/2010]
Le 26/05/2011 19:55, Sébastien Dinot a écrit : Ci-dessous la réponse de Benjamin Jean, juriste et fondateur de Vini, Vidi, Libri (http://vvlibri.org/). Sur la licence IP, il oublie également la présence d'une clause « NC » sur la redistribution telles quelles des données. « 4. Usage commercial ou non de la réutilisation La réutilisation est gratuite et n’impose aucune rémunération du concédant par le licencié, y compris au titre de son exploitation commerciale des informations publiques réutilisées, dès lors qu’elles sont commercialisées après de nouveaux traitements et dans un produit ou un service nouveau auprès des tiers. La réutilisation , commerciale ou non, doit être effectuée par le licencié : il ne peut pas agir en tant qu’intermédiaire et revendre les informations publiques en l’état à un tiers pour commercialisation. » http://www.rip.justice.fr/information_publique_librement_reutilisable Philippe - Forwarded message from Benjamin Jeanmje...@eml.cc - Date: Thu, 26 May 2011 17:26:03 +0200 From: Benjamin Jeanmje...@eml.cc To: Sébastien Dinotsebastien.di...@free.fr Subject: [Fwd: Re: [OSM-talk-fr] APIE - Réutilisation des données publiques - 24/09/2010] X-Mailer: Evolution 2.28.3 Mes messages ne passent pas ! Pour le reste, d'accord avec toi ;) ++ Ben Date: Thu, 26 May 2011 16:17:30 +0100 From: talk-fr-ow...@openstreetmap.org To: m...@venividilibri.org Subject: Re: [OSM-talk-fr] APIE - Réutilisation des données publiques - 24/09/2010 Vous n'êtes pas autorisé à envoyer des messages sur cette liste, votre message a été automatiquement rejeté. Si vous pensez que votre message a été rejeté par erreur, veuillez contacter le gestionnaire de la liste à l'adresse talk-fr-ow...@openstreetmap.org. Date: Thu, 26 May 2011 17:16:56 +0200 From: Benjamin Jeanm...@venividilibri.org To: François Van Der Biestfrancois.vanderbi...@camptocamp.com Cc: Discussions sur OSM en françaistalk-fr@openstreetmap.org Subject: Re: [OSM-talk-fr] APIE - Réutilisation des données publiques - 24/09/2010 X-Mailer: Evolution 2.28.3 Bonjour François, tous, Effectivement les licences de l'APIE ne sont pas compatibles avec une licence de type ODbL (ne serait-ce que parce qu'elles ne sont pas pensées de la même façon). Concernant la licence IP : je ne suis pas certain non plus qu'on puisse la considérer comme automatiquement compatible avec l'ODbL. En effet, de mémoire, elle est seulement basée sur les lois relatives aux informations publiques et ne cède aucun droit de propriété intellectuelle (ce qui n'est pas gênant dans l'hypothèse où le contenu récupéré n'est pas original au sens du droit d'auteur, que sa structuration ne l'est pas non plus, et (là c'est plus sensible) qu'on ne puisse pas considérer qu'il y ait eu un investissement substantiel conférant un droit sui generis sur la BDD). Enfin, elle est aussi limitée, dans le temps je crois (1 an renouvelable par tacite reconduction) : quid des contenus générés ? J'ai lu les échanges de mails sur le wiki, le correspondant ne s'est pas trop mouillé, ce serait bien qu'ils disent/acceptent que les BDD soient cumulativement sous ODbL pour l'intégration à OSM. Cordialement, Benjamin B onjour, Voila ce qui arrive quand on lit les mails trop vite : j'ai confondu licence IP (Information Publique librement réutilisable) et licence APIE. Bref, ce que j'ai écrit ci-dessous ne s'applique pas à la licence APIE mais à la licence IP (= celle du serveur GeoLittoral). J'abonde dans le sens de Sébastien : incompatibilité avec OSM. Désolé pour le bruit. F. 2011/5/26 François Van Der Biestfrancois.vanderbi...@camptocamp.com: Salut René-Luc, (et Benjamin) 2011/5/26 rldhontrldh...@gmail.com: Bonjour, En consultant la licence APIE sur la réutilisation des données publiques, voici ce qui y est écrit sur fond bleu (pour le mettre en avant) : Pour favoriser la création de nouveaux produits et services et contribuer au,développement économique, la loi n°78-753 du 17 juillet 1978 crée un droit de réutilisation des,informations publiques.,Ainsi, les informations qui entrent dans le champ de cette loi peuvent être exploitées à,d’autres fins que celles de la mission de service public pour les besoins de laquelle elles ont été,produites, y compris commerciales.,Les présentes conditions générales rappellent les droits et obligations des réutilisateurs. document disponible ici : https://www.apiefrance.com/sections/actualites/des-conditions-generales-pour-la-reutilisation-des-informations-publiques/downloadFile/attachedFile/CG_reutilisation_des_IP_23_septembre_V1.pdf précisant ceci : Conformément à l’article 12 de la Loi, le réutilisateur s’engage à ne pas altérer les Informations publiques, à ne pas en dénaturer le sens et à indiquer leur source et la date de leur dernière mise à jour. Ceci signifie-t-il que les données sous licences APIE - Réutilisation des données publiques - 24/09/2010 sont compatibles avec CC-by-SA et ODBL ? Oui, je pense. C'est peu
[OSM-talk-fr] Comment différencier une Zone 30 d'une limitation à 30 ?
Bonjour, D'après le wiki : http://wiki.openstreetmap.org/wiki/FR:Road_Signs#Panneaux_de_prescription_de_type_B , la seule information que l'on retranscrit dans OSM dans le cas d'une zone 30 concerne la limitation de vitesse. Je ne trouve pas cela normal ... limiter la zone 30 uniquement à l'aspect limitation de vitesse à 30 km/h est très réducteur de ce qu'est réellement une zone 30 : _article R110-2 du Code de la Route_ : « “Zone 30” : section ou ensemble de sections de voies constituant une zone affectée à la circulation de tous les usagers. Dans cette zone, la vitesse des véhicules est limitée à 30 km/h.*Toutes les chaussées sont à double sens pour les cyclistes*, sauf dispositions différentes prises par l'autorité investie du pouvoir de police. Les entrées et sorties de cette zone sont annoncées par une signalisation et l'ensemble de la zone est aménagé de façon cohérente avec la limitation de vitesse applicable. » Ces éléments sont associés à une signalisation spécifique (panneaux /zone 30/). Il ne devrait pas y avoir de marquage au sol, ni de délimitation des voies de circulation, ni de passages piétons, *ce qui permet aux piétons de traverser où ils le souhaitent*. Si on prend le cas par exemple de Louvil dans le nord de la France, les 2 concepts cohabitent et n'ont pas la même signification. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151540 Les piétons peuvent traverser où ils veulent, la priorité n'est pas données aux voitures. Par défaut toutes les rues sont des priorités à droite sauf indications contraires. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151951 La on est juste dans une rue limitée à 30km/h. Personnellement, je trouve que la nuance entre une zone 30 et une limitation à 30km/h est vraiment importante, même si malheureusement dans la tête des automobilistes cela ne fait aucune différence. Mais je pense que c'est plus par méconnaissance de la définition réelle de la zone 30 qu'autre chose. On a beaucoup trop tendance, justement à limiter la signification de la zone 30 à la limitation de vitesse. On pourrait presque définir la zone 30 comme une rue piétonne ou les véhicules sont autorisés (à la vue des lois et décrets qui concernent sur la zone 30). Qu'en pensez vous ? Cédric Olivier ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment différencier une Zone 30 d'une limitation à 30 ?
Perso moi j'utilise le tag source genre source:maxspeed=BE:zone30 ou BE:urban pour le 50 etc... 2011/5/27 Olivier Cédric cedric.oliv...@free.fr: Bonjour, D'après le wiki : http://wiki.openstreetmap.org/wiki/FR:Road_Signs#Panneaux_de_prescription_de_type_B , la seule information que l'on retranscrit dans OSM dans le cas d'une zone 30 concerne la limitation de vitesse. Je ne trouve pas cela normal ... limiter la zone 30 uniquement à l'aspect limitation de vitesse à 30 km/h est très réducteur de ce qu'est réellement une zone 30 : _article R110-2 du Code de la Route_ : « “Zone 30” : section ou ensemble de sections de voies constituant une zone affectée à la circulation de tous les usagers. Dans cette zone, la vitesse des véhicules est limitée à 30 km/h.*Toutes les chaussées sont à double sens pour les cyclistes*, sauf dispositions différentes prises par l'autorité investie du pouvoir de police. Les entrées et sorties de cette zone sont annoncées par une signalisation et l'ensemble de la zone est aménagé de façon cohérente avec la limitation de vitesse applicable. » Ces éléments sont associés à une signalisation spécifique (panneaux /zone 30/). Il ne devrait pas y avoir de marquage au sol, ni de délimitation des voies de circulation, ni de passages piétons, *ce qui permet aux piétons de traverser où ils le souhaitent*. Si on prend le cas par exemple de Louvil dans le nord de la France, les 2 concepts cohabitent et n'ont pas la même signification. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151540 Les piétons peuvent traverser où ils veulent, la priorité n'est pas données aux voitures. Par défaut toutes les rues sont des priorités à droite sauf indications contraires. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151951 La on est juste dans une rue limitée à 30km/h. Personnellement, je trouve que la nuance entre une zone 30 et une limitation à 30km/h est vraiment importante, même si malheureusement dans la tête des automobilistes cela ne fait aucune différence. Mais je pense que c'est plus par méconnaissance de la définition réelle de la zone 30 qu'autre chose. On a beaucoup trop tendance, justement à limiter la signification de la zone 30 à la limitation de vitesse. On pourrait presque définir la zone 30 comme une rue piétonne ou les véhicules sont autorisés (à la vue des lois et décrets qui concernent sur la zone 30). Qu'en pensez vous ? Cédric Olivier ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Comment différencier une Zone 30 d'une limitation à 30 ?
De : Olivier Cédric cedric.oliv...@free.fr Bonjour, D'après le wiki : http://wiki.openstreetmap.org/wiki/FR:Road_Signs#Panneaux_de_prescription_de_type_B , la seule information que l'on retranscrit dans OSM dans le cas d'une zone 30 concerne la limitation de vitesse. Je ne trouve pas cela normal ... limiter la zone 30 uniquement à l'aspect limitation de vitesse à 30 km/h est très réducteur de ce qu'est réellement une zone 30 : _article R110-2 du Code de la Route_ : « “Zone 30” : section ou ensemble de sections de voies constituant une zone affectée à la circulation de tous les usagers. Dans cette zone, la vitesse des véhicules est limitée à 30 km/h.*Toutes les chaussées sont à double sens pour les cyclistes*, sauf dispositions différentes prises par l'autorité investie du pouvoir de police. Les entrées et sorties de cette zone sont annoncées par une signalisation et l'ensemble de la zone est aménagé de façon cohérente avec la limitation de vitesse applicable. » Ces éléments sont associés à une signalisation spécifique (panneaux /zone 30/). Il ne devrait pas y avoir de marquage au sol, ni de délimitation des voies de circulation, ni de passages piétons, *ce qui permet aux piétons de traverser où ils le souhaitent*. Si on prend le cas par exemple de Louvil dans le nord de la France, les 2 concepts cohabitent et n'ont pas la même signification. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151540 Les piétons peuvent traverser où ils veulent, la priorité n'est pas données aux voitures. Par défaut toutes les rues sont des priorités à droite sauf indications contraires. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151951 La on est juste dans une rue limitée à 30km/h. Personnellement, je trouve que la nuance entre une zone 30 et une limitation à 30km/h est vraiment importante, même si malheureusement dans la tête des automobilistes cela ne fait aucune différence. Mais je pense que c'est plus par méconnaissance de la définition réelle de la zone 30 qu'autre chose. On a beaucoup trop tendance, justement à limiter la signification de la zone 30 à la limitation de vitesse. On pourrait presque définir la zone 30 comme une rue piétonne ou les véhicules sont autorisés (à la vue des lois et décrets qui concernent sur la zone 30). Qu'en pensez vous ? Ca me parait correspondre a une zone de recontre avec maxspeed a 30: http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dliving_street cf la specificite francaise dans le tableau de la page anglaise http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street Apres je ne sais pas si c est exactement la meme chose du point de vue reglementaire Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag:area - utilisation pour aire de service et péage ?
Bonjour, De : SylvainH Je demande votre avis sur l'utilisation du tag area pour les stations-services et autres aires de service. Je l'ai utilisé là : http://www.openstreetmap.org/?lat=50.601949095726lon=2.94224917888641zoom=17 http://www.openstreetmap.org/?lat=50.601949095726lon=2.94224917888641zoom=17 Est-ce possible de l'utiliser aussi pour des péages d'autoroutes, par exemple ici : http://www.openstreetmap.org/?lat=50.3267920017242lon=2.92309284210205zoom=14 http://www.openstreetmap.org/?lat=50.3267920017242lon=2.92309284210205zoom=14 Est-ce possible avec les fonctions de routage ? Pour matérialiser l'emprise de l'aire de service, je pencherais plutôt pour le tag landuse=*. Combiner highway=* et area=yes implique qu'au sein de la station-service il n'y a pas de voies de circulation déterminées, qu'on peut rouler de partout à partout quel que soit le sens. Je préfère essayer quand c'est possible de trouver des axes logiques et tracer des highway=* sans tag area. Dans le cas présent, highway=service (sans 's') avec oneway=yes pour les rampe d'entrée et sortie depuis la nationale, et highway=services (avec 's') pour les voies de circulation dans l'aire de service [1], hors voies de parking où on peut combiner highway=service et service=parking_aisle, voire amenity=parking sur un node ou un way fermé. Pour le routage, une aire ça n'est pas très pratique, pour l'exploiter il faut à un moment donné se rabattre sur un modèle qui combine nodes et ways. S'il existe une géométrie de surface (way fermé) pour l'aire de service dans son ensemble, les nodes situés dans la surface pourraient hériter des tags appliqués à l'aire (le nom de l'aire de service par exemple) pour que le graphe qui sert au calcul d'itinéraire puisse atteindre ces noeuds, et donc la destination aire de service. Pour le péage, quelle aire veux-tu matérialiser ? vincent [1] : http://wiki.openstreetmap.org/wiki/Tag:highway=services Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag:area - utilisation pour aire de service et péage ?
Le 27 mai 2011 10:37, Vincent de Chateau-Thierry v...@laposte.net a écrit : highway=services (avec 's') pour les voies de circulation dans l'aire de service [1], hors voies de parking où on peut combiner highway=service et service=parking_aisle, voire amenity=parking sur un node ou un way fermé. [1] : http://wiki.openstreetmap.org/wiki/Tag:highway=services Bonjour, La page du wiki référencée indique que highway=services (avec S) est à utiliser sur un node ou un way fermé (surface). Toujours d'après cette page, le tag sert à marquer une aire de service dans son ensemble. Donc il faudrait tagger l'emprise de l'aire sous forme de way fermé avec highway=services et les voies de circulation à l'intérieur de l'aire avec highway=service. Sauf si le wiki ne reflète pas l'usage actuel de highway=services ... Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag:area - utilisation pour aire de service et péage ?
De : Matthias Dietrich La page du wiki référencée indique que highway=services (avec S) est à utiliser sur un node ou un way fermé (surface). Toujours d'après cette page, le tag sert à marquer une aire de service dans son ensemble. Donc il faudrait tagger l'emprise de l'aire sous forme de way fermé avec highway=services et les voies de circulation à l'intérieur de l'aire avec highway=service. Sauf si le wiki ne reflète pas l'usage actuel de highway=services ... Oops ! désolé pour la confusion, merci Matthias. Mon landuse=* n'a pas lieu d'être. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag:area - utilisation pour aire de service et péage ?
Le 27/05/2011 11:00, Vincent de Chateau-Thierry a écrit : Oops ! désolé pour la confusion, merci Matthias. Mon landuse=* n'a pas lieu d'être. Peut-être qui si ! Dire ce qui serait bien plus logique : mettre le l'utilisation du terrain dans un tag landuse=services et garder le highway=* pour ce qui est de la circulation. Même si ça n'est pas l'usage actuel pour les raisons historiques. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Comment différencier une Zone 30 d'une limitation à 30 ?
Le 27/05/2011 10:04, THEVENON Julien a écrit : Si on prend le cas par exemple de Louvil dans le nord de la France, les 2 concepts cohabitent et n'ont pas la même signification. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151540 Les piétons peuvent traverser où ils veulent, la priorité n'est pas données aux voitures. Par défaut toutes les rues sont des priorités à droite sauf indications contraires. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151951 La on est juste dans une rue limitée à 30km/h. Personnellement, je trouve que la nuance entre une zone 30 et une limitation à 30km/h est vraiment importante, même si malheureusement dans la tête des automobilistes cela ne fait aucune différence. Mais je pense que c'est plus par méconnaissance de la définition réelle de la zone 30 qu'autre chose. On a beaucoup trop tendance, justement à limiter la signification de la zone 30 à la limitation de vitesse. On pourrait presque définir la zone 30 comme une rue piétonne ou les véhicules sont autorisés (à la vue des lois et décrets qui concernent sur la zone 30). Qu'en pensez vous ? Ca me parait correspondre a une zone de recontre avec maxspeed a 30: http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dliving_street cf la specificite francaise dans le tableau de la page anglaise http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street Apres je ne sais pas si c est exactement la meme chose du point de vue reglementaire Julien Pour moi c'est 2 choses différentes, la zone de rencontre est résidentielle. Dans mon cas la zone 30 est située sur une route départementale qui est assez passante, l'objectif de la zone 30 est bien sur de faire ralentir les véhicules durant la traversée du village. Je ne pense pas qu'il soit une bonne idée de modifier la classification de ma rue sur la durée de la zone 30. Cet axe est actuellement en tertiary et je pense que cela correspond bien à la fréquentation et l'importance de cette rue. Je ne suis pas contre le fait de mettre comme l'a proposé eMerzh source:maxspeed=FR:zone30 Il pourrait être opportun si cette information fait l'unanimité de l'ajouter au wiki, qu'en pensez vous ? Cédric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag:area - utilisation pour aire de service et péage ?
Selon Matthias Dietrich eiger@gmail.com: Le 27 mai 2011 10:37, Vincent de Chateau-Thierry v...@laposte.net a écrit : highway=services (avec 's') pour les voies de circulation dans l'aire de service [1], hors voies de parking où on peut combiner highway=service et service=parking_aisle, voire amenity=parking sur un node ou un way fermé. [1] : http://wiki.openstreetmap.org/wiki/Tag:highway=services Bonjour, La page du wiki référencée indique que highway=services (avec S) est à utiliser sur un node ou un way fermé (surface). Toujours d'après cette page, le tag sert à marquer une aire de service dans son ensemble. Donc il faudrait tagger l'emprise de l'aire sous forme de way fermé avec highway=services et les voies de circulation à l'intérieur de l'aire avec highway=service. Sauf si le wiki ne reflète pas l'usage actuel de highway=services ... Matthias La page http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_link mentionne aussi la possibilité de tagguer les rampes d'accès à la station service / aire de repos en motorway_link puisque sémantiquement ces rampes ont certaines propriétés (pas de piétons). Cela me parait un modèle correct : les rampes d'accès sont en motorway_link jusqu'à l'empreinte de la surface highway=services, ensuite et à l'intérieur de la surface toutes les routes sont en highway=service. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Comment différencier une Zone 30 d'une limitation à 30 ?
au fait, après avoir regarder sur taginfo , il y a déjà pas mal d'objets (~80 000) utilisant cette notation http://taginfo.openstreetmap.de/keys/source:maxspeed#values et pour la rue limitée a 30 je vois que la valeur sign est pas mal utilisée sinon il existe déjà une page pour cette clé .. p-e a lier avec la page des maxspeed et/ou à corrigé http://wiki.openstreetmap.org/wiki/Key:source:maxspeed 2011/5/27 Olivier Cédric cedric.oliv...@free.fr: Le 27/05/2011 10:04, THEVENON Julien a écrit : Si on prend le cas par exemple de Louvil dans le nord de la France, les 2 concepts cohabitent et n'ont pas la même signification. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151540 Les piétons peuvent traverser où ils veulent, la priorité n'est pas données aux voitures. Par défaut toutes les rues sont des priorités à droite sauf indications contraires. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151951 La on est juste dans une rue limitée à 30km/h. Personnellement, je trouve que la nuance entre une zone 30 et une limitation à 30km/h est vraiment importante, même si malheureusement dans la tête des automobilistes cela ne fait aucune différence. Mais je pense que c'est plus par méconnaissance de la définition réelle de la zone 30 qu'autre chose. On a beaucoup trop tendance, justement à limiter la signification de la zone 30 à la limitation de vitesse. On pourrait presque définir la zone 30 comme une rue piétonne ou les véhicules sont autorisés (à la vue des lois et décrets qui concernent sur la zone 30). Qu'en pensez vous ? Ca me parait correspondre a une zone de recontre avec maxspeed a 30: http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dliving_street cf la specificite francaise dans le tableau de la page anglaise http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street Apres je ne sais pas si c est exactement la meme chose du point de vue reglementaire Julien Pour moi c'est 2 choses différentes, la zone de rencontre est résidentielle. Dans mon cas la zone 30 est située sur une route départementale qui est assez passante, l'objectif de la zone 30 est bien sur de faire ralentir les véhicules durant la traversée du village. Je ne pense pas qu'il soit une bonne idée de modifier la classification de ma rue sur la durée de la zone 30. Cet axe est actuellement en tertiary et je pense que cela correspond bien à la fréquentation et l'importance de cette rue. Je ne suis pas contre le fait de mettre comme l'a proposé eMerzh source:maxspeed=FR:zone30 Il pourrait être opportun si cette information fait l'unanimité de l'ajouter au wiki, qu'en pensez vous ? Cédric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Comment différencier une Zone 30 d'une limitation à 30 ?
Le vendredi 27 mai 2011, à 09:04:11 +0100, THEVENON a écrit : De : Olivier Cédric cedric.oliv...@free.fr Bonjour, D'après le wiki : http://wiki.openstreetmap.org/wiki/FR:Road_Signs#Panneaux_de_prescription_de_type_B , la seule information que l'on retranscrit dans OSM dans le cas d'une zone 30 concerne la limitation de vitesse. Je ne trouve pas cela normal ... limiter la zone 30 uniquement à l'aspect limitation de vitesse à 30 km/h est très réducteur de ce qu'est réellement une zone 30 : _article R110-2 du Code de la Route_ : « “Zone 30” : section ou ensemble de sections de voies constituant une zone affectée à la circulation de tous les usagers. Dans cette zone, la vitesse des véhicules est limitée à 30 km/h.*Toutes les chaussées sont à double sens pour les cyclistes*, sauf dispositions différentes prises par l'autorité investie du pouvoir de police. Les entrées et sorties de cette zone sont annoncées par une signalisation et l'ensemble de la zone est aménagé de façon cohérente avec la limitation de vitesse applicable. » Ces éléments sont associés à une signalisation spécifique (panneaux /zone 30/). Il ne devrait pas y avoir de marquage au sol, ni de délimitation des voies de circulation, ni de passages piétons, *ce qui permet aux piétons de traverser où ils le souhaitent*. Si on prend le cas par exemple de Louvil dans le nord de la France, les 2 concepts cohabitent et n'ont pas la même signification. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151540 Les piétons peuvent traverser où ils veulent, la priorité n'est pas données aux voitures. Par défaut toutes les rues sont des priorités à droite sauf indications contraires. http://gallery3.cleo-carto.org/index.php/Louvil/IMG_20110525_151951 La on est juste dans une rue limitée à 30km/h. Personnellement, je trouve que la nuance entre une zone 30 et une limitation à 30km/h est vraiment importante, même si malheureusement dans la tête des automobilistes cela ne fait aucune différence. Mais je pense que c'est plus par méconnaissance de la définition réelle de la zone 30 qu'autre chose. On a beaucoup trop tendance, justement à limiter la signification de la zone 30 à la limitation de vitesse. On pourrait presque définir la zone 30 comme une rue piétonne ou les véhicules sont autorisés (à la vue des lois et décrets qui concernent sur la zone 30). Qu'en pensez vous ? Ca me parait correspondre a une zone de recontre avec maxspeed a 30: http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dliving_street cf la specificite francaise dans le tableau de la page anglaise http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street Apres je ne sais pas si c est exactement la meme chose du point de vue reglementaire non, la zone de rencontre, ce n'est pas la même chose que la zone 30. D'ailleurs sur le wiki, il est recommandé d'indiquer le tag maxspeed. Je ne suis pas sûr que ce soit une bonne idée. Si on indique la vitesse sur chaque tronçon de voie, le jour où les zones de rencontre passeront à 15km/h, les agglomérations à 40, et les autoroutes à 110, il faudra tout refaire. Que pensez-vous d'un tag: reglementation:FR=zone30 reglementation:FR=urban ou qqc d'approchant ? a+ arno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
