[Talk-cz] WeeklyOSM CZ 254
Ahoj, je dostupné vydání 254 týdeníku weeklyOSM: http://www.weeklyosm.eu/cz/archives/4042 Téma čísla: Poznámka není malér * Příběh zmizelé Dřevnice * Beta verze OpenAerialMap * Jak postupují práce na learnosm.org * Historie největších importů do OSM * Tři slova mohou stačit Pěkné počtení... ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk] Routing Applications
On Wed, Jun 17, 2015 at 09:00:37AM +, Janko Mihelić wrote: If you ask me, they are all in their infancy. Non of these routing services even route right. In a turn restriction the via role can be a way. Neither OSRM, ORS or GraphHopper knows how to restrict that, and that's IMHO one of the crucial parts of a routing engine. When one of them starts routing right, than we can talk about picking a winner service. Right now only MapQuest knows how to route. There is no such thing as a perfect routing engine. Every engine can be brought to its knees with some cluefully choosen endpoints. I am thankfull that we have the multitude of routing engines. At work i am using OSRM for calculating distance for telecoms infrastructure for which i am tuning the OSM dataset and calculate like 500K routes in a couple of minutes. On the mobile i am switching between OSMand and Mapfactor Navigator, but all of them refuse to route into a track even if its grade2 and your destination is at that track - FAIL. Routing home from work with mapquest gives me a route which is not that bad but can be beaten by 20% less travel time from a local. Thats just because everybody in this town knows that certain traffic lights are synced in a tricky manner. You cant put this into OSM. When looking at the bike route the route of mapquest is 1.5miles longer (4.6 - 6.2miles) than the Car route although there are cycle tracks in the map along ALL roads taken. There is even a shorter route using tracks in the wood but mapquest does not use them for bikes it seems. So a quick test with carefully chosen endpoints produces less then optimal solutions for ANY routing engine. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Regionale Ansprechpartner für openstreetmap.de gesucht
Hallo, Dietmar schrieb: 3. ein Anrufer vermisst im Landkreis Schweinfurt noch Buslinien, ist aber noch Mapper. Den habe ich davon abgeraten, mal eben sowas einzutragen und angeboten, das ich einen lokalen Mapper für ihn finde, dem er entweder angeben kann, was fehlt, damit der Mapper das ergänzt oder der ihm bei den ersten Mapping-Schritten helfen kann. Also zumindest im südlichen Landkreis scheint die Abdeckung gar nicht so schlecht zu sein, im Nördlichen ist dagegen eher das Gegenteil der Fall. Die Buslinien-Relationen in der Stadt Schweinfurt wurden zum großen Teil von mir selbst erstellt. Insofern darf mich der Mapper gerne mal kontaktieren, wenn er möchte. Grüße, Michael signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-co] Talleres de mapeo en Crisis pro-salgar en Bogotá y Medellín.
Vamos poco a poco pero seguros con la tarea #14, adicionalmente a los talleres del fin de semana, esa mañana se envió mensaje de apoyo a la lista del Equipo Humanitario de OpenStreetMap (HOT), de 14% la tarea va ahora por el 18%. http://tareas.openstreetmap.co/project/14 Salgar requiere tu ayuda, gracias por sus contribuciones! El 12 de junio de 2015, 14:40, Fredy Rivera fredyriv...@gmail.com escribió: Hola El día de mañana (Sabado 13) se realizarán sendos talleres de cartografía pro-Salgar en Bogotá y Medellín. El de Bogotá será nuevamente en hackBo con la monitoría de Oscar Ramos prantolima cupo limitado para 12 persona entrada libre previa inscripción en http://milfs.redhumus.org/?id=3 El de Medellín será en Proyecto NN http://www.proyectonn.com/ a las 10:00 y lo coordinaré yo (humano) :-) . Espero que puedan asistir, nos enfocaremos en la tarea 14 http://tareas.openstreetmap.co/project/14# Salu2 Humano. -- ## |___|__\___ | _ | |_ | } (_) (_) Twitter: @fredy_rivera Phone USA: (347) 688-4473 Mobil telephone: +57 3044886255 ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [OSM-talk-fr] [Hot-francophone] Orfeo Tool box , Satellite Sentinelle
Le 13/06/2015 19:20, Frederic Moine a écrit :
Pour ma part je vais surement aller faire des points du côté des
écrins et de Barcelonnette en France.
Bonsoir Frédéric,
Tu penses venir quand du côté de Barcelonnette ?
Du 8 au 10 juillet se tient {UDOS} 2015, l'Université d'été du
développement de logiciel libre et open source à Digne.
Avec une conférence de Jean-Louis Zimmermann spéciale collectivités
http://www.udos.fr/mini-conf-openstreemap.html
et une Session technique OpenStreetMap et environnements géographiques
open source
http://www.udos.fr/openstreetmap.html
Si tu passes à un autre moment, préviens toujours, ça peut être une
occasion de croiser des contributeurs locaux.
Librement
JCB
--
Des formats ouverts pour des données libres
http://www.apitux.org/index.php?2006/07/09/107-des-formats-ouverts-pour-des-donnees-libres
==APITUX : le choix du logiciel libre==
APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com/
SIRET : 452 887 441 00031 - APE : 6202A
===
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Routing Applications
On Wed, Jun 17, 2015 at 05:55:18PM +0100, Philip Barnes wrote: On Wed, 2015-06-17 at 09:00 +, Janko Mihelić wrote: If you ask me, they are all in their infancy. Non of these routing services even route right. In a turn restriction the via role can be a way. Neither OSRM, ORS or GraphHopper knows how to restrict that, and that's IMHO one of the crucial parts of a routing engine. When one of them starts routing right, than we can talk about picking a winner service. Right now only MapQuest knows how to route. Janko The other common thing that is missing from routing instructions is support for mini-roundabouts, tomtom certainly don't do this so it is something that OSM routing could pull ahead on. mini_roundabouts are a clear mis-design in OSM - I avoid and dont use them at all. There is no way without heavy preprocessing that a router can create a circular path from a point/node. Instead we should have had a tag which states that the center of the roundabout can be ridden/driven over. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] getmap in osm mode
On 6/17/2015 10:41 AM, Daniel Koć wrote: getmap works with so called public static image APIs, which are provided by Mapquest and Google. AFAIR, OSM does *not* provide such an API - at least at last time I checked. But, I've read that OSM now provides direct routing. If they would also provide an static image API, ... ;-) So what about that public static image APIs - do we have it (or will we some day)? OSM doesn't provide APIs except the editing API*. The routing on osm.org is from third-party providers using OSM data. I believe MapQuest Open has a static image API like MapQuest.com, except using OSM data globally. That would probably be very easy for them to implement, as it would basically reuse their existing MapQuest code. There is the /cgi-bin/export endpoint on the tile servers, but that is not suited for an application like this. * And arguably tile.osm.org ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-ca] OSM data quality in Canada
Hello list — My name is Martijn van Exel, I am on the OSM US board and work at Telenav. I’ve written to this list a few times before, but this time I am doing so with my Telenav hat on. Perhaps you know that we have the Scout apps (iOS, Android) which run on OSM data. (If you haven’t yet, please give Scout a try some time and let me know what you think!) We are always looking into ways to make significant contributions to OSM, in the US, Canada and elsewhere. We’re starting to look into Canada more, and I could really use your help with a few key questions: * What is the imports history, particularly in relation to road network, POIs and addresses? (Beyond what’s in the import catalogue page on the wiki, if anything) * What external (government and otherwise) open geospatial data sources are out there that have been or may be considered for improving OSM? * Are there any Canada-specific mapping and tagging conventions? * Are there any known big (national) issues in the Canadian OSM data? (misguided imports / bots, major tagging disputes, that kind of thing) * Which (other) companies / organizations / government agencies use OSM data for Canada? * Any suggestions for QA tools that would help the community, either existing or new? I’m happy to discuss on-list or off. Thanks! Martijn ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk] [Talk-ko] OSM and CartoDB in use for MERS mapping
Well, It is especially notable since it was created while S.Korea gov refused to publish the name of medical facilities. Then someone got the map data from OSM and analyzed the known facts (somehow), then created the page with the map. ps. I see my contribution, too! (I created a node which is now identified as MERS-infected.) -- Revi https://www.revi.pe.kr -- Sent from Android -- 2015. 6. 17. 오후 1:06에 Andrew Errington erringt...@gmail.com님이 작성: Sorry, slight correction. It's a map of medical facilities, not cases. Apologies for any alarm caused. Andrew On 17 June 2015 at 12:18, Andrew Errington erringt...@gmail.com wrote: Hello, You may have heard of the MERS situation in Korea. A map of cases and their location has been published here: http://issue.visualdive.co.kr/mers/ I am pleased to see that OSM is the background layer (I recognised some of my work). It's notable because Korea does have very good map coverage from Google, and local companies Daum and Naver, so there are several sources to choose from. It's possible that it was chosen due to the fact that that webpage needed to show statistics outside Korea, which Daum and Naver does not cover. Best wishes, Andrew ___ Talk-ko mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ko ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Précision des données culture.gouv
Ok, Merci pour ta réponse Et ne serai-t-il pas judicieux de prendre les adresses qui ne sont pas encore répercuté en refaisant un nouveau géocodage? Y a-t-il une page wiki avec les suivi des données chargés sur Osmose? Ça pourrait être intéressant (ne serait-ce que pour le suivi) Le 18 juin 2015 00:10, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 14/06/2015 10:35, ades_...@orange.fr a écrit : Normalement toutes les entrées de la base Mérimée sont géolocalisées (points et surfaces, plutôt très précis, RGF93), même si ça n’apparait pas sur le site culture.gouv.fr http://culture.gouv.fr. C’est vérifiable là : http://atlas.patrimoines.culture.fr/atlas/trunk/ (même si l’ergonomie est douteuse…) et il y a d’autres données, règlementaires celles-là, concernant le patrimoine (abords des MH, ex ZPPAUP, secteurs sauvegardés, etc.). Ce pourrait être une bonne chose de récupérer directement ces données (ou de les faire libérer) auprès du (par le) ministère. Un boulot pour asso fr ? ps pour les localisations actuelles sur OSM je crois avoir compris que ça vient de Wikipédia, mais je ne crois pas que ça avait été obtenu directement du ministère, plutôt par un travail à partir des adresses ? Je crois qu’il y a eu un fil là-dessus (il y a plusieurs années) Les données actuelles d'Osmose viennent de l'opendata sans localisation, complété par wikipedia pour avoir les liens uniquement et géocodé par adresse avec nominatim à une époque fort lointaine pré-bano. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-ca] OSM data quality in Canada
Unrelated, but I noticed that talk-ca is not archived on Nabble yet - this makes it hard to share and follow a conversation as a non-subscriber. I don’t know what’s involved in adding this list or if anyone would object? Martijn On Jun 17, 2015, at 4:47 PM, Martijn van Exel m...@rtijn.org wrote: Hi Andrew, Thanks for elaborating on the CanVec / Geobase imports! This also raises new questions.. See below. On Jun 17, 2015, at 3:00 PM, Andrew MacKinnon andrew...@gmail.com wrote: A lot of the data in Canada was imported from CanVec and Geobase, some of it by me several years ago. The imported data is pretty poor quality in many places. I haven't done much work on this recently, as imports have a bad reputation in OSM and I am mostly concerned with surveying. For example: - Some older road data comes from an import which combined CanVec and Statistics Canada road names, attempting to match the road names in Statistics Canada with roads without names from CanVec, and this data is poor quality. Is this described in more detail anywhere? Are the data / scripts / process still available? Which dat was poor quality, CanVec or Statistics Canada? - Road data in some areas is missing entirely. This is probably easy to visualize, but do you happen to know where / why? - The CanVec address data is low quality, and is often broken - e.g. on a tile boundary address ranges will be split in half, and comes from several different versions of CanVec. - Other CanVec layers such as woods, lakes and so on were imported in some areas but not others. Much of this data is low quality. Was some sort of progress page kept so we could see where certain features were imported or not (yet)? Has a followup ever been considered to augment / fix these botched / low quality imports? - Some road names have too many spaces e.g. John Street is John Street. Some address ranges are like that as well. - lanes=-1 and surface=unpaved for roads that are really paved in Quebec. - Better quality municipal GIS datasets are now available in some cities like Toronto, Peel Region and York Region and if they are properly licensed, these should be used whenever possible. There generally are some minor errors in these datasets, but they are far better quality than CanVec/Geobase. Ah, interesting. Is there already a list of these candidates or would it make sense to start one and look into proper licensing? I really like the TO-FIX Tiger Delta layer at http://osmlab.github.io/to-fix/#/task/tigerdelta which matches TIGER data with OSM data and tries to find errors. It would helpful if a similar tool were created for Canada. Obviously I am partial to MapRoulette, but sure, let me check it out, I am sure we can come up with something similar for Canada. What would the reference data be instead of TIGER? Again, thanks for your insights, Andrew. Martijn ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] OSM data quality in Canada
See http://wiki.openstreetmap.org/wiki/CanVec. CanVec data was converted to OSM format and is stored at http://ftp2.cits.rncan.gc.ca/OSM/pub/, and is split into files based on the National Topographic System, and then data was imported in some parts of Canada by manually cutting and pasting data from these files into JOSM. I did this in a large part of southern Ontario and some other users have done this as well. Importing CanVec data this way and correcting all the errors is tedious and hasn't been completed for all of Canada, and I haven't done very much with this for several years. Before this was done there were more primitive imports done, perhaps around 2008-2009 or so, and these imports are extremely low quality. I can't remember which OSM user did this. When OSM was new there was not much data in OSM, so a lot of imports were done and many of these imports were poor quality; now that OSM is more mature, imports are increasingly viewed unfavourably and there is a general attitude that data should be collected by surveying whenever possible. It would probably be best to use the newest version of the Geobase National Road Network (http://www.geobase.ca/) and compare this to the data in OSM and make corrections that way. Keep in mind that this data has errors and municipal datasets (where available) are always better quality. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] OSM data quality in Canada
Also see Ordinance Survey Locator Musical Chairs http://wiki.openstreetmap.org/wiki/OS_Locator_Musical_Chairs and http://ris.dev.openstreetmap.org/oslmusicalchairs/map for a comparison tool comparing UK Ordinance Survey data with OSM data, similar to the TIGER fixup tool. On Wed, Jun 17, 2015 at 7:10 PM, Andrew MacKinnon andrew...@gmail.com wrote: See http://wiki.openstreetmap.org/wiki/CanVec. CanVec data was converted to OSM format and is stored at http://ftp2.cits.rncan.gc.ca/OSM/pub/, and is split into files based on the National Topographic System, and then data was imported in some parts of Canada by manually cutting and pasting data from these files into JOSM. I did this in a large part of southern Ontario and some other users have done this as well. Importing CanVec data this way and correcting all the errors is tedious and hasn't been completed for all of Canada, and I haven't done very much with this for several years. Before this was done there were more primitive imports done, perhaps around 2008-2009 or so, and these imports are extremely low quality. I can't remember which OSM user did this. When OSM was new there was not much data in OSM, so a lot of imports were done and many of these imports were poor quality; now that OSM is more mature, imports are increasingly viewed unfavourably and there is a general attitude that data should be collected by surveying whenever possible. It would probably be best to use the newest version of the Geobase National Road Network (http://www.geobase.ca/) and compare this to the data in OSM and make corrections that way. Keep in mind that this data has errors and municipal datasets (where available) are always better quality. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] OSM data quality in Canada
Hi Andrew, Thanks for elaborating on the CanVec / Geobase imports! This also raises new questions.. See below. On Jun 17, 2015, at 3:00 PM, Andrew MacKinnon andrew...@gmail.com wrote: A lot of the data in Canada was imported from CanVec and Geobase, some of it by me several years ago. The imported data is pretty poor quality in many places. I haven't done much work on this recently, as imports have a bad reputation in OSM and I am mostly concerned with surveying. For example: - Some older road data comes from an import which combined CanVec and Statistics Canada road names, attempting to match the road names in Statistics Canada with roads without names from CanVec, and this data is poor quality. Is this described in more detail anywhere? Are the data / scripts / process still available? Which dat was poor quality, CanVec or Statistics Canada? - Road data in some areas is missing entirely. This is probably easy to visualize, but do you happen to know where / why? - The CanVec address data is low quality, and is often broken - e.g. on a tile boundary address ranges will be split in half, and comes from several different versions of CanVec. - Other CanVec layers such as woods, lakes and so on were imported in some areas but not others. Much of this data is low quality. Was some sort of progress page kept so we could see where certain features were imported or not (yet)? Has a followup ever been considered to augment / fix these botched / low quality imports? - Some road names have too many spaces e.g. John Street is John Street. Some address ranges are like that as well. - lanes=-1 and surface=unpaved for roads that are really paved in Quebec. - Better quality municipal GIS datasets are now available in some cities like Toronto, Peel Region and York Region and if they are properly licensed, these should be used whenever possible. There generally are some minor errors in these datasets, but they are far better quality than CanVec/Geobase. Ah, interesting. Is there already a list of these candidates or would it make sense to start one and look into proper licensing? I really like the TO-FIX Tiger Delta layer at http://osmlab.github.io/to-fix/#/task/tigerdelta which matches TIGER data with OSM data and tries to find errors. It would helpful if a similar tool were created for Canada. Obviously I am partial to MapRoulette, but sure, let me check it out, I am sure we can come up with something similar for Canada. What would the reference data be instead of TIGER? Again, thanks for your insights, Andrew. Martijn ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[OSM-talk] Response to discussion about OSM and local mappers article
I’m really glad to see all this discussion sparked by my post, which I have enjoyed reading. I’m sorry I wasn’t on this list to reply directly to many posts. (My article is here in case you did not see https://medium.com/@ricaji/openstreetmap-mapping-power-to-the-people-e938c38da93d https://medium.com/@ricaji/openstreetmap-mapping-power-to-the-people-e938c38da93d) First of all, I did not title the article “arguments against remote mapping” for a reason. It’s not my axe to grind. Someone said the article is more “for” local mapping than against remote which is true. My background is in international development and that is how I’ve approached the possibilities of OSM as well. There are plenty of times when remote mapping is a good thing... The question for me is more about how to prioritize and distinguish when and where and how to integrate this so that it increases the profile and abilities of local groups in a real way. Someone said, we don’t want to exclude mappers because of poverty - that’s what I’m talking about. There are quite a few parallels in development/aid work where foreigners tend to organize things for locals when they should be listening/ allowing local leadership more. That’s where I’m coming from. The growing efforts by HOT and Missing Maps and others are a very positive development, I do not mean to imply otherwise. But while something like Missing Maps may have a 50/50 intent, but the realities of international development and humanitarian work are such that it requires a lot more effort/resources for one 50 than the other, and with a lot less reward in terms of funding or public attention. As such, we need to generate much more support for, discussion of, and thinking around this process of engaging, organizing, supporting, funding, maintaining the interest of local mappers (while outside mappers are playing the supporting role that they should) in order to help them gain a higher profile and leadership. That to me is a broader membership discussion I’d rather see than arguing about remote mapping. It is also an opportunity since there is a spotlight on the remote volunteer mappers lately. They’re also looking to learn and understand far away places. Someone wrote: We need to encourage local mapping, but large-scale disasters create a need for immediate maps, which, in some cases, means outside help is needed.” This is true. But with such large scale disasters comes funding for mapping in other places which still has the needs of the international community as its focus. There’s an inevitability to the process and how it’s done which seems a bit premature. To me it’s important to keep up the variety and creativity as well as critical thinking about how we approach difficult topics like mapping with very vulnerable people. I was also hoping to highlight the longer term community building needed and talk about that. I’m not sure if OSMF is the right place to bring this or not, and if not, where? Well, I like a good debate, so I’m happy to see this and also to talk to anyone about any of this so feel free to contact me directly! ___ Erica Hagen GroundTruth Initiative http://groundtruth.in/ +1 773 313 5782 Map Kibera http://mapkibera.org/ | OpenSchoolsKenya http://openschoolskenya.org/ Check out my new talk from TEDxGateway here! Mapping the Slums https://www.youtube.com/watch?v=lVkyBf_TM9sfeature=youtu.be ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Some thoughts against remote mapping
On Tue, Jun 16, 2015 at 4:07 AM, moltonel 3x Combo molto...@gmail.com wrote: What I've been mulling over is the home location data on the profile. Right now it's close to useless. I'd like to be able to set multiple areas (not points) and rate them can survey / good local knowledge / particularly interested. ^^^ This is an excellent idea and a feature I would definitely use. Also, this thread is of great interest to me, but I'm entering it quite late and many points have already been discussed. I'll just say a few things: 1) I am thankful to Erica Hagen for her original post, as I think these are critical things to think about. 2) Hagen's point that there are degrees of local that we are failing to account for reminds me of many discussions I've had in my own community about what it means to be from a place, whose voices are viewed as representative of a neighborhood, who has access to power, etc. While much of the discussion here has been in the context of international/humanitarian mapping, these same questions play out on a micro scale in cities and neighborhoods. It is worth thinking about who is mapping in your own community and whether you are working to involve neighborhood residents, do offline outreach, etc. at home. Thanks, Eleanor ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Regionale Ansprechpartner für openstreetmap.de gesucht
Hallo Michael, hallo die anderen Poster zum Thema, vorab zum Thema 3. Umgebung Schweinfurt. Da leite ich die Mail an Dich, Michael Bemmerl, weiter, wenn sie kommt. Er meinte, er kommt erst morgen dazu, sie zu schreiben. vorab zum Thema 4. Privatstraße im Dresdener Umfeld: ich habe eben die Mail erhalten, es ist ein geteerter Wegabschnitt auf ihrem Grundstück und danach folgt ein Feldweg. Ich habe jetzt nochmal nachgefragt, was wie noch erlauben will, wenn überhaupt und wo ihr Grundstück konkret ist. Aktuell sind die Einstellungen ausreichend, das motor_vehicle nicht mehr darüber routet, aber es scheint so, das auch Radfahrer dort nicht fahren sollen und sie hat das Recht dazu, nein zu sagen. Ansonsten vier Antworten (mit Dietmar: gekennzeichnet) zu Michaels Post im einzelnen weiter unten. viele Grüße Dietmar Am 17.06.2015 um 17:16 schrieb Michael Reichert: Hallo Dietmar, Am 2015-06-17 um 16:09 schrieb Dietmar: Ich fände es gut, wenn a) sich aus den aktiven Communities jeweils eine Person findet, die dort genannt werden darf (bitte eine Mail an mich mit den Details, ich lasse das dann eintragen) b) oder, wenn jemand dort nicht öffentlich stehen will, aber im konkreten Fall ein Anliegen annehmen will, ich seine/ihre Mail oder Telefonnummer bekomme, um diese wahlweise an den Anrufer weiterzugeben oder den Kontakt indirekt vermittle. An welche Ansprechpartnerdichte denkst du denn? Einer pro Landkreis ist IMHO Overkill, da können wir gleich ein Callcenter eröffnen :-) Einer pro Bundesland (große/bevölkerungsstarke ggf. mehr) könnten es jedoch schon sein. Derzeit stehen dort Ansprechpartner für Augsburg, Ruhrgebiet, Hessen (Wiesbaden/Frankfurt), Saarland/Trier und Österreich. Dietmar: Hauptsache, es melden sich welche. Die Großstädte oder deren Umgebung sollten schon vorhanden sein, wenns geht. München, Stuttgart, Karlsruhe, Köln/Bonn, Hannover, Hamburg, Kiel, evtl. Lübeck, Kassel/Göttingen, Dresden, Berlin, Schwerin/Rostock. Irgendeine bessere Abdeckung als bisher, zumindest für jedes Bundesland wäre schon mal schön. Ich arbeite meist zuhause, die bisherigen Anrufe kamen meist während der normalen Arbeitszeit, ich habe überhaupt kein Problem, die Anrufe anzunehmen, wenn ich bei lokalen Themen keinen großen Aufwand habe, die weiterzureichen. Wenn sich für ein Gebiet niemand findet, werde ich natürlich versuchen, über lokale Mailinglisten das jeweilige Anliegen zu adressieren, aber ich bin nur auf wenigen drauf und das macht mir natürlich den größten Aufwand und das wollt Ihr doch sicher nicht, oder? ;) Oder man definiert für die nächstgelegenen Nachbarn einfach ein größeres Gebiet. Wenn also z.B. sich kein Leipziger findet, dann steht beim Dresdner Ansprechpartner nicht Dresden, sondern Sachsen oder Mitteldeutschland. Dietmar: wenn sich jemand meldet, kann er/sie natürlich definieren, welches Gebiet da stehen soll. Ein ganzes Bundesland wäre auch kein Problem, wenn die Person vernetzt ist mit den Communities in der Umgebung über Mailinglisten oder persönliche Kontakte. Damit Ihr wisst, was da so ankommt: 1. Anfrage einer Werbeagentur, ob/wie sie einen OSM-Kartenausschnitt für einen Flyer verwenden darf 2. hey, ein Augsburger, der eine Website betreibt und eine Abmahnung bekommen hat, weil er eine gedruckte Karte gescannt auf der Website verwendet hat und jetzt nach OSM wechseln will. 3. ein Anrufer vermisst im Landkreis Schweinfurt noch Buslinien, ist aber noch Mapper. Den habe ich davon abgeraten, mal eben sowas einzutragen und angeboten, das ich einen lokalen Mapper für ihn finde, dem er entweder angeben kann, was fehlt, damit der Mapper das ergänzt oder der ihm bei den ersten Mapping-Schritten helfen kann. 4. eine Anruferin aus Dresden, die in einer Privatstraße wohnt, bei der Leute durchfahren und einer hat ihr gesagt, er würde mit einer OSM Software da durchrouten. Für die Anliegen 3 und 4 werde ich vorauss. noch eine Mail erhalten mit Detailinfos und Kontaktdaten und hätte schon mal gerne jemanden, der da aktiv werden könnte. Das Team der Wochennotiz hat ja auch eine öffentliche Mailadresse, die gleichzeitig die teaminterne Mailingliste ist. Wir haben vor einigen Monaten auf unserer Kontaktseite folgenden Hinweis ergänzt: https://blog.openstreetmap.de/kontakt/ schreibt: Hinweise für die Wochennotiz oder Fragen rund um das Blog nehmen wir gerne entgegen. Für andere Fragen gibt es eine Vielzahl von Webseiten (OSM-Wiki, FAQ) und Foren, die helfen könnten. Dietmar: ich hatte bisher den Eindruck, die wollen das eher alle schnell per Telefongespräch machen, das waren in den drei priaten Fällen eher Personen 50+, die sind alle willens, am Ende des Gesprächs ihr Anliegen noch per Mail zu verfeinern, aber ein Hinweis auf posten in Foren und anmelden auf Mailinglisten oder auch nur das raussuchen, welche die richtige ist, können wir nicht erwarten, das ist eine zu hohe Startschwelle für diesen Kreis, die sich melden., Einen kleinen Zusatztext,
Re: [Talk-hr] Sedmi HR-OSGeo Meetup - 18. 06. 2015.
od mene nazalost nista, klinac bas tad ima rodjendanski tulum On Tue, Jun 09, 2015 at 08:11:54PM +, Janko Mihelić wrote: Mogao bih se pojaviti. Čak me zanima ovo D3.js predavanje. uto, 9. lip 2015. 21:51 hbogner hbog...@gmail.com je napisao: U četvrtak, 18. 06. 2015. održat će se sedmi HR-OSGeo Meetup. Pripremljena su dva predavanja: Tomislav Muic – Hello 3D world i Tomislav Bacinger - How can D3.js fulfill all your cartographic desires. Više informacija o događaju možete saznati na http://www.meetup.com/HR-OSGeo/. Molimo Vas da vaš dolazak potvrdite na Meetup servisu, kako bi imali okvirni broj sudionika. Predavanja su ovaj put više usmjerena prema development zajednici, ali poslje predavanja bi mogli održati i OSM druženje za one koji nisu zainteresirani za predavanja. Šta vi kažete? ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
[Talk-it] osmand 2.1
hanno rilasciato la nuova versione di osmand, eliminato il bug per la creazione dei pdi ;)___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-ca] OSM data quality in Canada
A lot of the data in Canada was imported from CanVec and Geobase, some of it by me several years ago. The imported data is pretty poor quality in many places. I haven't done much work on this recently, as imports have a bad reputation in OSM and I am mostly concerned with surveying. For example: - Some older road data comes from an import which combined CanVec and Statistics Canada road names, attempting to match the road names in Statistics Canada with roads without names from CanVec, and this data is poor quality. - Road data in some areas is missing entirely. - The CanVec address data is low quality, and is often broken - e.g. on a tile boundary address ranges will be split in half, and comes from several different versions of CanVec. - Other CanVec layers such as woods, lakes and so on were imported in some areas but not others. Much of this data is low quality. - Some road names have too many spaces e.g. John Street is John Street. Some address ranges are like that as well. - lanes=-1 and surface=unpaved for roads that are really paved in Quebec. - Better quality municipal GIS datasets are now available in some cities like Toronto, Peel Region and York Region and if they are properly licensed, these should be used whenever possible. There generally are some minor errors in these datasets, but they are far better quality than CanVec/Geobase. I really like the TO-FIX Tiger Delta layer at http://osmlab.github.io/to-fix/#/task/tigerdelta which matches TIGER data with OSM data and tries to find errors. It would helpful if a similar tool were created for Canada. On Wed, Jun 17, 2015 at 4:27 PM, Harald Kliems kli...@gmail.com wrote: A few things I can think of: On Wed, Jun 17, 2015 at 3:13 PM Martijn van Exel m...@rtijn.org wrote: * Are there any Canada-specific mapping and tagging conventions? - There seems to be a strong consensus that what elsewhere would be highway=unclassified is highway=residential, no matter if the road is in a populated area or not. * Are there any known big (national) issues in the Canadian OSM data? (misguided imports / bots, major tagging disputes, that kind of thing) I believe these mostly affect Quebec, but there are two import problems that never got systematically fixed, as far as I know: - CanVec import of highways where lanes=-1 and surface=unpaved. - CanVec or Geobase import where there is an extra blank between the street type designation and the name. E.g. Rue__Sherbrooke instead of Rue_Sherbrooke. Harald (now in the US) ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-br] Reunião - OSM Brasil 2015-06-17
Para conhecimento de todos, na reunião de hoje falamos sobre como organizações que tenham interesse em endereçamento na criação do projeto OpenAdrress Brasil, que por falta de outro nome chamarei assim por enquanto, tendo por referência o projeto internacional http://openaddresses.io. O Thierry relatou contatos feito com a associação de empresas de monitoramento de veículos cujo representante demonstrou interesse no processo, e perguntou o que fazer para envolver outras entidades (IBGE, Correio, etc.) e como dar o pontapé inicial no projeto. Neste ponto o Vitor levantou o problema da qualidade dos dados disponíveis para compor essa base e sugeriu a criação de um pré-projeto definindo o que constaria nessa base de endereços, níveis de informação e formas de uso/extração desses dados por parte dos usuários citando como exemplo o apontador.com.br, e sugerindo para carga inicial os dados de endereço disponível no OSM. Definiu-se que o projeto não tem como fim concorrer com o apontador, gmaps e outros nesse nicho mas sim ser um provedor de informação de endereço e todos concordaram que os endereços OSM podem compor a base inicial do projeto, onde o Thierry vai começar a compor textos e falar com seus contatos dando o processo como iniciado e tendo como apoiadores o OSM Brasil, http://codigourbano.org e outros que venham a aderir. As informações de tipo e nome de ponto comercial quando existirem não serão descartadas, mas sim comporão um conjunto de informações extras inerentes ao endereço. Após rápida discussão sobre a sugestão do Winnie de importar os dados do geolog-São Paulo para o OSM, em razão da complexidade e tempo, além de a informação não ter numeração de endereço optou-se por tentar incluir esse mapa como uma camada de edição ao OSM conforme foi feito com o IBGE. Sobre os dados do IBGE CNEFE, apesar de não serem de altíssima qualidade coloquei que neste ponto alguma informação é melhor que a realidade atual que é não ter nenhuma, mesmo no OSM temos diversas localidades que mal possuem nomeadas as Rodovias que as cortam e por isso devemos utilizar a camada IBGE para melhorar os dados do OSM. Quanto ao uso do CNEFE na base de endereços foi ponderado que o importante num primeiro momento é obter (Thierry) um compromisso do IBGE com uma licença ODBL ou equivalente, mesmo que executivos do IBGE se digam a favor da publicidade de dados, enquanto não houver uma licença formal podemos plantar uma bomba relógio no projeto com o uso dessa informação. Da mesma forma esta definido que a importação de dados do DNE dos correios esta descartada, até porque essa base não contém endereço e não seria relevante para o projeto. O CEP continua sendo uma informação importante mas não define o endereço, o endereço geográfico latitude/longitude acaba sendo mais relevante, especialmente para uso em roteirização. O Vitor estimou em 2 meses a montagem de uma versão alfa do projeto de endereços e vai tocar isso conforme disponibilidade, além de ter sugerido que as ações que envolvam o OSM sejam atualizadas no wiki: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil, especialmente o que diga respeito ao capítulo Brasil. Também relatou os encontros que teve nos EUA onde além da divulgação do OSM Brasil apresentou o projeto mapazonia: http://roads.mapazonia.org/ e o sobre o mapeamento de terras indígenas: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Terras_ind%C3%ADgenas Por último mas não menos importante ficou claro que será preciso algum tipo de apoio/patrocínio ( financeiro e/ou de recursos materiais e humano ) para o projeto pois a disponibilidade de hora/programação anda escassa. Abraços a todos ___ Reinaldo Neves Equação Informática (11) 3221-3722 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] Précision des données culture.gouv
Le 14/06/2015 10:35, ades_...@orange.fr a écrit : Normalement toutes les entrées de la base Mérimée sont géolocalisées (points et surfaces, plutôt très précis, RGF93), même si ça n’apparait pas sur le site culture.gouv.fr http://culture.gouv.fr. C’est vérifiable là : http://atlas.patrimoines.culture.fr/atlas/trunk/ (même si l’ergonomie est douteuse…) et il y a d’autres données, règlementaires celles-là, concernant le patrimoine (abords des MH, ex ZPPAUP, secteurs sauvegardés, etc.). Ce pourrait être une bonne chose de récupérer directement ces données (ou de les faire libérer) auprès du (par le) ministère. Un boulot pour asso fr ? ps pour les localisations actuelles sur OSM je crois avoir compris que ça vient de Wikipédia, mais je ne crois pas que ça avait été obtenu directement du ministère, plutôt par un travail à partir des adresses ? Je crois qu’il y a eu un fil là-dessus (il y a plusieurs années) Les données actuelles d'Osmose viennent de l'opendata sans localisation, complété par wikipedia pour avoir les liens uniquement et géocodé par adresse avec nominatim à une époque fort lointaine pré-bano. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] Road Surface Type Map
Does anyone know of a map that displays road surface type? If not maybe it been a good idea to request one from itomap. It would be a lot of help to mappers who map those tags. *Regards,* *Hans* *http://www.openstreetmap.org/user/TheDutchMan13 http://www.openstreetmap.org/user/TheDutchMan13* *Sorry for any misspellings* ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Reunião - OSM Brasil 2015-06-17
Excelente, Reinaldo, obrigado pelo relato. On Jun 17, 2015 6:17 PM, Reinaldo Neves rne...@equacao.com.br wrote: Para conhecimento de todos, na reunião de hoje falamos sobre como organizações que tenham interesse em endereçamento na criação do projeto OpenAdrress Brasil, que por falta de outro nome chamarei assim por enquanto, tendo por referência o projeto internacional *http://openaddresses.io http://openaddresses.io.* O Thierry relatou contatos feito com a associação de empresas de monitoramento de veículos cujo representante demonstrou interesse no processo, e perguntou o que fazer para envolver outras entidades (IBGE, Correio, etc.) e como dar o pontapé inicial no projeto. Neste ponto o Vitor levantou o problema da qualidade dos dados disponíveis para compor essa base e sugeriu a criação de um pré-projeto definindo o que constaria nessa base de endereços, níveis de informação e formas de uso/extração desses dados por parte dos usuários citando como exemplo o apontador.com.br, e sugerindo para carga inicial os dados de endereço disponível no OSM. Definiu-se que o projeto não tem como fim concorrer com o apontador, gmaps e outros nesse nicho mas sim ser um provedor de informação de endereço e todos concordaram que os endereços OSM podem compor a base inicial do projeto, onde o Thierry vai começar a compor textos e falar com seus contatos dando o processo como iniciado e tendo como apoiadores o OSM Brasil, http://codigourbano.org e outros que venham a aderir. As informações de tipo e nome de ponto comercial quando existirem não serão descartadas, mas sim comporão um conjunto de informações extras inerentes ao endereço. Após rápida discussão sobre a sugestão do Winnie de importar os dados do geolog-São Paulo para o OSM, em razão da complexidade e tempo, além de a informação não ter numeração de endereço optou-se por tentar incluir esse mapa como uma camada de edição ao OSM conforme foi feito com o IBGE. Sobre os dados do IBGE CNEFE, apesar de não serem de altíssima qualidade coloquei que neste ponto alguma informação é melhor que a realidade atual que é não ter nenhuma, mesmo no OSM temos diversas localidades que mal possuem nomeadas as Rodovias que as cortam e por isso devemos utilizar a camada IBGE para melhorar os dados do OSM. Quanto ao uso do CNEFE na base de endereços foi ponderado que o importante num primeiro momento é obter (Thierry) um compromisso do IBGE com uma licença ODBL ou equivalente, mesmo que executivos do IBGE se digam a favor da publicidade de dados, enquanto não houver uma licença formal podemos plantar uma bomba relógio no projeto com o uso dessa informação. Da mesma forma esta definido que a importação de dados do DNE dos correios esta descartada, até porque essa base não contém endereço e não seria relevante para o projeto. O CEP continua sendo uma informação importante mas não define o endereço, o endereço geográfico latitude/longitude acaba sendo mais relevante, especialmente para uso em roteirização. O Vitor estimou em 2 meses a montagem de uma versão alfa do projeto de endereços e vai tocar isso conforme disponibilidade, além de ter sugerido que as ações que envolvam o OSM sejam atualizadas no wiki: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil, especialmente o que diga respeito ao capítulo Brasil. Também relatou os encontros que teve nos EUA onde além da divulgação do OSM Brasil apresentou o projeto mapazonia: http://roads.mapazonia.org/ e o sobre o mapeamento de terras indígenas: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Terras_ind%C3%ADgenas Por último mas não menos importante ficou claro que será preciso algum tipo de apoio/patrocínio ( financeiro e/ou de recursos materiais e humano ) para o projeto pois a disponibilidade de hora/programação anda escassa. Abraços a todos ___ Reinaldo Neves Equação Informática (11) 3221-3722 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-in] Regionwise offline maps in OsmAnd
I noticed this too few days ago when I was planning to update India map. So I deleted India map and only downloaded Maharashtra map. Can you confirm how did you enable the Hindi/Marathi names in the map data? Is that built in now or is it a custom built map? Cheers, Onkar On Wed, Jun 17, 2015 at 7:12 PM, Yogesh योगि yog...@karnatakaeducation.org.in wrote: Hey everyone, Good news for OsmAnd users! Regionwise offline maps of India are now available for download directly from the app. May be they were available after the latest UI update but I gotta see it now when I tried to update my offline map data. The regions are split as per the admin boundaries of State(29) and UT regions(7)[1], so instead of downloading the whole India(200MB), users can get only the smaller size State's map which they need. Currently, although India map data is not as big as countries like Germany/France, this can still help users here considering the mobile data connectivity and the growing OSM mappers in India which may result in increased map data too. Also the Hindi rendering in OsmAnd looks great![2]. :) And going by the size of maps, including Maharastra, other south Indian states constitute more than 50% of Indian OSM data. Few UTs and most North-eastern states are less than one MB, may be because of their smaller area coverage and less mapping. I guess there are quite a few users of OsmAnd[3] here. For those who haven't heard of it yet, its a open-source map viewing and navigation application for offline(vector) and online(raster/tile) OSM maps. Its mainly used with offline vector maps(that have several advantages over raster/tile maps) and one of the very few open-source OSM apps which supports vector maps. OsmAnd is currently available for Android and iOS on Playstore[4]/F-droid[5] and on Appstore[6]. Get it now and see your contributed OpenStreetMap data in action! I've been using it for past one year and had submitted couple of pull requests few months back to include India regions in the app. [1]https://simple.wikipedia.org/wiki/India#Indian_states [2]http://i.imgur.com/nPZ9CyK.jpg [3]http://osmand.net/ [4]https://play.google.com/store/apps/details?id=net.osmand.plus [5]https://f-droid.org/repository/browse/?fdid=net.osmand.plus [6]https://itunes.apple.com/us/app/id934850257 cheers, -- Yogesh K S Sent from an Electronic Device ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Passion - Some people climb mountains - others write Free software. Don't ask why - the reason is the same. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [OSM-talk] Road Surface Type Map
On 18/06/2015 12:23 PM, Hans De Kryger wrote: Does anyone know of a map that displays road surface type? If not maybe it been a good idea to request one from itomap. It would be a lot of help to mappers who map those tags. OSMAnd has a function to display road surface... it does display the difference between asphalt, concrete and unpaved.. I don't know about others. Umm arr .. configure mapDetailsshow road surface .. it also has road quality, access restrictions ... and more. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Regionale Ansprechpartner für openstreetmap.de gesucht
sent from a phone Am 17.06.2015 um 17:58 schrieb Florian Lohoff f...@zz.de: Sobald da was von Privatweg - Durchfahrt verboten steht ist das was anderes. Anders kann ein nicht Ortskundiger Autofahrer ohne Navi das auch nicht erkennen. Wenn Durchfahrt verboten dabeisteht würde ich das auch erstmal akzeptieren, es gibt halt auch Schilder da steht nur Privatweg oder Privatstraße oder auch mit Zusatz Durchgang auf eigene Gefahr, gerade weil der Besitzer die Durchfahrt nicht verbieten darf (1) oder weil er die Benutzung freiwillig toleriert. Ich habe aber in Berlin Köpenick auch schon mal ein privates Tor gefunden, das einen öffentlichen Weg (Stichstraße zum Wasser) abgesperrt hatte (war allerdings offen), und daraufhin erfahren dass dort jahrelang abgesperrt war und das jetzt auf Betreiben der Stadt offen gehalten wird. Gruß Martin https://de.m.wikipedia.org/wiki/Wegerecht_(Sachenrecht) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Regionale Ansprechpartner für openstreetmap.de gesucht
On Wed, Jun 17, 2015 at 07:12:37PM +0200, Martin Koppenhoefer wrote: Wenn Durchfahrt verboten dabeisteht würde ich das auch erstmal akzeptieren, es gibt halt auch Schilder da steht nur Privatweg oder Privatstraße oder auch mit Zusatz Durchgang auf eigene Gefahr, gerade weil der Besitzer die Durchfahrt nicht verbieten darf (1) oder weil er die Benutzung freiwillig toleriert. Dann ist das eine Haftungsfrage aber eben keine die in die access tags gehört. Ich würde das in einen note packen und vielleicht ein paar mapillary bilder machen so das man das nochmal nachvollziehen kann. Ich habe aber in Berlin Köpenick auch schon mal ein privates Tor gefunden, das einen öffentlichen Weg (Stichstraße zum Wasser) abgesperrt hatte (war allerdings offen), und daraufhin erfahren dass dort jahrelang abgesperrt war und das jetzt auf Betreiben der Stadt offen gehalten wird. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Some thoughts against remote mapping
This Friday night I'm going to close out the quick, three question survey on remote mapping thread. If you haven't answered the survey already, go to https://www.surveymonkey.com/s/TRQYHFP to answer the three questions. Clifford On Tue, Jun 16, 2015 at 8:28 AM, Frederik Ramm frede...@remote.org wrote: Hi, On 06/15/2015 09:55 PM, john whelan wrote: Perhaps we need something like the HOT validation system in OSM more generally but I don't know how it would work. Locally OSM mappers have used a rich range of tags, I'd say about 25% other than highways didn't get rendered for one reason or another when they were initially tagged. On the German forum and mailing lists, occasionally newbies will pop up and say I've mapped this and that, could somebody have a look if everything is correct? Perhaps it could be as easy as setting a changeset tag review=yes please, and then a small web site listing changesets that have this tag and don't yet have a review discussion entry or something, so experienced mappers could look if there's something in need of review in their area. I'd be very careful to make sure this is voluntary; even a hint at a possible *mandatory* review process will immediately have everyone pointing out where this has got Google ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] getmap in osm mode
Out of curiosity - there is a getmap TeX package: http://www.ctan.org/tex-archive/macros/latex/contrib/getmap which can put the maps directly from the net using just the address. Currently it uses Google Maps and MapQuest, but not the other OSM maps we have, so I asked the author of getmap and here's what he reply to me: getmap works with so called public static image APIs, which are provided by Mapquest and Google. AFAIR, OSM does *not* provide such an API - at least at last time I checked. But, I've read that OSM now provides direct routing. If they would also provide an static image API, ... ;-) So what about that public static image APIs - do we have it (or will we some day)? -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] OSM data quality in Canada
If this is the consensus, I've been blissfully unaware and the wiki needs to be updated. The Canadian tagging guidelines (https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Regional_roadways_.28below_provincially_controlled.29) recommend using unclassified when not in residential areas, and that's how I've been tagging. The CANVEC imports generally use residential as you describe which has led to a lot of mis-tagged highways, but I wouldn't say this is a consensus agreement that this is how we want it to be. It’s just how the data was imported. I'm gradually re-tagging such highways in my area, but there's a lot that need to be fixed across very large areas and not many people working on it. Andrew Lester Victoria, BC, Canada From: Harald Kliems [mailto:kli...@gmail.com] Sent: Wednesday, June 17, 2015 1:27 PM To: Martijn van Exel; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] OSM data quality in Canada A few things I can think of: On Wed, Jun 17, 2015 at 3:13 PM Martijn van Exel m...@rtijn.org mailto:m...@rtijn.org wrote: * Are there any Canada-specific mapping and tagging conventions? - There seems to be a strong consensus that what elsewhere would be highway=unclassified is highway=residential, no matter if the road is in a populated area or not. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] OSM data quality in Canada
A few things I can think of: On Wed, Jun 17, 2015 at 3:13 PM Martijn van Exel m...@rtijn.org wrote: * Are there any Canada-specific mapping and tagging conventions? - There seems to be a strong consensus that what elsewhere would be highway=unclassified is highway=residential, no matter if the road is in a populated area or not. * Are there any known big (national) issues in the Canadian OSM data? (misguided imports / bots, major tagging disputes, that kind of thing) I believe these mostly affect Quebec, but there are two import problems that never got systematically fixed, as far as I know: - CanVec import of highways where lanes=-1 and surface=unpaved. - CanVec or Geobase import where there is an extra blank between the street type designation and the name. E.g. Rue__Sherbrooke instead of Rue_Sherbrooke. Harald (now in the US) ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] Précision des données culture.gouv
Ce serait peut-être mieux de demander au ministère de « libérer » les coordonnées, puisqu’elles existent et sont précises, plutôt que de refaire une approximation ;-) j’avais raté sur l’atlas du patrimoine que l’on pouvait importer un shp, mais vu l’ergonomie du site… et vu ma fainéantise je m’étais contenté des fichiers d’impression… j’ai jeté un coup d’œil à la licence et je n’ai rien compris …question pour des spécialistes d’osm… Le 18 juin 2015 à 00:39, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Ok, Merci pour ta réponse Et ne serai-t-il pas judicieux de prendre les adresses qui ne sont pas encore répercuté en refaisant un nouveau géocodage? Y a-t-il une page wiki avec les suivi des données chargés sur Osmose? Ça pourrait être intéressant (ne serait-ce que pour le suivi) Le 18 juin 2015 00:10, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : Le 14/06/2015 10:35, ades_...@orange.fr mailto:ades_...@orange.fr a écrit : Normalement toutes les entrées de la base Mérimée sont géolocalisées (points et surfaces, plutôt très précis, RGF93), même si ça n’apparait pas sur le site culture.gouv.fr http://culture.gouv.fr/ http://culture.gouv.fr http://culture.gouv.fr/. C’est vérifiable là : http://atlas.patrimoines.culture.fr/atlas/trunk/ http://atlas.patrimoines.culture.fr/atlas/trunk/ (même si l’ergonomie est douteuse…) et il y a d’autres données, règlementaires celles-là, concernant le patrimoine (abords des MH, ex ZPPAUP, secteurs sauvegardés, etc.). Ce pourrait être une bonne chose de récupérer directement ces données (ou de les faire libérer) auprès du (par le) ministère. Un boulot pour asso fr ? ps pour les localisations actuelles sur OSM je crois avoir compris que ça vient de Wikipédia, mais je ne crois pas que ça avait été obtenu directement du ministère, plutôt par un travail à partir des adresses ? Je crois qu’il y a eu un fil là-dessus (il y a plusieurs années) Les données actuelles d'Osmose viennent de l'opendata sans localisation, complété par wikipedia pour avoir les liens uniquement et géocodé par adresse avec nominatim à une époque fort lointaine pré-bano. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Road Surface Type Map
On 2015-06-18 04:23, Hans De Kryger wrote: Does anyone know of a map that displays road surface type? If not maybe it been a good idea to request one from itomap. It would be a lot of help to mappers who map those tags. Itomap has one: http://www.itoworld.com/map/215?lon=0lat=51.5zoom=11fullscreen=true Regards, Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [talk-ph] Renaming BDO branches (planned mechanical edit)
Dear Ian, Looks sensible to me. Are you doing this using an automated method (i.e. script) or manually reviewing all ~400 BDOs? On Wed, Jun 17, 2015 at 2:08 PM, ianlopez ian_lopez_1...@yahoo.com wrote: Last March 21, malenki made an edit on various Philippine banks [1]. In that changeset, he attempted to standardize tagging for BDO branches by renaming them to “Banco de Oro, among other changes. I intend to rename banks tagged as name=“Banco de Oro” (using the tag name=BDO), since they are branded as such [2], in which malenki agrees[3]. Not only that, this is an attempt to make the name tag for BDO branches consistent. Thus, the need for a mechanical edit to make the needed changes. Affected areas: Places with a BDO branch. Based on an Overpass turbo query, there are 410 branches in OpenStreetMap[4]. Planned tagging schema for BDO branches: amenity=bank name=BDO operator=BDO Unibank alt_name=Banco de Oro Optional tags atm=yes branch= [name of branch] (if previously added) address tags opening_hours= [time the branch is open] (if previously added) How will I edit: I got an OSM data extract of BDO branches in many parts of the country via overpass turbo. I intend to create 31 changesets for this edit: * two for Mindanao (Zamboanga Peninsula, Basilan, Sulu, Taw-Tawi, Northern Mindanao, Lanao del Sur and CARAGA; Davao Region, SOCCSKSARGEN and Maguindanao) * two for Visayas (Boracay, Panay and Negros; Cebu, Bohol, Samar and Leyte) * one for Palawan * four for Southern Luzon (Bicol; Laguna and Quezon; Batangas; Cavite) * fourteen for Metro Manila and Rizal (Parañaque [south of NAIA], Las Piñas and Muntinlupa; Parañaque [west of NAIA] and Pasay; Makati; Fort Bonifacio area, Taguig and Pasig [south of Pasig River/Napindan Channel]; Pasig [north of Pasig River/Napindan Channel]; Cainta, Taytay and Angono; Marikina and Antipolo; Mandaluyong and San Juan; Quezon City [District 4; Districts 2, 5 and 6; Districts 1 and 3]; Manila [north of Pasig River; south of Pasig River and Santa Ana]; Caloocan, Malabon, Navotas and Valenzuela) * eight for Northern and Central Luzon (Bulacan; Pampanga; Bataan and Zambales; Nueva Ecija and Tarlac; Pangasinan; La Union and Benguet; Isabela and Cagayan; Ilocos Provinces and Abra) I also intend to add, change (short_name=BDO to name=BDO; name=Bdo to name=BDO) and remove some tags in the process (type=*, osm_id=*, designation=* among others) Planned edit date: June 26, 2015 Feel free to make comments/suggestions concerning my planned mechanical edits in this thread. [1] http://www.openstreetmap.org/changeset/29637953 [2] per a changeset comment in [1], he states that You are quite welcome to do so., referring to the plan to rename the elements tagged as Banco de Oro to BDO [3] see https://www.bdo.com.ph/about-bdo/business-operation (alternate copy at https://web.archive.org/web/20150501072847/https://www.bdo.com.ph/about-bdo/business-operation ) [4] http://overpass-turbo.eu/s/9Yp - Blog: http://ianlopez1115.wordpress.com/ OpenStreetMap/Twitter: ianlopez1115 Facebook: ian.lopez ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden https://epsg4253.wordpress.com/ http://twitter.com/maningsambale -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [Talk-us] a plea to armchair mappers
On Thu, Jun 11, 2015 at 9:08 PM, James Mast rickmastfa...@hotmail.com wrote: Maybe we should invite the MapBox paid mappers to join in this conversation? This is something I would like to become (hint, hint). ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-es] Números de policía en OSM
Date: Thu, 11 Jun 2015 16:19:49 +0200 From: Carlos Dávila cdavi...@orangecorreo.es To: Discusión en Español de OpenStreetMap talk-es@openstreetmap.org Subject: Re: [Talk-es] Números de policía en OSM Message-ID: 55799905.6090...@orangecorreo.es Content-Type: text/plain; charset=utf-8; format=flowed El 11/06/15 a las 14:31, Juanma M. R. escribió: Hola, Estoy intentando entender el modelo de datos de OSM para poder operar con los números de policía que trae esta cartografía. Para temas de calles y otros menesteres me he aclarado pero para el tema de número de policía me cuesta sacar los datos que necesito. No sé si es por uno de los dos motivos siguientes: * Los números de policía para España (estoy probando con datos de Albacete) son pocos y no están bien documentados Con seguridad es uno de los motivos * La consulta que hago no es la que debiera. He estado mirándome la explicación del método karlsruhe y me da la impresión que no es tan sencillo como yo pensaba. Estoy trabajando con la BDD de Nominatim cargada tal como indica su documentación. La consulta al final es: select * from place where type ='house' and housenumber = '2' and street='Calle de la Caba' limit 1; El problema es que street no está en todos los números de portal. ¿Hay otra forma de acceder a ellos? Según la documentación addr_place debería estar inicializado ya que es altamente recomendable el meterlo. Pero utilizo street porque al menos en el modelo de nominatim es donde viene el nombre de la calle cuando lo tiene. No sé si Nominatim usa nombres de campos distintos a los originales de OSM, pero las etiquetas correctas a buscar serían addr:housenumber, addr:street y addr:place. Respecto a house, hay muchos números de policía que no están en una entidad house, puede ser un nodo que marca la entrada al edificio en cuestión, un edificio que no es una casa, etc. La verdad es que empecé directamente a trabajar con Nominatim y creo que los tags los representa de manera distinta en la BDD, pero muy muy parecida. Por tus indicaciones entiendo que estoy haciéndolo bien y el problema es que para Albacete por ejemplo no están vinculados los números de policía a la calle. En cualquier caso gracias por la aclaración. Necesitaba confirmar si lo había entendido bien o estaba equivocándome. Estoy en paralelo intentando hacer funcionar nominatim en local ( https://help.openstreetmap.org/questions/43244/problems-installing-nominatim-relations-and-functions-not-found ) para utilizar el propio nominatim y no tener que calentarme la cabeza, pero tengo problemas y por eso estoy intentando el plan B de trabajar con ellos directamente. ¿Alguna ayuda/idea/corrección? Gracias. Finalmente conseguí arreglarlo y tengo Nominatim funcionando en local. Así que tiraré de Nominatim para la búsqueda de calle + portal. En principio con esto tengo cubierto lo que necesitaba. Un saludo, Juan Manuel Moreno Rivera. ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [OSM-talk] Routing Applications
This was bothering me, too. But aren't we expecting too much? I guess that via ways could be not that easy to implement for all but the simplest cases (where it can be reduced to via nodes, anyway - like no U-turn on a double carriageway which intersects with a single-carriageway road). Can someone who actually works with commercial navigation data say if via ways have an equivalent in their systems? We can't live in our idealistic world if it means that implementations can't easily deliver proper solution. This indirectly backfires on our crediblity, whether we like it or not. If it were that easy, then at least some (more than 1 and few obscure) routers would have supported via ways. Routing is one of the areas where errors aren't tolerated and you will get all this OSM is shit from people. If Google, TomTom and HERE can sort it out, why can't we? Michał On Wed, Jun 17, 2015 at 11:05 AM, Nick Whitelegg nick.whitel...@solent.ac.uk wrote: Depends what you're after really. I'm impressed by GraphHopper's job in suggesting a foot route between Southampton and the village I spent my teenage years, 60km away - it actually suggests a route very close to the one I would have chosen myself. A bit more roads than ideal, but it is impressive. From: Janko Mihelić jan...@gmail.com Sent: 17 June 2015 10:00 To: Hans De Kryger; OpenStreetMap Subject: Re: [OSM-talk] Routing Applications If you ask me, they are all in their infancy. Non of these routing services even route right. In a turn restriction the via role can be a way. Neither OSRM, ORS or GraphHopper knows how to restrict that, and that's IMHO one of the crucial parts of a routing engine. When one of them starts routing right, than we can talk about picking a winner service. Right now only MapQuest knows how to route. Janko sri, 17. lip 2015. 05:34 Hans De Kryger hans.dekryge...@gmail.com je napisao: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? Am i missing something? I know it's nice to have different services for different uses but this doesn't seem like a good use of resources at all. I may be the only one with this opinion, but this has bug me for awhile. Regards, Hans http://www.openstreetmap.org/user/TheDutchMan13 *Sorry for any misspellings* ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Aggiornamento dei distributori di carburante
2015-06-17 12:46 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 17.06.2015 um 12:25 schrieb Simone Saviolo simone.savi...@gmail.com: Cosa proponi di fare con Q8 e Q8easy? Io li sto mappando separatamente. Lo stesso per TotalErg e TE24. finora credo di aver messo solo Q8 e TotalErg ma mi potrei adattare volentieri se vogliamo distinguerli come fai tu Io ho inserito tempo fa un Q8easy, ma nell'elenco MISE è riportato semplicemente come brand=Q8. Forse in quell'elenco non viene fatta questa distinzione, oppure dipende come al solito dalle segnalazioni fatte dagli operatori. Ad ogni modo non vedo grossa necessità di separare nel brand le due cose (forse più nel name). Su taginfo ci sono: brand=Q8 1238 brand=Q8 easy 9 brand=Q8 Easy 6 Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-es] FW: Participación de OpenStreetMap en el OpenExpo Day 2015
El día 17 de junio de 2015, 13:03, Luis García Castro lui...@gmail.com escribió: Buenas, Ya he publicado las transparencias de la charla que dí ayer en OpenExpo : http://luisgc.github.io/OpenStreetMap_open_collaborative_free El código fuente está en: https://github.com/LuisGC/OpenStreetMap_open_collaborative_free Espero que os guste. Lo he publicado todo con licencia CC-BY-SA (como no podía ser de otra manera), así que lo podéis reutilizar como queráis. Y como podéis ver, me he apoyado mucho en los materiales que otros ya habéis utilizado antes, ¡muchas gracias de nuevo!! Fue un placer conocer a algunos de vosotros, deberíamos vernos de vez en cuando :-) Un saludo, -- Luis GC Luís muy guapas las diapos, lástima no haber podido asistir y eso que me pillaba cerca pero últimamente no me alcanza la vida :-( A ver si organizamos una cervezas o algo la gente que estamos por Madrid, estaría bien. ¡Saludos! -- Jorge Sanz http://www.osgeo.org http://wiki.osgeo.org/wiki/Jorge_Sanz GPG: 86F8 3EA0 BD19 0CA2 801D 4FB2 6B45 68E4 6FB2 D89D ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [OSM-talk] Routing Applications
On 17/06/2015 05:33, Hans De Kryger wrote: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? Am i missing something ? I know it's nice to have different services for different uses but this doesn't seem like a good use of resources at all. This is a recurring question in all free software. Whereas, in a market segment's maturity, network effects come to overwhelm centrifugal forces, in earlier phases there are distinct advantages to diversity. Not only does diversity offer faster exploration of the solution space, but it also affords greater resilience against organizational stresses. Also, focusing resources of a single project might not improve the end-user outcome: software quality is only partly correlated to resource allocation, especially for small projects and early stages where quality in the core development team is paramount. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
Je rejoins la proposition de Pierre-Yves, de pouvoir étendre une plage horaire sur les jours à droite/gauche (et donc de mettre aussi le = sur les 2 bords verticaux). De plus, il faudrait pouvoir indiquer si c'est ouvert/fermé les jours fériés, dont les dates sont soit connues (01/01, 08/05, 11/11, 25/12, ...) soit calculables (Pâques, Ascension, Pentecôte, ...), ainsi que pour les vacances scolaires. Francescu Le 17 juin 2015 07:50, PanierAvide panierav...@riseup.net a écrit : Merci :) C'est noté, je vais voir s'il y a possibilité de rajouter ça par dessus la bibliothèque utilisée pour le calendrier. Le = permet de montrer que l'objet est extensible par le bas, que l'on peut le déplacer, ... Pareil, c'est géré par la bibliothèque de calendrier. Si c'est vraiment troublant je peux voir pour le retirer. Le 17/06/2015 07:26, Pierre-Yves Berrard a écrit : Beau travail :) J'ajouterais la possibilité d'étirer les plages vers la gauche ou la droite :pratique pour les jours ayant les mêmes plages. Sinon, je n'ai pas compris à quoi servait le = au deuxième clic. PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Aggiornamento dei distributori di carburante
Federico Cortese wrote 2015-06-16 22:28 GMT+02:00 Cascafico Giovanni lt; cascafico@ gt;: Per gli indirizzi molto spesso il campo è sbagliato perchè molti impianti si trovano su strade provinciali e i nomi di queste strade nel database MISE sono completamente inventati. Ciao Federico ciao, questo mi rassicura molto. qualche settimana fa ho mappato i civici lungo una provinciale e mi risulta che l'indirizzo associato al benzinaio di verderio inferiore (comune che non esiste più) sia molto più a nord rispetto dove si trova il benzinaio (nel database è anche inserito in una posizione sbagliata) e comunque già preso da un altra attività. non so come comportarmi ma sapere che potrebbe essere stato il benzinaio potrebbe spiegare un po' di cose...comunque nei prossimi giorni potrei decidere di fare un ulteriore passaggio in quella zona per assicurarmi di non aver fatto un errore nell'inserimento/posizionamento dei civici... La cosa strana è che non è la prima volta che vedo quello stesso civico usato da altre attività (anche distanti) sulla stessa via...io ho inserito solo quello che ho visto (e l'unico 56 che ho visto era in un ingresso di un azienda), ma a questo punto ho il dubbio che a più attività sia stato assegnato (magari per errore) lo stesso civico. che voi sappiate può succedere questa cosa? come mi dovrei comportare? - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Aggiornamento-dei-distributori-di-carburante-tp5848265p5848384.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
Wow, je dis chapeau ! Beau boulot ! Stf Le 17/06/2015 08:20, PanierAvide a écrit : La gestion des saisonnalités est prévue, je prends note de l'intégrer rapidement ;) Cependant, dans la syntaxe opening_hours il est possible de préciser les jours fériés dans leur ensemble (PH), et il est possible de préciser une date en particulier (donc si les horaires changent d'un jour férié fixe à un autre, pas de soucis), autant pour les jours fériés calculables seul pâques est géré [1]. Pour l'instant la syntaxe ne permettra pas de pousser le détail à des commerces qui ouvrent à des heures différentes selon le jour férié (ceci dit ça doit être relativement rare ?). [1] https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#explain:variable_date Le 17/06/2015 08:10, Francescu GAROBY a écrit : Je rejoins la proposition de Pierre-Yves, de pouvoir étendre une plage horaire sur les jours à droite/gauche (et donc de mettre aussi le = sur les 2 bords verticaux). De plus, il faudrait pouvoir indiquer si c'est ouvert/fermé les jours fériés, dont les dates sont soit connues (01/01, 08/05, 11/11, 25/12, ...) soit calculables (Pâques, Ascension, Pentecôte, ...), ainsi que pour les vacances scolaires. Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
La gestion des saisonnalités est prévue, je prends note de l'intégrer rapidement ;) Cependant, dans la syntaxe opening_hours il est possible de préciser les jours fériés dans leur ensemble (PH), et il est possible de préciser une date en particulier (donc si les horaires changent d'un jour férié fixe à un autre, pas de soucis), autant pour les jours fériés calculables seul pâques est géré [1]. Pour l'instant la syntaxe ne permettra pas de pousser le détail à des commerces qui ouvrent à des heures différentes selon le jour férié (ceci dit ça doit être relativement rare ?). [1] https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#explain:variable_date Le 17/06/2015 08:10, Francescu GAROBY a écrit : Je rejoins la proposition de Pierre-Yves, de pouvoir étendre une plage horaire sur les jours à droite/gauche (et donc de mettre aussi le = sur les 2 bords verticaux). De plus, il faudrait pouvoir indiquer si c'est ouvert/fermé les jours fériés, dont les dates sont soit connues (01/01, 08/05, 11/11, 25/12, ...) soit calculables (Pâques, Ascension, Pentecôte, ...), ainsi que pour les vacances scolaires. Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-ph] Roads to Baler
I haven't been to Baler through Bongabon (only through Pantabangan) but a follower in my blog suggested that it is better that the GPS map routes to Pantabangan instead of Bongabon. Judging from his suggestion, Pantabangan might be better to be a trunk than the one through Bongabon. Ervin Malicdem for Schadow1 Expeditions a Filipino must not be a stranger to his own motherland. http://www.s1expeditions.com On Jun 17, 2015 1:39 PM, maning sambale emmanuel.samb...@gmail.com wrote: Hi, I'm improving road geomatery over Baler and surrounding areas: http://www.openstreetmap.org/#map=12/15.7367/121.3412 Currently there are two main roads going to Baler. One via Pantabangan which was marked as highway=primary. The other one is via Bongabon which was marked as trunk. Both have very good GPS tracks. But looking at the surface from imagery, it seems the Pantabangan route is better. I haven't been to Baler so I'm wondering which road is better (by car) routing wise. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden https://epsg4253.wordpress.com/ http://twitter.com/maningsambale -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [Talk-de] Probleme mit Mapper - was tun?
On Tue, 16 Jun 2015 23:58:29 +0200, Bernhard Weiskopf wrote: Irgendwie hat der Mapper nach meiner Meinung noch fast gar nichts richtiges getan, sondern nur falsches oder nicht belegtes, wobei ich die nicht belegten Einträge sehr anzweifle. Am liebsten würde ich alle seine Änderungen revertieren, das macht aber immer mehr Aufwand, je länger er ändert oder einträgt. Vereinzelte Fehler, wie nicht verbundene Wege, wurden inzwischen von anderen Mappern korrigiert. Je länger du wartest und je mehr andere Mapper zwischenrein reparieren, desto aufwendiger wird die Sache. Wenn du nur die einzelnen Changesets des Mappers zurücksetzt, ist das im Verhältnis der geringere Aufwand. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
Mille bravos PanierAvide, je n'aurai pas rêvé mieux. C'est exactement l'outil user friendly que je souhaitais pour initier les noobs que j'ai sous la main. Je rejoins la proposition de Pierre-Yves, de pouvoir étendre une plage horaire sur les jours à droite/gauche (et donc de mettre aussi le = sur les 2 bords verticaux). +1 Pour l'instant la syntaxe ne permettra pas de pousser le détail à des commerces qui ouvrent à des heures différentes selon le jour férié (ceci dit ça doit être relativement rare ?). à priori, oui. Une spécification des horaires d'ouverture durant les jours fériés est déjà un grand pas en avant. Encore merci ! Le 17 juin 2015 08:57, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Wow, je dis chapeau ! Beau boulot ! Stf Le 17/06/2015 08:20, PanierAvide a écrit : La gestion des saisonnalités est prévue, je prends note de l'intégrer rapidement ;) Cependant, dans la syntaxe opening_hours il est possible de préciser les jours fériés dans leur ensemble (PH), et il est possible de préciser une date en particulier (donc si les horaires changent d'un jour férié fixe à un autre, pas de soucis), autant pour les jours fériés calculables seul pâques est géré [1]. Pour l'instant la syntaxe ne permettra pas de pousser le détail à des commerces qui ouvrent à des heures différentes selon le jour férié (ceci dit ça doit être relativement rare ?). [1] https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#explain:variable_date Le 17/06/2015 08:10, Francescu GAROBY a écrit : Je rejoins la proposition de Pierre-Yves, de pouvoir étendre une plage horaire sur les jours à droite/gauche (et donc de mettre aussi le = sur les 2 bords verticaux). De plus, il faudrait pouvoir indiquer si c'est ouvert/fermé les jours fériés, dont les dates sont soit connues (01/01, 08/05, 11/11, 25/12, ...) soit calculables (Pâques, Ascension, Pentecôte, ...), ainsi que pour les vacances scolaires. Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-ph] Roads to Baler
Maning, The road via Pantabangan is the main road use going to Baler by buses and cars. The road via Bongabon, will pass tru Sierra Madre and along this road, there is a memorial marker for Aurora Quezon (wife of Pres. Quezon). This route is scenic but some parts are prone to landslide. And due to the road condition several years ago, a 4x4 car was more suitable to use. --bunny On Wednesday, 17 June 2015, 14:36, Ervin Malicdem schad...@gmail.com wrote: I haven't been to Baler through Bongabon (only through Pantabangan) but a follower in my blog suggested that it is better that the GPS map routes to Pantabangan instead of Bongabon. Judging from his suggestion, Pantabangan might be better to be a trunk than the one through Bongabon. Ervin Malicdem for Schadow1 Expeditions a Filipino must not be a stranger to his own motherland. http://www.s1expeditions.comOn Jun 17, 2015 1:39 PM, maning sambale emmanuel.samb...@gmail.com wrote: Hi, I'm improving road geomatery over Baler and surrounding areas: http://www.openstreetmap.org/#map=12/15.7367/121.3412 Currently there are two main roads going to Baler. One via Pantabangan which was marked as highway=primary. The other one is via Bongabon which was marked as trunk. Both have very good GPS tracks. But looking at the surface from imagery, it seems the Pantabangan route is better. I haven't been to Baler so I'm wondering which road is better (by car) routing wise. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden https://epsg4253.wordpress.com/ http://twitter.com/maningsambale -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
La taille vertical est beaucoup trop grande, ce qui oblige au scroll vertical et ne facilite pas les choses (parce que la sélection se fait par cellules entières). Il n'y a pas moyen de faire des rectangles beaucoup moins haut, quite à aller à la précision du pixel et une heure indicative à) quelques minutes près qu'on peut encore ajuster dans le champ texte ? (peut-être avec un zoom avant/arrière si on veut vois plus de précision des heures) Sinon seule la dernière cellule permet de changer la durée d'une période et d'évidence on devrait pouvoir sélectionner un bord droit ou gauche pour étendre sur plusieurs jours successifs. Autre problème: seule la dernière cellule permet de changer la durée, les autres déplacent la zone qui peut sortir des limites de la table. La première cellule devrait aussi avoir son bord supérieur déplaçable, et dans tous les cas la sélection ne peut pas sortir des 7 jours (sinon cela doit soit boucler, soir tronquer : la remarque vaut aussi bien pour ce qui est avant la première cellule que ce qui est après car le déplacement n'en tient pas compte) L'idée étant que dans tous les cas cela doit tenir dans la fenêtre. Là c'est une présenttion de type agenda comme s'il y avait du texte à saisir dans les cellules pour noter un événement ou un rendez-vous. J'aurais plutôt mis les heures sur l'axe horizontal et les jours (ou autres lignes pour les dates PH, etc...) sur l'axe vertical (dans ce cas le zoom des heures est un zoom de l'axe horizontal mais le zoom par défaut affiche les 24 heures). Ca pourrait alors devenir un widget intégrable dans un formulaire, ou même un popup d'information (seule différence: le popup d'information n'est pas éditable, il affiche juste la valeur du champ et le tableau en dessous, et le zoom n'est pas absolument nécessaire pour cette présentation statique), y compris depuis un site externe qui pourrait afficher les deux dans un IFRAME (sans aucune autre décoration: juste le champ texte et le tableau, voire seulement le tableau, sans aucune marge) Le 17 juin 2015 08:57, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Wow, je dis chapeau ! Beau boulot ! Stf Le 17/06/2015 08:20, PanierAvide a écrit : La gestion des saisonnalités est prévue, je prends note de l'intégrer rapidement ;) Cependant, dans la syntaxe opening_hours il est possible de préciser les jours fériés dans leur ensemble (PH), et il est possible de préciser une date en particulier (donc si les horaires changent d'un jour férié fixe à un autre, pas de soucis), autant pour les jours fériés calculables seul pâques est géré [1]. Pour l'instant la syntaxe ne permettra pas de pousser le détail à des commerces qui ouvrent à des heures différentes selon le jour férié (ceci dit ça doit être relativement rare ?). [1] https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#explain:variable_date Le 17/06/2015 08:10, Francescu GAROBY a écrit : Je rejoins la proposition de Pierre-Yves, de pouvoir étendre une plage horaire sur les jours à droite/gauche (et donc de mettre aussi le = sur les 2 bords verticaux). De plus, il faudrait pouvoir indiquer si c'est ouvert/fermé les jours fériés, dont les dates sont soit connues (01/01, 08/05, 11/11, 25/12, ...) soit calculables (Pâques, Ascension, Pentecôte, ...), ainsi que pour les vacances scolaires. Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Aggiornamento dei distributori di carburante
sent from a phone Am 16.06.2015 um 21:53 schrieb Federico Cortese cortese...@gmail.com: Mettere name = PV 123 di Tizio mi sembra non aggiunga nessuna informazione al database. Sono d'accordo con te: mettere il nome ad un impianto non è che abbia molto senso. invece è quello che è documentato, il problema sta nel render, quello dovrebbe preferire brand su name. Quando fai una ricerca è spesso utile avere un nome per distinguere i vari risultati tra di loro ciao Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
Il giorno 17 giugno 2015 11:53, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2015-06-16 23:06 GMT+02:00 Federico Cortese cortese...@gmail.com: O meglio brand=Independent, con la e ;) in brand ci metto quello che si vede, Independent lo metterei quando c'è scritto. Se vedo qualcosa così: http://www.bizbuysell.com/Business-Opportunity/Independent-Gas-Station-and-C-Store/1151360/ metterei brand=Clark oppure qui http://2.bp.blogspot.com/-W4LDSNaFmjc/UEI_A2456MI/CyE/d0BuIPeNIs4/s1600/benzinaCarrefour.jpg brand=Carrefour Perciò non metterei Api-Ip (6 volte in taginfo oggi) http://taginfo.osm.org/search?q=brand%3DApi perché viene percipito come IP (987 volte) http://taginfo.osm.org/search?q=brand%3DIP Se importassimo tutti questi dati come sono adesso (ed ha già cominciato, perché ieri erano 3 Api-Ip ed oggi 6) il valore di brand per IP si storcerebbe completamente. Cosa proponi di fare con Q8 e Q8easy? Io li sto mappando separatamente. Lo stesso per TotalErg e TE24. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
http://toolserver.openstreetmap.it/phpBenz/listProvincia.php http://toolserver.openstreetmap.it/phpBenz/statsProv.php Grazie! A me il secondo link non da i risultati sperati per la cartina: non ci sono i punti. Sono una bestia, non avevo messo il link alla pagina giusta. Corretto ;-D Verificato, ora va bene! Grazie! Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-es] FW: Participación de OpenStreetMap en el OpenExpo Day 2015
Buenas, Ya he publicado las transparencias de la charla que dí ayer en OpenExpo : http://luisgc.github.io/OpenStreetMap_open_collaborative_free El código fuente está en: https://github.com/LuisGC/OpenStreetMap_open_collaborative_free Espero que os guste. Lo he publicado todo con licencia CC-BY-SA (como no podía ser de otra manera), así que lo podéis reutilizar como queráis. Y como podéis ver, me he apoyado mucho en los materiales que otros ya habéis utilizado antes, ¡muchas gracias de nuevo!! Fue un placer conocer a algunos de vosotros, deberíamos vernos de vez en cuando :-) Un saludo, -- Luis GC ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-it] Aggiornamento dei distributori di carburante
sent from a phone Am 16.06.2015 um 22:41 schrieb Federico Cortese cortese...@gmail.com: Per gli indirizzi molto spesso il campo è sbagliato perchè molti impianti si trovano su strade provinciali e i nomi di queste strade nel database MISE sono completamente inventati. sono gli indirizzi che i proprietari ritengono utili per essere trovato, non sono necessariamente indirizzi veri/ufficiali, ma in qualche senso li vedo validi. Per me potrebbero avere uno spazio in addr:full senza essere interpretati ciao Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
Da: Stefano saba...@gmail.com Questa era facile (c'è la colonna apposta, è bastato replicare le pagine) :D http://toolserver.openstreetmap.it/phpBenz/listProvincia.php http://toolserver.openstreetmap.it/phpBenz/statsProv.php Grazie! A me il secondo link non da i risultati sperati per la cartina: non ci sono i punti. Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-lv] Rīgas adrešu punktu imports no opendata.riga.lv
Ieliek punktu un tam pieraksta adresi. Normāla lieta. Ir valstis kas tādu praksi piekopj arī ja ēkas ir. On Wed, Jun 17, 2015 at 12:32 PM Janis Elmeris janis.elme...@intelligentsystems.lv wrote: Kā domāts importēt adresi vietai, kur nav ēkas? Jānis On 15.06.2015. 16:02, Viesturs Zarins wrote: VEF rajonā kādus piecus jau pamanīju. Varētu būt diezgan izplatīta štelle. Cilvēki pamatā liek mazos burtus, jo tādi ir uz numuru plāksnēm. Viesturs On Mon, Jun 15, 2015 at 4:00 PM Vitaly Bolshakov v.bolshak...@gmail.com wrote: Labdien! Ir labi pamanīts! Būs laikam tādus gadījumus arī jāizlabo OSM (adrešu sarakstā tādu atstarpju nav starp numuriem un burtiem). Ja tādu gadījumu neatradis daudz, tad mēģināšu manuāli izlabot. Ar cieņu, Vitālijs On Mon, 15 Jun 2015 15:54:21 +0300, Viesturs Zarins viest...@gmail.com wrote: Izsktās tīri ok. Vienu lietu pamanīju - Brīvības gatve 212A - http://bolshakov.lv/osm#map=19/56.97040114477699/24.15818452835083 Tipa ir adrese bet ar mazo burtu un atstarpi. Mos var uztaisīt lai automātiski atrod esošās adreses kas ir līzīgas līdz lielajiem/mazajiem burtiem un atstarpēm un izlabo tās. Viesturs ___ Talk-lv mailing listTalk-lv@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [OSM-talk] Routing Applications
If you ask me, they are all in their infancy. Non of these routing services even route right. In a turn restriction the via role can be a way. Neither OSRM, ORS or GraphHopper knows how to restrict that, and that's IMHO one of the crucial parts of a routing engine. When one of them starts routing right, than we can talk about picking a winner service. Right now only MapQuest knows how to route. Janko sri, 17. lip 2015. 05:34 Hans De Kryger hans.dekryge...@gmail.com je napisao: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? Am i missing something? I know it's nice to have different services for different uses but this doesn't seem like a good use of resources at all. I may be the only one with this opinion, but this has bug me for awhile. *Regards,* *Hans* *http://www.openstreetmap.org/user/TheDutchMan13 http://www.openstreetmap.org/user/TheDutchMan13* *Sorry for any misspellings* ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing Applications
Depends what you're after really. I'm impressed by GraphHopper's job in suggesting a foot route between Southampton and the village I spent my teenage years, 60km away - it actually suggests a route very close to the one I would have chosen myself. A bit more roads than ideal, but it is impressive. From: Janko Mihelic jan...@gmail.com Sent: 17 June 2015 10:00 To: Hans De Kryger; OpenStreetMap Subject: Re: [OSM-talk] Routing Applications If you ask me, they are all in their infancy. Non of these routing services even route right. In a turn restriction the via role can be a way. Neither OSRM, ORS or GraphHopper knows how to restrict that, and that's IMHO one of the crucial parts of a routing engine. When one of them starts routing right, than we can talk about picking a winner service. Right now only MapQuest knows how to route. Janko sri, 17. lip 2015. 05:34 Hans De Kryger hans.dekryge...@gmail.commailto:hans.dekryge...@gmail.com je napisao: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? Am i missing something? I know it's nice to have different services for different uses but this doesn't seem like a good use of resources at all. I may be the only one with this opinion, but this has bug me for awhile. Regards, Hans http://www.openstreetmap.org/user/TheDutchMan13 *Sorry for any misspellings* ___ talk mailing list talk@openstreetmap.orgmailto:talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Aggiornamento dei distributori di carburante
2015-06-17 11:53 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: in brand ci metto quello che si vede, Independent lo metterei quando c'è scritto. Se vedo qualcosa così: Per me va bene anche come dici tu, decidiamo come fare ed applichiamo un metodo comune. Perciò non metterei Api-Ip (6 volte in taginfo oggi) http://taginfo.osm.org/search?q=brand%3DApi perché viene percipito come IP (987 volte) http://taginfo.osm.org/search?q=brand%3DIP Se importassimo tutti questi dati come sono adesso (ed ha già cominciato, perché ieri erano 3 Api-Ip ed oggi 6) il valore di brand per IP si storcerebbe completamente. Sicuramente sono quelli che ho inserito io (dovrebbero essere 8 in realtà stando a overpass http://overpass-turbo.eu/s/9YI), se si decide per brand=IP correggo subito. ciao, Martin Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] nuovi server in arrivo
Ciao a tutti, se potete contribuite. http://donate.openstreetmap.org/server2015/ PS chi utilizza OSM ottenendone ricavi dovrebbe contribuire in modo più sostanziale ;-) -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
Il 17/giu/2015 11:13, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: invece è quello che è documentato, il problema sta nel render, quello dovrebbe preferire brand su name. Quando fai una ricerca è spesso utile avere un nome per distinguere i vari risultati tra di loro Dovrebbe renderizzare brand + eventuale name, ad esempio Esso Mascherone Ovest per le autostradali, oppure Q8 per le stradali che normalmente non hanno nome, salvo casi particolari. In un mondo ideale, non ci sarebbe bisogno di specificare il brand perché renderizzaresti il logo della Compagnia al posto dell'icona. Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
2015-06-16 11:11 GMT+02:00 Andrea Musuruane musur...@gmail.com: Ciao Sabas, essendo un import, non bisognerebbe seguire le relative linee guida? Personalmente non lo reputo un import in quanto c'è un grosso lavoro di verifica da fare che non mi sembra affatto banale. Quanto alla IODL 2.0 concordo che la licenza dichiara che bisogna citare la fonte, ma lo fa anche in maniera leggera http://www.dati.gov.it/iodl/2.0/ I vincoli sono - indicare la fonte delle Informazioni e il nome del Licenziante, includendo, se possibile, una copia di questa licenza o un collegamento (link) ad essa. = l'importante è quindi citare la fonte in qualche modo, non viene specificato il fatto che sia ben visibile e l'agganciare la licenza è considerato superfluo - non riutilizzare le Informazioni in un modo che suggerisca che abbiano carattere di ufficialità o che il Licenziante approvi l'uso che fai delle Informazioni; = mi sembra che inserite dentro OSM questo aspetto di ufficialità venga a mancare - prendere ogni misura ragionevole affinché gli usi innanzi consentiti non traggano in inganno altri soggetti e le Informazioni medesime non vengano travisate. = su questo forse potremmo discutere, ma c'è anche da dire che gli stessi dati del MiSE hanno i loro errori Personalmente penso che, come comunità italiana, allargata poi a quella nazionale, potremmo cominciare a discutere del tema dell'import quando questo viene fatto manualmente e verificato, quanto, praticamente, i dati da cui si attinge, vengono usati come supporto al data entry e non sono invece l'inserimento stesso. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
2015-06-17 11:33 GMT+02:00 Maurizio Napolitano napoo...@gmail.com: Personalmente penso che, come comunità italiana, allargata poi a quella nazionale, potremmo cominciare a discutere del tema dell'import quando questo viene fatto manualmente e verificato, quanto, praticamente, i dati da cui si attinge, vengono usati come supporto al data entry e non sono invece l'inserimento stesso. +1, sono d'accordo, in ogni caso penso sia un import per i valori ref:mise. Il fatto che facciamo anche un cross checking e una verfica del dato non cambia niente, la fonte di quelle informazioni che prendiamo sono sotto IODL 2.0. Personalmente sono favorevole a prendere al meno quel campo (ref:mise), ma di trattare le altre informazioni con cautela. Penso che abbiamo fatto bene a segnalare l'import anche alla lista internazionale import, in quanto i dati coprono l'intero paese e non solo un comune o una provincia. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
2015-06-16 23:06 GMT+02:00 Federico Cortese cortese...@gmail.com: O meglio brand=Independent, con la e ;) in brand ci metto quello che si vede, Independent lo metterei quando c'è scritto. Se vedo qualcosa così: http://www.bizbuysell.com/Business-Opportunity/Independent-Gas-Station-and-C-Store/1151360/ metterei brand=Clark oppure qui http://2.bp.blogspot.com/-W4LDSNaFmjc/UEI_A2456MI/CyE/d0BuIPeNIs4/s1600/benzinaCarrefour.jpg brand=Carrefour Perciò non metterei Api-Ip (6 volte in taginfo oggi) http://taginfo.osm.org/search?q=brand%3DApi perché viene percipito come IP (987 volte) http://taginfo.osm.org/search?q=brand%3DIP Se importassimo tutti questi dati come sono adesso (ed ha già cominciato, perché ieri erano 3 Api-Ip ed oggi 6) il valore di brand per IP si storcerebbe completamente. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
sent from a phone Am 17.06.2015 um 12:25 schrieb Simone Saviolo simone.savi...@gmail.com: Cosa proponi di fare con Q8 e Q8easy? Io li sto mappando separatamente. Lo stesso per TotalErg e TE24. finora credo di aver messo solo Q8 e TotalErg ma mi potrei adattare volentieri se vogliamo distinguerli come fai tu ciao Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamento dei distributori di carburante
2015-06-17 12:43 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: secondo me è già deciso se guardi taginfo di ieri: mille contro 3 Ok ho corretto, la prossima volta troverai solo brand=IP su taginfo :) Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-es] Charla OSM-HOT en el IGN
Buenas, El IGN me ha invitado a dar una charla sobre OSM y el HOT la semana que viene, el miércoles 24 de junio, a las 7 en el salón de actos[1]. La convocatoria es abierta por lo que si alguno se anima a venir y echarme un capote es más que bienvenido, estoy seguro de que me van a crujir a preguntas :-) Supongo que haré una versión corta de las diapos sobre las que últimamente me apoyo para contar cosas de OSM[2] y luego me centraré en temas de HOT, cómo se organiza la faena, ejemplos de activaciones, visualización de resultados y tal, me imagino que sobre el material del taller que hice con Pedro-Juan Ferrer este año en Girona[3] ¡Saludos! [1] https://www.facebook.com/156297191073688/photos/a.175582982478442.31537.156297191073688/851035621599838/?type=1theater [2] http://jsanz.github.io/slides-elhackaton-osm/#/ [3] http://taller-hot-jsl-2015.readthedocs.org/es/master/ -- Jorge Sanz http://www.osgeo.org http://wiki.osgeo.org/wiki/Jorge_Sanz GPG: 86F8 3EA0 BD19 0CA2 801D 4FB2 6B45 68E4 6FB2 D89D ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [OSM-talk] Routing Applications
This has been fixed in Osmand early this year after being reported more than 2 years ago. Unfortunately, multiple via ways are still not supported. https://code.google.com/p/osmand/issues/detail?id=1729 On 6/17/15, Janko Mihelić jan...@gmail.com wrote: If you ask me, they are all in their infancy. Non of these routing services even route right. In a turn restriction the via role can be a way. Neither OSRM, ORS or GraphHopper knows how to restrict that, and that's IMHO one of the crucial parts of a routing engine. When one of them starts routing right, than we can talk about picking a winner service. Right now only MapQuest knows how to route. Janko sri, 17. lip 2015. 05:34 Hans De Kryger hans.dekryge...@gmail.com je napisao: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? Am i missing something? I know it's nice to have different services for different uses but this doesn't seem like a good use of resources at all. I may be the only one with this opinion, but this has bug me for awhile. *Regards,* *Hans* *http://www.openstreetmap.org/user/TheDutchMan13 http://www.openstreetmap.org/user/TheDutchMan13* *Sorry for any misspellings* ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] lieu dit Bio a Montauban avec code postal 46500
Bonjour, De: Cactusbone cactusb...@free.fr a Montauban il y a un noeud bizarre : http://www.openstreetmap.org/node/469367704 qui semble correspondre à une ville plus haut : http://www.openstreetmap.org/#map=14/44.7768/1.7897 d'après l'historique ça ressemble plus a une insertion erronée corrigée plus ou moins au fil du temps. je suis d'avis de supprimer ce point, mais je ne connais pas Montauban, il y a vraiment un lieu dit Bio ? D'après Fantoir il y a bien un lieu-dit Bio sur la commune de Montauban, avec le code 82121B064H = visible sur http://cadastre.openstreetmap.fr/fantoir/liste_brute_fantoir.html#insee=82121 Vu de ma chaise (= loin de Montauban) j'aurais donc tendance à ne supprimer que le code postal sur ce point, même si le calcul de population n'est pas complètement évident. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Routing Applications
In theory competition drives functionality improvements, although in this case it's not clear if this happened. Any map based website that doesn't include a permalink option isn't worth using, Unless it's been recently added is very well hidden OSMR hasn't this option. On 17/06/2015 04:33, Hans De Kryger wrote: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? Am i missing something? I know it's nice to have different services for different uses but this doesn't seem like a good use of resources at all. I may be the only one with this opinion, but this has bug me for awhile. *Regards,** * *Hans* * * *http://www.openstreetmap.org/user/TheDutchMan13 http://www.openstreetmap.org/user/TheDutchMan13 * * * *Sorry for any misspellings* --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing Applications
On Wed, Jun 17, 2015 at 2:55 PM, Eugene Alvin Villar sea...@gmail.com wrote: Imagine a single-carriageway road crossing a dual-carriageway road. All turns are allowed except u-turns from one side of the dual-carriageway to the other. This common situation can only be modeled using a turn restriction with a via way. Now if the via way had to be split for any reason, then you have multiple via ways. Isn't the restriction type (no_u_turn, no_left_turn, no_right_turn) basically just for display purposes? Because given from, to and via it only matters whether it's no_* or only_*. The solution I think is going to give correct routing would be to make a no_u_turn where one of the carriageways is from, the node at intersection is via and that small connecting segment is to. Michał ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] lieu dit Bio a Montauban avec code postal 46500
bien vu ! Merci ! je fait ça ! je laisse la population pour le moment, même si c'est proche de la population de la ville de Bio -- View this message in context: http://gis.19327.n5.nabble.com/lieu-dit-Bio-a-Montauban-avec-code-postal-46500-tp5848438p5848447.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-be] Cycle surveying party in Brussels ?
in die link staat enkel maar dat er naar surface gekeken wordt (op het eerste zicht). dan denk ik dat http://cycle.travel/map al met meer factoren rekening houdt. mvg m 2015-06-17 14:43 GMT+02:00 Philippe Casteleyn philippecastel...@hotmail.com : Ik ben nog niet zo ver in de studie, u vindt wellicht iets beter. https://www.mapbox.com/blog/customizing-osrm-with-openstreetmap/ Ph Casteleyn Dahliastraat 16 2800 Mechelen gsm 0486 516261 From: talk-be-requ...@openstreetmap.org Subject: Talk-be Digest, Vol 90, Issue 16 To: talk-be@openstreetmap.org Date: Wed, 17 Jun 2015 12:00:05 + Send Talk-be mailing list submissions to talk-be@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-be or, via email, send a message with subject or body 'help' to talk-be-requ...@openstreetmap.org You can reach the person managing the list at talk-be-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-be digest... Today's Topics: 1. Re: Melkerij / Laiterie (Marc Gemis) 2. Re: Cycle surveying party in Brussels ? (Marc Gemis) -- Message: 1 Date: Tue, 16 Jun 2015 15:01:26 +0200 From: Marc Gemis marc.ge...@gmail.com To: OpenStreetMap Belgium talk-be@openstreetmap.org Subject: Re: [OSM-talk-be] Melkerij / Laiterie Message-ID: cajkjx-rqrecncbpqssodhh7srtxouxyasg+mfp58jnurox0...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Sluit me aan bij Sander, met de spelling correctie van Jo: dus man_made=works + produce=dairy Volgens taginfo [1] zou dat al 20 keer gebruikt zijn mvg m [1] http://taginfo.openstreetmap.org/keys/produce#values 2015-06-16 14:11 GMT+02:00 Sander Deryckere sander...@gmail.com: Bij ons wordt met een melkerij de melkverwerkende fabriek bedoeld. Dit zie je ook aan straatnamen, typisch loopt de Melkerijstraat naar een melk fabriek (zie https://www.openstreetmap.org/#map=17/50.91316/2.90858 ). Een plaats waar koeien verzorgd, en dan ook gemolken wordt meestal een Melkveebedrijf genoemd, en geen melkerij. Ik zou gaan voor man_made=works + produce=diary, eventueel met de shop tags als ze daar zuivelproducten verkopen aan particulieren. Het feit dat de melkerijen in Mali kleiner zijn is niet echt van belang voor mij. Grootte moet in perspectief gezien worden, en aangezien bijna alle fabrieken daar kleiner zullen zijn, vergelijkbaar met onze fabrieken van een aantal decennia terug, kunnen we ook gerust van een fabriek spreken. Door het gebruik van de sub-tag maak je meer kans dat de fabrieken gerenderd worden. Zelfs als de renderer niet weet wat een melkerij is, kan a.d.h.v. man_made=works een fabrieks-icoontje weergegeven worden, en dankzij de naam wordt het meestal duidelijk welke fabriek het is. Meer gespecialiseerde renderers kunnen dan een specifiek melkerij icoontje tonen voor man_made=works + produce=diary. Groeten, Sander Op 16 juni 2015 13:11 schreef Jorieke Vyncke jorieke.vyn...@gmail.com : Hey Jo, Bedankt voor je antwoord en het mee denken! Ik denk dat de soort melkerij waar ik naar op zoek ben, eigenlijk wel heel vergelijkbaar is met het systeem dat er vroeger bestond bij ons. Vroeger werden de koeien immers allemaal met de hand gemelkt en werd de melk nadien naar de melkerij gebracht. Elk dorpje had vroeger zijn eigen melkerij, kijk maar hoeveel oude melkerijen er bestaan en melkerijstraten. Deze melkerijen zijn na een tijd inderdaad geevolueerd naar een melkfabriek bij ons. Hier trouwens ook, er zijn enkele grote melkfabrieken, vb MaliLait, maar de meerderheid is dus nog de kleine melkerij. Ook op wikipedia trouwens een mooi artikel http://nl.wikipedia.org/wiki/Milcobel. Eigenlijk denk ik dat je het een beetje met een windmolen kan vergelijken... die mappen we als man_made=works, dus wat denken jullie van man_made=diary ? Met dan inderdaad toe te voegen shop=beverages + drink:milk=yes en andere... Groetjes, Jorieke Op 16-06-15 heeft Jowinfi...@gmail.com het volgende geschreven: Ik vrees dat je een tag zal moeten voorstellen. In zekere zin is het niet echt een melkerij, al heet het wel zo. De melkerij is, wat mij betreft, de plaats waar de koeien gemolken worden. Dit is eigenlijk de volgende stap, het verwerken van de melk. Ik vrees dat je nieuwe tags zal moeten voorstellen op tagging. Je kan er dan ook nog boter of yoghurt van maken en verpakken. Dat zal soms op dezelfde plaatsen gebeuren en soms ook niet, dus aparte tags voor elk stap van het proces... Hier gaat het als volgt, de koeien worden om de 12 uur aan melkmachines gehangen. Daarna gaan ze de wei op, of ze
Re: [OSM-talk] Routing Applications
On Wed Jun 17 13:47:31 2015 GMT+0100, Michael Reichert wrote: Hi, Am 2015-06-17 um 14:38 schrieb Eugene Alvin Villar: This has been fixed in Osmand early this year after being reported more than 2 years ago. Unfortunately, multiple via ways are still not supported. I wonder if a via way instead of an via node is necessary so much. I wonder more where someone /really/ needs multiple via ways. Can you call examples for multiple via ways (link to relation)? One example that cannot be done with a node. http://osm.org/relation/2653875 Phil (trigpoint) -- Sent from my Jolla ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing Applications
Can someone who actually works with commercial navigation data say if via ways have an equivalent in their systems? TomTom and HERE data both have restrictions that are comprised of multiple via edges (ways). At MapQuest, my team and I integrated these restrictions into the routing engine and when we imported OSM data the logic to handle these complex restrictions was already in place - that is why MapQuest supports them. Now at Mapzen, we are developing an open source routing engine (Valhalla: https://github.com/valhalla). We have not yet implemented these complex restrictions but plan to in the coming months. The logic is not simple and can complicate what might otherwise be a clean design. I think the number of these complex restrictions is low in OSM, but often they represent important cases. -- David Nesbitt d...@mapzen.com 443-206-1819 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-be] Cycle surveying party in Brussels ?
Ik ben nog niet zo ver in de studie, u vindt wellicht iets beter. https://www.mapbox.com/blog/customizing-osrm-with-openstreetmap/ Ph Casteleyn Dahliastraat 16 2800 Mechelen gsm 0486 516261 From: talk-be-requ...@openstreetmap.org Subject: Talk-be Digest, Vol 90, Issue 16 To: talk-be@openstreetmap.org Date: Wed, 17 Jun 2015 12:00:05 + Send Talk-be mailing list submissions to talk-be@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-be or, via email, send a message with subject or body 'help' to talk-be-requ...@openstreetmap.org You can reach the person managing the list at talk-be-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-be digest... Today's Topics: 1. Re: Melkerij / Laiterie (Marc Gemis) 2. Re: Cycle surveying party in Brussels ? (Marc Gemis) -- Message: 1 Date: Tue, 16 Jun 2015 15:01:26 +0200 From: Marc Gemis marc.ge...@gmail.com To: OpenStreetMap Belgium talk-be@openstreetmap.org Subject: Re: [OSM-talk-be] Melkerij / Laiterie Message-ID: cajkjx-rqrecncbpqssodhh7srtxouxyasg+mfp58jnurox0...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Sluit me aan bij Sander, met de spelling correctie van Jo: dus man_made=works + produce=dairy Volgens taginfo [1] zou dat al 20 keer gebruikt zijn mvg m [1] http://taginfo.openstreetmap.org/keys/produce#values 2015-06-16 14:11 GMT+02:00 Sander Deryckere sander...@gmail.com: Bij ons wordt met een melkerij de melkverwerkende fabriek bedoeld. Dit zie je ook aan straatnamen, typisch loopt de Melkerijstraat naar een melk fabriek (zie https://www.openstreetmap.org/#map=17/50.91316/2.90858 ). Een plaats waar koeien verzorgd, en dan ook gemolken wordt meestal een Melkveebedrijf genoemd, en geen melkerij. Ik zou gaan voor man_made=works + produce=diary, eventueel met de shop tags als ze daar zuivelproducten verkopen aan particulieren. Het feit dat de melkerijen in Mali kleiner zijn is niet echt van belang voor mij. Grootte moet in perspectief gezien worden, en aangezien bijna alle fabrieken daar kleiner zullen zijn, vergelijkbaar met onze fabrieken van een aantal decennia terug, kunnen we ook gerust van een fabriek spreken. Door het gebruik van de sub-tag maak je meer kans dat de fabrieken gerenderd worden. Zelfs als de renderer niet weet wat een melkerij is, kan a.d.h.v. man_made=works een fabrieks-icoontje weergegeven worden, en dankzij de naam wordt het meestal duidelijk welke fabriek het is. Meer gespecialiseerde renderers kunnen dan een specifiek melkerij icoontje tonen voor man_made=works + produce=diary. Groeten, Sander Op 16 juni 2015 13:11 schreef Jorieke Vyncke jorieke.vyn...@gmail.com: Hey Jo, Bedankt voor je antwoord en het mee denken! Ik denk dat de soort melkerij waar ik naar op zoek ben, eigenlijk wel heel vergelijkbaar is met het systeem dat er vroeger bestond bij ons. Vroeger werden de koeien immers allemaal met de hand gemelkt en werd de melk nadien naar de melkerij gebracht. Elk dorpje had vroeger zijn eigen melkerij, kijk maar hoeveel oude melkerijen er bestaan en melkerijstraten. Deze melkerijen zijn na een tijd inderdaad geevolueerd naar een melkfabriek bij ons. Hier trouwens ook, er zijn enkele grote melkfabrieken, vb MaliLait, maar de meerderheid is dus nog de kleine melkerij. Ook op wikipedia trouwens een mooi artikel http://nl.wikipedia.org/wiki/Milcobel. Eigenlijk denk ik dat je het een beetje met een windmolen kan vergelijken... die mappen we als man_made=works, dus wat denken jullie van man_made=diary ? Met dan inderdaad toe te voegen shop=beverages + drink:milk=yes en andere... Groetjes, Jorieke Op 16-06-15 heeft Jowinfi...@gmail.com het volgende geschreven: Ik vrees dat je een tag zal moeten voorstellen. In zekere zin is het niet echt een melkerij, al heet het wel zo. De melkerij is, wat mij betreft, de plaats waar de koeien gemolken worden. Dit is eigenlijk de volgende stap, het verwerken van de melk. Ik vrees dat je nieuwe tags zal moeten voorstellen op tagging. Je kan er dan ook nog boter of yoghurt van maken en verpakken. Dat zal soms op dezelfde plaatsen gebeuren en soms ook niet, dus aparte tags voor elk stap van het proces... Hier gaat het als volgt, de koeien worden om de 12 uur aan melkmachines gehangen. Daarna gaan ze de wei op, of ze worden vooraf binnengehaald. Alles gaat in een groot vat en er komt een citerne langs om de melk op te halen. Dan gaat het naar een 'melkfabriek', die de hele rest van de verwerking en verpakking doen. Vroeger ging dat anders; er bestaan bv. ook aanhangers waarmee de koeien op de weide gemolken kunnen worden, of
Re: [talk-ph] Roads to Baler
Seems settled then. Please edit. cheers, Maning Sambale (mobile) On Jun 17, 2015 7:50 PM, Eugene Alvin Villar sea...@gmail.com wrote: I checked a few travel blogs and the consensus is via Pantabangan. This is also the route of Genesis Bus, the only bus company that offers direct trips from Manila. On 6/17/15, Ervin Malicdem schad...@gmail.com wrote: I haven't been to Baler through Bongabon (only through Pantabangan) but a follower in my blog suggested that it is better that the GPS map routes to Pantabangan instead of Bongabon. Judging from his suggestion, Pantabangan might be better to be a trunk than the one through Bongabon. Ervin Malicdem for Schadow1 Expeditions a Filipino must not be a stranger to his own motherland. http://www.s1expeditions.com On Jun 17, 2015 1:39 PM, maning sambale emmanuel.samb...@gmail.com wrote: Hi, I'm improving road geomatery over Baler and surrounding areas: http://www.openstreetmap.org/#map=12/15.7367/121.3412 Currently there are two main roads going to Baler. One via Pantabangan which was marked as highway=primary. The other one is via Bongabon which was marked as trunk. Both have very good GPS tracks. But looking at the surface from imagery, it seems the Pantabangan route is better. I haven't been to Baler so I'm wondering which road is better (by car) routing wise. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden https://epsg4253.wordpress.com/ http://twitter.com/maningsambale -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] Routing Applications
Imagine a single-carriageway road crossing a dual-carriageway road. All turns are allowed except u-turns from one side of the dual-carriageway to the other. This common situation can only be modeled using a turn restriction with a via way. Now if the via way had to be split for any reason, then you have multiple via ways. On 6/17/15, Michael Reichert naka...@gmx.net wrote: Hi, Am 2015-06-17 um 14:38 schrieb Eugene Alvin Villar: This has been fixed in Osmand early this year after being reported more than 2 years ago. Unfortunately, multiple via ways are still not supported. I wonder if a via way instead of an via node is necessary so much. I wonder more where someone /really/ needs multiple via ways. Can you call examples for multiple via ways (link to relation)? Best regard Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] README tag with editor support
On Thu, Jun 11, 2015 at 12:27 PM, Richard Welty rwe...@averillpark.net wrote: so i have two things in mind here: 1) formalize the README tag as a way to caution future mappers 2) request editor support, when someone goes to change a README tagged entity, it would be nice if editors would popup a dialog saying something along the lines of Warning: read the following before making any changes to this object README text follows other suggestions that have been made have included trying to make the dates on which imagery was collected more obvious, adding warnings when edits are newer than available imagery (or newer than the imagery layer currently being displayed), and pressing to get more current imagery into place. does anyone have any thoughts on how to approach this? Sounds like a cross between why OSMBugs was named Notes when it was integrated into OSM, combined with a need for better tracking of categories of notes, which is something I rather liked from Mapdust. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing Applications
Hi, Am 2015-06-17 um 14:38 schrieb Eugene Alvin Villar: This has been fixed in Osmand early this year after being reported more than 2 years ago. Unfortunately, multiple via ways are still not supported. I wonder if a via way instead of an via node is necessary so much. I wonder more where someone /really/ needs multiple via ways. Can you call examples for multiple via ways (link to relation)? Best regard Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] lieu dit Bio a Montauban avec code postal 46500
a Montauban il y a un noeud bizarre : http://www.openstreetmap.org/node/469367704 qui semble correspondre à une ville plus haut : http://www.openstreetmap.org/#map=14/44.7768/1.7897 d'après l'historique ça ressemble plus a une insertion erronée corrigée plus ou moins au fil du temps. je suis d'avis de supprimer ce point, mais je ne connais pas Montauban, il y a vraiment un lieu dit Bio ? -- View this message in context: http://gis.19327.n5.nabble.com/lieu-dit-Bio-a-Montauban-avec-code-postal-46500-tp5848438.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-us] README tag with editor support
On Thu, Jun 11, 2015 at 12:27 PM, Richard Welty rwe...@averillpark.net wrote: so i have two things in mind here: 1) formalize the README tag as a way to caution future mappers 2) request editor support, when someone goes to change a README tagged entity, it would be nice if editors would popup a dialog saying something along the lines of Warning: read the following before making any changes to this object README text follows other suggestions that have been made have included trying to make the dates on which imagery was collected more obvious, adding warnings when edits are newer than available imagery (or newer than the imagery layer currently being displayed), and pressing to get more current imagery into place. does anyone have any thoughts on how to approach this? Sounds like a cross between why OSMBugs was named Notes when it was integrated into OSM, combined with a need for better tracking of categories of notes, which is something I rather liked from Mapdust. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Routing Applications
On 2015-06-17 15:08, Michał Brzozowski wrote: On Wed, Jun 17, 2015 at 2:55 PM, Eugene Alvin Villar sea...@gmail.com wrote: Imagine a single-carriageway road crossing a dual-carriageway road. All turns are allowed except u-turns from one side of the dual-carriageway to the other. This common situation can only be modeled using a turn restriction with a via way. Now if the via way had to be split for any reason, then you have multiple via ways. Isn't the restriction type (no_u_turn, no_left_turn, no_right_turn) basically just for display purposes? Because given from, to and via it only matters whether it's no_* or only_*. The solution I think is going to give correct routing would be to make a no_u_turn where one of the carriageways is from, the node at intersection is via and that small connecting segment is to. No, because then you also restrict left (or right, in LHD countries) turns. Imagine this situation (ASCII art): +--6--8--1--+ | 2 | +--5--9--3--+ | 4 | + Driving from way 1 to way 3 is not allowed (U-turn). Making a turn restricting from way 1 to way 2 via node 8 prohibits driving from way 1 to way 4 also. You have to make a restriction from way 1 to way 3 via way 2. I think you are right in saying that the type of restriction is only for display and has no real purpose for the router. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing Applications
Hi, In theory competition drives functionality improvements, although in this case it's not clear if this happened. Any map based website that doesn't include a permalink option isn't worth using, Unless it's been recently added is very well hidden OSMR hasn't this option. OSRM has the option to Generate Link at the top right of the box containing the route description (i.e. quite visible in my opinion) and has had that as long as I used their service (so not too recent). It even offers to put the link into a QR code for you. Patrick Petschge Kilian ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Regionale Ansprechpartner für openstreetmap.de gesucht
Am 17. Juni 2015 um 16:09 schrieb Dietmar ostr...@diesei.de: 4. eine Anruferin aus Dresden, die in einer Privatstraße wohnt, bei der Leute durchfahren und einer hat ihr gesagt, er würde mit einer OSM Software da durchrouten. Privatstraße im Sinne von da darf man nicht durchfahren, oder die ist in Privateigentum, aber man darf durchfahren? Viele Leute in Privatstraßen halten am liebsten jeglichen Verkehr raus, der nicht für sie ist, das ist zwar verständlich, aber wenn der Zugang für die Öffentlichkeit garantiert ist, sollte man sich davon nicht abschrecken lassen. Nur weil irgendwo ein Schild Privatstraße hängt, heisst das nichts für den Zugang. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Regionale Ansprechpartner für openstreetmap.de gesucht
Hallo, ich habe mich vor einigen Tagen auf der deutschen openstreetmap.de Website bei Kontakte [1] für den Raum Augsburg eintragen lassen. Leider sind auf dieser Seite nur wenige Ansprechpartner aufgeführt, sodaß ich schon mehrfach Anrufe bekommen habe für Gebiete, in denen aktive Communities existieren, für die auf der Seite aber niemand aufgeführt ist und ich habe da als erste Kontaktadresse wg. Augsburg wohl eine bevorzugte/benachteiligte Position ;) Ich fände es gut, wenn a) sich aus den aktiven Communities jeweils eine Person findet, die dort genannt werden darf (bitte eine Mail an mich mit den Details, ich lasse das dann eintragen) b) oder, wenn jemand dort nicht öffentlich stehen will, aber im konkreten Fall ein Anliegen annehmen will, ich seine/ihre Mail oder Telefonnummer bekomme, um diese wahlweise an den Anrufer weiterzugeben oder den Kontakt indirekt vermittle. Wenn sich für ein Gebiet niemand findet, werde ich natürlich versuchen, über lokale Mailinglisten das jeweilige Anliegen zu adressieren, aber ich bin nur auf wenigen drauf und das macht mir natürlich den größten Aufwand und das wollt Ihr doch sicher nicht, oder? ;) Damit Ihr wisst, was da so ankommt: 1. Anfrage einer Werbeagentur, ob/wie sie einen OSM-Kartenausschnitt für einen Flyer verwenden darf 2. hey, ein Augsburger, der eine Website betreibt und eine Abmahnung bekommen hat, weil er eine gedruckte Karte gescannt auf der Website verwendet hat und jetzt nach OSM wechseln will. 3. ein Anrufer vermisst im Landkreis Schweinfurt noch Buslinien, ist aber noch Mapper. Den habe ich davon abgeraten, mal eben sowas einzutragen und angeboten, das ich einen lokalen Mapper für ihn finde, dem er entweder angeben kann, was fehlt, damit der Mapper das ergänzt oder der ihm bei den ersten Mapping-Schritten helfen kann. 4. eine Anruferin aus Dresden, die in einer Privatstraße wohnt, bei der Leute durchfahren und einer hat ihr gesagt, er würde mit einer OSM Software da durchrouten. Für die Anliegen 3 und 4 werde ich vorauss. noch eine Mail erhalten mit Detailinfos und Kontaktdaten und hätte schon mal gerne jemanden, der da aktiv werden könnte. Für die überregionalen Anfragen suche ich mir natürlich die passenden Leute, wenn ich was nicht erledigen kann. viele Grüße Dietmar aka okilimu [1] http://openstreetmap.de/impressum.html ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Routing Applications
On 17/06/15 04:33, Hans De Kryger wrote: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? Am i missing something? I know it's nice to have different services for different uses but this doesn't seem like a good use of resources at all. I may be the only one with this opinion, but this has bug me for awhile. Normally I advocate against lots of duplication as there are lots of examples where several projects are all competing for the same developer pool, but here I tend towards a little diversity allows alternate algorithms to be explored. There are problems with all of the current set of routing engines and no one has the full solution. I'm stuck with OSMAND most of the time on the satnav, but have to ignore it's recommended routes locally as they are simply wrong. Last time I played with OSRM and ORS in parallel both produced different routes with some common inaccuracies. There is still enough work that needs finishing for a number of engines to co exist. When they all start producing the same 'perfect' answer then it may be time to merge some? But what is perfect for one user may be wildly wrong for another ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing Applications
OSMR requires a link to centre on a desired location so they can start a new route, not load an existing one. I'm aware of 'zoom to user' but that shares location data. Many people don't like doing that. Unless I'm missing something, the 'generate link' you describe doesn't zoom to the route. Dave F. On 17/06/2015 15:08, Patrick Kilian wrote: Hi, In theory competition drives functionality improvements, although in this case it's not clear if this happened. Any map based website that doesn't include a permalink option isn't worth using, Unless it's been recently added is very well hidden OSMR hasn't this option. OSRM has the option to Generate Link at the top right of the box containing the route description (i.e. quite visible in my opinion) and has had that as long as I used their service (so not too recent). It even offers to put the link into a QR code for you. Patrick Petschge Kilian ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] lieu dit Bio a Montauban avec code postal 46500
De: Cactusbone cactusb...@free.fr bien vu ! Merci ! je fait ça ! je laisse la population pour le moment, même si c'est proche de la population de la ville de Bio Alors à mon tour de dire 'bien vu !' :) 256 c'est en effet la population de la commune de Bio(46) au recensement de 1999 : http://www.recensement-1999.insee.fr/default.asp?asp_action=produitc_typeprod=DDSc_prod=E_DEMOc_theme=ALLc_codgeo=46030c_nivgeo=C Ça ressemble vraiment à un copier/coller un peu rapide des données de la commune. Donc finalement je vote pour la suppression du tag population, aussi. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Routing Applications
2015-06-17 16:27 GMT+02:00 Lester Caine les...@lsces.co.uk: On 17/06/15 04:33, Hans De Kryger wrote: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? as far as I understand these 2 services use different algorithms, where OSRM is very fast in calculating and guarantees the best route (according to the map data), ORS can handle multiple means of transport much cheaper (e.g. bike routing, truck routing, foot routing) and has features like avoid area which I don't know if OSRM does offer. Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-ht] Le bonjour à OSM Haiti
Bonjour la communauté OSM Haïti, Cela fait un bout de temps depuis 2013, difficile d’oublier Haïti cependant. Je continue à être en contact avec certains d’entre vous, et je remercie les personnes ayant pris de mes nouvelles et aux autres qui ont continué l’adaptation des outils OpenSource dans leurs communautés. *Fin 2013/Début 2014 :* J’ai pu monter avec Presler et Cartong (Aurélien) un projet UAV, pour avoir la 1ere mission 100% dédiée pour OSM Haïti après le refus de HOT de faire des formations sur le projet CAP103. (Projet souvent monté la nuit, en dehors de mes horaires de travail). Nous avons pu vous sensibiliser aux outils Drones et réaliser de nombreux vols sur vos zones d’intérêts, très peu suivi d’ailleurs d’une cartographie. Je ne doute pas que ces images peuvent servir et je comprends bien que vos priorités ne soient pas uniquement tournées vers la cartographie OSM. Nous n’avons pas pu laisser le Drone qui coute très cher à la maintenance (après la mission de 2014 il a fallu débourser 2500 euro pour remettre en état le drone. Ce qui est un cout non négligeable après 10 jours de missions. La leçon apprise est qu’il est important de bien former des pilotes expérimentés pour limiter la casse et prévoir des drones de formation (mais on n’a jamais eu le budget pour cela, ni l’infrastructure). *Fin 2014/Début 2015 :* comme chaque vacances que je peux poser, j’avais commencé à imaginer /discuter un projet pour soutenir deux makers Space , celui d’*Infotronic* * = Et celui d’*Haïti communiterre * ***(Infotronic à reçu fin 2014 de data center accueillant des serveurs dans des conteneurs, le directeur a proposé à OSM de la place dans ce data serveur). PS : Pour vous diffuser les images satellites et Drones nous utilisons des serveurs qui se trouvent dans des universités ou école. C’est un fonctionnement commun à OSM car nous n’avons pas de budget propre pour cela. PS2 : Nous avons grillé le serveur qui contenait les images drones Haïti de 2014, les deux disques étant grillés nous n’avons plus d’image de 2014. Jusqu’à nouvelle ordre. Voir projet ci-dessous : https://www.dropbox.com/s/22l4552xig0rlig/Dossier_MakerSpace_General_27Fev2015.docx?dl=0 PS3 : Le projet n’a pas trouvé de financement, car il faut à la fin du financement pour réaliser des actions : ) Au plaisir de réaliser des projets avec vous et bonne continuation à tous, FredM ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
Re: [Talk-de] Privatwege - Regionale Ansprechpartner für openstreetmap.de gesucht
On Wed, 17 Jun 2015, Martin Koppenhoefer wrote: Am 17. Juni 2015 um 16:09 schrieb Dietmar ostr...@diesei.de: 4. eine Anruferin aus Dresden, die in einer Privatstraße wohnt, bei der Leute durchfahren und einer hat ihr gesagt, er würde mit einer OSM Software da durchrouten. Privatstraße im Sinne von da darf man nicht durchfahren, oder die ist in Privateigentum, aber man darf durchfahren? Viele Leute in Privatstraßen halten am liebsten jeglichen Verkehr raus, der nicht für sie ist, das ist zwar verständlich, aber wenn der Zugang für die Öffentlichkeit garantiert ist, sollte man sich davon nicht abschrecken lassen. Nur weil irgendwo ein Schild Privatstraße hängt, heisst das nichts für den Zugang. Privatstrassen sind, wie der Name schon sagt, in privatem Besitz, d.h. da gilt erstmal das Hausrecht des Besitzers. Wenn ein Anwesen nur ueber diesen Privatweg zu erreichen ist, gilt aber das Zufahrtsrecht, d.h. der Anwohner oder dessen Besucher duerfen diesen Weg nutzen. Wenn ein Privatweg im Routing als Abkuerzung genutzt wird, aergert das verstaendlicherweise den Besitzer und ist auch nicht gestattet. Das ist aber eher eine Frage des Routers, ob und wie er diese Information auswertet. Und ich weiss aus eigener Erfahrung, dass viele Privatwege durch Bauernhoefe laufen, wo oft ein unfreundlicher Hund lauert ;) Das moechte man gerade beim bike-routing vermeiden. A. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-co] State of the Map LatAm 2015
-- Mensaje reenviado -- De: talk-co-boun...@openstreetmap.org Fecha: 17 de junio de 2015, 10:06 Asunto: Notificación de descarte automático Para: talk-co-ow...@openstreetmap.org -- Mensaje reenviado -- From: Julio Costa Zambelli julio.co...@openstreetmap.cl Date: Wed, 17 Jun 2015 12:05:48 -0300 Subject: State of the Map LatAm 2015 Estimados, Solo recordarles a quienes quieran asistir al ConDatos, Abrelatam y State of the Map LatAm en Santiago durante los primeros días de Septiembre (4 al 10), con ayuda de las becas del ConDatos (http://www.condatos.org/), las postulaciones a estas cierran el 19 de Junio (en 2 días). Debemos aclarar que esas becas son completamente independientes de nuestro evento y NO tenemos control sobre su asignación o si habrá flexibilidad de fechas como para que puedan viajar a Santiago en las fechas que les permitan asistir al SotM LatAm 2015. Por lo que el querer asistir al State of the Map no es un argumento de postulación. De todas formas nos mantendremos en contacto con los organizadores del ConDatos para procurar que así sea. Quienes quieran postular, háganlo ahora. Saludos, Julio Costa Zambelli Fundación OpenStreetMap Chile julio.co...@openstreetmap.cl http://www.openstreetmap.cl/ Cel: +56(9)89981083 ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [OSM-talk-fr] YoHours (était: outil user-friendly pour taguer les horaires opening_hours)
Tant que nous sommes dans les suggestions, j'imagine tout à fait un outil de ce type, adapté au tactile, et intégré dans DesignMyApp. C'est sans doute à voir avec eux. A+ Stf Le 17/06/2015 18:10, PanierAvide a écrit : Merci à tous pour vos remarques et suggestions (parfois nombreuses) ;) Je note tout cela, et je me chargerai d'intégrer ça pour la prochaine version. Par contre je suis pas certain que mettre les jours en ligne soit une bonne idée, justement parce que la plupart de présentation de ce type (agendas) sont avec des jours en colonnes. Les dates spéciales ou saisons seront dans des onglets, avec un calendrier spécifique à chaque saisonnalité définie (à étudier, c'est pas encore fait). L'idée du widget est intéressante, ça permettrait d'intégrer le composant à d'autres outils. Cordialement. Le 17/06/2015 10:10, Philippe Verdy a écrit : La taille vertical est beaucoup trop grande, ce qui oblige au scroll vertical et ne facilite pas les choses (parce que la sélection se fait par cellules entières). Il n'y a pas moyen de faire des rectangles beaucoup moins haut, quite à aller à la précision du pixel et une heure indicative à) quelques minutes près qu'on peut encore ajuster dans le champ texte ? (peut-être avec un zoom avant/arrière si on veut vois plus de précision des heures) Sinon seule la dernière cellule permet de changer la durée d'une période et d'évidence on devrait pouvoir sélectionner un bord droit ou gauche pour étendre sur plusieurs jours successifs. Autre problème: seule la dernière cellule permet de changer la durée, les autres déplacent la zone qui peut sortir des limites de la table. La première cellule devrait aussi avoir son bord supérieur déplaçable, et dans tous les cas la sélection ne peut pas sortir des 7 jours (sinon cela doit soit boucler, soir tronquer : la remarque vaut aussi bien pour ce qui est avant la première cellule que ce qui est après car le déplacement n'en tient pas compte) L'idée étant que dans tous les cas cela doit tenir dans la fenêtre. Là c'est une présenttion de type agenda comme s'il y avait du texte à saisir dans les cellules pour noter un événement ou un rendez-vous. J'aurais plutôt mis les heures sur l'axe horizontal et les jours (ou autres lignes pour les dates PH, etc...) sur l'axe vertical (dans ce cas le zoom des heures est un zoom de l'axe horizontal mais le zoom par défaut affiche les 24 heures). Ca pourrait alors devenir un widget intégrable dans un formulaire, ou même un popup d'information (seule différence: le popup d'information n'est pas éditable, il affiche juste la valeur du champ et le tableau en dessous, et le zoom n'est pas absolument nécessaire pour cette présentation statique), y compris depuis un site externe qui pourrait afficher les deux dans un IFRAME (sans aucune autre décoration: juste le champ texte et le tableau, voire seulement le tableau, sans aucune marge) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Routing Applications
On Wed, 2015-06-17 at 09:00 +, Janko Mihelić wrote: If you ask me, they are all in their infancy. Non of these routing services even route right. In a turn restriction the via role can be a way. Neither OSRM, ORS or GraphHopper knows how to restrict that, and that's IMHO one of the crucial parts of a routing engine. When one of them starts routing right, than we can talk about picking a winner service. Right now only MapQuest knows how to route. Janko The other common thing that is missing from routing instructions is support for mini-roundabouts, tomtom certainly don't do this so it is something that OSM routing could pull ahead on. Phil (trigpoint)___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[osm-ve] State of the Map LatAm 2015
Estimados, Solo recordarles a quienes quieran asistir al ConDatos, Abrelatam y State of the Map LatAm en Santiago durante los primeros días de Septiembre (4 al 10), con ayuda de las becas del ConDatos (http://www.condatos.org/), las postulaciones a estas cierran el 19 de Junio (en 2 días). Debemos aclarar que esas becas son completamente independientes de nuestro evento y NO tenemos control sobre su asignación o si habrá flexibilidad de fechas como para que puedan viajar a Santiago en las fechas que les permitan asistir al SotM LatAm 2015. Por lo que el querer asistir al State of the Map no es un argumento de postulación. De todas formas nos mantendremos en contacto con los organizadores del ConDatos para procurar que así sea. Quienes quieran postular, háganlo ahora. Saludos, Julio Costa Zambelli Fundación OpenStreetMap Chile julio.co...@openstreetmap.cl http://www.openstreetmap.cl/ Cel: +56(9)89981083 ___ Talk-ve mailing list Talk-ve@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ve
Re: [Talk-de] Regionale Ansprechpartner für openstreetmap.de gesucht
Hallo Dietmar, Am 2015-06-17 um 16:09 schrieb Dietmar: Ich fände es gut, wenn a) sich aus den aktiven Communities jeweils eine Person findet, die dort genannt werden darf (bitte eine Mail an mich mit den Details, ich lasse das dann eintragen) b) oder, wenn jemand dort nicht öffentlich stehen will, aber im konkreten Fall ein Anliegen annehmen will, ich seine/ihre Mail oder Telefonnummer bekomme, um diese wahlweise an den Anrufer weiterzugeben oder den Kontakt indirekt vermittle. An welche Ansprechpartnerdichte denkst du denn? Einer pro Landkreis ist IMHO Overkill, da können wir gleich ein Callcenter eröffnen :-) Einer pro Bundesland (große/bevölkerungsstarke ggf. mehr) könnten es jedoch schon sein. Derzeit stehen dort Ansprechpartner für Augsburg, Ruhrgebiet, Hessen (Wiesbaden/Frankfurt), Saarland/Trier und Österreich. Wenn sich für ein Gebiet niemand findet, werde ich natürlich versuchen, über lokale Mailinglisten das jeweilige Anliegen zu adressieren, aber ich bin nur auf wenigen drauf und das macht mir natürlich den größten Aufwand und das wollt Ihr doch sicher nicht, oder? ;) Oder man definiert für die nächstgelegenen Nachbarn einfach ein größeres Gebiet. Wenn also z.B. sich kein Leipziger findet, dann steht beim Dresdner Ansprechpartner nicht Dresden, sondern Sachsen oder Mitteldeutschland. Damit Ihr wisst, was da so ankommt: 1. Anfrage einer Werbeagentur, ob/wie sie einen OSM-Kartenausschnitt für einen Flyer verwenden darf 2. hey, ein Augsburger, der eine Website betreibt und eine Abmahnung bekommen hat, weil er eine gedruckte Karte gescannt auf der Website verwendet hat und jetzt nach OSM wechseln will. 3. ein Anrufer vermisst im Landkreis Schweinfurt noch Buslinien, ist aber noch Mapper. Den habe ich davon abgeraten, mal eben sowas einzutragen und angeboten, das ich einen lokalen Mapper für ihn finde, dem er entweder angeben kann, was fehlt, damit der Mapper das ergänzt oder der ihm bei den ersten Mapping-Schritten helfen kann. 4. eine Anruferin aus Dresden, die in einer Privatstraße wohnt, bei der Leute durchfahren und einer hat ihr gesagt, er würde mit einer OSM Software da durchrouten. Für die Anliegen 3 und 4 werde ich vorauss. noch eine Mail erhalten mit Detailinfos und Kontaktdaten und hätte schon mal gerne jemanden, der da aktiv werden könnte. Das Team der Wochennotiz hat ja auch eine öffentliche Mailadresse, die gleichzeitig die teaminterne Mailingliste ist. Wir haben vor einigen Monaten auf unserer Kontaktseite folgenden Hinweis ergänzt: https://blog.openstreetmap.de/kontakt/ schreibt: Hinweise für die Wochennotiz oder Fragen rund um das Blog nehmen wir gerne entgegen. Für andere Fragen gibt es eine Vielzahl von Webseiten (OSM-Wiki, FAQ) und Foren, die helfen könnten. OSM-Wiki verlinkt auf https://wiki.openstreetmap.org/wiki/DE:Main_Page FAQ verlinkt auf https://help.openstreetmap.org/ Foren verlinkt auf http://forum.openstreetmap.org/viewforum.php?id=14 Seither hat das Mailaufkommen deutlich nachgelassen. Statt vorher weniger als zehn Mails pro Monat trifft nun nur noch alle sechs Wochen eine Mail an, die nicht im Zusammenhang mit der Wochennotiz steht (oder Spam ist). Mails, die trotzdem bei uns landen, werden dann mit einer Langfassung des obigen freundlich beantwortet. Man könnte darüber nachdenken, einen ähnlichen Text auch auf openstreetmap.de bei den Kontaktdaten zu platzieren. Vielleicht wandert dann die ein oder andere Anfrage auf eine Mailingliste oder ins Forum. Dort lesen mehrere Leute und die Mail geht nicht unter. (Öffentliche Kanäle sind nicht für alle Zwecke geeignet, aber für vieles) Wie wäre es mit diesem Text. OpenStreetMap ist ein Community-Projekt, das von Tausenden Leuten gemeinsam vorangetrieben wird. Daher gibt es keinen offiziellen Ansprechpartner und keinen Vorsitzenden. Bei Fragen wenden Sie sich bitte an einen der folgenden Community-Kommunikationskanäle: - deutsche Mailingliste (Anmeldung vorher erforderlich) - regionale deutsche Mailinglisten (Anmeldung vorher empfohlen) [1] - deutschsprachiges OpenStreetMap-Forum - OSM Help Sollte man vielleicht zur SOSM und OpenStreetMap Austria als deutschsprachige Nachbarvereine verlinken? Viele Grüße Michael [1] Diese Listen sind so klein und überschaubar, dass der Moderator auch mal eine Mail von einem Nicht-Abonnenten freigeben kann – für die großen Listen wie diese hier ist das jedoch keine Option. -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-pe] State of the Map LatAm 2015
Estimados, Solo recordarles a quienes quieran asistir al ConDatos, Abrelatam y State of the Map LatAm en Santiago durante los primeros días de Septiembre (4 al 10), con ayuda de las becas del ConDatos (http://www.condatos.org/), las postulaciones a estas cierran el 19 de Junio (en 2 días). Debemos aclarar que esas becas son completamente independientes de nuestro evento y NO tenemos control sobre su asignación o si habrá flexibilidad de fechas como para que puedan viajar a Santiago en las fechas que les permitan asistir al SotM LatAm 2015. Por lo que el querer asistir al State of the Map no es un argumento de postulación. De todas formas nos mantendremos en contacto con los organizadores del ConDatos para procurar que así sea. Quienes quieran postular, háganlo ahora. Saludos, Julio Costa Zambelli Fundación OpenStreetMap Chile julio.co...@openstreetmap.cl http://www.openstreetmap.cl/ Cel: +56(9)89981083 ___ Talk-pe mailing list Talk-pe@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pe
Re: [OSM-talk] Routing Applications
Hi, Am 2015-06-17 um 05:33 schrieb Hans De Kryger: Why do OSRM OpenRoutingService compete against each other instead of joining resources and combining efforts to make the best routing service out there? Am i missing something? There are differences in history between these two projects. ORS (OpenRouteService) is a project started by University of Heidelberg as a closed-source project in 2010 (?). It was dead between 2012 and 2014, i.e. no data update, no bugfixing because it is a university project. Open Source Routing Machine (OSRM) was started by Dennis Luxen who gained a PhD at Karlsruhe Institute of Technology. Afterwards he worked for Mapbox which now contributes much to OSRM. Summarized: OSRM is a commercial open source project and ORS is a university project. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
