Re: [talk-ph] Booth/exhibit ideas for PhilGEOS symposium
Dear Totor, Your Cebu animation was one of the highlights in our exhibit booth last week at the PhilGEOS 2012 Symposium [0]. Thanks again for sharing. [0] http://www.flickr.com/photos/esambale/8219862402/in/photostream/ On Sat, Nov 17, 2012 at 12:04 AM, maning sambale emmanuel.samb...@gmail.com wrote: This is great Totor! I will surely use this vis. Looking forward to the writeup. Maning Sambale (mobile) On Nov 15, 2012 7:39 PM, Totor totor_...@yahoo.com wrote: Hi, I just finished an animation of the (nearly) complete history of edits in Cebu City. I wanted to make a page describing how I made it before to post it here, but I'll probably not have time the coming weeks. Feel free to use (and/or modify) any of the following versions as you see fit. http://osm.totor.ph/aniCebu2.gif (800x600 animation with glow and cc-by-sa attribution, 12Mb) http://osm.totor.ph/aniCebu2.avi (same in avi format, 3Mb) http://osm.totor.ph/aniCebu2-300.gif (smaller gif in 300x225, 2Mb) Original animation without effects or attribution: http://osm.totor.ph/aniCebu.gif (600kb) Cheers, Totor ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] zone30/50/70 vs Bebouwde kom/Agglomération/Built-up area
2012/11/26 A.Pirard.Papou a.pirard.pa...@gmail.com On 2012-11-26 16:55, Ben Laenen wrote : Also, why the BE prefix, these roads are in Belgium, no need to duplicate that information on all the roads. I'm much interested in this remark. For writing POI files, one must determine in which municipality (polygonal relation) a street (way) is. How can it be done? To keep tabs on what municipality a street belongs to, you can use the associatedStreet relation: The road connecting Leuven to Tienen, starts out on the border of 2 'deelgemeentes': To the north of it the houses are in Kessel-Lo (3010): http://www.openstreetmap.org/browse/relation/1490437 To the south, near to Leuven the houses are in Heverlee (3001): http://www.openstreetmap.org/browse/relation/2599890 A bit further, still to the south the houses were previously in Korbeek-Lo, but since the fusioning they are now in Leuven (3000): http://www.openstreetmap.org/browse/relation/2599889 Further to the east, the houses are in the part of Korbeek-Lo, which is now part of Bierbeek (3360): http://www.openstreetmap.org/browse/relation/1518513 Still further, they are in Lovenjoel, also part of Bierbeek (3360): http://www.openstreetmap.org/browse/relation/2599620 So every time the postcode or the name of the (deel)gemeente changes a new associatedStreet relation is started to gather those streets and the houses/address nodes belonging to them together. Some streets belong to more than 1 associatedStreet relation. Houses with 2 addresses or a border passing through them can also belong ot more than 1 associatedStreet relation, but that should be exceptional. When all your associatedStreet relations are complete, you can search for them in JOSM or with the Overpass API, using either the postcode or the name of the (deel)gemeentes you're interested in. You can draw the polygon you want based on that. Jo ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] boundary names and my program
Hi, I have improved my border scanning program. For additional fun, I computed the length of borderlines between municipalities. You can see the Province Liège result @ http://wiki.openstreetmap.org/wiki/User:Papou/OSM. I intend to check the borders for various kinds of errors later and build a worksheet (1). At present, it only builds that worksheet for persons to reserve and mark completion of tasks. Click on the headers to sort the columns, especially by length. I thought I could make a shortest-border contest, but you can see the problem: a 3 meter winner! That's because, despite the practice is discouraged, Mr Verdy has been using paths as borders. After ignoring streams, paths and barbed wire borders, it turns out that the winner is: Deutschland — Belgique / België / Belgien Congratulations !!! What is that? That's the name Mr Verdy has given it instead of a simple commune X commune Y. But it's easy to find which border it is by looking to which areas it belongs: Verviers (town, arrondissement, province?), Deutschsprachige Gemeinschaft, Deutschland (Landmasse), Deutschland, Rheinland-Pfalz, Burg-Reuland, Liège (town, arrondissement, province?), België - Belgique - Belgien, Belgigue / België / Belgien (land mass), Deutschland — Belgique / België / Belgien, Eifelkreis Bitburg-Prüm, Eifel, Sevenig (Our), Arzfeld and ... 1259856. Conclusions: In order for my program (and others) to work and be useful, * *the names of the borders must be Municipality A — Municipality B* and not 30 times Belgium — Germany or Liège —Verviers. Note that this is border identification. The names Belgium an Germany are taken from the relations and written on the borderline to indicate country limits anyway. * proper ways must be used for borders, not paths, railways, streams, landuse etc... *Can we all agree on that?* (1) I can check that each border has 2 communes and that the municipality and border names are the same. I can check that the municipality has a well formed phone number, is_in, and a huge lot of things like that: I will ask you the rules you think of. Cheers, Papou André. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] tesco store location data
On 05/11/12 17:27, David Prime wrote: Now, my question is whether I should import this into OSM. Obviously the data is very useful (every store is categorised: metro, express, extra, etc) but the licencing situation is murky. Anyone want to weight in on whether I should do an import? I know Tesco's Chief Information Architect and have asked him for an ODBL-licensed data dump. He's working on it, and I hope to have news for you soon. Gerv ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] What to call OSM data?
On 2012-11-26 11:22, Martin Koppenhoefer wrote: I'd like to point out that even though your claim might be true in terms of quantity (didn't check that but have my doubts too, because there are far more road ways in the db than landuse) there are many countries which didn't import CORINE, Germany and Italy for instance (I think also UK) About one year ago, I made a rough count of the values for the source key, for all OSM ways in geofabrik's europe.osm.pbf. IIRC: about 1% of the ways looked like imported CORINE, Urban Atlas, or similar data. Hermann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Recommendations for OSM mobile app?
I've never found an app I can recommend, because I don't use my phone enough. http://wiki.openstreetmap.org/wiki/Android and http://wiki.openstreetmap.org/wiki/IPhone have long lists. On 24 November 2012 05:51, Steve Bennett stevag...@gmail.com wrote: Hi all, I'm looking for a recommendations of mobile apps to recommend, for people visiting rail trails in Australia. What we* need is: Must have: 1) It has to be simple to use. There are lots of powerful apps like OSMand, Locus etc, but they're incredibly complex, with lots of features we don't need. 2) Should by default use bicycle rendering (OpenCycleMap or other), or be very easy to change to that. 3) We'll need a recommendation for both iPhone and Android. Nice to have: 4) Easy-to-use offline tile downloading/use would be a bonus. (Personally I find it pretty complex switching between offline vector rendering and online tiles in the apps I mentioned before). 5) Features like food/drink near here would be a bonus. 6) Ability to also choose Google Maps would be a bonus. 7) Ability to route along bike paths (ie, rail trails) would be nice. Once we've chosen an app, we're going to have to give instructions like download the app, push this button to change to cycle mode, push this button to download tiles etc, so the simpler the better. Thanks, Steve * we = Rail Trails Australia ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What to call OSM data?
On 26 November 2012 15:58, Lester Caine les...@lsces.co.uk wrote: Richard Fairhurst wrote: Kate Chapman wrote: Does anyone have suggestions or a preference? OpenStreetMap says it all. As in Hi. We're OpenStreetMap. You may have heard of us. I'd second that ... does not need any more -- I third that, was trying to get to the end of the thread to say it myself. Although I first read the second part as You have heard of us (no 'may' :). -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Recommendations for OSM mobile app?
I wanted to tell you a few days ago that OsmAnd does all you want. Maybe write a small manual page for it, for the subset of features your users need. I didn't do it then, hoping somebody else would have a better suggestion. Polyglot 2012/11/24 Steve Bennett stevag...@gmail.com Hi all, I'm looking for a recommendations of mobile apps to recommend, for people visiting rail trails in Australia. What we* need is: Must have: 1) It has to be simple to use. There are lots of powerful apps like OSMand, Locus etc, but they're incredibly complex, with lots of features we don't need. 2) Should by default use bicycle rendering (OpenCycleMap or other), or be very easy to change to that. 3) We'll need a recommendation for both iPhone and Android. Nice to have: 4) Easy-to-use offline tile downloading/use would be a bonus. (Personally I find it pretty complex switching between offline vector rendering and online tiles in the apps I mentioned before). 5) Features like food/drink near here would be a bonus. 6) Ability to also choose Google Maps would be a bonus. 7) Ability to route along bike paths (ie, rail trails) would be nice. Once we've chosen an app, we're going to have to give instructions like download the app, push this button to change to cycle mode, push this button to download tiles etc, so the simpler the better. Thanks, Steve * we = Rail Trails Australia ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Recommendations for OSM mobile app?
That would be my approach as well. Cheerio John On 27 November 2012 12:56, Jo winfi...@gmail.com wrote: I wanted to tell you a few days ago that OsmAnd does all you want. Maybe write a small manual page for it, for the subset of features your users need. I didn't do it then, hoping somebody else would have a better suggestion. Polyglot 2012/11/24 Steve Bennett stevag...@gmail.com Hi all, I'm looking for a recommendations of mobile apps to recommend, for people visiting rail trails in Australia. What we* need is: Must have: 1) It has to be simple to use. There are lots of powerful apps like OSMand, Locus etc, but they're incredibly complex, with lots of features we don't need. 2) Should by default use bicycle rendering (OpenCycleMap or other), or be very easy to change to that. 3) We'll need a recommendation for both iPhone and Android. Nice to have: 4) Easy-to-use offline tile downloading/use would be a bonus. (Personally I find it pretty complex switching between offline vector rendering and online tiles in the apps I mentioned before). 5) Features like food/drink near here would be a bonus. 6) Ability to also choose Google Maps would be a bonus. 7) Ability to route along bike paths (ie, rail trails) would be nice. Once we've chosen an app, we're going to have to give instructions like download the app, push this button to change to cycle mode, push this button to download tiles etc, so the simpler the better. Thanks, Steve * we = Rail Trails Australia ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Voorbeelden commercieel gebruik openstreetmap
Hoi allemaal, European Digital Rights initiative is op zoek naar: Does anyone have interesting examples of businesses built on re-use of public service information or on any data that was previously restricted/reserved and is now re-useable? Ik dacht zelf aan Apple: http://blog.osmfoundation.org/2012/03/08/welcome-apple/ Hebben jullie nog een paar sterke voorbeelden? Hoeft geen enorme lijst te zijn, enkele krachtige is voldoende. fijne avond! Ante ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Voorbeelden commercieel gebruik openstreetmap
MapBox heeft een berg voorbeelden, de meeste met OSM als als custom achtergrondkaart: http://mapbox.com/showcase/ On Tue, Nov 27, 2012 at 10:17 AM, Ante a...@ffii.org wrote: Hoi allemaal, European Digital Rights initiative is op zoek naar: Does anyone have interesting examples of businesses built on re-use of public service information or on any data that was previously restricted/reserved and is now re-useable? Ik dacht zelf aan Apple: http://blog.osmfoundation.org/2012/03/08/welcome-apple/ Hebben jullie nog een paar sterke voorbeelden? Hoeft geen enorme lijst te zijn, enkele krachtige is voldoende. fijne avond! Ante ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Voorbeelden commercieel gebruik openstreetmap
Apple beter niet gebruiken, inmiddels is er een andere kaart in gebruik en schijnt er nog maar heel weinig OSM in te zitten. Gr, Floris On Tue, Nov 27, 2012 at 6:17 PM, Ante a...@ffii.org wrote: Hoi allemaal, European Digital Rights initiative is op zoek naar: Does anyone have interesting examples of businesses built on re-use of public service information or on any data that was previously restricted/reserved and is now re-useable? Ik dacht zelf aan Apple: http://blog.osmfoundation.org/2012/03/08/welcome-apple/ Hebben jullie nog een paar sterke voorbeelden? Hoeft geen enorme lijst te zijn, enkele krachtige is voldoende. fijne avond! Ante ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-br] usar os mapas da OSM em um gps veicular
Para Windows CE, alguns links úteis: http://wiki.openstreetmap.org/wiki/Software/PNA#WinCE_based http://wiki.openstreetmap.org/wiki/Windows_Mobile 2012/11/27 Bruno Augusto stra...@gmail.com Bom Dia pessoal! Obrigado pelas dicas! Realmente o OsmAnd é muito bom pra se usar no celular e dispositivos android. (eu estou usando no meu celular normalmente) mas eu procurei não achei nada similar para ser usado naqueles gps que rodam com base no winCE. o mais próx a um sistema que possa ser instalado em um dispositivos destes foi o garmin mobile, porém não tive muito sucesso na instalação dele. alguem tem mais alguma opção de software? também to pensando em adquirir um gps com android e coloco o OsmAnd direto nele também. Bruno Augusto Mühlenhoff Em 27 de novembro de 2012 11:16, Robian rfra...@yahoo.com.br escreveu: Aun, O que você acha do routing off-line do OsmAnd? Eu achei que com esse routing nativo e off-line ficou mais rápido e com a vantagem de não precisar de Internet. -- *De:* Aun Yngve Johnsen li...@gimnechiske.org *Para:* OSM talk-br talk-br@openstreetmap.org *Enviadas:* Terça-feira, 27 de Novembro de 2012 3:58 *Assunto:* Re: [Talk-br] usar os mapas da OSM em um gps veicular Também usand OsmAnd e gostando, juntos com o routing do CloudMade e gostando. Após ver como poder achar lugares com OsmAnd, meu esposa mudo idea do OSM, ela não mais odeia que eu gastando tempo contribuinda a projeto. Aun Y. Johnsen Sent from my iPad +55 (27) 9736-3919 (vivo) On 27. nov. 2012, at 01:33, Robian rfra...@yahoo.com.br wrote: Eu também gosto muito do OsmAnd, principalmente o fato dele salvar automaticamente trilhas em GPX dos lugares que estou passando. Depois, eu utilizo essas trilhas GPX para subir para o servidor OSM e editar vias onde não há imagens aéreas do BING. -- *De:* Arlindo Pereira openstreet...@arlindopereira.com *Para:* OSM talk-br talk-br@openstreetmap.org *Enviadas:* Segunda-feira, 26 de Novembro de 2012 21:17 *Assunto:* Re: [Talk-br] usar os mapas da OSM em um gps veicular Acredito que o OsmAnd seja mesmo a melhor opção dado que você tenha um tablet Android. É possível baixar os dados do Brasil inteiro para a memória do aparelho via wi-fi e usar enquanto offline. Em 26/11/2012 20:22, Gerald Weber gwebe...@gmail.com escreveu: Realmente achei os mapas do Navfree desatualizados e com a nítida impressão que de que são incompletos. Um outro bom programa para Android é mapfactor http://navigatorfree.mapfactor.com, tem interface 3D. Lembrei o nome do programa para Tomtom, é Navit, tem uma versão dele para Android também. Voltando ao Osmand o que gosto nele é que não precisa esperar disponibilizar os mapas novos. Por exemplo, outro dia eu fiz um pedaço de uma área rural em Lagoa Santa e no mesmo final de semana quis ir lá passear. Salvei o pedaço que tinha mapeado do Josm e processei com um programa que acompanha o Osmand, daí foi só copiar para a pasta do Osmand no tablet e pronto. O mapa tava disponível off-line para mim. abraço a todos Gerald 2012/11/26 Rodrigo Avila rodr...@avila.net.br O Navfree declara que as atualizações são trimestrais. Mas quando eu tentei usar, já fazia mais de ano que o mapa náo era atualizado. Tomara que tenha mudado. Em segunda-feira, 26 de novembro de 2012, Eduardo Maçan escreveu: Tem também o NavFree e o próprio MapQuest para android. Acho que o NavFree é mais parecido com o que você procura (acho que as atualizações dele são trimestrais, mesmo com o mapa do OSM) 2012/11/26 George Silva georger.si...@gmail.com Esse software, o Mapwel, te permite inclusive fazer download direto dos dados do OSM para você prepará-los par aimprotar no Garmim...é bem legal. Nos garmin, funciona bem. 2012/11/26 Gerald Weber gwebe...@gmail.com É possível, mas dá um trabalho infernal. No Tomtom tem que instalar um outro software que substitui o navegador nativo. É uma interface muito simplificada, sem a sofisticação do navegador original. Eu fiz isto e sinceramente não valeu a pena. Me parece que Garmin é mais flexível, mas como não tenho nunca tentei usar. Mais simples usar um smartphone ou tablet e instalar o osmand ou algum outro aplicativo que usa mapas OSM. abraço Gerald 2012/11/26 Bruno Augusto stra...@gmail.com Boa Tarde a todos! Gostaria de saber se alguem já portou os mapas da OSM para serem usados em um gps veicular (tipo IGO, Navgator e afins). eu sou um usuário ocasional deste tipo de equipamento e o que me incomoda normalmente no uso é a imprecisão dos mapas usados nestes equipamentos, mesmo usando mapa atualizado, pois normalmente a taxa de atualização é anual. me ocorreu se seria possível este tipo de utilização. Agradeço a compreenção PS: Têm alguem aqui de Curitiba e região? -- -- Rodrigo de Avila Analista de Desenvolvimento rodr...@avila.net.br • www.avila.net.br
Re: [Talk-de] RFC zum Proposal winter_service
Am 27.11.2012 02:33, schrieb Andreas Labres: On 26.11.12 10:21, Andreas Neumann wrote: Könnte man damit nicht evtl. auch im Winter gesperrte Überlandstraßen taggen? Also dafür würde ich mir schon einen road_closed=-11-01 - -04-01 oder sowas Tag (Wintersperre von bis, und je nachdem, wie der Konsens ist, wie man Jahreszahlenlose Daten eingibt) wünschen. Das Problem ist, dass man die Straßen nicht Monatsgenau sperren kann. Sie werden schlicht und einfach nicht geräumt. Fällt also mal eine ausreichende Menge Schnee sind sie gesperrt. Gibts Winter ohne Schnee, dann sind sie offen... Es steht nur an den Straßenschildern dran, dass die Route keinen Winterdienst hat. MfG Andreas -- Andreas Neumann http://stadtplan-ilmenau.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
An sich finde ich die Idee gut. winter_service und snowplowing=yes/no sagen doch das gleiche aus, bzw. wenn winter_service=yes, dann wird auch der Schnee geräumt und wenn der Schnee nicht geräumt wird, dann ist auch winter_service=no. Hier sollte dein Proposal besser strukturiert sein. snowplowing=heated hat dagegen eine zusätzliche Information. Allgemein halte ich es für schwer, winter_service zu taggen, da er nach Prioritäten abläuft. Bei Dauerschneefall reicht die Kapazität nur aus, die Hauptstraßen frei zu halten, schneit es nur über Nacht, kann es durchaus sein, dass bis zum Abend auch die Wohnstraßen geräumt sind. So etwas dynamisches in ein starres tagging zu gießen halte ich für nicht sinnvoll bzw. die priorität ergibt sich aus der highway-Klasse. Bleiben noch Straßen die im Winter komplett gesperrt werden, wie zum Beispiel Pässe. Hier würde ich nur erfassen, dass die Straße gesperrt wird und in description oder ähnlichem die ungefähren Zeiten. Wenn jemand Lust hat, kann er natürlich auch erfassen, dass die Straße jetzt gesperrt ist. Das würde ich dann aber auch mit einem access=no machen, da an den Sperren in der Regel entsprechende Schilder stehen. Bei den Wegen abseits der Straßen ist eine Erfassung durchaus sinnvoll. Zusammenfassend: winter_service=yes würde ich auf Straßen nicht erfassen. Weder als Default noch explizit. Dagegen sinnvoll ist die Erfassung von Einrichtungen wie beheizte Straßen etc. Sollte es auf Wegen mit Räumpflicht Schilder geben, die eine Räumung ausschließen sollte ein winter_service=no verwendet werden. Bei Wegen ohne Räumpflicht würde ich erfassen, dass dieser Weg geräumt wird. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hamburger WMS-Dienste für OpenStreetMap-Zwecke freigegeben
Moin, die Freie und Hansestadt Hamburg hat durch den Landesbetrieb Geoinformation und Vermessung (LGV) zwei WMS-Dienste des Stadtgebietes (incl.Neuwerk) mit für OpenData angepassten Capabilities kostenfrei für die kommerzielle und nicht-kommerzielle Nutzung bereitgestellt: http://gateway.hamburg.de/OGCFassade/HH_WMS_DOP40.aspx?SERVICE=WMSREQUEST=GetCapabilitiesversion=1.1.1 http://gateway.hamburg.de/OGCFassade/HH_WMS_Geobasisdaten.aspx?SERVICE=WMSREQUEST=GetCapabilitiesversion=1.1.1 Weitere Einzelheiten im Forum: http://forum.openstreetmap.org/viewtopic.php?id=19227 Viel Spaß Joachim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27. November 2012 02:38 schrieb Andreas Labres l...@lab.at: On 26.11.12 21:36, malenki wrote: gritting= und salting= wird bereits zahlreich verwendet und ist im Proposal angegeben und verlinkt. Naja, das sind aber (meiner Einschätzung nach) Wildwuchs-Tags. Also da stünde es schon dafür, mal ein ausgewachsenes Konzept dafür zu entwerfen. Vor allem, wenn man das schon mal anfasst. naja, gritting kommt rund 13000 mal vor (mit priority_1 und 3 als Hauptwerten) und maintenance=gritting/salting gibt es rund 19.000 mal, das kann man quasi schon als etabliert sehen, zumindest werden es nicht nur ein oder 2 User sein, die das verwenden (sofern es kein Import war). salting als Key gibt es dagegen 0 mal (und einmal maintenance:salting). *ing Tags riechen übrigens schon sehr nach keiner guten Idee... ;) wieso? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27. November 2012 11:20 schrieb Henning Scholland o...@aighes.de: An sich finde ich die Idee gut. +1 winter_service und snowplowing=yes/no sagen doch das gleiche aus, bzw. wenn winter_service=yes, dann wird auch der Schnee geräumt und wenn der Schnee nicht geräumt wird, dann ist auch winter_service=no. Hier sollte dein Proposal besser strukturiert sein. snowplowing=heated hat dagegen eine zusätzliche Information. Allgemein halte ich es für schwer, winter_service zu taggen, da er nach Prioritäten abläuft. Bei Dauerschneefall reicht die Kapazität nur aus, die Hauptstraßen frei zu halten, schneit es nur über Nacht, kann es durchaus sein, dass bis zum Abend auch die Wohnstraßen geräumt sind. So etwas dynamisches in ein starres tagging zu gießen halte ich für nicht sinnvoll bzw. die priorität ergibt sich aus der highway-Klasse. das hängt auch sehr von der Stadt ab (die entscheidet AFAIK, ob und vor allem in welchem Umfang es Winterdienst gibt). In Berlin z.B. erinnere ich mich, dass dort Wohnstraßen zumindest teilweise gar nicht geräumt wurden (d.h. dass es dort nach einigen Tagen Kälte alles vereist war), während die Hauptstraßen und die Zuwegungen zu Krankenhäusern etc. immer schnell geräumt wurden. Bleiben noch Straßen die im Winter komplett gesperrt werden, wie zum Beispiel Pässe. Hier würde ich nur erfassen, dass die Straße gesperrt wird und in description oder ähnlichem die ungefähren Zeiten. +1 Wenn jemand Lust hat, kann er natürlich auch erfassen, dass die Straße jetzt gesperrt ist. -0.5, solche kurzfristigen Informationen wären besser in einer Event-DB oder einem anderen dynamischen Service aufgehobe finde ich. In den Daten würde es m.E. ausreichen einen Hinweis zu haben, dass die Straße nur bei entsprechenden Wetterbedingungen befahrbar ist. Wobei auch der Unterschied gemacht werden muss, ob es sich um ein Befahrverbot handelt, oder ob man halt ohne Geländefahrzeug und Schneeketten (bzw. Kettenfahrzeug) nicht durchkommt. Access und Subtags sind legale Beschränkungen, keine Beschreibung eines physischen Zustands. Das würde ich dann aber auch mit einem access=no machen, da an den Sperren in der Regel entsprechende Schilder stehen. welche Schilder stehen da? Ist das Betreten dieser Straßen dann auch für Wanderer verboten? Wenn nicht ist ein pauschales access=no zu weit gesprungen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hamburger WMS-Dienste für OpenStreetMap-Zwecke freigegeben
Hallo Joachim, das schaut ja schon gar nicht mal so schlecht aus. Leider sind die Bilder in Eimsbüttel ein wenig alt, so dass neue Gebäude logischerweise nicht gemappt oder verbessert werden können. Aber zumindest neuer als die alten Bing-Bilder sind sie schonmal. Mal sehen wie aktuell die neuen dann sein werden. Wäre es sinnvoll die Häuser anhand deren DK5 Karte zu verschieben, oder wie sollte man da vorgehen? Danke für deine Mühe Benjamin Am 27.11.2012 11:29, schrieb Joachim Kast: Moin, die Freie und Hansestadt Hamburg hat durch den Landesbetrieb Geoinformation und Vermessung (LGV) zwei WMS-Dienste des Stadtgebietes (incl.Neuwerk) mit für OpenData angepassten Capabilities kostenfrei für die kommerzielle und nicht-kommerzielle Nutzung bereitgestellt: http://gateway.hamburg.de/OGCFassade/HH_WMS_DOP40.aspx?SERVICE=WMSREQUEST=GetCapabilitiesversion=1.1.1 http://gateway.hamburg.de/OGCFassade/HH_WMS_Geobasisdaten.aspx?SERVICE=WMSREQUEST=GetCapabilitiesversion=1.1.1 Weitere Einzelheiten im Forum: http://forum.openstreetmap.org/viewtopic.php?id=19227 Viel Spaß Joachim ___ 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] Hamburger WMS-Dienste für OpenStreetMap-Zwecke freigegeben
Da die amtliche Karte und Luftbild sehr lagegenau sind, sollte man die OSM-Daten verschieben. Die amtlichen Bilder werden so alle 2-3 Jahre aktualisiert, wobei bei den Stadtstaaten die Tendenz zu kürzeren Intervallen geht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hamburger WMS-Dienste für OpenStreetMap-Zwecke freigegeben
Beinahe vergessen: Seitens OSM sind wir eigentlich nur Trittbrettfahrer. Die Hauptarbeit hat eine Volksinitiative geleistet: http://www.transparenzgesetz.de/ http://chaosradio.ccc.de/cr180.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
On 27.11.12 11:34, Martin Koppenhoefer wrote: naja, gritting kommt rund 13000 mal vor (mit priority_1 und 3 als Hauptwerten) und maintenance=gritting/salting gibt es rund 19.000 mal, das kann man quasi schon als etabliert sehen Ok. Trotzdem schaut's nach Schnellschuss aus, finde ich. Ich wünschte mir einen hier wird gestreut Tag und vielleicht noch einen Zusatz: und zwar nur mit Splitt oder mit Salz. Zur Not: gritting=grit|salt oder gritting:material=grit|salt. Und wenn ich länger nachdenke, fände ich eben einen hier gibt's (k)einen (oder eingeschränkten) Winterservice als Überbegriff besser, sprich: hier wird geräumt und gestreut (außer vielleicht auf Zufahrten zu Berghütten passiert das idR gemeinsam) und den Zusatz, welches Streugut (winter_service:gritting_material oder winter_service:material oder so). Und beim Räumen gibt's halt auch noch den zeitlichen (fast rund um die Uhr oder nur tagsüber oder wenn alles andere erledigt ist) und den Priority Aspekt. Aber überhaupt ist das ein sehr dynamisches Thema, das wichtigste ist, wenn /nicht/ geräumt wird (oder umgekehrt so Besonderheiten, dass ein cycleway=track eben doch geräumt wird). Dass das Räumen/Streuen dann mal schneller, mal langsamer (oder mit unterschiedlichem Streugut) passiert, kann man wohl nur live nachsehen... *ing Tags riechen übrigens schon sehr nach keiner guten Idee... ;) wieso? Kann ich Dir nicht sagen, ein Gschmäckle hat's halt für mich. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27. November 2012 12:20 schrieb Andreas Labres l...@lab.at: On 27.11.12 11:34, Martin Koppenhoefer wrote: naja, gritting kommt rund 13000 mal vor (mit priority_1 und 3 als Hauptwerten) und maintenance=gritting/salting gibt es rund 19.000 mal, das kann man quasi schon als etabliert sehen Ok. Trotzdem schaut's nach Schnellschuss aus, finde ich. Ich wünschte mir einen hier wird gestreut Tag und vielleicht noch einen Zusatz: und zwar nur mit Splitt oder mit Salz. Zur Not: gritting=grit|salt oder gritting:material=grit|salt. OK, wenn aber andere Leute nun schon ein anderes Schema umgesetzt haben (wo der Wert von gritting nicht das Material angibt, sondern eine Prioritätsstufe), dann muss man doch darauf eingehen und für das Material was anderes verwenden, oder? gritting:material oder so. grit ist AFAIK bereits eine Mischung aus Salz und einem anderen Material, neben Split (gebrochener Stein) kommt ggf. auch Sand oder Asche zum Einsatz. Ob man das überhaupt so sehen kann (hier wird nur Split gestreut, hier nur Sand bzw. Sand-Split-Mischung) weiss ich allerdings nicht. Und wenn ich länger nachdenke, fände ich eben einen hier gibt's (k)einen (oder eingeschränkten) Winterservice als Überbegriff besser, sprich: hier wird geräumt und gestreut (außer vielleicht auf Zufahrten zu Berghütten passiert das idR gemeinsam) und den Zusatz, welches Streugut (winter_service:gritting_material oder winter_service:material oder so). Und beim Räumen gibt's halt auch noch den zeitlichen (fast rund um die Uhr oder nur tagsüber oder wenn alles andere erledigt ist) und den Priority Aspekt. ja, dagegen spricht ja nichts, solange Du nicht drangehst, etablierte (bzw. in größerer Zahl in Nutzung befindliche) tags umzudeuten. Aber überhaupt ist das ein sehr dynamisches Thema, das wichtigste ist, wenn /nicht/ geräumt wird (oder umgekehrt so Besonderheiten, dass ein cycleway=track eben doch geräumt wird). Dass das Räumen/Streuen dann mal schneller, mal langsamer (oder mit unterschiedlichem Streugut) passiert, kann man wohl nur live nachsehen... was wichtiger zu taggen ist hängt sehr davon ab, was der lokale Normalfall ist (räumen oder nicht räumen), und das hängt wiederum sehr von den (klimatischen) Gegebenheiten ab. Als in Rom letztes Jahr mal für 3 Tage der Schnee liegen geblieben ist hat der Bürgermeister den Notstand ausgerufen und alle gebeten, wenn möglich zuhause zu bleiben. Und das war anfangs bei ca. 10 und später bei 20-30 cm Schnee ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
On 27.11.12 10:48, Andreas Neumann wrote: Das Problem ist, dass man die Straßen nicht Monatsgenau sperren kann. Natürlich kann man, gibt zahlreiche Passstraßen mit definierter Wintersperre (und das ist auch etwas, das Sinn macht, in einer Karte aufzuscheinen!). Und für die anderen Fälle wäre ein winter_service=no ja sinnvoll. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Wegen des Streuguts reicht wohl eine Unterscheidung, ob Salz oder nicht. Wie man das englisch sinnvoll vormuliert, sollen native speaker sagen. On 27.11.12 12:32, Martin Koppenhoefer wrote: Als in Rom letztes Jahr mal für 3 Tage der Schnee liegen geblieben ist hat der Bürgermeister den Notstand ausgerufen Kann mich an die Fernsehberichte erinnern. Aber Rom ist jetzt nicht ein Ort, wo winter_service als Tag irgendwie relevant wäre, oder? ;) /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27.11.2012 11:42, schrieb Martin Koppenhoefer: Am 27. November 2012 11:20 schrieb Henning Scholland o...@aighes.de: winter_service und snowplowing=yes/no sagen doch das gleiche aus, bzw. wenn winter_service=yes, dann wird auch der Schnee geräumt und wenn der Schnee nicht geräumt wird, dann ist auch winter_service=no. Hier sollte dein Proposal besser strukturiert sein. snowplowing=heated hat dagegen eine zusätzliche Information. Allgemein halte ich es für schwer, winter_service zu taggen, da er nach Prioritäten abläuft. Bei Dauerschneefall reicht die Kapazität nur aus, die Hauptstraßen frei zu halten, schneit es nur über Nacht, kann es durchaus sein, dass bis zum Abend auch die Wohnstraßen geräumt sind. So etwas dynamisches in ein starres tagging zu gießen halte ich für nicht sinnvoll bzw. die priorität ergibt sich aus der highway-Klasse. das hängt auch sehr von der Stadt ab (die entscheidet AFAIK, ob und vor allem in welchem Umfang es Winterdienst gibt). In Berlin z.B. erinnere ich mich, dass dort Wohnstraßen zumindest teilweise gar nicht geräumt wurden (d.h. dass es dort nach einigen Tagen Kälte alles vereist war), während die Hauptstraßen und die Zuwegungen zu Krankenhäusern etc. immer schnell geräumt wurden. Ja, das hängt auch sehr von der erwarteten Menge an Schnee an. Mein Eindruck ist: Je schneesicherer, desto mehr wird geräumt. Wenn jemand Lust hat, kann er natürlich auch erfassen, dass die Straße jetzt gesperrt ist. -0.5, solche kurzfristigen Informationen wären besser in einer Event-DB oder einem anderen dynamischen Service aufgehobe finde ich. In den Daten würde es m.E. ausreichen einen Hinweis zu haben, dass die Straße nur bei entsprechenden Wetterbedingungen befahrbar ist. Wobei auch der Unterschied gemacht werden muss, ob es sich um ein Befahrverbot handelt, oder ob man halt ohne Geländefahrzeug und Schneeketten (bzw. Kettenfahrzeug) nicht durchkommt. Access und Subtags sind legale Beschränkungen, keine Beschreibung eines physischen Zustands. Das war so gemeint, dass man entsprechende access-Tags setzt, wenn die Straße gesperrt ist und sie wieder entfernt, wenn die Straße wieder frei ist. Das würde ich dann aber auch mit einem access=no machen, da an den Sperren in der Regel entsprechende Schilder stehen. welche Schilder stehen da? Ist das Betreten dieser Straßen dann auch für Wanderer verboten? Wenn nicht ist ein pauschales access=no zu weit gesprungen. Ich hab es bisher nur in Norwegen an den Wintersperrenschranken gesehen. Da war ein Z250 dran, also eher vehicle=no. Muss mal dann im konkreten Fall schauen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27.11.2012 12:33, schrieb Andreas Labres: On 27.11.12 10:48, Andreas Neumann wrote: Das Problem ist, dass man die Straßen nicht Monatsgenau sperren kann. Natürlich kann man, gibt zahlreiche Passstraßen mit definierter Wintersperre (und das ist auch etwas, das Sinn macht, in einer Karte aufzuscheinen!). Und für die anderen Fälle wäre ein winter_service=no ja sinnvoll. Die würden den Pass auch sperren, wenn er noch passierbar ist, aber das Datum erreicht ist und andersrum offen lassen, wenn das Datum noch nicht erreicht ist, aber der Pass nicht mehr passierbar ist? Kann ich mir nur schwer vorstellen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27. November 2012 12:51 schrieb Henning Scholland o...@aighes.de: das hängt auch sehr von der Stadt ab (die entscheidet AFAIK, ob und vor allem in welchem Umfang es Winterdienst gibt). In Berlin z.B. erinnere ich mich, dass dort Wohnstraßen zumindest teilweise gar nicht geräumt wurden (d.h. dass es dort nach einigen Tagen Kälte alles vereist war), während die Hauptstraßen und die Zuwegungen zu Krankenhäusern etc. immer schnell geräumt wurden. Ja, das hängt auch sehr von der erwarteten Menge an Schnee an. Mein Eindruck ist: Je schneesicherer, desto mehr wird geräumt. ja, und von der Haushaltslage ;-) Wenn jemand Lust hat, kann er natürlich auch erfassen, dass die Straße jetzt gesperrt ist. -0.5, solche kurzfristigen Informationen wären besser in einer Event-DB oder einem anderen dynamischen Service aufgehobe finde ich. Das war so gemeint, dass man entsprechende access-Tags setzt, wenn die Straße gesperrt ist und sie wieder entfernt, wenn die Straße wieder frei ist. das hatte ich auch so verstanden welche Schilder stehen da? Ist das Betreten dieser Straßen dann auch für Wanderer verboten? Wenn nicht ist ein pauschales access=no zu weit gesprungen. Ich hab es bisher nur in Norwegen an den Wintersperrenschranken gesehen. Da war ein Z250 dran, also eher vehicle=no. Muss mal dann im konkreten Fall schauen. habe das mal gegooglet und die meisten Schilder waren Z250, teilweise aber auch mit Zusätzen wie Lawinengefahr und in einem Fall auch explizit auf Fußgänger bezogen. Wird man dann halt entsprechend dem Schild taggen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing! Bing! Bing! Neue Luftbilder!
Das gibts ja gar nicht. Wie kann ich nur so ein Pech haben??? bei den neuen Bing-Bildern liege ich mitten in den ausgelassenen Bereichen und auch die neuen Hamburg-Bilder reichen auch nicht bis zu mir. Kann mir jemand sagen ob das Gebiet zwischen Bremen-Hamburg-Hannover auch neue Bilder bekommt? Was ist mit den Blöcken die noch fehlen, kommen die noch? Mit freundlichen Grüßen Stephan aka smarties ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
On 27.11.12 13:09, Henning Scholland wrote: Die würden den Pass auch sperren, wenn er noch passierbar ist, aber das Datum erreicht ist Als Beispiel: Der Großglockner ist von Anfang November bis Anfang Mai gesperrt. Heuer begann die Sperre wegen des frühen Wintereinbruchs schon am 29. Oktober. Und 2011 wurde die Wintersperre wegen des milden Winters und der fortgeschrittenen Räumung bereits am 21. April wieder geöffnet. Aber es wäre kein Fehler, wenn in einer Karte steht, dass die Straße von November bis April gesperrt ist. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausbau des Toiletten-Templates
Hi, eine ordentliche Toilette tagge ich mit allem drum und dran so: http://www.openstreetmap.org/browse/node/2015864795 Mit freundlichen Grüßen Stephan aka smarties Original-Nachricht Datum: Mon, 19 Nov 2012 09:34:51 +0100 Von: Jan Tappenbeck o...@tappenbeck.net An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: [Talk-de] Ausbau des Toiletten-Templates hi! die deutschen Rastplätze werden viel ausgebaut und da würde ich es als sinnvoll halten das Template um den Wickelraum und LKW-Fahrer-Duschräume zu erweiteren. Wie taggt man einen Wickelraum - im Wiki habe ich schon zum Begriff Baby nichts gefunden. Einer Ideen ? Gruß Jan :-) ___ 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] Ausbau des Toiletten-Templates
Hallo Stephan, als Nichtbehinderter würde ich mich trotzdem gern beteiligen centralkey = eurokey Woran erkennt man dieses Schloss? Grüße,Andreas Am 27.11.2012 14:42, schrieb smart...@gmx-topmail.de: Hi, eine ordentliche Toilette tagge ich mit allem drum und dran so: http://www.openstreetmap.org/browse/node/2015864795 Mit freundlichen Grüßen Stephan aka smarties ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27.11.2012 14:41, schrieb Andreas Labres: On 27.11.12 13:09, Henning Scholland wrote: Die würden den Pass auch sperren, wenn er noch passierbar ist, aber das Datum erreicht ist Als Beispiel: Der Großglockner ist von Anfang November bis Anfang Mai gesperrt. Heuer begann die Sperre wegen des frühen Wintereinbruchs schon am 29. Oktober. Und 2011 wurde die Wintersperre wegen des milden Winters und der fortgeschrittenen Räumung bereits am 21. April wieder geöffnet. Aber es wäre kein Fehler, wenn in einer Karte steht, dass die Straße von November bis April gesperrt ist. Keine Frage, aber dann würde ich das Tag dafür anders nennen als bestehende zeitliche Sperren. Bspw. regular_closed=Nov-Apr. day_on und day_off haben eher etwas definitives. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing! Bing! Bing! Neue Luftbilder!
Am 27.11.2012 14:33, schrieb smart...@gmx-topmail.de: Das gibts ja gar nicht. Wie kann ich nur so ein Pech haben??? bei den neuen Bing-Bildern liege ich mitten in den ausgelassenen Bereichen und auch die neuen Hamburg-Bilder reichen auch nicht bis zu mir. Kann mir jemand sagen ob das Gebiet zwischen Bremen-Hamburg-Hannover auch neue Bilder bekommt? Was ist mit den Blöcken die noch fehlen, kommen die noch? Ja, kommt alles noch. Bisher gab es die Updates ungefähr monatlich. Vor Weihnachten hast du dann die nächste Chance auf einen Treffer bei Bing ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausbau des Toiletten-Templates
Am 27. November 2012 14:52 schrieb Andreas Schmidt schmidt-postf...@freenet.de: als Nichtbehinderter würde ich mich trotzdem gern beteiligen centralkey = eurokey Woran erkennt man dieses Schloss? Am Aufkleber, s. hier: http://www.proinfirmis.ch/de/subseiten/eurokey-anlagenbau/sie-moechten/broschuere-eurokey.html Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausbau des Toiletten-Templates
danke, ich hatte noch nie darauf geachtet. Bei Wikipedia habe ich gerade http://de.wikipedia.org/wiki/Euroschl%C3%BCssel gefunden. Und hier noch was http://www.cbf-da.de/shop.html?page=shop.product_detailsflypage=flypage.tplproduct_id=31category_id=6 Da der schon 1986 erfunden wurde, dürfte er wohl fast überall bekannt sein. Grüße, Andreas Am 27.11.2012 15:12, schrieb Martin Koppenhoefer: Am 27. November 2012 14:52 schrieb Andreas Schmidt schmidt-postf...@freenet.de: als Nichtbehinderter würde ich mich trotzdem gern beteiligen centralkey = eurokey Woran erkennt man dieses Schloss? Am Aufkleber, s. hier: http://www.proinfirmis.ch/de/subseiten/eurokey-anlagenbau/sie-moechten/broschuere-eurokey.html Gruß Martin ___ 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] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?
Hallo an alle, bei der relativ einfachen Kreuzung bei Weinheim http://www.openstreetmap.org/?mlat=49.557mlon=8.6486zoom=18layers=M habe ich einige Fehler beseitigt (jemand hatte an drei von vier Straßen Abbiegeverbote nach links eingetragen, die Rechsabbiege-Spuren waren komplett als lange, separate Fahrbahnen gezeichnet usw.) und einige Tags ergänzt. An der Kreuzung darf man von allen vier Richtungen jeweils links, rechts und geradeaus weiterfahren, direkt in der Mitte aber nicht rechts abbiegen (dafür ist ja die separate Fahrbahn da). Wie verhindert man nun, dass man im kleinen mittleren Quadrat drei Mal nach links geschickt wird, um dann doch rechts abbiegen zu können, wenn man die Rechtsabbiegefarbahn verpasst hat? (Linksabbiegen in der Mitte ist ja an allen vier Knotenpunkten erlaubt) http://map.project-osrm.org/?hl=deloc=49.5569,8.6483loc=49.5564,8.6487z=1 8 Wie trägt man hier Wendeverbote ein? Soweit ich mich erinnere, darf man an dieser Kreuzung nicht wenden, wenn man von Norden, Westen oder Süden kommt. Nur von Osten kommend ist Wenden nicht verboten. (Muss ich aber nochmal genau vor Ort prüfen). Über zusätzliche Kreuzfahrbahnen in der Mitte wären die Abbiege- und Wende-Verbote über Relationen möglich, das wäre aber Spurmapping. Oder muss man das hier doch machen? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Henning Scholland schrieb: Am 27.11.2012 14:41, schrieb Andreas Labres: On 27.11.12 13:09, Henning Scholland wrote: Die würden den Pass auch sperren, wenn er noch passierbar ist, aber das Datum erreicht ist? Da war ein Fragezeichen ^ Als Beispiel: Der Großglockner ist von Anfang November bis Anfang Mai gesperrt. Heuer begann die Sperre wegen des frühen Wintereinbruchs schon am 29. Oktober. Und 2011 wurde die Wintersperre wegen des milden Winters und der fortgeschrittenen Räumung bereits am 21. April wieder geöffnet. Aber es wäre kein Fehler, wenn in einer Karte steht, dass die Straße von November bis April gesperrt ist. Keine Frage, aber dann würde ich das Tag dafür anders nennen als bestehende zeitliche Sperren. Bspw. regular_closed=Nov-Apr. day_on und day_off haben eher etwas definitives. Mit der Verwendung von winter_service=no dachte ich, dass man dann dem Router sagen kann: Keine im Winter gesperrten Straßen, wie man in den aktuellen Navis unbefestigte Straßen und andere Kategorien ausschließen kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
André Riedel schrieb: Am 26. November 2012 21:36 schrieb malenki o...@malenki.ch: Andreas Neumann schrieb: Am 25.11.2012 11:40, schrieb Andreas Labres: winter_service=yes sollte es prinzipiell nicht geben, finde ich. Stimmt. Das Proposal habe ich entsprechend geändert. Ich finde gerade bei Radwegen Überland oder Wald- und Feldwegen kann man nicht davon ausgehen, dass diese im Winter geräumt werden. Ja Gesperrt sind deswegen auch nicht, denn Schlitten- und Langlauffahrer freuen sich. Nur beschränkt. Wenn viele Fußgänger über den Schnee getrampelt sind, ist das Skifahren darauf keine Freude. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Martin Koppenhoefer schrieb: OK, wenn aber andere Leute nun schon ein anderes Schema umgesetzt haben (wo der Wert von gritting nicht das Material angibt, sondern eine Prioritätsstufe), dann muss man doch darauf eingehen und für das Material was anderes verwenden, oder? gritting:material oder so. grit ist AFAIK bereits eine Mischung aus Salz und einem anderen Material, neben Split (gebrochener Stein) kommt ggf. auch Sand oder Asche zum Einsatz. Ob man das überhaupt so sehen kann (hier wird nur Split gestreut, hier nur Sand bzw. Sand-Split-Mischung) weiss ich allerdings nicht. Hierzuorts wird vom Winterdienst sortenrein gestreut. Entweder nur Salz mit Lauge (hauptsächlich) oder gelegentlich nur Splitt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Henning Scholland schrieb: An sich finde ich die Idee gut. Danke ;) winter_service und snowplowing=yes/no sagen doch das gleiche aus, bzw. wenn winter_service=yes, dann wird auch der Schnee geräumt und wenn der Schnee nicht geräumt wird, dann ist auch winter_service=no. Hier sollte dein Proposal besser strukturiert sein. Für konkrete Hinweise wäre ich dankbar. snowplowing= wird bereits 25.500 mal verwendet, auf dieses Tag wurde ich in der Diskussion erst nach dem Verfassen des Proposals aufmerksam gemacht. Allgemein halte ich es für schwer, winter_service zu taggen, da er nach Prioritäten abläuft. Hauptsächlich kommt es mir darauf an festzuhalten, wo Winterdienst nur sporadisch oder gar nicht stattfindet. Bei Dauerschneefall reicht die Kapazität nur aus, die Hauptstraßen frei zu halten, schneit es nur über Nacht, kann es durchaus sein, dass bis zum Abend auch die Wohnstraßen geräumt sind. So etwas dynamisches in ein starres tagging zu gießen halte ich für nicht sinnvoll bzw. die priorität ergibt sich aus der highway-Klasse. +1 Das ist auch nicht meine Intention. Zusammenfassend: winter_service=yes würde ich auf Straßen nicht erfassen. Weder als Default noch explizit. Dagegen sinnvoll ist die Erfassung von Einrichtungen wie beheizte Straßen etc. Sollte es auf Wegen mit Räumpflicht Schilder geben, die eine Räumung ausschließen sollte ein winter_service=no verwendet werden. Bei Wegen ohne Räumpflicht würde ich erfassen, dass dieser Weg geräumt wird. Gut getroffen. Wenn du magst, kannst du das gern in tagging-kompatibler Form in das Proposal schreiben. :) Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27.11.2012 22:25, schrieb malenki: Mit der Verwendung von winter_service=no dachte ich, dass man dann dem Router sagen kann: Keine im Winter gesperrten Straßen, wie man in den aktuellen Navis unbefestigte Straßen und andere Kategorien ausschließen kann. Hallo malenki, winter_service=no wird afaik allgemein genutzt, um zu sagen Hier wird nicht geräumt. Für eine Straßensperrung wegen Winter halte ich das schon sprachlich für falsch. Vor allem ist es doch egal, warum die Straße gesperrt ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?
Hallo Bernhard, Am Dienstag, 27. November 2012, 21:46:51 schrieb Bernhard Weiskopf: Wie verhindert man nun, dass man im kleinen mittleren Quadrat drei Mal nach links geschickt wird, um dann doch rechts abbiegen zu können, wenn man die Rechtsabbiegefarbahn verpasst hat? (Linksabbiegen in der Mitte ist ja an allen vier Knotenpunkten erlaubt) http://map.project-osrm.org/?hl=deloc=49.5569,8.6483loc=49.5564,8.6487z=18 Wie trägt man hier Wendeverbote ein? Soweit ich mich erinnere, darf man an dieser Kreuzung nicht wenden, wenn man von Norden, Westen oder Süden kommt. Nur von Osten kommend ist Wenden nicht verboten. (Muss ich aber nochmal genau vor Ort prüfen). ich hab mal nach deiner Beschreibung entsprechende Abbiegebeschränkungen eingetragen. Über zusätzliche Kreuzfahrbahnen in der Mitte wären die Abbiege- und Wende-Verbote über Relationen möglich, das wäre aber Spurmapping. Oder muss man das hier doch machen? Nein, muss man nicht. Abbiegebeschränkungen können als via *statt* dem Zwischenknoten auch ein oder mehrere Wege enthalten. Damit lassen sich auch komplizierte Verbote erfassen. Was man hierbei wissen sollte: - das JOSM-Plugin unterstützt selbst keine via-Wege - OSRM unterstützt keine via-Wege in Abbiegebeschränkungen (ist aber geplant), Navit unterstützt nur einen einzigen via-Weg, die einzige mir bekannte vollständige Implementierung hat MapQuest. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?
Am 27. November 2012 21:46 schrieb Bernhard Weiskopf bweisk...@gmx.de: An der Kreuzung darf man von allen vier Richtungen jeweils links, rechts und geradeaus weiterfahren, direkt in der Mitte aber nicht rechts abbiegen (dafür ist ja die separate Fahrbahn da). Wie verhindert man nun, dass man im kleinen mittleren Quadrat drei Mal nach links geschickt wird, um dann doch rechts abbiegen zu können, wenn man die Rechtsabbiegefarbahn verpasst hat? (Linksabbiegen in der Mitte ist ja an allen vier Knotenpunkten erlaubt) http://map.project-osrm.org/?hl=deloc=49.5569,8.6483loc=49.5564,8.6487z=1 8 Man könnte im Kreuzungsbereich die parallelen Spuren zusammenfassen, so dass sich 8 Straßen da in einem Punkt treffen. Dann würde wegen der oneways jeweils 1 no_u-turn-Relation ausreichen für die 4 Wege die auf die Kreuzung hinführen (plus ggf. Rechtsabbiegeverbot). Oder man macht no-u-turn-relationen mit ways als via-Member. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?
Hallo Martin, Am Dienstag, 27. November 2012, 23:45:42 schrieb Martin Koppenhoefer: Man könnte im Kreuzungsbereich die parallelen Spuren zusammenfassen, so dass sich 8 Straßen da in einem Punkt treffen. …genau, und das halb-rechts abbiegen statt geradeaus gibt es dann gratis dazu. *sigh* Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
Am 27.11.2012 14:32, schrieb Martin Koppenhoefer: Am 27. November 2012 12:51 schrieb Henning Scholland o...@aighes.de: das hängt auch sehr von der Stadt ab (die entscheidet AFAIK, ob und vor allem in welchem Umfang es Winterdienst gibt). In Berlin z.B. erinnere ich mich, dass dort Wohnstraßen zumindest teilweise gar nicht geräumt wurden (d.h. dass es dort nach einigen Tagen Kälte alles vereist war), während die Hauptstraßen und die Zuwegungen zu Krankenhäusern etc. immer schnell geräumt wurden. Ja, das hängt auch sehr von der erwarteten Menge an Schnee an. Mein Eindruck ist: Je schneesicherer, desto mehr wird geräumt. ja, und von der Haushaltslage ;-) .. und dem Verlauf des Winters...Gelegentlich sind auch mal die Streuvorräte erschöpft. Von daher macht es wenig Sinn irgendwelche Streu- und Räumgewohnheiten zu taggen. Das ist zu grosser Pflegeaufwand bei zu wenig Nutzen. Besser fände ich eine Winterqualifizierung von Strassen in mehreren Stufen zu taggen, so etwa in den Stufen 0: Ganzjährig normalerweise keine Beeinrächtigung zu erwarten. 1: An wenigen Tagen im Jahr ist Winterdienst erforderlich 2: Während der Wintermonate häufiger beeinträchtigt / Winterdienst notwendig 3: Ausgedehnter Winterdienst erforderlich 4: Strasse wird regelmässig bei starkem Schneefall gesperrt (bis zu mehreren Tagen) 5: Regelmässige Wintersperre mehrere Wochen bis Monate 6. Nur wenige Wochen im Sommer nutzbar Zusammen mit dem Wetterbericht und der Strassenkategorie kann man so sicher besser in konkreten Situationen abschätzen was einem erwartet. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?
Am 27.11.2012 23:45, schrieb Martin Koppenhoefer: Man könnte im Kreuzungsbereich die parallelen Spuren zusammenfassen, so dass sich 8 Straßen da in einem Punkt treffen. Dann würde wegen der oneways jeweils 1 no_u-turn-Relation ausreichen für die 4 Wege die auf die Kreuzung hinführen (plus ggf. Rechtsabbiegeverbot). Oder man macht no-u-turn-relationen mit ways als via-Member. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Wenn ich mir das Luftbild so ansehe, dann sind das eindeutig baulich getrennte im Kreuzungsbereich gerade verlaufende Fahrspuren, wenn man da jetzt die Wege für den einen Kreuzungspunkt zusammenschwenkt, dann kommt das schon in Richtung mappen für den Router. Die Lösung mit mehrer vias ist zwar den meisten Routern noch nicht geläufig, aber sie ist korrekt. LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC zum Proposal winter_service
On 27.11.12 22:25, malenki wrote: Mit der Verwendung von winter_service=no dachte ich, dass man dann dem Router sagen kann: Keine im Winter gesperrten Straßen, wie man in den aktuellen Navis unbefestigte Straßen und andere Kategorien ausschließen kann. Sorry, den Satz versteh ich grade nicht... Aber beim Großglockner geht's nicht um winter_service, weil den gibt's dort ja, nur eben von November bis April nicht. ;) /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-in] Fwd: Fw: [Wikimedia-l] Fwd: Wikimedia/mapping event in Europe early next year?
Hi, Hope these come or we can organise something like this in India soon. Pradeep From: Erik Moeller e...@wikimedia.org; To: Wikimedia developers wikitec...@lists.wikimedia.org; Wikimedia Mailing List wikimedi...@lists.wikimedia.org; Subject: [Wikimedia-l] Fwd: Wikimedia/mapping event in Europe early next year? Sent: Wed, Nov 28, 2012 2:49:26 AM -- Forwarded message -- From: Erik Moeller e...@wikimedia.org Date: Tue, Nov 27, 2012 at 6:49 PM Subject: Wikimedia/mapping event in Europe early next year? To: map...@lists.wikimedia.org Hi folks, it's been a long time coming, but we're finally gearing up for putting some development effort into an OSM tileservice running in production to serve Wikimedia sites. This is being driven by the mobile team but obviously has lots of non-mobile use cases as well, including the recent Wikivoyage addition to the Wikimedia familiy. This work will probably not kick off before January/February 2013; before then, the mobile team is working to finish up the GeoData extension ( https://www.mediawiki.org/wiki/Extension:Geodata ). To get broader community involvement and sync up with existing volunteer efforts in this area, it'd IMO be useful to plan a face-to-face meetup/hackfest just focused on geodata/mapping related development work sometime around Feb/March 2013. WMF is not going to organize this, but we can help sponsor travel and bring the key developers from our side who will work on this. Are there any takers for supporting a 20-30 people development event in Europe focused on mapping/geodata? I'm suggesting Europe because I know quite a few of the relevant folks are there, but am open to other options as well. Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-it] Ferrovie: situazione stazioni e routing
Leggermente offtopic. Il dataset ferroviario viene usato dal nuovo gioco TrainLord (trainlord.com), è aggiornato ad Ottobre 2012, quindi prima di questa discussione Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ferrovie: situazione stazioni e routing
2012/11/27 sabas88 saba...@gmail.com: Leggermente offtopic. Il dataset ferroviario viene usato dal nuovo gioco TrainLord (trainlord.com), è aggiornato ad Ottobre 2012, quindi prima di questa discussione Rilasciano i tiles in cc-by-sa3.0 e citano anche l'ODbL per i dati OSM, bravi. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ferrovie: situazione stazioni e routing
Il 26/11/2012 20:21, Federico Cozzi ha scritto: Insisto: con railway=station bisogna mappare solo il locale viaggiatori, cioè quello che è una stazione ferroviaria per l'uomo (e il routing) comune. Qui http://wiki.openstreetmap.org/wiki/Railway_stations dice: A node should be tagged as railway=station or railway=halt to mark the actual station/halt. (rather than being on a node, this tag could be on the building, mentioned below) Quindi railway=station deve essere un nodo. In alternativa: For larger stations it is often convenient to mark the entire station building. To complete this, create a closed way and use the tag,building=train_station. Quindi, per mapping più preciso, railway=station deve essere l'edificio della stazione. Per precisione massima: It is especially convenient in route planning to include the building entrances. This is accomplished by tagging the appropriate nodes in a building's boundary as building=entrance orrailway=subway_entrance. Da nessuna parte si dice di mappare come railway=station una intera area, inclusiva di binari ecc. Un tempo si usava mettere railway=station sul binario, e credo che in molti casi il tag si trovi ancora su quel nodo... Comunque, quella di mettere il tag sull'area è solo un'idea (mai messa in pratica). E si riferiva solamente alle stazioni in cui è stato già mappato l'edificio con building=train_station e l'area della stazione come landuse=railway (qualcuno potrebbe obiettare che, da wiki, questo tag pare sia solo per le aree ad accesso riservato). ciao Paolo M ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Ferrovie: situazione stazioni e routing
2012/11/27 Paolo Monegato gato.selvad...@gmail.com: Un tempo si usava mettere railway=station sul binario, e credo che in molti casi il tag si trovi ancora su quel nodo... Comunque, quella di mettere il tag sull'area è solo un'idea (mai messa in pratica). a Roma qualcuno tempo fa aveva cambiato tutte le stazioni e messo railway=station sull'area (supposta) della stazione. Pensandoci all'epoca mi sembrava logico, e non ho cambiato avviso ;-) Sopratutto nelle grande città una stazione può avere molto più di un edificio ed ingresso, ma anche per stazioni non troppo grandi avere 2 ingressi (da ogni lato dei binari) è una situazione abbastanza corrente. Vorrei aggiungere un piccolo semi-offtopic: stazioni della metro. C'è un tag (forse non documentato) per indicare il tipo di stazione: station=subway / light_rail ecc. http://taginfo.openstreetmap.org/keys/station#overview Invito tutti di utilizzarlo (sopratutto a Napoli, Milano, Torino ecc. dove ci sono le metro). E' un po' ridondante perchè si vede anche dai binari su cui si trova la stazione, (premesso che ci sono le stop-position) ma facilizza parecchio il rendering (non serve preprocessing). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] POI all'interno di un edificio
Buonasera a tutt*, sto cominciando ad aggiungere un po' di dettagli alla mappa, e mi sono trovato di fronte alla situazione (comune) di POI situati ad un certo piano di un edificio (generalmente uffici). Stasera, visto che mi sto dedicando ai dettagli, voglio finalmente decidere come mapparli :) Ora, finché l'edificio ha pochi piani (1-2), e l'esercizio è l'unica attività al suo interno, io ho sempre mappato l'intero edificio come l'attività. Non è correttissimo, lo so, ma quantomeno semplifica un po' le cose. Nel caso in cui l'esercizio sia al piano terra, solitamente ha un proprio civico, per cui il problema non si pone. Sono ora di fronte ad un palazzo di 8 piani, al cui piano primo c'è un'agenzia assicurativa. Ovviamente l'ingresso è al piano terra, comune col resto dell'edificio. Per cui segno building=yes, addr:housenumber=*, e... e il POI dove lo metto? Metterlo sul perimetro dell'edificio non ha molto senso (perché non è direttamente accessibile dalla strada); allora ho pensato di metterlo vagante dentro il perimetro (con appropriato tag level=*). Ufficio: http://www.openstreetmap.org/browse/node/2036712070 Edificio: http://www.openstreetmap.org/browse/way/193157250 Ingresso: http://www.openstreetmap.org/browse/node/2036712132 Questa, però, è una situazione che va bene per *un* POI dentro l'edificio. Ovviamente esistono edifici con più uffici al loro interno; già rabbrividisco all'idea di avere tanti POI vaganti in maniera disordinata -- la cosa più logica sarebbe mettere i POI sovrapposti, con l'unica differenza in level= (a parte i tag specifici dell'attività). Questo però diventa un macello in qualunque editor attuale, e anche a livello di rendering. (ok, non mappiamo per il rendering né per l'editor, ma se esiste un modo corretto che faccia contenti tutti, meglio usarlo). Purtroppo non mi vengono in mente idee migliori del POI vagante; qualcuno ha qualche idea in merito? Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] POI all'interno di un edificio
Il 27/11/2012 18:26, David Paleino ha scritto: Ufficio: http://www.openstreetmap.org/browse/node/2036712070 Edificio: http://www.openstreetmap.org/browse/way/193157250 Ingresso: http://www.openstreetmap.org/browse/node/2036712132 Sull'ingresso dovresti aggiungerci il tag entrance=main Purtroppo non mi vengono in mente idee migliori del POI vagante; qualcuno ha qualche idea in merito? Esiste la proposta IndoorOSM [1] ma secondo me è fin troppo elaborata e dettagliata (= poco manutenibile) [1] http://wiki.openstreetmap.org/wiki/IndoorOSM -- Maurizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] POI all'interno di un edificio
2012/11/27 David Paleino da...@debian.org: dell'edificio. Per cui segno building=yes, addr:housenumber=*, e... e il POI dove lo metto? Metterlo sul perimetro dell'edificio non ha molto senso (perché non è direttamente accessibile dalla strada); allora ho pensato di metterlo vagante dentro il perimetro (con appropriato tag level=*). si, al solito si fa così Ufficio: http://www.openstreetmap.org/browse/node/2036712070 Edificio: http://www.openstreetmap.org/browse/way/193157250 Ingresso: http://www.openstreetmap.org/browse/node/2036712132 all'ingresso potresti anche mettere un tag entrance (entrance=yes/main ecc.) Questa, però, è una situazione che va bene per *un* POI dentro l'edificio. va bene anche per più POI, perchè no? E' vero che non è molto dettagliato, si potrebbe anche indicare il perimetro del singolo POI insieme al piano (ai piani) dove appartiene, ma spesso ci manca la voglia è la connoscenza per mappare questi particolari. Ovviamente esistono edifici con più uffici al loro interno; già rabbrividisco all'idea di avere tanti POI vaganti in maniera disordinata -- la cosa più logica sarebbe mettere i POI sovrapposti, con l'unica differenza in level= (a parte i tag specifici dell'attività). non cambia molto mettere punti sovraposti, è sempre la stessa approssimazione (mappare un area come punto). La solita soluzione un po' ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] spam su openstreetbug
sul famoso sito http://openstreetbugs.schokokeks.org per segnalare errori su openstreetmap c'è qualcuno che in zona velletri (Roma) sta aggiungendo tantissime segnalazione senza senso ! infatti le segnalazione sono costituite da due massimo tre lettere ! non capisco cosa sta facendo questa persona c'è un modo per bloccarla ? -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Ami l'arte e vuoi arredare casa con stile? Su MisterCupido.com puoi acquistare le RIPRODUZIONI DEI QUADRI di: Van Gogh, Monet, Klimt, Modigliani, Cezanne, Hayez, Michelangelo, Raffaello, ecc Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12386d=27-11 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Tag Ref per uffici postali
Ciao a tutti. Il wiki propone di abbinare il tag Ref agli uffici postali http://wiki.openstreetmap.org/wiki/IT:Tag:amenity%3Dpost_office Questo numero da inserire è in base alle vostre esperienze il frazionario che si reperisce sul sito www.poste.it a fronte di ogni ufficio postale? Per me è quello, dovrebbe essere univoco. Ciao. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Incontro OpenStreetMap a Bolzano
All'interno di una serie di iniziative in Alto Adige e' nata l'idea di fare un incontro pre-natalizio fra gli utenti openstreetmap dell'alto adige. Lo scopo e' quello di avere un confronto fra i rappresentanti della comunita' e di coinvolgere anche la PA della Provincia Autonoma di Bolzano. La sede dell'evento e' presso il TIS di Bolzano. La data e' da definire, ma se qualcuno e' interessato che non esiti a segnarsi qui http://www.doodle.com/dq5upccuk8qqigu7 In copia Luisa e Patrick, fra i promotori dell'iniziativa -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-co] Arreglos con miras a Geocoder
Hola, apuntándole al geocoder en las zonas urbanas que ya tienen nomenclatura definida encontré que hay unas intersecciones que pueden tener algunos errores, en ese sentido ahora lookco tiene otra opción. En el select además de contar con: * Imágenes de alta resolución * Nombres de vías sospechosos Ahora está acompañado de * Intersecciones sospechosas Se marcaron intersecciones sospechosas aquellas en las cuales hay más de dos vías con nombres distintos. http://test.openstreetmap.co:5000 Así que tenemos más labores de arreglo. Una noche de esta ponemos a botika a correr a ver si normalizamos nuevas contribuciones que hayan llegado ;) Happy mapping. ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
[Talk-dk] Generende blå cirkler
Når jeg bruge wikiens browse-link, fx som her http://www.openstreetmap.org/browse/relation/1166772 så kommer der en masse blå cirkler. Hvorfor det ?? Hvordan kommer man af med dem ?? /sba-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Generende blå cirkler
Hej Sonny Det ser ud som om det er punkter som har attributter, fx. postkasse, jernbane kryds eller lyskryds. Dem kan du nok ikke fjerne, det er bare information der skulle gøre det lettere for dig at finde noder der ikke bare er punkter på en way, men i sig selv har en betydning på kortet. Kim ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Generende blå cirkler
Når jeg zoomer ind på dem, kan jeg se at de forekommer hvor der er lyskryds, jernbaneoverskæringer, mini-rundkørsler og note-tags på ruten, altså generelt tags på noder i rute-relationen. Jeg har ikke umiddelbart noget godt gæt på grunden til cirklerne, men det kunne jo tænkes at nogen synes de er til hjælp. Tirsdag den 27. november 2012 15:30:49 skrev Sonny B. Andersen: Når jeg bruge wiki’ens browse-link, fx som her http://www.openstreetmap.org/browse/relation/1166772 så kommer der en masse blå cirkler. Hvorfor det ?? Hvordan kommer man af med dem ?? /sba-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-gb-westmidlands] Listed Bdgs map on Mapbox
Hi Stuart Glad you like the map. The English Heritage data is a bit flaky. I've been working from a pdf list prepared by BCC some time ago which is much more accurate - also the layer in the self-service planning map(only for checking purposes of course!) which I guess comes from the same list My Heritage map is now updated with public artworks (this data is derived from OSM so is not extensive) Do you know if Centro have a geocoded list of all their Interchange scultpures? :-) Glad to co-operate with you (and Rob) on Tilemill - more heads makes for faster learning. Perhaps a separate meeting somewhere quiet with WiFi? The problem with blank views in the self-service planning map seems to have corrected itself Also some feedback requested on the Heritage map from anyone: I think the blueplaques popups look a bit bland where the image just essentially repeats the text. I'm thinking maybe an image of the person might be more interesting. Also any ideas on who to circulate to publicise this: I can think of Birmingham Civic Society, Birmingham Conservation Trust, Marketing Birmingham to start with Regards Brian ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-es] Google mapmaker
O esto http://wiki.openstreetmap.org/wiki/Awards El dl 26 de 11 de 2012 a les 09:43 +0100, en/na Felix va escriure: Hombre, lo de los badges me suena haberlo visto alguna vez por al wiki de osm. No está mal como incentivo a la colaboración de la gente, pero si de momento no se han añadido, a algo tan sencillo como los perfiles de openstreetmap.org, será por algo :P On Mon, Nov 26, 2012 at 9:30 AM, Jonay Santana jonay.sant...@gmail.com wrote: Otra cosa es quien es el propietario de esos datos, claro... El 26/11/2012 08:27, Roberto Pla p...@aire.org escribió: ¿Con Google tambien se puede mapear y yo no me había enterado?. Lo que mas me ha emocionado es lod elos Badges, ¡me devuelve a mis tiempos de Boy-Scout! :) http://support.google.com/mapmaker/answer/2643662?hl=enref_topic=30029 http://support.google.com/mapmaker/answer/1096018/ -- Roberto Plà http://robertopla.net/ ___ 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 -- Felix ___ 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] Autobahnfotos: A1 von Salzburg Richtung Wien
Hi! Seit kurzem habe ich Fotos der A1 von Alland aus Richtung Salzburg bis zur deutschen Grenzen. Was mir allerdings fehlt ist die Gegenrichtung, also von Salzburg Richtung Wien. Falls jemand von dieser Strecke (georeferenzierte) Fotos hat wäre ich dankbar. Wie üblich sind vor allem Geschwindigkeitsbegrenzung und Hinweisschilder bei Ausfahrten für mich interessant, aber hin und wieder ist auch einfach nur die Spuranzahl hilfreich, da auf den Luftbildern an einigen Stellen der dreispurige Ausbau noch nicht ersichtlich ist. Falls also jemand aktuelle Fotos aus diesem Abschnitt hat, wäre ich dankbar dafür. Gerne stelle ich auch meine Fotos zur Verfügung. vg, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gewässernetz Tirol
Hi, ... zum Tiroler Gewässernetz: (1) Der HZB-Code ist ein hierarchischer Code in dem vom 'Hydrografischen Zentralbüro' (Bundesdienststelle) , geführten Flächenverzeichnis der Einzugsgebiete aller österreichischen Flüsse. Jeder Fluss trägt die Nummer seines Einzugsgebietes. Die hierarchische Codierung ist nicht stabil, sondern kann sich - aus welchen Gründen auch immer ? - ändern. So gab es z.B. kürzlich in Osttirol eine Änderung ab der dritten Ebene: die Drau wurde von 220 in 374 umgetauft, und damit auch die HZB-Codes aller in die Drau mündenden Gewässer. Links zur Organisation des Hydrografischen Dienstes: http://www.tirol.gv.at/themen/umwelt/wasser/wasserkreislauf/hydrographie/ http://www.lebensministerium.at/wasser/wasser-oesterreich/wasserkreislauf/hydrographie_oesterreich.html (2) Neben dem HZB-Verzeichnis gibt es in Tirol auch noch ein eigenes, auf bezirksweisen Verordnungen basierendes, Flächenverzeichnis der Wildbacheinzugsgebiete, deren Codierung (WLV-Code) und Ausdehnung - weil detaillierter in der Abgrenzung - stimmt nicht mit den HZB-Einzugsgebieten überein. z.B: http://www.ris.bka.gv.at/Dokumente/Lgbl/LGBL_TI_20091217_108/LGBL_TI_20091217_108.pdf (3) Die GEW_ID ist eine eindeutige, interne technische Nummer. In Abhängigkeit von div. verwaltungstechnischen Vorgängen kann es auch hier beim jährlichen Gewässernetz-Release u.U. zu Änderungen kommen. ... wer möchte das in OSM Jahr für Jahr nachziehen, und wo liegt der Mehrwert ? Ich denke, in OSM sollte der Gewässer-Name [GEW_NAME_A] reichen. Über die Anzahl der Nummern im HZB-Code [HZBGEW] oder über die Größenklassifizierung der Einzugsgebiete nach EU-Wasserrahmenrichtlinie [GEW_WRRL] sollte aber beim Import die hierarchische Bedeutung der Gewässer berücksichtigt werden. Ich hab mir das noch nicht so genau angesehen, aber das Angebot an brauchbaren Tags im Sinne von 'Strom - Fluss - Bach - Bächlein - Rinnsal ...' Bzw. Gewässer 1. bis n-ter Ordnung scheint überschaubar zu sein. Vielleicht macht es generell Sinn, bei Fließgewässern einen Hierarchie-Tag einzuführen? lG franz. -Ursprüngliche Nachricht- Von: Simon Legner [mailto:simon.leg...@gmail.com] Gesendet: Montag, 26. November 2012 11:14 An: OpenStreetMap AT Betreff: Re: [Talk-at] Gewässernetz Tirol Hallo! On 25/11/12 19:36, Erwin OSM wrote: habe gerade festgestellt, dass Du unter der Kennung simon04_data_tirol_gv_at mit dem Import begonnen hast, den Inn und die Sill. Ja. Das habe ich auch an die Mailingliste geschrieben (13.11.2012). Wenn Du schon importierst, dann sollten doch ein paar mehr Attribute von tirol.gv.at übernommen werden, so meine Meinung. Ich halte zum Beispiel GEW_ID (T2010R1) zur einwandfreien Identifizierung für sehr wichtig. So gibt es doch einige Bäche und Flüsse mit absolut gleichen Namen. Durch diese ID könnten die Gewässer einwandfrei identifiziert werden, jeder Bach hat eine andere Bezeichnung. Das scheint irgendeine ID aus diesem Datensatz zu sein. Diese Information bringt mMn nur dann etwas, wenn sie an jedem Gewässer dabei ist. Wenn man dies will, dann würde ich den Key aber eher `ref:data.tirol.gv.at` nennen. Auch würde ich HZBGEW (2-8-153) am Objekt belassen. Durch diese Nummer kann ein Interessierter den Verlauf absolut richtig zurück verfolgen. Die 2-8 stünde für den Inn, 2-8-153 steht für die Sill. Die Zahl 2-8-153-60 besagt also, dass der Viller Bach (2-8-153-60) in die Sill (2-8-153) und die in den Inn fließt (2-8). Dies könnte doch für Interessierte sehr interessant sein, so denke ich. Das scheint in der Tat ganz interessant zu sein. Eventuell macht das dann auch GEW_ID überflüssig. Auch hier: wenn man das haben will, sollte man einen international verständlichen Tag verwenden: https://wiki.openstreetmap.org/w/index.php?title=Relation:waterwayaction=edit erwähnt für Deutschland `ref:fgkz`. Gibt es in Österreich eine ähnliche Abkürzung? Über die restlichen Attribute könnte man auch noch diskutieren. Ja. Das Tagging habe ich bereits im September zur Diskussion gestellt … Ad http://www.openstreetmap.org/browse/way/192901258 Ich finde es nicht gut, `destination` für das »nachfolgende Gewässer« (Mündung) zu verwenden, da lt. Wiki dieser Tag ganz anders verwendet wird. Außerdem ergibt sich dies auch der Gewässerkennziffer und aus den Daten an sich. Über die Verwendung von `GEW_ID`, `GEW_NAME_A`, `HZBGEW` in der Datenbank habe ich oben bereits was geschrieben. Grüße Simon ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Radwege in Wien
On Tue, 27 Nov 2012 22:52:15 +0100 Markus Straub markus.straub...@gmail.com wrote: .. irgendwie fehlt das #Verkehrs-Radwege auf der Wiki-Seite? cache problem? :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Radwege in Wien
On 27.11.2012 22:18, Stefan Tauner wrote: Grüß euch! Da mir der LCN-Wildwuchs mißfällt und es bisher keine wirklich etablierten Regeln gab, hab ich mir die Freiheit genommen und welche formuliert. :) Wirkt für mich beim ersten Durchdenken schlüssig und JA Relationen neigen dazu kaputt zu sein und laden dazu ein missbräuchlich verwendet zu werden (- Sammelrelationen). LG, Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Radwege in Wien
On 27.11.2012 22:18, Stefan Tauner wrote: Da mir der LCN-Wildwuchs mißfällt und es bisher keine wirklich etablierten Regeln gab, hab ich mir die Freiheit genommen und welche formuliert. :) http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Radwege#Verkehrs-Radwege Ist natürlich nur eine Diskussions-Grundlage, aber solange niemand etwas dagegen sagt, werde ich dieses Schema anwenden. D.h. LCN löschen, wo IMHO unnötig und die fehlenden (davon gibt's mindestens so viele, auch vom Basisnetz/RCN) ergänzen. Wozu das lcn=yes gut sein soll, hab ich noch nie verstanden. (Darf man denn nur dort radfahren, wo das gesetzt ist?) Auch das network=rcn/lcn ist meiner Meinung nach ein Schmafu, weil diese verschiedenen Netze nur auf Karten existieren. In der Realität gibt es zwischen den ersponnenen Hierarchieebenen keinen Unterschied. Deine Regeln sind auf alle Fälle ein Schritt in die richtige Richtung. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Radwege in Wien
On 28.11.2012 02:53, Stefan Tauner wrote: Auch das network=rcn/lcn ist meiner Meinung nach ein Schmafu, weil diese verschiedenen Netze nur auf Karten existieren. In der Realität gibt es zwischen den ersponnenen Hierarchieebenen keinen Unterschied. das ist so nicht richtig und das habe ich auch versucht im wiki ein wenig zu erklären. es gibt qualitative unterschiede, was ausbau, instandhaltung, schneeräumung, streckenführung usw. betrifft (zumindest theoretisch, praktisch gibts vor allem zwischen basis- und grundnetz oft keine unterschiede zb. donauinsel vs. transdanubisches ufer (eurovelo) und nur, weil eine strecke eine basisroute ist, heißt das noch lange nicht, daß man darauf fahren will (gürtelradweg...)). der eigentliche sinn (echte routen damit zu taggen) kann in einer stadt kaum bis gar nicht erfüllt werden, dh aber nicht, daß man sie nicht dennoch sinnvoll einsetzen kann, um das navigieren zu unterstützen (ob manuell oder berechnet). Wie du schon schreibst - in der Realität gibt es diese Unterschiede nicht. Darum macht es auch keinen Sinn, sie zum Navigieren zu nutzen. Ein Navi routet besser an Hand der realen Wege, nicht über Fantasierouten. Das gilt auch umgekehrt - der linksseitige Donauradweg (von Korneuburg kommend) ist in den Basisrouten gar nicht eingezeichnet, aber real einer der wichtigsten in Wien und verdient daher mindestens network=rwn. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Radwege in Wien
On 28.11.12 02:38, Friedrich Volkmann wrote: Wozu das lcn=yes gut sein soll, hab ich noch nie verstanden. Ich hab das immer als ist Teil des Wiener Radwegenetzes verstanden. Und es wird in der OpenCycleMap eben hervorgehoben. Grade in Wien stehen zwar oftmals irgendwelche Schilder rum, aber es gibt wenige wirkliche Routen. Ist IMO viel Stückelwerk und dafür funktioniert das lcn=yes gut. Aber wenn das wer besser machen will, gern. Tät mich halt interessieren, wie... Übrigens, der EV9 ist grade mal wieder sehr kaputtet in AT... /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] remappage après suppression des données CEDRIC007
Le 27 novembre 2012 09:13, adrien carpentier ad.carpent...@gmail.com a écrit : on a suivi de loin la discussion sur le sujet des contrib de cédric007 sur le valenciennois Voilà la zone impactée: http://yosmhm.neis-one.org/?CEDRIC007 -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mises à jour Bing
Philippe Verdy verd...@wanadoo.fr a ?crit : En passant par un autre lien [...] http://www.bing.com/maps/?v=2cp=46.545968~4.689639lvl=6dir=0sty=happ=50493~myappname~worldtour~p_rid~87d0b920-02cb-41d3-af70-972a2ddf9eccFORM=LMLTCC Même en passant par le bon lien, je constate que seule l'Europe de l'Ouest et les USA sont coloriés. Rien à Mada en particulier. L'affichage ne semble correspondre qu'à la plus haute résolution. J'ai raté un réglage? Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
Le 27 novembre 2012 09:13, adrien carpentier ad.carpent...@gmail.com a écrit : Salut! on a suivi de loin la discussion sur le sujet des contrib de cédric007 sur le valenciennois nous sommes plusieurs du npdc à pouvoir essayer d'aider à remapper après la suppression cependant, il va vraiment me manquer de temps en ce moment pour coordonner le remappage est-il possible de nous y guider un peu? notamment quand aura lieu la suppression, quels secteurs ont été touchés?, charge à celles et ceux motivés de préciser le coin qu'ils vont retravailler tous les ajouts des autres contributeurs sur les données créées par cédric peuvent-ils être sauvés dans un calque pour nous en resservir? Merci de votre aide à bientôt adrien -- http://www.virage-energie-npdc.org/ Bonjour, Personnellement, je suis partisan du remappage *avant* suppression comme cela a pu se faire avec le Redaction Bot du changement de licence. J'ai d'ailleurs déjà commencé à recherche (et à remplacer (suppression + retraçage sur la base du cadastre) ) les contributions de CEDRIC007, mais je ne sais trouver que celles où il est le dernier contributeur. http://overpass.osm.rambler.ru/cgi/xapi?*[@user=CEDRIC007][@meta] A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
C'est facile : il suffit de communiquer autour... de trouver un leader et quelques outils de mutualisation / affichage de mapatron (j'aime bien le terme). Pour le job, il suffit d'implémenter l'outil ( https://github.com/hotosm/osm-tasking-manager) qu'utilise HOT ( http://tasks.hotosm.org/) et qui est développé par Pierre GIRAUD de CampToCamp Pour l'affichage, il existe déjà plein d'outils (j'ai même bricolé un truc pour mes mapping party : http://freeroute.fr/update) A+ -- Marc Sibert m...@sibert.fr Le 27 novembre 2012 10:48, Sylvain Maillard sylvain.maill...@gmail.com a écrit : tiens d'ailleurs ça me fait penser ... il n'y aurait pas un moyen de mettre en place des remapatron spécifiques dans des cas comme ça ? ça faciliterait grandement le bouchage de trous dans des cas de suppression de données ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
en fait je pensais à celui qui est maintenant appelé maproulette ( https://github.com/mvexel/remapatron), et qui a été utilisé lors du passage à l'odbl pour re-cartographier des way qui allaient être supprimés ... mais c'est clair que l'outil de HOT est tout ausis intérressant ! Le 27 novembre 2012 11:43, Marc SIBERT m...@sibert.fr a écrit : C'est facile : il suffit de communiquer autour... de trouver un leader et quelques outils de mutualisation / affichage de mapatron (j'aime bien le terme). Pour le job, il suffit d'implémenter l'outil ( https://github.com/hotosm/osm-tasking-manager) qu'utilise HOT ( http://tasks.hotosm.org/) et qui est développé par Pierre GIRAUD de CampToCamp Pour l'affichage, il existe déjà plein d'outils (j'ai même bricolé un truc pour mes mapping party : http://freeroute.fr/update) A+ -- Marc Sibert m...@sibert.fr Le 27 novembre 2012 10:48, Sylvain Maillard sylvain.maill...@gmail.coma écrit : tiens d'ailleurs ça me fait penser ... il n'y aurait pas un moyen de mettre en place des remapatron spécifiques dans des cas comme ça ? ça faciliterait grandement le bouchage de trous dans des cas de suppression de données ! ___ 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] Mises à jour Bing
Non tu n'as rien raté. L'orthophotographie n'est disponible qu'en Europe et aux USA. Pour le reste du monde ce sont les photos satellites, non orthorectifiées (donc avec des problèmes aussi d'alignement entre les prises de vue accolées dans la même tuile si on zoome un peu trop). L'appli montre aussi les dates d'imports des données satellites (tous les 3 mois environ, contre tous les mois pour la base orthophotographique haute résolution) pour le reste du monde. L'appli ne montre pas les imports des vues aériennes à 45 degrés du mode Bird's eye (non orthorectifiées elles non plus et prise à des angles très variables d'un endroit à l'autre) et qui commencent à dater sérieusement. Le 27 novembre 2012 10:19, Eric Sibert courr...@eric.sibert.fr a écrit : Philippe Verdy verd...@wanadoo.fr a ?crit : En passant par un autre lien [...] http://www.bing.com/maps/?v=2**cp=46.545968~4.689639lvl=6** dir=0sty=happ=50493~**myappname~worldtour~p_rid~** 87d0b920-02cb-41d3-af70-**972a2ddf9eccFORM=LMLTCChttp://www.bing.com/maps/?v=2cp=46.545968~4.689639lvl=6dir=0sty=happ=50493~myappname~worldtour~p_rid~87d0b920-02cb-41d3-af70-972a2ddf9eccFORM=LMLTCC Même en passant par le bon lien, je constate que seule l'Europe de l'Ouest et les USA sont coloriés. Rien à Mada en particulier. L'affichage ne semble correspondre qu'à la plus haute résolution. J'ai raté un réglage? Eric __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] remappage *avant* suppression des données CEDRIC007
Personnellement, je suis partisan du remappage *avant* suppression comme cela a pu se faire avec le Redaction Bot du changement de licence. Je viens de regarder un endroit au hasard dans le secteur (Wavrechain-sous-Denain). En dehors de l'utilisation de Google Sat (source des gros décalages?), ces contributions ne sont de toute façon pas follichonnes. Problèmes de connectivité à certains carrefours, voies dont lexistence sur le terrain paraissent douteuses, traçage à la hache. A mon avis, ça sera plus rapide de repartir à zéro après nettoyage que de refaire avant en se laissant perturber par tous les trucs foireux qu'il a mis. Sans parler des problèmes de connexion à l'existant : à chaque carrefour on va se demander clean/pas clean??? La seule grosse perte, mais on n'y peut rien, ce sont les contributeurs qui sont repassés derrière lui pour corriger ses nombreux défauts. Faut juste appliquer rapidement le script de nettoyage que l'OSMF avait mis en place pour le changement de licence mais appliqué à ce contributeur. Que fait le DWG ? ;-) Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
Je ne pense pas que Valencienne lui-même sera tellement impacté. En revanche les autoroutes du coin seront à reconnecter si ce qu'il a fait sur les échangeurs vient à les casser. De même mettre en priorité le travail sur la frontière franco-belge et juste après les autoroutes (A1, A2, surtout l'A21). Ensuite les nationales ou départementales. Des cours d'eau mineurs seront certainement effacés et il y aura plus de travail, mais ce n'est pas dramatique. Le gros du travail sera dans les villages à l'ouest de Valencienne où il a le plus travaillé et dans les détails de la campagne. A priori le bâti sera conservé pour l'essentiel, cela ne vient pas de lui mais des imports du cadastre, ce qui va faciliter la reconstruction des routes et des rues. Il va manquer des bois, des limites de polygone Corine retouchés, et surtout la toponymie locale des lieux-dits et les petits commerces, et la classification de certains bâtiments. Des limites de communes seront brisées. Pensez aussi aux villages en Belgique et aux contributeurs belges. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
Le mardi 27 novembre 2012 13:53:28, Eric Sibert a écrit : Faut juste appliquer rapidement le script de nettoyage que l'OSMF avait mis en place pour le changement de licence mais appliqué à ce contributeur. Que fait le DWG ? ;-) Il est là ! Moi, j'attends juste les instructions. J'ai indiqué attendre 3/4 jours depuis lundi voir où va la discussion et si pas d'opposition, faire la rédaction. J'ai entendu 3 voix s'élevées contre une suppression ou, tout du moins, contre une suppression tout de suite, donc j'attends. j'attends soit qu'on me dise : - bon, finalement vas y = je fais - non, mais si, mais oui, mais ça, mais hop, ... pendant 2 semaines = je fais - C'est bon, je gère ce projet, j'ai copié ça, analysé si et je vais coordonner l'effort de remap avec données encore en base, donnes moi 1 mois = j'attends Mon avis, je l'ai donné : il faut supprimer, et le plus tôt sera le mieux. Une nouvelle m'a été suggérée par le DWG expert en redaction massive et galères : Si on lance le remmaping avec données tintées en base, la tentation est grande de bidouiller = copier + effacer + coller pour faire disparaitre l'historique De déplacer juste tous les noeuds dans 20cm De quand même copier les noms en provenance de la donnée tintée bref, d'embrouiller l'affaire encore plus Le mieux, à mon avis, c'est d'avoir une représentation incopiable de ce qui va être supprimé, (garder ça sous forme d'image ou des gpx simplifiés) et de tout effacé pour ensuite remapper Mais c'est du boulot, et je ne me propose pas pour le faire. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap.org passe à Leaflet
Et celui-ci : Des lignes blanches qui apparaissent entre certaines tuiles. Firefox 16.0.2, W7 ? Elles n'étaient pas présentes avant. JB Le 26.11.2012 17:03, Christian Quest a écrit : Je viens de vérifier sur mon Mac... c'était nickel avec Firefox 16.0.2, mais une fois mis à jour en Firefox 17, j'ai le même défaut d'affichage. N'ayant pas trouvé de rapport de bug sur trac, j'en ai créé un avec ta pièce jointe : https://trac.openstreetmap.org/ticket/4702 [2] Le 26 novembre 2012 16:49, Francescu GAROBY windu...@gmail.com a écrit : Je rencontre (sans doute) le même problème que toi (cf. screenshot ci-joint), avec Fx 17 sous Windows 8 (avec Fx 17 sous Linux, aucun pb), avec l'URL de prod. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest [3] ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [1] Links: -- [1] http://lists.openstreetmap.org/listinfo/talk-fr [2] https://trac.openstreetmap.org/ticket/4702 [3] http://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
Il n'y a pas que la tentation de copier-coller et effacer l'ancien. Le problème est de savoir à l'avance ce qui doit être effacé et ce qui peut être conservé car on a déjà une autorisation nécessaire par ailleurs. Qu'une licence indiquée soit invalide n'empêche pas qu'il puisse exister une autre licence compatible et d'avoir un recours avant. La procédure permettant d'identifier précisément ce sur suoi on va agir lors d'un incident, et d'en prendre le contrôle d'abord tout en permettant un suivi de chaque incident, en son temps, et prévoir les ressources nécessaire pour le remapping ou d'autres points à vérifier avant me parait essentielle avant d'envoyer un stupide robot faire le ménage sans test possible préalable. La suppression est plus vite faite et plus facile que la restauration ! Bref la planification n'est pas exclue quand il n'y a pas d'urgence (surtout ici, l'urgence n'est plus là après 2 ans ce n'est pas 2 semaines qui vont agraver le problème de façon significative). Et ce n'est pas non plus un problème spécifique car cela peut se reproduire assez souvent dans plein d'endroits, qu'on gérera comme des incidents séparés. Les tickets ne sont pas adaptés pour discuter des solutions et recours communautaires, et effacer sans rien dire à la communauté n'est pas non plus une bonne politique. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
- on sais déjà ce qu'il y a à effacer: tout - on sais parfaitement que dedans il y aura des données qu'on peut garder, mais elles sont mélangées avec des données incompatibles et il n'y a aucun moyen de les distinguer des autres - la procédure prévue me parait plutôt claire : il faut tout faire disparaître. donc suppression, sauf si quelqu'un a une meilleure idée techniquement possible! - ça n'est pas une procédure en urgence, puisque justement sly a mis un délai avant d'agir - les tickets ont pour vocation unique de faire une liste des problèmes recensés pour pouvoir en discuter et faire un suivi; les discussions communautaires se passent ailleurs - je ne vois même pas pourquoi il est question d'effacer sans rien dire à la communauté puisqu'on est justement en train d'en discuter ... Sylvain Le 27 novembre 2012 15:33, Philippe Verdy verd...@wanadoo.fr a écrit : Il n'y a pas que la tentation de copier-coller et effacer l'ancien. Le problème est de savoir à l'avance ce qui doit être effacé et ce qui peut être conservé car on a déjà une autorisation nécessaire par ailleurs. Qu'une licence indiquée soit invalide n'empêche pas qu'il puisse exister une autre licence compatible et d'avoir un recours avant. La procédure permettant d'identifier précisément ce sur suoi on va agir lors d'un incident, et d'en prendre le contrôle d'abord tout en permettant un suivi de chaque incident, en son temps, et prévoir les ressources nécessaire pour le remapping ou d'autres points à vérifier avant me parait essentielle avant d'envoyer un stupide robot faire le ménage sans test possible préalable. La suppression est plus vite faite et plus facile que la restauration ! Bref la planification n'est pas exclue quand il n'y a pas d'urgence (surtout ici, l'urgence n'est plus là après 2 ans ce n'est pas 2 semaines qui vont agraver le problème de façon significative). Et ce n'est pas non plus un problème spécifique car cela peut se reproduire assez souvent dans plein d'endroits, qu'on gérera comme des incidents séparés. Les tickets ne sont pas adaptés pour discuter des solutions et recours communautaires, et effacer sans rien dire à la communauté n'est pas non plus une bonne politique. ___ 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] réutilisation citoyenne d'OpenStreetMap
J'ai découvert par hasard cette réutilisation que je trouve particulièrement intéressante : http://pourletram.fr/DATA/Documents/koenig-collectif-22.pdf. (page 2) J'ai pris contact avec eux pour leur signaler l'absence de crédits et leur dire tout le bien que je pensais de ce genre de réutilisation. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Salut christophe, On dimanche 25 novembre 2012, Christophe Merlet wrote: Les messages de philippe sont certes, la plupart du temps, lourd, verbeux et hors sujet, mais de là a les supprimer parce que tu peux le faire est inacceptable. Je trouve ce comportement déplorable et injustifiable. J'avais pensé ne pas répondre au début pour éviter d'enflammer ce sujet, mais je me suis dis, que, peut-être, ignorer était plus frustrant encore. Je ne souhaite pas pour autant m'étendre sur la question, et ne le ferais que si plusieurs personnes* trouvent mon action inadaptée et ont besoin de plus amples explications. Mais pour ma part, je me contenterais de remercier Philippe Verdy pour son email qu'il t'a répondu qui me semble pleinement expliquer et justifier mes actions sans avoir besoin d'en rajouter. La situation me semblant grotesque, je préfère ajouter cette note de rire, et précise donc qu'il s'agit bien de sarcasme. Et que je continuerais à modérer, agressivement s'il le faut, le forum et le suivi de bug dont j'ai la charge puisqu'il semble que personne n'a les couil... (ou ne l'a jugé utile) de le faire sur talk-fr. * = tout particulièrement les personnes qui font, bien plus que ceux qui parlent. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
Faut juste appliquer rapidement le script de nettoyage que l'OSMF avait mis en place pour le changement de licence mais appliqué à ce contributeur. Que fait le DWG ? ;-) Il est là ! En fait, ma question sous-jacente était plus technique. Le DWG a-t-il les outils pour un nettoyage ramenant les objets à leur état antérieur aux apports de ce contributeur (façon changement de licence)? j'attends soit qu'on me dise : - bon, finalement vas y = je fais +1. - C'est bon, je gère ce projet, j'ai copié ça, analysé si et je vais coordonner l'effort de remap avec données encore en base, donnes moi 1 mois = j'attends Je ne vais pas coordonner l'effort de remap ni remapper préventivement ;-) Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Openstreetmap] remappage après suppression des données CEDRIC007
Salut, J'interviens tard sur cette affaire, désolé. C'est une vieille affaire que celle de CEDRIC007. On en avait déjà parlé sur cette liste lorsque j'avais soulevé le lièvre en 2010. La suppression des données sera une bonne chose, notamment pour occuper nos longues soirées d'hiver. La violation de licence était flagrante, si l'affaire s'était ébruité, ç'aurait fait du mal à notre image. La reconstruction du Valenciennois ne sera pas trop compliquée je pense : CEDRIC007 était un bourrin du tracé de voirie. À nous de bourriner autant que lui. Les détails les plus chronophages comme les POI ne devraient pas souffrir de la disparition de ces données. Tout au plus auront-ils été mal calés et devra-t-on corriger leur position sur la carte*. C'est du gâteau ! Philippe, peut-être trop optimiste * changer leur position sur le terrain serait long et pénible Le 27/11/2012 09:13, adrien carpentier a écrit : Salut! on a suivi de loin la discussion sur le sujet des contrib de cédric007 sur le valenciennois nous sommes plusieurs du npdc à pouvoir essayer d'aider à remapper après la suppression cependant, il va vraiment me manquer de temps en ce moment pour coordonner le remappage est-il possible de nous y guider un peu? notamment quand aura lieu la suppression, quels secteurs ont été touchés?, charge à celles et ceux motivés de préciser le coin qu'ils vont retravailler tous les ajouts des autres contributeurs sur les données créées par cédric peuvent-ils être sauvés dans un calque pour nous en resservir? Merci de votre aide à bientôt adrien -- http://www.virage-energie-npdc.org/ ___ Openstreetmap mailing list openstreet...@chtinux.org http://lists.linux62.org/cgi-bin/mailman/listinfo/openstreetmap ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
On mardi 27 novembre 2012, Eric Sibert wrote: Il est là ! En fait, ma question sous-jacente était plus technique. Le DWG a-t-il les outils pour un nettoyage ramenant les objets à leur état antérieur aux apports de ce contributeur (façon changement de licence)? Oui on a, il fonctionne, a été testé, a prouvé qu'il marchait suffisament bien. Et d'ailleurs, c'est exactement cet outil dont tu parles, car le changement de licence a utilisé une approche par utilisateur, et il a été recyclé et un tout petit peu adapté afin de gérer exactement le genre de cas dont nous discutons. Ce qu'on attends juste, c'est un go j'attends soit qu'on me dise : - bon, finalement vas y = je fais +1. +2 - C'est bon, je gère ce projet, j'ai copié ça, analysé si et je vais coordonner l'effort de remap avec données encore en base, donnes moi 1 mois = j'attends Je ne vais pas coordonner l'effort de remap ni remapper préventivement ;-) Pas mieux, mais c'est pas parce qu'on ne veut pas que pour autant ça nous donne le droit, il me semble, d'imposer la rédaction (même si la majorité est d'accord) D'où ma proposition : on attend une certaine durée, si aucun coordonnateur ne présente un plan de reprise permettant de régler le problème, là on fera. Car on ne peut pas se permettre le blabla de prendre le dessus et de planquer notre tête dans le sable en attendant que google se réveille. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Le mardi 27 novembre 2012 à 16:47 +0100, sly (sylvain letuffe) a écrit : Salut christophe, On dimanche 25 novembre 2012, Christophe Merlet wrote: Les messages de philippe sont certes, la plupart du temps, lourd, verbeux et hors sujet, mais de là a les supprimer parce que tu peux le faire est inacceptable. Je trouve ce comportement déplorable et injustifiable. J'avais pensé ne pas répondre au début pour éviter d'enflammer ce sujet, mais je me suis dis, que, peut-être, ignorer était plus frustrant encore. Je ne souhaite pas pour autant m'étendre sur la question, et ne le ferais que si plusieurs personnes* trouvent mon action inadaptée et ont besoin de plus amples explications. Mais pour ma part, je me contenterais de remercier Philippe Verdy pour son email qu'il t'a répondu qui me semble pleinement expliquer et justifier mes actions sans avoir besoin d'en rajouter. La situation me semblant grotesque, je préfère ajouter cette note de rire, et précise donc qu'il s'agit bien de sarcasme. Et que je continuerais à modérer, agressivement s'il le faut, le forum et le suivi de bug dont j'ai la charge puisqu'il semble que personne n'a les couil... (ou ne l'a jugé utile) de le faire sur talk-fr. * = tout particulièrement les personnes qui font, bien plus que ceux qui parlent. J'ai été pendant presque 10 ans coordinateur des traductions française du projet GNOME. Je n'ai jamais kické, blacklisté, banni, édité quelqu'un qui me soulait que ce soit sur IRC, listes de diffusions ou autres. Par contre des coup de gueule... oui. De même dans toutes les autres assos où j'ai eu des responsabilités et les moyens de me laisser aller à ce genre de dérives. Et ce n'est pas non plus sur OSM que je le ferais, car je n'estimes pas qu'avoir ce comportement de justicier est faire preuve de virilité... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
Avant de lancer l'effacement, j'aurais juste voulu récupérer l'ensemble des données teintées et lancer une opération préventive (et coordonnée) de *remplacement* des données. Mais je ne sais pas faire cette requête des données teintées, je sais juste faire la requête des éléments modifié en dernier par Cédric. Si vous savez faire cette requête, Si l'existant veut le coup (trop bourrin ?), Alors je demande [1 mois ferme] de délai. Dans tous les autres cas, je laisse pisser. Après tout, moi, je m'en fou, j'ai du poil aux pates, ça me tient chaud l'hivers p core dump /. A+ -- Marc Sibert m...@sibert.fr Le 27 novembre 2012 17:19, sly (sylvain letuffe) li...@letuffe.org a écrit : On mardi 27 novembre 2012, Eric Sibert wrote: Il est là ! En fait, ma question sous-jacente était plus technique. Le DWG a-t-il les outils pour un nettoyage ramenant les objets à leur état antérieur aux apports de ce contributeur (façon changement de licence)? Oui on a, il fonctionne, a été testé, a prouvé qu'il marchait suffisament bien. Et d'ailleurs, c'est exactement cet outil dont tu parles, car le changement de licence a utilisé une approche par utilisateur, et il a été recyclé et un tout petit peu adapté afin de gérer exactement le genre de cas dont nous discutons. Ce qu'on attends juste, c'est un go j'attends soit qu'on me dise : - bon, finalement vas y = je fais +1. +2 - C'est bon, je gère ce projet, j'ai copié ça, analysé si et je vais coordonner l'effort de remap avec données encore en base, donnes moi 1 mois = j'attends Je ne vais pas coordonner l'effort de remap ni remapper préventivement ;-) Pas mieux, mais c'est pas parce qu'on ne veut pas que pour autant ça nous donne le droit, il me semble, d'imposer la rédaction (même si la majorité est d'accord) D'où ma proposition : on attend une certaine durée, si aucun coordonnateur ne présente un plan de reprise permettant de régler le problème, là on fera. Car on ne peut pas se permettre le blabla de prendre le dessus et de planquer notre tête dans le sable en attendant que google se réveille. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
On mardi 27 novembre 2012, Christophe Merlet wrote: J'ai été pendant presque 10 ans coordinateur des traductions française du projet GNOME. C'est sensé prouver quelque chose ? Je n'ai jamais kické, blacklisté, banni, édité quelqu'un qui me soulait que ce soit sur IRC, listes de diffusions ou autres. J'ai envie de dire tant mieux pour toi, je n'ai juste pas eu cette chance on dirait. Ou, peut-être, tu n'as pas eu cette malchance. Dans d'autres temps, d'autres communautées, et d'autres personnes, ça aurait peut-être pû t'arriver. Par contre des coup de gueule... oui. A chacun sa manière de perdre son temps, j'ai fais un choix différent du tient dans certains cas. Et ce n'est pas non plus sur OSM que je le ferais En as-tu seulement l'occasion ? C'est une évidence que si tu n'en as pas le besoin, tu ne le fera pas, pas plus que moi. , car je n'estimes pas qu'avoir ce comportement de justicier est faire preuve de virilité... /me ne voit pas le rapport avec la choucroutte. Cette discussion ne nous avance pas beaucoup de toute façon, j'ai un problème, tu ne m'offres pas de solution. Mais je ne suis pas fermé, si tu souhaites prendre en charge le problème P. V. je te le laisse, avec la méthode de ton choix peut m'importe, seul le résultat m'importe. Et j'ai tout pouvoir pour te faire modérateur des tickets ou du forum, tu candidates ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes
Danger Troll Je soutiens Sylvain dans son action car : - J'estime que les rapport signal / bruit de Philippe V est inférieur à l'acceptable sur les différents supports de communication ; - J'admets que la liste publique talk-fr reste un lieu de partage de tous les points de vue (même les plus bruyants) et donc que la censure ne s'y applique pas (ni le bannissement) ; - J'estime, par contre, que cette pollution *ne doit pas* s'étendre à des outils ou des listes techniques qui permettent à ceux qui font (*doocratie *) de travailler efficacement (la censure s'est faite sur l'outil de tickets). A+ -- Marc Sibert m...@sibert.fr Le 27 novembre 2012 17:28, Christophe Merlet red...@redfoxcenter.org a écrit : Le mardi 27 novembre 2012 à 16:47 +0100, sly (sylvain letuffe) a écrit : Salut christophe, On dimanche 25 novembre 2012, Christophe Merlet wrote: Les messages de philippe sont certes, la plupart du temps, lourd, verbeux et hors sujet, mais de là a les supprimer parce que tu peux le faire est inacceptable. Je trouve ce comportement déplorable et injustifiable. J'avais pensé ne pas répondre au début pour éviter d'enflammer ce sujet, mais je me suis dis, que, peut-être, ignorer était plus frustrant encore. Je ne souhaite pas pour autant m'étendre sur la question, et ne le ferais que si plusieurs personnes* trouvent mon action inadaptée et ont besoin de plus amples explications. Mais pour ma part, je me contenterais de remercier Philippe Verdy pour son email qu'il t'a répondu qui me semble pleinement expliquer et justifier mes actions sans avoir besoin d'en rajouter. La situation me semblant grotesque, je préfère ajouter cette note de rire, et précise donc qu'il s'agit bien de sarcasme. Et que je continuerais à modérer, agressivement s'il le faut, le forum et le suivi de bug dont j'ai la charge puisqu'il semble que personne n'a les couil... (ou ne l'a jugé utile) de le faire sur talk-fr. * = tout particulièrement les personnes qui font, bien plus que ceux qui parlent. J'ai été pendant presque 10 ans coordinateur des traductions française du projet GNOME. Je n'ai jamais kické, blacklisté, banni, édité quelqu'un qui me soulait que ce soit sur IRC, listes de diffusions ou autres. Par contre des coup de gueule... oui. De même dans toutes les autres assos où j'ai eu des responsabilités et les moyens de me laisser aller à ce genre de dérives. Et ce n'est pas non plus sur OSM que je le ferais, car je n'estimes pas qu'avoir ce comportement de justicier est faire preuve de virilité... Librement, -- Christophe Merlet (RedFox) ___ 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] Suppression des tirets cadratins
Bonjour, Je constate une lente (mais certaine) progression de l'usage d'un caractère typographique qui, amha, n'a rien à faire dans les tags name d'OSM. Je parle du tiret cadratin ou tiret long, unicode 0x2014. Exemples: http://www.openstreetmap.org/browse/relation/90341 Petit rappel : OSM est une base de données, pas une société d'édition de beaux livres ou de belles cartes avec de beaux tirets longs, moyens ou carrés pour faire joli. Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. Alors, lorsque je rencontrerais ce genre de caractère exotique, je les remplacerais par le bon vieux tiret, unicode 0x002D, code ASCII 0x2D, touche clavier '-'. Et je répéterais ce que disait un de nos anciens premiers ministres à ceux qui insisteraient: je vous demande de vous arrêter. Je connais les auteurs de ces mauvaises habitudes (toujours les mêmes) mais je ne dénonce pas en public. Ils se reconnaîtront. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réf.: Re: remappage *avant* suppression des données CEDRIC007
je peux sortir un fichier .osm . a partir de la tu dois pouvoir l ouvrir avec Josm ou peut etre meme le charger avec openlayers non? -- Le mar. 27 nov. 2012 17:51 HNEC, Marc SIBERT a écrit : OK voyons. Mon point de vue reste qu'il faudrait un outil pour visualiser où il faut faire de la reprise, comme feu l'outil suisse OSM CLEANMAPhttp://cleanmap.poole.ch/?zoom=10lat=46.6508lon=4.945 Le pré-requis est donc l'obtention des données teintées. A+ Le 27 novembre 2012 17:43, THEVENON Julien julien_theve...@yahoo.fr a écrit : je peux peut etre bricoler quelque chose pour recuperer tous les objets qu il a edite mais je ne promets rien. ca t irait ? Julien -- *De :* Marc SIBERT m...@sibert.fr *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Mardi 27 novembre 2012 17h34 *Objet :* Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007 Avant de lancer l'effacement, j'aurais juste voulu récupérer l'ensemble des données teintées et lancer une opération préventive (et coordonnée) de *remplacement* des données. Mais je ne sais pas faire cette requête des données teintées, je sais juste faire la requête des éléments modifié en dernier par Cédric. Si vous savez faire cette requête, Si l'existant veut le coup (trop bourrin ?), Alors je demande [1 mois ferme] de délai. Dans tous les autres cas, je laisse pisser. Après tout, moi, je m'en fou, j'ai du poil aux pates, ça me tient chaud l'hivers p core dump /. A+ -- Marc Sibert m...@sibert.fr Le 27 novembre 2012 17:19, sly (sylvain letuffe) li...@letuffe.org a écrit : On mardi 27 novembre 2012, Eric Sibert wrote: Il est là ! En fait, ma question sous-jacente était plus technique. Le DWG a-t-il les outils pour un nettoyage ramenant les objets à leur état antérieur aux apports de ce contributeur (façon changement de licence)? Oui on a, il fonctionne, a été testé, a prouvé qu'il marchait suffisament bien. Et d'ailleurs, c'est exactement cet outil dont tu parles, car le changement de licence a utilisé une approche par utilisateur, et il a été recyclé et un tout petit peu adapté afin de gérer exactement le genre de cas dont nous discutons. Ce qu'on attends juste, c'est un go j'attends soit qu'on me dise : - bon, finalement vas y = je fais +1. +2 - C'est bon, je gère ce projet, j'ai copié ça, analysé si et je vais coordonner l'effort de remap avec données encore en base, donnes moi 1 mois = j'attends Je ne vais pas coordonner l'effort de remap ni remapper préventivement ;-) Pas mieux, mais c'est pas parce qu'on ne veut pas que pour autant ça nous donne le droit, il me semble, d'imposer la rédaction (même si la majorité est d'accord) D'où ma proposition : on attend une certaine durée, si aucun coordonnateur ne présente un plan de reprise permettant de régler le problème, là on fera. Car on ne peut pas se permettre le blabla de prendre le dessus et de planquer notre tête dans le sable en attendant que google se réveille. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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 -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
http://toolserver.org/~osm/locale/__all.html?zoom=11lat=50.36145lon=3.59047layers=B Le 27 novembre 2012 17:59, sly (sylvain letuffe) li...@letuffe.org a écrit : On mardi 27 novembre 2012, THEVENON Julien wrote: je peux peut etre bricoler quelque chose pour recuperer tous les objets qu il a edite mais je ne promets rien. ca t irait ? Je ne suis pas super bien placé sur ce projet de re-mapping car je compte m'en tenir loin, mais je vous suggère une idée (à cause des divers problèmes évoqués dans l'autre fil en rapport à ça) : Ne pas lancer la compagne de re-mapping avec données tintées en base (parce que qualité, parce que risque de re-copie, parce que pas forcément plus simple) A la place, télécharger les tuiles en provenance d'osm telles qu'elles sont à l'heure actuelle à un zoom du style 9/10/11/12 dans la zone impactée (il y a des outils tout fait pour ça) pour lequel les noms n'apparaissent pas, juste les formes, et uniquement vue de loin (pour pas qu'elles soient intéressantes à décalquer bêtement) Rendre ça dispo. Effacer tout. Commencer le re-mapping (c'est bien plus simple de remapper un trou il me semble, car visible, que de se servir de données tintées) en utilisant le fond de carte sous JOSM comme base pour repérer les pas trous devenus trous. Autre solution : Faire un rendu non copiable des données touchées, mais là, ça devient plus difficile quand même. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
yo, HS(running gag :) je sens qu'on va encore être d'accord, ça devient pénible à force, heureusement qu'on a le wiki pour s'étriper/HS On mardi 27 novembre 2012, Pieren wrote: Je constate une lente (mais certaine) progression de l'usage d'un caractère typographique qui, amha, n'a rien à faire dans les tags name d'OSM. Je parle du tiret cadratin ou tiret long, unicode 0x2014. Exemples: http://www.openstreetmap.org/browse/relation/90341 Put... j'avais peur de re-re-passer pour un chieur à lancer le sujet, mais ce tiret m'a valu un échange vif (et bizarrement sans intérêt et trop long avec l'unique auteur de tous ces tirets) J'ai laissé tombé car ça me semblait futile. Mais c'est revenu sur la liste tagging : http://gis.19327.n5.nabble.com/Naming-boundary-ways-td5728863.html#a5729805 Où l'on m'a presque reproché que ça soit un français qui propage ça à toute l'europe. Donc : +1 Petit rappel : OSM est une base de données, pas une société d'édition de beaux livres ou de belles cartes avec de beaux tirets longs +1 , moyens ou carrés pour faire joli. Les caractères de ponctuation doivent pouvoir être saisis par n'importe quel quidam sur n'importe quel clavier et être reconnus par n'importe quel logiciel. +1 : Les mappeurs devraient avoir la priorité et de la simplicité dès que c'est possible sans que ça n'impacte négativement les autres mappeurs (si si ,les relations c'est bien) Alors, lorsque je rencontrerais ce genre de caractère exotique, je les remplacerais par le bon vieux tiret, unicode 0x002D, code ASCII 0x2D, touche clavier '-'. +1 ou ; ou , ou / ou j'en sais rien mais un truc qui se trouve sur le clavier des gens Et je répéterais ce que disait un de nos anciens premiers ministres à ceux qui insisteraient: je vous demande de vous arrêter. +1 Je connais les auteurs de ces mauvaises habitudes (toujours les mêmes) mais je ne dénonce pas en public. Ils se reconnaîtront. Là, j'en ai marre des +1, on dirait une république bananière : -1 D'abord, c'est toujours le même et pas les, et c'est celui qui explique (avec des messages trop longs) aux autres sans écouter leurs arguments et qui n'écoute la démocratie que sous la menace et tente trop souvent d'imposer son point de vue plutôt qu'opter pour la prudence du statu quo. Après ils se reconnaîtront, je viens de passer à ils le reconnaîtront -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] remappage *avant* suppression des données CEDRIC007
On mardi 27 novembre 2012, Ab_fab wrote: http://toolserver.org/~osm/locale/__all.html?zoom=11lat=50.36145lon=3.59047layers=B Ha ouais, top ! ça peut aider ça, le top du top serait que cette couche ne soit pas mise à jour et on n'aurait rien à faire de plus ;-) Sinon, ça se sauvegarde, même si wikimedia risque de tirer la tronche si on pompe 50k tuiles de leurs serveur -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Zones blanches
Le message suivant de : ## Je voudrais savoir si il est possible de créer une carte des zones blanches ADSL dans mon département. Comment cartographier ces zones et comment créer une carte dédiée ? a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bonsoir, Le 27/11/2012 18:21, sly (sylvain letuffe) a écrit : yo, HS(running gag :) je sens qu'on va encore être d'accord, ça devient pénible à force, heureusement qu'on a le wiki pour s'étriper/HS On mardi 27 novembre 2012, Pieren wrote: Je constate une lente (mais certaine) progression de l'usage d'un caractère typographique qui, amha, n'a rien à faire dans les tags name d'OSM. Je parle du tiret cadratin ou tiret long, unicode 0x2014. Exemples: http://www.openstreetmap.org/browse/relation/90341 Put... j'avais peur de re-re-passer pour un chieur à lancer le sujet, mais ce tiret m'a valu un échange vif (et bizarrement sans intérêt et trop long avec l'unique auteur de tous ces tirets) J'ai laissé tombé car ça me semblait futile. Mais c'est revenu sur la liste tagging : http://gis.19327.n5.nabble.com/Naming-boundary-ways-td5728863.html#a5729805 D'accord avec vous 2 sur le besoin de faire simple, et donc de propager des caractères disponibles simplement. HS ou presque En revanche, je suis tout à fait contre l'idée de coller un tag name à des limites administratives qui ne sont que des limites (et pas une route, ou une rivière par ex.). C'est essentiellement sur ces objets qu'on trouve les tirets cadratins, il ne faudra pas compter sur moi pour les remplacer par des tirets courts. Le seul sort que j'ai envie de réserver à ces tags, c'est la suppression. Je partage plusieurs points de vue exprimés sur tagging (merci Sly pour le lien vers ce fil). En substance : ne pas nommer ce qui ne porte pas de nom, quitte, à la rigueur, à placer sur un tag note=* la mention actuellement portée par name=*. Je connais les arguments sur le confort d'édition que ces noms apportent, mais je ne m'y range pas. / vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
