[Talk-cat] Editors d'Osona
Bon dia de nou, volia fer una crida per aquí per saber qui més hi ha a la llista que estigui editant per la comarca d'Osona. Penso que estaria bé que estiguem en contacte per coordinar-nos una mica i saber què està fent cadascú. Es podria fer una llesta d'usuaris que hagin editat en aquesta zona els últims mesos/anys per posar-nos-hi en contacte? Moltes gràcies a tots! Fermí ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
[OSM-talk] Layers and landuse
I recently taught my rendering hack about the ’layer’ tag, and immediately encountered a set of new problems. For example, consider this ditch: http://www.openstreetmap.org/way/243331898 http://www.openstreetmap.org/way/243331898 . It has layer=-1, probably to indicate that is passes under the road which it crosses. However, it is entirely covered by a landuse=farmland with no layer tag, which I take to mean an implicit layer=0. This means that my renderer now renders the farmland over the ditch, completely hiding the latter. Meanwhile, Mapnik obviously does what the tagger intended. Is this a tagging error, that I should fix by editing the data, or is it something that my renderer should be able to cope with? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cat] Majúscules i minúscules
Gràcies per la resposta Carlos, però no em serveix, a Vic hi ha molts carrers on la placa està completament en majúscules https://www.google.es/maps/@41.932942,2.256578,3a,20.9y,285.54h,94.59t/data=%213m6%211e1%213m4%211skw3SkUzdFNg_HI966z3uMg%212e0%217i13312%218i6656?hl=ca. Fermí El 27/06/2015 a les 11:41, Carlos Sánchez ha escrit: Jo el que faig es escriure-ho tal i com apareix a peu de carrer si tinc dubtes. El dia 27 de juny de 2015, 9:29, Fermí Tanyà ferm...@gmx.net mailto:ferm...@gmx.net ha escrit: Bon dia, Tenia entès que els noms (name) que s'introdueixen a OSM han d'anar en minúscules, excepte quan es tracta de nom propis. Segons el meu entendre s'hauria d'escriure carrer de Jacint Verdaguer i no pas Carrer de Jacint Verdaguer. Llavors és cosa del renderitzador tractar les majúscules i minúscules segons cregui necessari. Vaig equivocat o ho tinc mal entès? Jo ho estava fent així, i modificava els que trobava fets de l'altra manera per coincidir amb aquest criteri de no començar amb majúscules, però ara m'he trobat aquest changset http://www.openstreetmap.org/changeset/31908020 on veig un usuari que s'ha dedicat a canviar-ho en sentit contrari al que jo pensava que era el correcte. M'ho podeu aclarir els que teniu més experiència i coneixement del tema? Fermí ___ Talk-cat mailing list Talk-cat@openstreetmap.org mailto:Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat -- *Carlos Sánchez *About.me http://about.me/carlos.sanchez* * ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
[Talk-cz] WeeklyOSM CZ 256
Ahoj, je dostupné vydání 256 týdeníku weeklyOSM: http://www.weeklyosm.eu/cz/archives/4205 Téma čísla: landuse * Sbírka na nové servery. * Import LPIS dokončen. * Kalendář OSM akcí. * Přednáška o RapidJSON. * I OSM má své pískoviště. Pěkné počtení... ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
Autre problème avec cette analyse osmose: on avait utilisé jusque maintenant ref=* et pas ref:FR:LaPoste... - le rapprochement fait pas osmose ne semble pas se faire (ou alors la tolérance de distance est insuffisante). - les formulaires de JOSM prennent en compte ref=* - on va avoir un mix entre les deux... Il faut à mon avis vraiment la revoir, car entre la mauvaise qualité du géocodage initial fait par La Poste et ces tags en contradiction avec ce qui a été fait jusque maintenant on risque sérieusement de dégrader plutôt que d'améliorer les données OSM. Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite aux lettres. Faites attention aussi à la fraicheur des données... dans mon bled bourguignon, il y a plusieurs boites aux lettres qui ont été supprimées à l'automne dernier, mais qui sont encore dans ce fichier opendata. Le 26 juin 2015 22:06, erwan salomon r...@gmx.fr a écrit : si ça peut aider dans mon coin (Plœmeur 56270, mais aussi un peu les villes limitrophes) Osmose me propose 3 erreurs par boites aux lettres 1 *Boîte postale sans ref:FR:LaPoste* (en violet) 1 *Boîte postale, proposition d'intégration* (en vert) 1 *Boîte postale non intégrée* (en vert) à 1-5 m de la boite déjà présente (une bonne partie me semble acceptable à ~1m près, quelques boites sont très mal placée cf l'aéroport 10-20 m) ça fait beaucoup pour la même boite je précise que les boites de ce coin ont été mapées par moi même en cumulant photo perso pour le repérage précis et photo bing (je ne connaissais pas l'orthophoto de la région Bretagne à l'époque) en plus d'une bonne connaissance de leur position relative aux bâtiments (j'ai travaillé un temps comme facteur, j'en connais une bonne part de mémoire) je suis donc confiant sur leurs positions à disons 0,5-1 m (même si j'ai pu me tromper par moments) http://osmose.openstreetmap.fr/fr/map/#item=7051%2C8022%2C8023zoom=13lat=47.7354lon=-3.4318layer=Mapnikoverlays=FFFT Le 26 juin 2015 à 13:52, Christian Quest a écrit : Oui, il y a un mix. Je suis en contact avec le responsable côté Poste et j'avais eu le fichier entre les mains il y a déjà quelques semaines. J'avais remonté des problèmes, suggéré de re-géocoder ça avec la BAN via addok, mais visiblement ça n'a pas été fait. Ce qu'on peut aussi faire, c'est comparer les lat/lon retournés par addok+BAN à ceux fournis. Si il y a trop de différence, il faut faire attention. Le 25/06/2015 23:09, Frédéric Rodrigo a écrit : Vu la description de la fiabilisation sur data.gouv ça ne doit pas être autre chose que du géocodage. À relire l'explication je me demande s'il ne mélangent pas adresse et coordonnées géographiques. Je vais poser la question. Le 25/06/2015 22:52, Christian Quest a écrit : ça sent TRES fort le géocodage... et le géocodage pas frais. As-tu essayé de re géocoder ça avec addok/BAN sur adresse.data.gouv.fr http://adresse.data.gouv.fr ? ça évitera d'en avoir en plein champs ;) Le 25 juin 2015 22:31, Pierre-Yves Berrard pierre.yves.berr...@gmail.com mailto:pierre.yves.berr...@gmail.com pierre.yves.berr...@gmail.com a écrit : Le 25 juin 2015 22:05, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com fred.rodr...@gmail.com a écrit : Bonsoir, Depuis quelques jours les boites au lettre de la poste dans l'espace public sont disponible sur data.gouv.fr http://data.gouv.fr https://www.data.gouv.fr/fr/datasets/liste-des-boites-aux-lettres-de-rue-france-metropolitaine-et-dom-1/ La qualité est assez bonne mais ça sent quand même le géocodage. Elles sont disponibles pour intégration dans Osmose : http://osmose.openstreetmap.fr/fr/map/#item=7051,8022,8023 C'est un peu comme un saint Graal qui devient accessible ;) Frédéric, mappeur de ref de boites aux lettres. Sympa. Je vais regarder si ça colle avec les ref que j'ai déjà rentrées. PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ 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 -- Christian Quest - OpenStreetMap France ___ 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 -- Christian Quest - OpenStreetMap
Re: [Talk-it] Aggiornamento dei distributori di carburante
sent from a phone Am 26.06.2015 um 19:20 schrieb Aury88 spacedrive...@gmail.com: sono d'accordo che non sia un brand, allora dovrebbe essere chiaro che non va taggato come tale ;-) ma è anche vero che abbiamo un tag riferito ai brand e un value che per convenzione indica che non c'è il brand. bo, quella convenzione non la conoscevo e non ricordo che fosse stato deciso da qualche parte (ma chiaramente il mondo osm è troppo grande per seguire tutto) ..fin quando non ci sarà ambiguità nel significato del value Indipendent a causa della comparsa di un brand chiamato con la stessa stringa secondo me non è un grosso problema. non capisco perché dovremmo insistere in un modo di taggare che non funziona e che non è documentato bene http://wiki.openstreetmap.org/wiki/Key:brand (non c'è riferimento) http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel (nemmeno) ciao Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-cat] Majúscules i minúscules
Hola, jo ho tinc entès com tu. Crec que fa molt temps es va comentar a la llista. Ara no sóc a casa i no ho puc buscar, cal recuperar aquells correus i informar a l'usuari. Salut! On 27 June 2015 11:52:41 CEST, Fermí Tanyà ferm...@gmx.net wrote: Gràcies per la resposta Carlos, però no em serveix, a Vic hi ha molts carrers on la placa està completament en majúscules https://www.google.es/maps/@41.932942,2.256578,3a,20.9y,285.54h,94.59t/data=%213m6%211e1%213m4%211skw3SkUzdFNg_HI966z3uMg%212e0%217i13312%218i6656?hl=ca. Fermí El 27/06/2015 a les 11:41, Carlos Sánchez ha escrit: Jo el que faig es escriure-ho tal i com apareix a peu de carrer si tinc dubtes. El dia 27 de juny de 2015, 9:29, Fermí Tanyà ferm...@gmx.net mailto:ferm...@gmx.net ha escrit: Bon dia, Tenia entès que els noms (name) que s'introdueixen a OSM han d'anar en minúscules, excepte quan es tracta de nom propis. Segons el meu entendre s'hauria d'escriure carrer de Jacint Verdaguer i no pas Carrer de Jacint Verdaguer. Llavors és cosa del renderitzador tractar les majúscules i minúscules segons cregui necessari. Vaig equivocat o ho tinc mal entès? Jo ho estava fent així, i modificava els que trobava fets de l'altra manera per coincidir amb aquest criteri de no començar amb majúscules, però ara m'he trobat aquest changset http://www.openstreetmap.org/changeset/31908020 on veig un usuari que s'ha dedicat a canviar-ho en sentit contrari al que jo pensava que era el correcte. M'ho podeu aclarir els que teniu més experiència i coneixement del tema? Fermí ___ Talk-cat mailing list Talk-cat@openstreetmap.org mailto:Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat -- *Carlos Sánchez *About.me http://about.me/carlos.sanchez* * ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
question bête vous avez pris en compte que le mode de projection varie en fonction des points enregistrés ? bon j'y connais pas grand chose alors je ne sais pas quelle influence ça a mais une grosse partie du fichier utilise ESPG :2154 puis ont trouve quelques EPSG :2975 et EPSG :102113 Le 25 juin 2015 à 22:05, Frédéric Rodrigo a écrit : Bonsoir, Depuis quelques jours les boites au lettre de la poste dans l'espace public sont disponible sur data.gouv.fr https://www.data.gouv.fr/fr/datasets/liste-des-boites-aux-lettres-de-rue-france-metropolitaine-et-dom-1/ La qualité est assez bonne mais ça sent quand même le géocodage. Elles sont disponibles pour intégration dans Osmose : http://osmose.openstreetmap.fr/fr/map/#item=7051,8022,8023 C'est un peu comme un saint Graal qui devient accessible ;) Frédéric, mappeur de ref de boites aux lettres. ___ 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-be] Bruxelles centre : nouveau piétonnier
Hi Benoit, I downloaded the data and fixed it. It involved detaching the node from the landuse, then moving it back for about a kilometer. When one can zoom in and out while dragging a selection this is not hard to do. I have no idea how to accomplish that with iD, but since I don't know how to use it, I don't know how to accomplish anything with it. Thanks for reporting it. Jo 2015-06-26 18:52 GMT+02:00 Benoit Leseul benoit.les...@gmail.com: Hi everyone, Great work on the pedestrian area! I see a problem with the Delhaize Anspach object though, not totally sure how to fix it (at least in iD, maybe it's easy with JOSM) : https://www.openstreetmap.org/way/244955720 -- Benoit 2015-06-25 18:21 GMT+02:00 Matthieu Gaillet mgwebm...@fastmail.fm: - Switching to english since most people are talking english here - So I just did the upload, changeset #32208516. No conflict at all for 550 modified objects. Joy ! :-) Matthieu On 25 Jun 2015, at 16:24, Jo winfi...@gmail.com wrote: Cela me semble préférable à une nuit passé à resoudre des conflits... 2015-06-25 16:11 GMT+02:00 Matthieu Gaillet matth...@gaillet.be: Alors si personne n’est contraire j’uploade ce soir. Il est vrai que le temps que les serveurs propagent la mise à jour et que les utilisateurs le fassent également ça nous laisse de la marge. On 25 Jun 2015, at 16:07, Jo winfi...@gmail.com wrote: En fait, il ne serait même pas si grave si nous sommes un peu trop tôt... 2015-06-25 16:00 GMT+02:00 Matthieu Gaillet matth...@gaillet.be: Merci Jo. Comme je m’ennuyais hier soir, j’ai commencé le boulot, essentiellement changer des tags aux routes existantes, des sens de circulation, et tracer des areas pedestrian. Le reste (pistes cyclables notamment, elle sont entrain d’être tracées) pourra être fait par après. L’idée est de faire en sorte qu’OSM soit prêt à minuit pile ;) Si ça marche on pourrait d’ailleurs en faire un communiqué de presse... J’espère que cette partie au moins ne posera pas trop de souci. Je vous ferai un retour d’expérience. Matthieu On 25 Jun 2015, at 13:00, Jo winfi...@gmail.com wrote: Salut Matthieu, J'attendrai simplement le jour que ça change et puis je commencerais de changer petit à petit. Si tu vas préparer des fichiers une semaine à l'avance, tu risques d'avoir beaucoup de conflits à resoudre. Jo 2015-06-24 17:26 GMT+02:00 Matthieu Gaillet mgwebm...@fastmail.fm: Hello, Dans quelques jours, le centre-ville de Bruxelles va être bouleversé par la mise en place d’un piétonnier, et surtout de la fermeture des axes principaux aux voitures et de la mise en place d’un « mini-ring » ou « boucle de desserte ». La majeure partie des changements est déjà connue via le site officiel de la Ville : http://plandecirculation.be/ Questions : 1°) pouvons-nous utiliser ces informations pour mettre à jour OSM ? Remarquez l’usage de Mapbox au passage ! 2°) est-ce que cela vaut la peine de préparer un changeset et de l’uploader dans une petite semaine ? 3°) est-ce d’autres mappeurs travaillent déjà là-dessus ? Si oui, comment coordonner tout ça ? Cette question vaut de manière générale pour tout changement d’envergure et planifié... Merci de vos réponses ! Matthieu ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] Using OSM data without modifying - are there any guidelines?
Simon Poole wrote: As the name of this list says it is legal talk (aka yapping without consequence) ... not get-help-from-the-OSMF. With my list admin hat on, I think that's a little harsh. Often, as you say, queries can be resolved by pointing to the relevant published guidelines and there's no reason why the community can't do this on this list - or on help.osm.org, or wherever - rather than burdening LWG with the task of fielding so many routine enquiries. legal-talk@ is not a bad first port of call. It is indeed only a -talk list but we don't necessarily need to bite people who come to talk. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Using-OSM-data-without-modifying-are-there-any-guidelines-tp5848948p5849030.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Layers and landuse
On 27/06/15 10:40, Ture Pålsson wrote: I recently taught my rendering hack about the ’layer’ tag, and immediately encountered a set of new problems. For example, consider this ditch: http://www.openstreetmap.org/way/243331898 . It has layer=-1, probably to indicate that is passes under the road which it crosses. However, it is entirely covered by a landuse=farmland with no layer tag, which I take to mean an implicit layer=0. This means that my renderer now renders the farmland over the ditch, completely hiding the latter. Meanwhile, Mapnik obviously does what the tagger intended. Is this a tagging error, that I should fix by editing the data, or is it something that my renderer should be able to cope with? This is not a tagging error. You should have different sets of layers for different things. Usually areas are in a lower set of layers than lines, meaning that all areas are rendered below lines. This makes tunnels visible below a forest and similar things. And also your example is covered by this. Michael ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cat] Editors d'Osona
Hola Fermí, Segurament hi ha fórmules més fàcils, però potser això et serveix: http://resultmaps.neis-one.org/oooc?zoom=11lat=41.9243lon=2.25864layers=B00TFT Amb aquesta eina vam elaborar el llistat de contribuïdors catalans per informar-los a través del correu intern d'OpenStreetMap de la creació de la llista talk-cat. Salut! El dia 27 de juny de 2015, 9:35, Fermí Tanyà ferm...@gmx.net ha escrit: Bon dia de nou, volia fer una crida per aquí per saber qui més hi ha a la llista que estigui editant per la comarca d'Osona. Penso que estaria bé que estiguem en contacte per coordinar-nos una mica i saber què està fent cadascú. Es podria fer una llesta d'usuaris que hagin editat en aquesta zona els últims mesos/anys per posar-nos-hi en contacte? Moltes gràcies a tots! Fermí ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat -- *KONFRARE ALBERT* La Konfraria de la Vila del Pingüí de La Palma de Cervelló www.konfraria.org • @La_Konfraria http://twitter.com/La_Konfraria ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [OSM-legal-talk] Using OSM data without modifying - are there any guidelines?
Naturally, in a perfect world, you are correct. Unluckily experience shows (both here and on help) that the responders don't point to the guidelines and the other relevant material (at best they refer to outdated pre-licence change wiki pages) they offer their own, not clearly identified as such, opinions. Now if the people asking the questions were aware of that and took the answers with multiple grains of salt, you could say: ok, let the armchair lawyers have their fun. Alas what happens is that it simply provides perfect material for the FUD-mongers. For the record, the OSMFs policies are enshrined in the following places: http://www.openstreetmap.org/copyright http://wiki.osmfoundation.org/wiki/License http://wiki.osmfoundation.org/wiki/License/Community_Guidelines Simon Am 27.06.2015 um 10:23 schrieb Richard Fairhurst: Simon Poole wrote: As the name of this list says it is legal talk (aka yapping without consequence) ... not get-help-from-the-OSMF. With my list admin hat on, I think that's a little harsh. Often, as you say, queries can be resolved by pointing to the relevant published guidelines and there's no reason why the community can't do this on this list - or on help.osm.org, or wherever - rather than burdening LWG with the task of fielding so many routine enquiries. legal-talk@ is not a bad first port of call. It is indeed only a -talk list but we don't necessarily need to bite people who come to talk. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Using-OSM-data-without-modifying-are-there-any-guidelines-tp5848948p5849030.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-es] Subir el censo de locales de Madrid
Buenos días a tod@s Pues claro que la solución sería combinar ambos métodos, ya me suponía que empezaría a tomar forma por ahí :-). Estáis pensando lo mismo que yo [1] Por favor, no me malinterpretéis. Cuando hablo de problemas me refiero a cosas con las que hay que contar para ir enumerando tareas a cumplir. Como ingeniero, para mí un problema es algo a solucionar y cuando digo tedioso es algo digno de ser automatizado. Respecto a las próximas mapping parties, se está gestando una en Tetuán con iniciativas vecinales de la zona. Será para después del verano. La semana que viene espero poder daros unas fechas y un marco geográfico de acción. Quieren darle el tinte de accesibilidad que le hemos puesto a las últimas, teniendo en cuenta que es un buen reclamo para animar a la gente a que se apunte. Yo sigo con mi labor de recordatorio de la etiqueta weelchair a la hora de introducir nuevos datos. Decir también que no son solo los locales comerciales lo que revisaremos. A partir de la reunión de la semana que viene espero estar en contacto con alguien que lleve esta iniciativa hasta los oídos del Ayuntamiento, para ver cómo podríamos colaborar. Pienso tanto en el aspecto técnico como en el de la difusión, cara a hacer varias acciones sincronizadas en distintos barrios. Insisto en no perder nunca el aspecto social (con un equipo de geofrikis virtuales apoyando en la sombra, por supuesto ;-) Si tenéis canal con el Ayto. no dudéis en usarlo, pero esperad a que tengamos fecha en la agenda. También pienso en el IGN, que queda al lado. Al ser multitud de datos y no tener ni la más remota idea de la calidad de los mismos (sin ofender, pero poco metadatos he visto en esos juegos de datos), mi propuesta es centrarnos en un piloto en esa zona para detectar errores comunes y tomar nota para estar un poco más seguros de lo que hacemos, cara a hacer algo aún más masivo. Por ejemplo: No estoy seguro aún de si el criterio para asignar coordenadas es por geocodificación de direcciones postales llanamente, lo que significaría que se perdería la verdadera posición del local. Resolver una sola posición en los casos de duplicidad, decidir cuál será el criterio, si nos podemos fiar ciegamente de las coordenadas que da el Ayuntamiento o son más fiables las tomadas en campo, a la hora de automatizar el proceso... ¿Solo nos interesan los negocios a pie de calle?¿Filtramos los que están en pisos? Creo que hay que ir pensando también en la metodología común: - Las herramientas para coordinar el trabajo - las herramientas que emplearemos para tratar los datos (OpenRefine, Qgis, se me ocurre...); - los procesos a realizar antes de dividir en paquetes de datos. - Los procesos a realizar después, por cada paquete - Un lugar donde alojar los datos y documentar bien el proceso para que cualquiera pueda repetirlo y detectar posibles errores o inconsistencias; No estoy seguro de los límites de volumen de datos de Github, por ejemplo. También considero el uso de tecnologías abiertas en la medida de lo posible Seguro que tenéis más cosas en la cabeza. Por mí, ha empezado el brainstorming. Espero que ya estéis haciendo experimentos, tenemos todo el verano por delante. Un saludo, Alejandro [1] https://www.youtube.com/watch?v=dgKQdejwyXE El 26/06/15 a las 17:55, Luis García Castro escribió: El 26 de junio de 2015, 15:01, Alejandro Zappala alayzapp...@yahoo.es mailto:alayzapp...@yahoo.es escribió: Revisando los datos me doy cuenta de que otro de los grandes problemas sería la asignación de etiquetas de la actividad de cada local. Automatizar el proceso para hacer el mapeo entre la nomenclatura del Ayuntamiento para los tipos de negocio y la de OSM, requeriría de un proceso, de verdad, complicado (sobretodo la decisión de los que son homólogos) Hombre, siempre podría avanzarse y automatizar los negocios que tengamos claros y sean homólogos e ignorar por ahora el resto. Una importación mensual automatizada de un fichero de fuente fiable (aunque hagamos una importación parcial del mismo) es brutal. No veo que sea mejor o peor que un trabajo de campo, yo veo que son cosas simplemente complementarias y el trabajo de campo nunca podrá ser tan frecuente y extenso. -- Luis García ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-cat] Majúscules i minúscules
Correu d'en Jaume del 31/7/2013: Hola, el què diu la normativa catalana [1] pàg. 11 i [2] pàg. 29: Els genèrics. Els noms genèrics que indiquen el tipus de via urbana (carrer, plaça, avinguda, passatge, passeig, rambla, baixada, etc.) són noms comuns i, per tant, s’escriuen amb minúscula inicial (llevat que vagin en posició inicial o després de punt). Cal respectar les formes característiques locals (rambla, rial, travessera, travessia, costa, esplanada, etc.). Quan s’hagin d’escriure en plaques o rètols, es considera que es troben en posició inicial i, per tant, s’han d’escriure amb majúscula inicial. el què diu la normativa espanyola [3] pàg. 19: «Los topónimos de Cataluña tienen como única forma oficial la catalana, de acuerdo con la normativa lingüística del Institut d’Estudis Catalans, excepto los del Valle de Arán, que tienen la aranesa.» pàg 37: En el MTN25 todos los rótulos deben iniciarse con mayúscula, por lo tanto, el artículo inicial de una capital se rotulará siempre con mayúscula, aun cuando esté registrado con minúscula. Se trata de la única excepción en que se modifica la forma recogida en el REL Ejs.: L’Alfàs del Pi, La Vilavella pero no: l’Alfàs del Pi, la Vilavella. Jo entenc que carrer, plaça, avinguda, passatge, passeig, rambla, baixada, etc. van en minúscula excepte si estan en posició inicial o després d'un punt o en plaques i rètols. O sigui posaré carrer en majúscula quan començo una oració o en un rètol o placa. Per si en teniu dubtes en la mateixa normativa hi ha un munt d'exemples on trobem (fora de les plaques) els genèrics (inclòs carrer) en minúscula [1] pàg. 20 en endavant, i tot el [2] He posat també el que diuen les normatives espanyoles per què queda constància que la nostra normativa és la què conta i que ells retolen igual que nosaltres encara que el registre [Registro de entidades locales] sigui en minúscula. Aleshores, la meva consideració és què el camp 'name' de la base de dades no és cap oració ni forma part de cap escrit i per tant no va en majúscula. Per mi tampoc no és ni una placa ni un rètol i per tant tampoc ho posaria en majúscula. Així que per mi tot en minúscula, encara que, jo el primer, ho trobi lleig i no hi estigui avesat. Una altra cosa és quan això ho volem imprimir en un rètol: IEC - 1 m. [LC] Inscripció breu que, impresa o pintada sobre un suport, es posa en un lloc visible per a informar el públic. El rètol d’una botiga. Els rètols d’un carrer. Però el nom d'un carrer en un mapa no sé si pot considerar-se un rètol. Apa, ja he escrit prou. Salut! [1] http://www20.gencat.cat/docs/ptop/Home/Serveis%20i%20tramits/Biblioteca%20i%20documentacio/Planificacio%20territorial/Publicacions/Cartografia%20i%20toponimia/Criteris%20per%20a%20la%20toponimia%20dambit%20municipal_Criteris/docs/criteris_denominacio.pdf [2] http://www20.gencat.cat/docs/ptop/Home/Serveis%20i%20tramits/Biblioteca%20i%20documentacio/Planificacio%20territorial/Publicacions/Cartografia%20i%20toponimia/Criteris%20per%20a%20la%20toponimia%20dambit%20municipal_Criteris/docs/criteris_escriptura.pdf [3] http://www.fomento.gob.es/NR/rdonlyres/C7B3628F-1BFB-431E-A7FA-99A97C2A9ECC/28709/NormasToponimiaparaMTN25.pdf 2015-06-27 12:04 GMT+02:00 Jaume Figueras i Jové jaume.figue...@upc.edu: Hola, jo ho tinc entès com tu. Crec que fa molt temps es va comentar a la llista. Ara no sóc a casa i no ho puc buscar, cal recuperar aquells correus i informar a l'usuari. Salut! On 27 June 2015 11:52:41 CEST, Fermí Tanyà ferm...@gmx.net wrote: Gràcies per la resposta Carlos, però no em serveix, a Vic hi ha molts carrers on la placa està completament en majúscules https://www.google.es/maps/@41.932942,2.256578,3a,20.9y,285.54h,94.59t/data=%213m6%211e1%213m4%211skw3SkUzdFNg_HI966z3uMg%212e0%217i13312%218i6656?hl=ca . Fermí El 27/06/2015 a les 11:41, Carlos Sánchez ha escrit: Jo el que faig es escriure-ho tal i com apareix a peu de carrer si tinc dubtes. El dia 27 de juny de 2015, 9:29, Fermí Tanyà ferm...@gmx.net ha escrit: Bon dia, Tenia entès que els noms (name) que s'introdueixen a OSM han d'anar en minúscules, excepte quan es tracta de nom propis. Segons el meu entendre s'hauria d'escriure carrer de Jacint Verdaguer i no pas Carrer de Jacint Verdaguer. Llavors és cosa del renderitzador tractar les majúscules i minúscules segons cregui necessari. Vaig equivocat o ho tinc mal entès? Jo ho estava fent així, i modificava els que trobava fets de l'altra manera per coincidir amb aquest criteri de no començar amb majúscules, però ara m'he trobat aquest changset http://www.openstreetmap.org/changeset/31908020 on veig un usuari que s'ha dedicat a canviar-ho en sentit contrari al que jo pensava que era el correcte. M'ho podeu aclarir els que teniu més experiència i coneixement del tema? Fermí ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat --
Re: [Talk-br] Limite de cidades com distritos
Em 26 de junho de 2015 16:58, Nelson A. de Oliveira nao...@gmail.com escreveu: Se o IBGE define que sempre existe distrito (mesmo que seja igual ao município), qual o problema de ter isso no OSM? E se alguém quiser obter todos os distritos (sede ou não) a partir do OSM, vai ficar sem? De acordo. Repito-me: Trata-se de manter a consistência lógica na representação que é feita pelo mapa digital (base de dados). Com OpenStreetMap é preciso deixar de lado a ideia de que um mapa é um papel impresso. Alexandre ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-cat] Editors d'Osona i majúscules en noms de carrers
Hola, Jo no acostumo a editar res a Vic (ni Osona) però fa uns mesos hi vaig dibuixar alguns (pocs) carrers i sentits de circulació: em sap greu quan ciutats importants tenen zones sense mapejar. El cas és que jo tinc la costum de posar el nom (i la mateixa paraula carrer) en majúscules, tal com ho trobo al vissir3 del ICGC. Fa mesos es va difondre (potser només recordar, però jo no ho sabia abans) per aquesta llista la norma de posar els articles dels noms de municipi en minúscules. A més del comentari es fa fer una macro per verificar i canviar aquests noms. Si hi ha alguna norma de consens respecte el nom dels carrers, fora bo confirmar-ho, difondre-ho i corregir-ho el més automàticament possible. Jo ho he fet a vegades (sobretot els noms en castellà) de corregir textos d'altres que no m'agradin però sempre hi ha el perill d'entrar en una guerra que distreu recursos: posats a modificar la feina d'altres millor tenir una norma que hom pugui justificar. Salut (a veure si ens veiem al citylab a l'octubre...) josep ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-br] Limite de cidades com distritos
Ivaldo, eu entendo que a receita é simples. A realidade é como o Nelson diz abaixo e convém que o OpenStreetMap represente exatamente a realidade. Mesmo na linguagem comum do povo, se forem entrar no detalhe, há ao menos o distrito sede. Pouco importa se as áreas do distrito sede único e da cidade irão coincidir no mapa. Trata-se de manter a consistência lógica na representação que é feita pelo mapa digital (base de dados). Com OpenStreetMap é preciso deixar de lado a ideia de que um mapa é um papel impresso. Alexandre Magno Em 26 de junho de 2015 12:20, Nelson A. de Oliveira nao...@gmail.com escreveu: Até onde vejo todo município é constituído de distritos. Pode ter apenas o distrito sede (o próprio município) ou distrit -sede + subdistritos (que é o caso aqui). Procure o item 1.8 aqui: http://www.ipeadata.gov.br/doc/DivisaoTerritorialBrasileira_IBGE.pdf Leia também o item 1.9 Todo município tem no mínimo 1 distrito (ele mesmo). É assim que o IBGE representa. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Draft updated privacy policy
Am 18.06.2015 um 18:16 schrieb Greg Troxel: Simon Poole si...@poole.ch writes: I've produced an updated version of the OSM privacy policy: http://wiki.openstreetmap.org/wiki/Updated_Privacy_Policy (the original resides here: http://wiki.openstreetmap.org/wiki/Privacy_Policy). I have a few big-picture comments so I'm sending them to talk@. With respect to data obtained from the site, I think that's nominatim queries and also the particular areas that are looked at, posssibly associated with IP address, and associated with a user if logged in. The policy doesn't address if logs are kept by IP address or by username, and for how long. At first glance, I would be in favor of limiting log lifetime to 30 days or so, and not backing them up. I would for example find a (beyond-admins) heatmap of which locations were loaded to be overly invasive if it were more granular than 1km or so. See below. in support of the operation of the services from a technical, security and planning point of view. That's fine in theory, but the question is to whom are they accessible/disclosed, and under what terms. It's pretty clear you mean by a small subset people working within OSM who agree not to disclose anything beyond counts/trends. That's fine, but it's not what the text says - as long as there is a nexus to support of operations, any disclosure is within policy. I'll be adding a clarification on that. as anonymised, summarised data for research and other purposes. Such data may be offered publicly via http://planet.openstreetmap.org or other channels and used by 3rd parties. Anonymized and summarized are different and it is very tricky to prevent reidentification of anonymized data. So summarized, where the individual items no longer appear (queries/month, etc.), I have no issue with. The intention is that any published data is both summarised and anonymised (there is no or in the sentence). While you are correct that anonymised is a bit of a no-op in that scenario, it is there to avoid concerns. If individual addresses appear, then there's no summarization, and the geo nature of things means that there can be a single address in a region, even if there are 10K in the dataset. What that means, I don't know, but it doesn't seem good to publish the list of addresses that people looked up. to improve the OpenStreetMap dataset. For example by analysing nominatim queries for missing addresses and postcodes and providing such data to the OSM community. It may be reasonable to have on the nomination failure page a add this query to a public list of queries without an answer. That will both avoid people's queries getting published when they didn't want them to, and also filter out some typos. Sort of like a map note by address we can't geocode, rather than by coordinates. Given that it hasn't actually been implemented I can't say for sure, but I suspect (just as with the tile statistics) we would only publish addresses for areas with a certain minimum density of requests per higher level admin entity. Aka we wouldn't be publishing an individual address for a city or similar. In practical terms I don't think this is an issue in any case since individual requests via the UI will be completely drowned out by bulk geocoding via the API (which is the main reason we want to do this in the first place). See http://munin.openstreetmap.org/openstreetmap/poldi.openstreetmap/index.html and http://munin.openstreetmap.org/openstreetmap/pummelzacken.openstreetmap/index.html. We are currently peaking at roughly 350 requests per second. With real routing, addresses that are frequent from values are likely those of OSM users; publishing that seems uncool. No personal information or information that could be linked to an individual will be released to third parties, except as required by law. That's pretty strong, given reidentifciation concerns. So perhaps that's other than as specififed above. It may need some tweaking wrt addresses. Third party services providing content linked to via or third party JavaScript files utilised by OSMF provided sites are not covered by this policy and you will need to refer to the respective service providers for more information. Examples of such services and content are the HOT and CycleMap map layers on openstreetmap.org and the JavaSctipt frameworks used by help.openstreetmap.org. This is an interesting question. It would be reasonable for OSMF to require that other entities whose content is integrated into openstreetmap.org have privacy policies that are consistent with OSMF's privacy policy. Arguably this should be the case, as it requires some sophistication to know what's separate. Outside of the scope of this document. The javascript frameworks are an interesting question, and I don't know if the
Re: [OSM-talk-fr] Chiffres romains
Salut, Tous les caractères affichés dans la table marche en copier/coller si tu veux. Tu peux copier le tableau et le mettre sous open-office par exemple pour l'avoir en local (hors connexion) et copier/coller les chiffres que tu souhaites utiliser. Ce sont les vrai chiffres romain et non des lettres dans le tableau que j'ai fourni Le 27 juin 2015 14:44, Eric SIBERT courr...@eric.sibert.fr a écrit : Le 26/06/2015 19:39, Jérôme Seigneuret a écrit : En effet, j'ai trouvé ça dans la partie /general ponctuation/ de la table utf-8 Voici les codes Unicode Caractère UTF-8 encodage HTML name U+2160 Ⅰ 226133160 #8544; ROMAN NUMERAL ONE U+2161 Ⅱ 226133161 #8545; ROMAN NUMERAL TWO Dans l'idée, ça me plairait. Après, comme ça a déjà été remarqué, c'est un peu bâtard avec les correspondances pour chaque nombre arabe de 1 à 12 puis seulement les chiffres romains isolés au-delà. Par contre, je ne trouve pas comment saisir ça dans JOSM/WinXP. Je me perds dans google. Si vous avez des pistes... Le copier/coller de thunderbird vers josm a l'air de fonctionner. Pour V, je trouve dans le fichier osm le code : E2 85 A4. Eric ___ 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] Chiffres romains
De l'un côté ça me plaît, car maintenant c'est clair sans ambiguïtés que ce ne sont pas des lettres. De l'autre côté ça signifie que chaque client doit réinterpréter chaque fois de nouveau pour déterminer la valeur. Un tag supplémentaire pourrait remédier cela. On Jun 27, 2015 3:01 PM, Jérôme Seigneuret jseigneuret-...@yahoo.fr wrote: Salut, Tous les caractères affichés dans la table marche en copier/coller si tu veux. Tu peux copier le tableau et le mettre sous open-office par exemple pour l'avoir en local (hors connexion) et copier/coller les chiffres que tu souhaites utiliser. Ce sont les vrai chiffres romain et non des lettres dans le tableau que j'ai fourni Le 27 juin 2015 14:44, Eric SIBERT courr...@eric.sibert.fr a écrit : Le 26/06/2015 19:39, Jérôme Seigneuret a écrit : En effet, j'ai trouvé ça dans la partie /general ponctuation/ de la table utf-8 Voici les codes Unicode Caractère UTF-8 encodage HTML name U+2160 Ⅰ 226133160 #8544; ROMAN NUMERAL ONE U+2161 Ⅱ 226133161 #8545; ROMAN NUMERAL TWO Dans l'idée, ça me plairait. Après, comme ça a déjà été remarqué, c'est un peu bâtard avec les correspondances pour chaque nombre arabe de 1 à 12 puis seulement les chiffres romains isolés au-delà. Par contre, je ne trouve pas comment saisir ça dans JOSM/WinXP. Je me perds dans google. Si vous avez des pistes... Le copier/coller de thunderbird vers josm a l'air de fonctionner. Pour V, je trouve dans le fichier osm le code : E2 85 A4. Eric ___ 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: [OSM-talk-fr] Chiffres romains
Le mieux est parfois l'ennemi du bien.Les chiffres créent des problèmes d'ambiguïté ? Une succession de lettres est elle un mot ou un nombre ? A priori c'est un mot. Essayez d'écrire Jean XXIII et Henri IV ou encore Louis XIV sur une feuille de papier libre. Examinez ensuite si la graphie des lettres dans les nombres que vous avez écris à la romaine est la même que celle des autres lettres de votre écriture. Pour ma part ce n'est pas la même. Il s'agit bien de symboles.Le problème viens qu'il y a erreur de graphie lorsquon écrit Louis XIV en remplaçant les symboles des chiffres romains par des lettres ordinaires.Les structures de données n'ont pas été prévues pour supporter du chiffre romain ou l'utilisation des symboles est trop compliquée pour être utilisé dans le nom principal et pour autant il faut bien que le sens soit compris.Alors Jean 23 Henri 4 et Louis 14 dans le name ont l'avantage de ne pas créé d'ambiguité, contrairement à Henri IV ou George V, même si la graphie n'est pas exacte ( néanmoins le rendu doit pouvoir être possible en chiffre romains sur les cartes), alors que Georges V avec V majuscule n'est pas plus exact mais lui créé une ambiguité.La mise des chiffres en toute lettre me semble le meilleur compromis. Le Vendredi 26 juin 2015 13h59, Eric Sibert courr...@eric.sibert.fr a écrit : Bonjour, Il y a moyen de saisir des chiffres romains dans OSM/Josm? Parce que quand le logiciel de guidage me parle de George vé ou Henry ivé, j'ai du mal :-p Je pourrais aussi avoir des références comportant des chiffres romains et pour certains traitements, ça serait bien que ce soit reconnu comme des nombres mais affiché comme des chiffres romains sur les cartes. Eric ___ 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] Chiffres romains
Bonjour, En ce qui concerne les chiffres romains, je vois mal comment une détection automatisée pourrait fonctionner. Quelle expression régulière pourra-t-elle deviner que George V utilise un chiffre romain mais pas Avenue D (à Manhattan), Quai C ou Escalier I ? Exemple : cette requête Overpass (certes imparfaite) essaie de détecter les cas d'utilisation de nombres en chiffres romains. Difficile de séparer les cas où c'est vraiment des chiffres romains (pas si nombreux) de ceux où c'est une lettre : http://overpass-turbo.eu/s/a8O Et surtout, comme le signalait Jérôme Seigneuret, le problème des chiffres romains n'est que l'arbre qui cache la forêt des prononciations locales ou irrégulières. Un GPS m'a un jour conseillé de prendre la direction Kimpé lors d'un voyage en Bretagne... En fait, c'est même plus général que le GPS. La prononciation des données d'OSM est une question générale d'accessibilité (malvoyants, etc.), que seul un champ spécifique peut résoudre. Il n'y a pas des réflexions à ce sujet ? Le 27/06/2015 03:41, Philippe Verdy a écrit : Bref on revient à la solution de fournir un alt_name=* Pourquoi alt_name ? J'attends de mon GPS vocal qu'il utilise le name, puisque c'est lui qui figure sur les panneaux en bord de route. Et si on met la prononciation dans le alt_name parce qu'on sait que certains GPS utilisent le alt_name d'une certaine manière, c'est qu'on tague pour le GPS... Il me paraît bien plus logique, du point de vue de la base de données comme des utilisateurs, d'utiliser un champ spécifique, quel que soit son nom (name:fr-fonapi, name:phonetics, name:fr:phonetics). Ensuite, celui qui exporte les données OSM vers un GPS pourra toujours, le cas échéant, mettre ce champ là où ce sera le plus utile pour le GPS (ou pour tel lecteur d'écran). D'autant qu'on n'est pas obligé d'exiger la saisie en API. Une saisie approximative (Quimpère, George 5) pourrait faire l'affaire. Il y a aussi X-SAMPA, version ASCII de l'API, mais je ne sais pas si c'est vraiment une simplification, surtout pour la langue française. -- Thierry B. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-br] Lobby pro iD avisar ao mesclar vias com diferentes etiquetas e/ou relações dependentes
Estamos em 2015, quebrar relações não deveria ser fácil: https://github.com/openstreetmap/iD/issues/2358#issuecomment-115978245 Isso afeta: - limites administrativos, e multipolígonos em geral - relações de rota (rodovias, linhas de ônibus, rotas ciclísticas, etc.) Só não afeta restrições de conversão porque já é devidamente tratada - o que é bizarro, tratar corretamente só um tipo de relação e não os demais. -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limite de cidades com distritos
Talvez aqui também caberia ter diferenciação (com border_type) do que é distrito sede e o que é apenas distrito. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-cat] Editors d'Osona
Jo visc a la frontera, però envoltat d'Osona i intento ampliar i corregint el que no és correcte. signature.asc Description: PGP signature ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-br] Limite de cidades com distritos
É sobre isso que eu opino assim https://lists.openstreetmap.org/pipermail/talk-br/2015-June/010194.html. Em 26 de junho de 2015 16:23, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Vitor, ok, entendi, mas essa questão de definição de distrito pelo IBGE não é a minha dúvida, mas sim se ela deve ser mapeada. No exemplo que o Nelson deu abaixo, entendo ser desnecessário o adm_level=9. O que devemos pensar é o seguinte: no exemplo dado (1 distrito/1 cidade, ou 2, 3,4... distritos para 1 cidade)se ficar apenas o adm_level=8 (cidade), até que ponto está incorreto? (semânticamente, dentro do OSM). Ou seja, para que 2 se tudo pode ser feito com 1? Quem pesquisa por distrito de São Paulo? (cidade de São Paulo/SP), embora ele exista? É indiferente. Se me recordo, essa denominação de distrito/comarca só é mencionado em registro civil. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
Les latitudes, longitudes sont également présentes. Mais pour l'instant l'analyse ne tourne que sur le serveur qui traite la France métropolitaine. Le 27/06/2015 10:26, erwan salomon a écrit : question bête vous avez pris en compte que le mode de projection varie en fonction des points enregistrés ? bon j'y connais pas grand chose alors je ne sais pas quelle influence ça a mais une grosse partie du fichier utilise ESPG :2154 puis ont trouve quelquesEPSG :2975 et EPSG :102113 Le 25 juin 2015 à 22:05, Frédéric Rodrigo a écrit : Bonsoir, Depuis quelques jours les boites au lettre de la poste dans l'espace public sont disponible sur data.gouv.fr http://data.gouv.fr https://www.data.gouv.fr/fr/datasets/liste-des-boites-aux-lettres-de-rue-france-metropolitaine-et-dom-1/ La qualité est assez bonne mais ça sent quand même le géocodage. Elles sont disponibles pour intégration dans Osmose : http://osmose.openstreetmap.fr/fr/map/#item=7051,8022,8023 C'est un peu comme un saint Graal qui devient accessible ;) Frédéric, mappeur de ref de boites aux lettres. ___ 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
[OSM-talk-fr] Rendu QA: retour à la normale...
Le rendu QA qui permet de visualiser les zones où il manque potentiellement des routes et des bâtiments en comparant données OSM et données carroyées de l'INSEE ne se mettait plus à jour correctement depuis quelques temps. Je viens (enfin) de corriger ça, et les premiers niveaux de zooms (6 à 11) ont aussi été remis à jour. http://tile.openstreetmap.fr/?zoom=6lat=46.67312lon=2.31237layers=000BTFF On compte actuellement: - 405371 carreaux cyan indiquant des bâtiments potentiellement manquants - 61995 carreaux magenta indiquant des routes potentiellement manquantes... Ces stats remises à jour chaque nuit et accessibles sur http://osm13.openstreetmap.fr/~cquest/qa_stats.txt -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
Le 27/06/2015 09:49, Christian Quest a écrit : Autre problème avec cette analyse osmose: on avait utilisé jusque maintenant ref=* et pas ref:FR:LaPoste... - le rapprochement fait pas osmose ne semble pas se faire (ou alors la tolérance de distance est insuffisante). - les formulaires de JOSM prennent en compte ref=* - on va avoir un mix entre les deux... Je corrige, passage vers ref. Il faut à mon avis vraiment la revoir, car entre la mauvaise qualité du géocodage initial fait par La Poste et ces tags en contradiction avec ce qui a été fait jusque maintenant on risque sérieusement de dégrader plutôt que d'améliorer les données OSM. Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite aux lettres. Ça ne peut pas faire de mal. Faites attention aussi à la fraicheur des données... dans mon bled bourguignon, il y a plusieurs boites aux lettres qui ont été supprimées à l'automne dernier, mais qui sont encore dans ce fichier opendata. De mon coté, Bordeaux, en ville donc, je trouve la fraicheur des positions plutôt bonne, même si ça reste du géocodage. Il est est quand même évident qu'il faut corriger les positions à la main avant intégration dans OSM. Le 26 juin 2015 22:06, erwan salomon r...@gmx.fr mailto:r...@gmx.fr a écrit : si ça peut aider dans mon coin (Plœmeur 56270, mais aussi un peu les villes limitrophes) Osmose me propose 3 erreurs par boites aux lettres 1 *Boîte postale sans ref:FR:LaPoste* (en violet) 1*Boîte postale, proposition d'intégration* (en vert) 1 *Boîte postale non intégrée* (en vert) à 1-5 m de la boite déjà présente (une bonne partie me semble acceptable à ~1m près, quelques boites sont très mal placée cf l'aéroport 10-20 m) ça fait beaucoup pour la même boite Concernant les 3 types de remontées c'est le fonctionnement normal d'Osmose pour l'intégration de données : - boites dans OSM pas retrouvées dans l'OpenData - boites dans l'OpenData pas retrouvées dans OSM - proposition de rapprochement Oui, il y a un mix. Je suis en contact avec le responsable côté Poste et j'avais eu le fichier entre les mains il y a déjà quelques semaines. J'avais remonté des problèmes, suggéré de re-géocoder ça avec la BAN via addok, mais visiblement ça n'a pas été fait. Ce qu'on peut aussi faire, c'est comparer les lat/lon retournés par addok+BAN à ceux fournis. Si il y a trop de différence, il faut faire attention. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-cat] Majúscules i minúscules
Hola, personalment, a la meva àrea, Llefià, Badalona, tinc els noms en minúscules, però quan edito o fins i tot creo carrers a Barcelona o altres llocs faig servir el que ja han establert els que han editat anteriorment a la zona, que majorment fan servir les majúscules :( Ho faig per que la gent que edita aquella zona no consideri la meva edició com una intromissió. Ho podria fer indicant que el més correcte és utilitzar les minúscules, és cert. Crec que es podria fer servir un bot per canviar-ho, però com he dit abans, hauriem de fer difusió a la comunitat per només fer-ho una vegada. També podriem parlar de la conveniència de fer servir el de amb els noms dels carrers. És el mateix carrer de Pérez Galdós que carrer Pérez Galdós? Salutacions, Jose Luis 2015-06-27 13:39 GMT+02:00 Jose Luis Infante jlinfa...@llefia.org: Correu d'en Jaume del 31/7/2013: Hola, el què diu la normativa catalana [1] pàg. 11 i [2] pàg. 29: Els genèrics. Els noms genèrics que indiquen el tipus de via urbana (carrer, plaça, avinguda, passatge, passeig, rambla, baixada, etc.) són noms comuns i, per tant, s’escriuen amb minúscula inicial (llevat que vagin en posició inicial o després de punt). Cal respectar les formes característiques locals (rambla, rial, travessera, travessia, costa, esplanada, etc.). Quan s’hagin d’escriure en plaques o rètols, es considera que es troben en posició inicial i, per tant, s’han d’escriure amb majúscula inicial. el què diu la normativa espanyola [3] pàg. 19: «Los topónimos de Cataluña tienen como única forma oficial la catalana, de acuerdo con la normativa lingüística del Institut d’Estudis Catalans, excepto los del Valle de Arán, que tienen la aranesa.» pàg 37: En el MTN25 todos los rótulos deben iniciarse con mayúscula, por lo tanto, el artículo inicial de una capital se rotulará siempre con mayúscula, aun cuando esté registrado con minúscula. Se trata de la única excepción en que se modifica la forma recogida en el REL Ejs.: L’Alfàs del Pi, La Vilavella pero no: l’Alfàs del Pi, la Vilavella. Jo entenc que carrer, plaça, avinguda, passatge, passeig, rambla, baixada, etc. van en minúscula excepte si estan en posició inicial o després d'un punt o en plaques i rètols. O sigui posaré carrer en majúscula quan començo una oració o en un rètol o placa. Per si en teniu dubtes en la mateixa normativa hi ha un munt d'exemples on trobem (fora de les plaques) els genèrics (inclòs carrer) en minúscula [1] pàg. 20 en endavant, i tot el [2] He posat també el que diuen les normatives espanyoles per què queda constància que la nostra normativa és la què conta i que ells retolen igual que nosaltres encara que el registre [Registro de entidades locales] sigui en minúscula. Aleshores, la meva consideració és què el camp 'name' de la base de dades no és cap oració ni forma part de cap escrit i per tant no va en majúscula. Per mi tampoc no és ni una placa ni un rètol i per tant tampoc ho posaria en majúscula. Així que per mi tot en minúscula, encara que, jo el primer, ho trobi lleig i no hi estigui avesat. Una altra cosa és quan això ho volem imprimir en un rètol: IEC - 1 m. [LC] Inscripció breu que, impresa o pintada sobre un suport, es posa en un lloc visible per a informar el públic. El rètol d’una botiga. Els rètols d’un carrer. Però el nom d'un carrer en un mapa no sé si pot considerar-se un rètol. Apa, ja he escrit prou. Salut! [1] http://www20.gencat.cat/docs/ptop/Home/Serveis%20i%20tramits/Biblioteca%20i%20documentacio/Planificacio%20territorial/Publicacions/Cartografia%20i%20toponimia/Criteris%20per%20a%20la%20toponimia%20dambit%20municipal_Criteris/docs/criteris_denominacio.pdf [2] http://www20.gencat.cat/docs/ptop/Home/Serveis%20i%20tramits/Biblioteca%20i%20documentacio/Planificacio%20territorial/Publicacions/Cartografia%20i%20toponimia/Criteris%20per%20a%20la%20toponimia%20dambit%20municipal_Criteris/docs/criteris_escriptura.pdf [3] http://www.fomento.gob.es/NR/rdonlyres/C7B3628F-1BFB-431E-A7FA-99A97C2A9ECC/28709/NormasToponimiaparaMTN25.pdf 2015-06-27 12:04 GMT+02:00 Jaume Figueras i Jové jaume.figue...@upc.edu: Hola, jo ho tinc entès com tu. Crec que fa molt temps es va comentar a la llista. Ara no sóc a casa i no ho puc buscar, cal recuperar aquells correus i informar a l'usuari. Salut! On 27 June 2015 11:52:41 CEST, Fermí Tanyà ferm...@gmx.net wrote: Gràcies per la resposta Carlos, però no em serveix, a Vic hi ha molts carrers on la placa està completament en majúscules https://www.google.es/maps/@41.932942,2.256578,3a,20.9y,285.54h,94.59t/data=%213m6%211e1%213m4%211skw3SkUzdFNg_HI966z3uMg%212e0%217i13312%218i6656?hl=ca . Fermí El 27/06/2015 a les 11:41, Carlos Sánchez ha escrit: Jo el que faig es escriure-ho tal i com apareix a peu de carrer si tinc dubtes. El dia 27 de juny de 2015, 9:29, Fermí Tanyà ferm...@gmx.net ha escrit: Bon dia, Tenia entès que els noms (name) que s'introdueixen a OSM han
Re: [OSM-talk-fr] Chiffres romains
Le 26/06/2015 19:39, Jérôme Seigneuret a écrit : En effet, j'ai trouvé ça dans la partie /general ponctuation/ de la table utf-8 Voici les codes Unicode Caractère UTF-8 encodage HTML name U+2160 Ⅰ 226133160 #8544; ROMAN NUMERAL ONE U+2161 Ⅱ 226133161 #8545; ROMAN NUMERAL TWO Dans l'idée, ça me plairait. Après, comme ça a déjà été remarqué, c'est un peu bâtard avec les correspondances pour chaque nombre arabe de 1 à 12 puis seulement les chiffres romains isolés au-delà. Par contre, je ne trouve pas comment saisir ça dans JOSM/WinXP. Je me perds dans google. Si vous avez des pistes... Le copier/coller de thunderbird vers josm a l'air de fonctionner. Pour V, je trouve dans le fichier osm le code : E2 85 A4. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
J'ai fait l'essaie. J'ai mis un chiffre romain dans le nom d'une petite rue. Je vais voir ce que ça donne en terme de rendu, de recherche du nom de la rue et de guidage. Je vous tiens au courant. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Plugin Mapillary pour Josm
On notera également que Mapillary continue a jouer le jeu en publiant un article sur son blog : http://blog.mapillary.com/update/2015/06/25/josm-mapillary.html Le 24/06/2015 14:10, Stéphane Péneau a écrit : Hello tous ! Pour ceux qui ne sont pas au courant, un plugin pour afficher les photos de Mapillary directement dans Josm, est en cours de développement. Ce plugin est déjà présent dans la liste par défaut des versions récentes, vous avez juste à l'activer pour le tester. Vous pouvez suivre le développement à cette adresse : http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Mapillary Et les rapports de bogues ici : https://josm.openstreetmap.de/query?status=assignedstatus=closedstatus=needinfostatus=newstatus=reopenedcomponent=Plugin+mapillarydesc=1order=id Je trouve que ça fonctionne déjà assez bien. StephaneP ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Jean-Baptiste ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-cat] Fwd: Llibertat de panorama
Animo a que es contacti amb la gent de Mapillary, si el que fotografien comença a tenir drets d'autor el projecte estarà mort. Salut i panorames (els que siguin) yopaseopor 2015-06-25 12:55 GMT+02:00 Konfrare Albert lakonfrariadelav...@gmail.com: Ep! Reenvio això. Estaria bé que ens posicionéssim i veiéssim com podem ajudar. No estaria de més contactar amb altres grups d'OSM. Salut! PD: Jo com a col·laborador d'OSM estic completament a favor de recolzar la campanya ja que penso que és prou important. -- Missatge reenviat -- De: David Parreño Mont Data: 25 de juny de 2015, 11:45 Assumpte: Llibertat de panorama Bon dia company, Com sabràs, des d'Amical Wikimedia vam engegar a finals de la setmana passada una campanya pública a favor de la llibertat de panorama davant l'amenaça que el Parlament Europeu aprovi el 9 de juliol un informe que inclou una esmena que posaria punt final a la llibertat de panorama, tot afectant greument la Viquipèdia, creadors de continguts, fotògrafs o mitjans de comunicació. Al nostre web i xarxes socials, podeu veure explicada la campanya extensament. Tanmateix, estem en un punt on ens hem adonat que cal ser una campanya coral, sobretot de cara a convèncer els mitjans. És per això que estem buscant suports externs a la campanya. Sabries si podríem comptar amb el suport d'OpenStreetMaps o altres comunitats de coneixement/programari lliure? Això suposaria mostrar públicament (a través de les xarxes socials, web, ...) el vostre posicionament i que puguem informar que comptem amb el vostre suport. Som conscients que estem treballant a contra-rellotge, per això us demanaríem una resposta tan aviat com ho hagueu decidit. Moltes gràcies, David Parreño Mont -- *KONFRARE ALBERT* La Konfraria de la Vila del Pingüí de La Palma de Cervelló www.konfraria.org • @La_Konfraria http://twitter.com/La_Konfraria ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] Enroda't i Fòrum TIC Social
Doncs ja porto 200 cadenes, qui s'apunta? Va, que només queden 6781 ;) Salut i QGIS en català yopaseopor PD: Anem a piñón, però anem, ladran luego cabalgamos ^_^ 2015-06-23 22:50 GMT+02:00 josep constantí jconsta...@yahoo.es: Vinga, ara qgis... Sent from Yahoo Mail on Android https://overview.mail.yahoo.com/mobile/?.src=Android -- *From*:yo paseopor yopaseo...@gmail.com *Date*:dt., juny 23, 2015 at 21:11 *Subject*:Re: [Talk-cat] Enroda't i Fòrum TIC Social Us comunico que la traducció de Wheelmap al català a Transifex està finalitzada (la d'Iphone no l'he pogut començar pq reclamen formar part d'un equip i tot i que s'ha sol·licitat encara no ho han concedit). Salut i mapes...en català yopaseopor 2015-06-15 17:51 GMT+02:00 Konfrare Albert lakonfrariadelav...@gmail.com : Hola José Luis, Fantàstica iniciativa ;)) Comentar només tres cosetes: - Per la presentació si vols pots aprofitar aquesta: https://prezi.com/ypsgawnos4g5/openstreetmap-i-la-palma-de-cervello/ Ja és una mica antiga i caldria actualitzar-hi alguna cosa i treure la part de la Palma. És una idea. - Sobre el Wheelmap cal saber que vaig començar a fer-ne la traducció al català i per altres temes vaig deixar-ho córrer. L'aplicació per Android i el lloc web estan gairebé al 95%, només falta que algú s'hi posi, ho revisi una mica i demani que pugin la traducció. Potser la gent d'Enroda't els sembla interessant i volen fer-ho. La traducció es fa des de Transifex: https://www.transifex.com/organization/sozialhelden La traducció per a iPhone no la vaig començar. - I sobre la jornada en sí, et suggereixo que l'afegeixis a: http://wiki.openstreetmap.org/wiki/WikiProject_Catalan/Activitats I així tenim un recull de tot el que es va fent. Gràcies!! El dia 15 de juny de 2015, 14:56, Simó Albert i Beltran s...@probeta.net ha escrit: Molt bé, ànims! Però tot i que a molts us agrada el Mapillary, si us plau, no el confongueu amb OpenStreetMap. ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat -- *KONFRARE ALBERT* La Konfraria de la Vila del Pingüí de La Palma de Cervelló www.konfraria.org • @La_Konfraria http://twitter.com/La_Konfraria ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
[Talk-br] Limite de cidades com distritos
Gente... não quero parecer que sou teimoso... (e sou hein..) desculpe a oposição, mas tenho um pensamento diferente. Vejam, o que é melhor? Fazer 10 com 1 ou 1 com 10? Um soft com 500 linhas de código, ou um com 390, se ambos fazem a mesma coisa? Eu penso que seja fazer 10 com 1... É cultura lean/kaizen. Procuro aplicar isso no que faço. O que me preocupa é o seguinte: toda essa discussão (e ela é boa) surgiu por uma dúvida que tive ao pesquisar o limite de uma cidade no OSM e compará-la com o IBGE. Vejam que não sei quase nada de osm, mas já colaboro há quase um ano, com mais de 2000 edições, e mesmo assim tive dúvidas. Imagina para um usuário que vai pesquisar a primeira vez e se depara com um resultado desses. Se Dois Irmãos do Buriti tivesse apenas 1 adm_level=9 (Palmeiras/distrito) e 1 adm_level=8 (Dois Irmãos do Buriti/cidade), o cara iria pensar... Poxa, essa cidade tem um distrito, e pronto. Nada de complicado. Agora, como é, olha a reação dele: que confusão, essa cidade tem 2 distritos, sendo que um é a própria cidade e mais a cidade que também tem o mesmo nome do distrito... não entedi nada... Não há problemas em o osm mostrar quando distritos foram necessários... (vejam, necessário). São Paulo pode ser mostrado com adm_level=8 e seus bairros, com adm_level=9, como é. A minha indagação é: para quê São Paulo com adm_level=8 e adm_level=9? Apenas porque o IBGE diz que toda a cidade deve ter pelos menos 1 distrito (sede)? Se o cara quer pesquisar os distritos (digamos) de uma cidade que tenha 5 distritos, além da sede. Ele vai achar os 5 distritos com adm_level=9 e a cidade com adm_level=8. Pronto, a cidade tem 6 divisões administrativas. Agora, eu gostei dessa idéia do Nelson de diferenciar pelo border_type... isso já facilita o entendimento do cara... Inclusive vou utilizar essa idéia da delimitação dos bairros de Campo Grande, que tem os bairros, e dentro deles diversos parcelamentos/loteamos/sub-bairros, com nomes distintos... Tipo: para bairros: . . . . . . . . . e para sub-bairros: - - - - - - - - - ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
An onboarding guide which explains relations to the extent that a mapper could confidently edit them would be quite a bit more than that. Welcome to OpenStreetMap! This is a visual editor which lets you define things that you see in the world and their spatial component, specifically in a map form. However, the most important part of the map is a non-visible semantic relational attribute of the data. These relations are abstract groups that can contain zero elements, or thousands. They can contain other relations. Maybe they can even contain themselves. Almost all of the time, a relation with zero members is a mistake, except for one case where it isnt.[2] The distinction between relations as a bug in the data and as a legitimate, complex semantic statement is not something we can autodetect, so use your judgment. Cool: let's start editing relations. Well, first, earlier we said that relations aren't spatial. Well, some are, some aren't. Maybe half and half. Some are used to structure multipolygon geometries. Okay, but most relations are invisible. You're editing the map, but the relation is for routing software or maybe a very large polygon which is limited by some technical limits that we'll get into later. Regardless, when you break those kinds of relations, you won't know, because you can't see the breakage on the map, only in some software that you probably aren't using. Great, so relations are groups of things that can be zero or many, for technical reasons, spatial relationships, or abstract relationships. Now we're getting started. Relations, unlike sets in math, are ordered. Unlike ordered sets, they also have special ways in which each element is contained. So they're kind of like ordered, semantic sets of potentially anything. And, typically, invisible. Now that we've discussed the basics of relations, let's cover each of the different kinds, including each kind's stipulations of what is contained, whether order matters, and the role tags that are unique to each use-case. ...You can see where this is going: I haven't started to explain what you use relations for, and we've already seen the sort of mountain of unpredictable complexity they add to the OpenStreetMap data model - one of the fundamental things that makes it both more powerful than most data models and incompatible with all other data models. The problem coming from the building an editor perspective is that relations add a level of complexity to the question of not breaking data that wholly explains why it's such a rarely attempted feat to edit all openstreetmap data. I would love if this problem were fixable with documentation, but unfortunately, this is actually just a deep issue that isn't easy to document, and iD would still be grilled on the regular for not preventing people from doing things. The data model could be improved in a few ways: if it embraced the long-awaited area datatype[1] and stopped using relations as a brittle stopgap around multipolygons and node limits. Or if it specified enforced well-established types of relations in such a way that the validity of an editor's approach was agreed-on rather than constantly argued about. And it's not that I hate relations: they are truly one of the only successful instances of linked data in the entire world of computers. They're also a legitimate reflection of the world's actual complexity. But reconciling their ephemeral, non-visual, intensely-freeform properties with the ideal of a map of the world everyone can edit is not a simple matter. Tom [1]: http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html [2]: http://wiki.openstreetmap.org/wiki/Empty_relations On Sat, Jun 27, 2015 at 12:58 PM, Fernando Trebien fernando.treb...@gmail.com wrote: This is surely going to spur controversy, but here I go. Imagine a world in which a new mapper opens its (newly-discovered) favourite editor and is presented with the following message the first time they edit anything: You can map using points and relations. Relations are groups of things with specific roles: groups of points make lines, groups of lines can make things like routes bus routes, city boundaries, hollow buildings, turn restrictions, etc., groups of routes can make route networks. Mappers rarely group further, but they could. Because lines are very common, you can draw them by simply adding many points one after another. If you want to make more complex relations such as routes and boundaries, check out the relation editor. Of course, such an editor would have to be designed with that philosophy in mind from the start. Is this a rant? Not really, this a sincere impression I've had for a very long time. Many novice users are confused by relations because they need to build their understanding later, often when someone complains they've made some mistake. When this notion of grouping is presented at the very beginning, I believe people will easily understand it for
Re: [Talk-cat] Majúscules i minúscules
Jo ho escric com ho trobo a la placa de carrer. Google i ICGC ja ho fan amb el tema majúscules, minúscules.I per afegir teca, sóc mestre, als nens els demanem que escriguin la primera sempre en majúscules, així com els noms propis. Salut i majúscules yopaseopor PD: deixar-ho tot al bon funcionament del renderitzador a vegades no dóna els resultats desitjats https://github.com/gravitystorm/openstreetmap-carto/issues 2015-06-27 15:15 GMT+02:00 pit...@eclipso.eu: Jo segueixo la norma de l'IEC d'escriure la inicial de Carrer, Passatge, Trevessera, o que sigui, en majúscula i acostumo a corregir els que trobo d'una altra manera perquè no són normatius ... poca cosa perquè no em dedico massa a les zones urbanes a no se que em vinguin de pas. El nom d'un carrer a un mapa és com la seva placa, per tant, la norma indica que la lletra inicial del tipus de via ha d'anar en majúscula, ... tal com ho fa l'ICC o la cartografia del sistema Sitmun. Pel que fa al de, normativament hauria d'anar, però penso que si és possible (coneixement) és preferible respectar la forma que s'utilitzi a la seva placa ... per aquell principi de cartografiar el que hi ha al terreny. salutacions pitort --- original message --- *From:* Jose Luis Infante jlinfa...@llefia.org *Date:* 27.06.2015 13:56:54 *To:* OpenStreetMap in catalan talk-cat@openstreetmap.org *Subject:* Re: [Talk-cat] Majúscules i minúscules Hola, personalment, a la meva àrea, Llefià, Badalona, tinc els noms en minúscules, però quan edito o fins i tot creo carrers a Barcelona o altres llocs faig servir el que ja han establert els que han editat anteriorment a la zona, que majorment fan servir les majúscules :( Ho faig per que la gent que edita aquella zona no consideri la meva edició com una intromissió. Ho podria fer indicant que el més correcte és utilitzar les minúscules, és cert. Crec que es podria fer servir un bot per canviar-ho, però com he dit abans, hauriem de fer difusió a la comunitat per només fer-ho una vegada. També podriem parlar de la conveniència de fer servir el de amb els noms dels carrers. És el mateix carrer de Pérez Galdós que carrer Pérez Galdós? Salutacions, Jose Luis 2015-06-27 13:39 GMT+02:00 Jose Luis Infante jlinfa...@llefia.org: Correu d'en Jaume del 31/7/2013: Hola, el què diu la normativa catalana [1] pàg. 11 i [2] pàg. 29: Els genèrics. Els noms genèrics que indiquen el tipus de via urbana (carrer, plaça, avinguda, passatge, passeig, rambla, baixada, etc.) són noms comuns i, per tant, s’escriuen amb minúscula inicial (llevat que vagin en posició inicial o després de punt). Cal respectar les formes característiques locals (rambla, rial, travessera, travessia, costa, esplanada, etc.). Quan s’hagin d’escriure en plaques o rètols, es considera que es troben en posició inicial i, per tant, s’han d’escriure amb majúscula inicial. el què diu la normativa espanyola [3] pàg. 19: «Los topónimos de Cataluña tienen como única forma oficial la catalana, de acuerdo con la normativa lingüística del Institut d’Estudis Catalans, excepto los del Valle de Arán, que tienen la aranesa.» pàg 37: En el MTN25 todos los rótulos deben iniciarse con mayúscula, por lo tanto, el artículo inicial de una capital se rotulará siempre con mayúscula, aun cuando esté registrado con minúscula. Se trata de la única excepción en que se modifica la forma recogida en el REL Ejs.: L’Alfàs del Pi, La Vilavella pero no: l’Alfàs del Pi, la Vilavella. Jo entenc que carrer, plaça, avinguda, passatge, passeig, rambla, baixada, etc. van en minúscula excepte si estan en posició inicial o després d'un punt o en plaques i rètols. O sigui posaré carrer en majúscula quan començo una oració o en un rètol o placa. Per si en teniu dubtes en la mateixa normativa hi ha un munt d'exemples on trobem (fora de les plaques) els genèrics (inclòs carrer) en minúscula [1] pàg. 20 en endavant, i tot el [2] He posat també el que diuen les normatives espanyoles per què queda constància que la nostra normativa és la què conta i que ells retolen igual que nosaltres encara que el registre [Registro de entidades locales] sigui en minúscula. Aleshores, la meva consideració és què el camp 'name' de la base de dades no és cap oració ni forma part de cap escrit i per tant no va en majúscula. Per mi tampoc no és ni una placa ni un rètol i per tant tampoc ho posaria en majúscula. Així que per mi tot en minúscula, encara que, jo el primer, ho trobi lleig i no hi estigui avesat. Una altra cosa és quan això ho volem imprimir en un rètol: IEC - 1 m. [LC] Inscripció breu que, impresa o pintada sobre un suport, es posa en un lloc visible per a informar el públic. El rètol d’una botiga. Els rètols d’un carrer. Però el nom d'un carrer en un mapa no sé si pot considerar-se un rètol. Apa, ja he escrit prou. Salut! [1]
Re: [OSM-talk-fr] Chiffres romains
Le 27 juin 2015 19:15, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : En France on parle français(Une seule langue officielle) dans tout les cas donc fr ou fr_FR comme français de France. Le problème n'est pas là. Le problème est que tu restreint le tag seulement à la France alors qu'il est dans le monde entier, partout où on veut parler français. Bref c'est pas une mauvaise interprétation est c'est utilisé comme tel dans les API et dans le système Android (système sur lequel est installé OsmAnd) Je ne l'invente pas non plus http://www.iana.org/assignments/lang-subtags-templates/fonipa.txt Non car tu oublie le mot important 'variant et la syntaxe très précise des labels de langues BCP47 : nulle part il n'est possible d'utiuliser un sous-label de variante (variant subtag) en tête. L'expression que tu as trouvée no-prefix signifie si tu avais correctement lu la RFC que le sous-label n'est pas restreint à certains préfixes maix utilisable pour tous les préfixes (mais un préfixe reste nécessaire dans la labrel de langue complet) Bref relis correctement la RFC et commence par la section du décrit la syntaxe d'un labele de langue qui a obligatoirement en tête un sous-label de langue primaire (tel que fr, mul ou und). fonapi ne renvoi pas de résultat sur IANA mais fonipa comme fonupa https://www.iana.org/assignments/lang-subtags-templates/lang-subtags-templates.txt Et ça fait bien référence à la RFC5646 https://www.ietf.org/rfc/rfc5646.txt En effet il doit y avoir un prefix. Pas de problème! Enfin ! Et puis on doit absoluement éviter de référencer une RFC quand on parles de BCP 47 (ou de n'importe quelle BCP de l'IETF= qui est composé de plusieurs RFC et de corrections ultérieures, ainsi que du registre IANA. BCP 47 a été la RFC 646, puis 4646 puis 5646, mais elle a été acompagnée aussi de plusieurs autres RFC (avec différents statuts: certains normatifs d'autres informatifs). Concernant les codes acceptés, la référence c'est la base IANA, mais la RFC décrit seulement l'usage (dans le passé la RFC 646 donnait une liste de codes, c'est fini et remplacé par une référence normative à la base et plusieurs machanismes et protocoles documentant comment utiliser les codes de la base IANA ou comment en ajouter, et ce qui peut y être corrigé ou pas, et comment assurer la compatibilité ascendante des codes, la chose qu'oublie totalement les différents volets de l'ISO 639 qui n'offre strictement aucune interprétation que pour des codes isolés et décrits juste par un nom anglais et quelques synonymes: ISO 639 n'est pas un catalogue assez précis ni stable, la base IANA pour BCP 47 l'est beaucoup plus). Concernant les fautes de frappe sur ces codes fonapi, c'est un enfer sur un smartphone qui change à la volée plusieurs fois même ce qu'on vient de corriger déjà, et le rechange encore avant l'envoi d'un texte. Fichu clavier Android merdique qui insiste pour vouloir trouver des mots français et ne sait pas gérer un texte utilisant plusierus langues ni retenir le fait qu'on s'est déjà opposé à la correction automatique d'un mot et qu'il ne doit pas la remettre derrière ! Ce clavier n'est fait que pour chatter quelques mots. (Note: c'est aussi merdique sur un clavier mobile pour iOS ou pour Windows, les correcteurs font n'importe quoi quand ils veulent même quand on ne le veut pas, et ne re retiennent rien du tout. Pourtant jamais je n'ai tapé fonapi, j'ai mis fonipa mais en relisant le simpe survol en défilant le texte faits des corrections sans qu'on les voit, Je me demande sd'où il a sorti fonapi alors que ce mot n'est pas non plus dans un dico mais pourrait reseembler à fon (abréviation courante de (télé)phone) et api (la pomme), le smartphone connait aussi la marque Fon (fournisseur de hotspots Wifi). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] Limite de cidades com distritos
Ivaldo, é melhor não ter informação no OSM ou é melhor que quem for utilizar filtre apenas o que necessita? :-) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limite de cidades com distritos
Uma coisa que a gente precisa diferenciar ao mapear é o OSM em si e os serviços agregados ou que utilizam ele. O OSM é, no fundo, apenas um banco de dados (possui apenas as informações dos objetos). Ele possui um mapa padrão, um buscador padrão, uma aplicação de rotas padrão, mas são todos aplicativos que utilizam as informações do OSM, de acordo com algumas regras específicas. A gente nunca mapeia para uma determinada aplicação, visualização ou uso. Pode ser que a busca padrão do OSM (o Nominatim) não retorne o resultado exatamente da forma que você queira, mas alguém pode fazer uma aplicação que trate isso de acordo com as suas necessidades. Por exemplo, sempre retornar o limite de maior admin_level quando existem dois com o mesmo nome (assim a cidade sempre seria mostrada, e não do distrito sede). Se a gente ficar mapeando para só aparecer o limite da cidade no buscador padrão a gente vai ficar com informações incompletas no OSM. Em termos de OSM os dados estão certos (e válidos de acordo com a definição de distritos no Brasil). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-legal-talk] Using OSM data without modifying - are there any guidelines?
Which nicely illustrates that should the OSM database not be found to be worthy of sui generis database protection (a distinct possibility), the ODbL would clearly be enforceable based on contract law. Of course you're right that contracts can be used to create obligations outside of copyright or database right--but only if the parties enter such a contract. In the Ryanair case, PR Aviation was collecting information from Ryanair's site, and the court held that accessing the site amounted to entering a contractual relationship (as defined by the site TOS). But of course OSM extracts and snapshots are available all over the web, and from interfaces that don't introduce or even mention any contractual relationship with OSMF as a condition of download (whether the user is an OSM contributor or has used OSMF-owned services directly might be relevant here). A lawyer commenting on the post you provided explains the dynamic well: http://ipkitten.blogspot.com/2015/01/breaking-cjeu-says-that-owner-of-online.html?showComment=1421340621683#c7550848707130069201 Naturally enforceable property rights via the ODbL attach to the data even when there is no contract. But not to data that is excluded from such property rights by law, such as IDs. As you point out, in practice this seems unlikely to matter here: the Fairhurst Doctrine is a useful and thoughtful policy statement from the community about what it intends to do with the property rights it does have, and it seems to clearly indicate that OSMF isn't interested in asserting claims over trivial use of IDs, whether or not the rights underlying such claims exist. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
Bonjour, (attention c'est long) Le 27/06/2015 13:53, Frédéric Rodrigo a écrit : Le 27/06/2015 09:49, Christian Quest a écrit : Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite aux lettres. Ça ne peut pas faire de mal. Ça n'est pas parce que c'est fourni dans la source qu'on en veut forcément en base, si ? On peut en avoir un usage indirect, si ça permet de valider la cohérence d'une couche de polygones de codes postaux par exemple, mais de là à dire que le code postal est un attribut des boîtes aux lettres *dans* OSM, il y a de la marge. D'une manière générale, tous les épisodes d'intégration d'OpenData nous apprennent au moins une chose, c'est qu'on doit être critiques par rapport aux sources. Ça ne s'applique pas qu'aux valeurs d'attributs ou à la géométrie, le choix des tags est aussi concerné... Il est est quand même évident qu'il faut corriger les positions à la main avant intégration dans OSM. Mais est-ce si évident ? Pour moi clairement non. Il est très simple (trop ?) de valider les propositions de création de nodes telles que. Or en dehors de sa propre connaissance du terrain, on n'a rien à confronter à la source OD pour vérifier sa qualité. Ici rien n'est visible depuis une orthophoto, on ne peut pas faire la même démarche qu'avec les routes ou les bâtiments, où on a au moins bing et le Cadastre à confronter pour se faire un jugement. Pour des boîtes aux lettres, comme pour les bancs, les hydrants et autres micro contenus, en dehors des endroits couverts par Mapillary, on n'est dépourvu de sources à confronter/comparer. Et comme il est simple de vérifier, sur des boîtes aux lettres de son environnement, le côté pifométrique de la source (par chez moi c'est flagrant, avec géocodage à la rue par exemple, ce qui est un non sens), je suis plus que réservé sur l'intérêt de la proposition d'intégration. Ce que je verrais plus volontiers : - proposition de conflation pour les boîtes détectées mais dépourvues de tag ref - et simple visualisation (sans possibilité de bascule vers un éditeur) pour les autres. C'est un simple porté à connaissance, qui peut aiguiller chacun sur son territoire pour aller vérifier sur place l'existence *et le positionnement* des boîtes. Ça paraîtra fastidieux et/ou radical à certains, de mon côté je suis convaincu de cette nécessité. Sans positionnement fin de ce type d'objets (je mets les hydrants dans le même sac) OSM n'a pas de valeur ajoutée à les intégrer. S'il s'agit juste de les accumuler en base sans apport de qualité, on peut déjà le faire, d'un point de vue utilisateur, sans passer par la case OSM. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
Le 27/06/2015 17:37, Vincent de Château-Thierry a écrit : Bonjour, (attention c'est long) Le 27/06/2015 13:53, Frédéric Rodrigo a écrit : Le 27/06/2015 09:49, Christian Quest a écrit : Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite aux lettres. Ça ne peut pas faire de mal. Ça n'est pas parce que c'est fourni dans la source qu'on en veut forcément en base, si ? On peut en avoir un usage indirect, si ça permet de valider la cohérence d'une couche de polygones de codes postaux par exemple, mais de là à dire que le code postal est un attribut des boîtes aux lettres *dans* OSM, il y a de la marge. D'une manière générale, tous les épisodes d'intégration d'OpenData nous apprennent au moins une chose, c'est qu'on doit être critiques par rapport aux sources. Ça ne s'applique pas qu'aux valeurs d'attributs ou à la géométrie, le choix des tags est aussi concerné... Bon. Si ce tag ne va a personne je l'enlève. Il est est quand même évident qu'il faut corriger les positions à la main avant intégration dans OSM. Mais est-ce si évident ? Pour moi clairement non. Il est très simple (trop ?) de valider les propositions de création de nodes telles que. Or en dehors de sa propre connaissance du terrain, on n'a rien à confronter à la source OD pour vérifier sa qualité. Ici rien n'est visible depuis une orthophoto, on ne peut pas faire la même démarche qu'avec les routes ou les bâtiments, où on a au moins bing et le Cadastre à confronter pour se faire un jugement. Pour des boîtes aux lettres, comme pour les bancs, les hydrants et autres micro contenus, en dehors des endroits couverts par Mapillary, on n'est dépourvu de sources à confronter/comparer. Et comme il est simple de vérifier, sur des boîtes aux lettres de son environnement, le côté pifométrique de la source (par chez moi c'est flagrant, avec géocodage à la rue par exemple, ce qui est un non sens), je suis plus que réservé sur l'intérêt de la proposition d'intégration. Ce que je verrais plus volontiers : - proposition de conflation pour les boîtes détectées mais dépourvues de tag ref - et simple visualisation (sans possibilité de bascule vers un éditeur) pour les autres. C'est un simple porté à connaissance, qui peut aiguiller chacun sur son territoire pour aller vérifier sur place l'existence *et le positionnement* des boîtes. Ça paraîtra fastidieux et/ou radical à certains, de mon côté je suis convaincu de cette nécessité. Sans positionnement fin de ce type d'objets (je mets les hydrants dans le même sac) OSM n'a pas de valeur ajoutée à les intégrer. S'il s'agit juste de les accumuler en base sans apport de qualité, on peut déjà le faire, d'un point de vue utilisateur, sans passer par la case OSM. vincent Je trouve que tu fait à l'intégration le même procès que à l'import. L'intégration n'a de sens que si entre le clic de souris et la chaise il y un cerveau, je suis d'accord. Mais c'est justement pour cela que l'on passe par une intégration et non une importation. Je ne souhaite pas limite un outil sous prétexte qu'il est trop facile (et rapide) à utiliser. Je fais assez confiance au cerveau qui se met au bout de la souri avant de cliquer dessus. Je suis toute fois d'accord que plus d'implication sur Osmose serait la bien venue. Je me pose d’ailleurs de plus en plus la question de la pertinence de séparer les intégrations dans un autre Osmose. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
Le 27/06/2015 17:54, Frédéric Rodrigo a écrit : Je trouve que tu fait à l'intégration le même procès que à l'import. L'intégration n'a de sens que si entre le clic de souris et la chaise il y un cerveau, je suis d'accord. Mais c'est justement pour cela que l'on passe par une intégration et non une importation. Je ne souhaite pas limite un outil sous prétexte qu'il est trop facile (et rapide) à utiliser. Pour lever un possible doute, mon message n'est surtout pas un procès envers Osmose. Ce que je veux pointer, et qui différencie la démarche de celle des imports (essentiellement celui du bâti), c'est qu'on ne dispose pas de sources opposables à celle proposée dans Osmose, vu la faible emprise des objets sur le terrain. Donc le jugement de chacun, (aka le cerveau), n'est finalement pas si central dans la démarche. Et même l'adresse postale, s'agissant d'un géocodage, est d'une aide très moyenne, quand on parle d'équipements de la voie publique, et non de caractéristiques d'un bâtiment (commerce, ERP, etc). Ok la boîte aux lettres est rttachée, disons administrativement, à une adresse, mais ça ne dit pas du tout précisément où elle se situe sur le terrain. Dit autrement : quand la seule source disponible hors OpenData est le terrain, faut-il proposer l'intégration, ou juste suggérer une vérification sur place ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chiffres romains
@Thierry : Tu as résumé le fond du problème.
Je n'ai pas encore traité du X-SAMPA mais j'ai plus l'impression que c'est
un parallèle ASCII de l'IPA Unicode
d'ailleurs il y a des types phonétiques qui sont dans X-SAMPA et qui ne
sont pas dans l'IPA
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi et
le fameux codage BCP47
Celui est mentionné par Philippe Verdy :
- http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/72406
Ducoup je sais qu'Eric nous parle OsmAnd sur android ;-)
L'alphabet phonétique international (IPA est l'abréviation anglaise) répond
est un standard iso (15924)
Je suis allé faire un tour sur la doc BCP 47
https://tools.ietf.org/html/bcp47 et donc la structure n'est pas encore
la bonne car en me tapant la doc je viens de voir qu'on parle d'un suffixe
*fonipa*. Surement une erreur involontaire dans la page de Wikipedia. En
même temps je préfère avoir les informations à la source.
*An example of such a no-prefix variant is the subtag 'fonipa', which
represents the*
* International Phonetic Alphabet, a scheme that can be used to
transcribe many languages*
Je suis allé sur du code Android et j'ai trouvé ça comme variante de language
1. FONIPA{alphabet phonétique international}
2. FONUPA{alphabet phonétique ouralique}
name:fonipa est valable pour une traduction international
name:fr-fonipa pour la France en respect à la RFC 5646
https://tools.ietf.org/html/rfc5646
Le 27 juin 2015 16:33, Thierry Bézecourt thie...@thbz.org a écrit :
Bonjour,
En ce qui concerne les chiffres romains, je vois mal comment une détection
automatisée pourrait fonctionner. Quelle expression régulière pourra-t-elle
deviner que George V utilise un chiffre romain mais pas Avenue D (à
Manhattan), Quai C ou Escalier I ?
Exemple : cette requête Overpass (certes imparfaite) essaie de détecter
les cas d'utilisation de nombres en chiffres romains. Difficile de séparer
les cas où c'est vraiment des chiffres romains (pas si nombreux) de ceux où
c'est une lettre : http://overpass-turbo.eu/s/a8O
Et surtout, comme le signalait Jérôme Seigneuret, le problème des chiffres
romains n'est que l'arbre qui cache la forêt des prononciations locales ou
irrégulières. Un GPS m'a un jour conseillé de prendre la direction Kimpé
lors d'un voyage en Bretagne...
En fait, c'est même plus général que le GPS. La prononciation des données
d'OSM est une question générale d'accessibilité (malvoyants, etc.), que
seul un champ spécifique peut résoudre. Il n'y a pas des réflexions à ce
sujet ?
Le 27/06/2015 03:41, Philippe Verdy a écrit :
Bref on revient à la solution de fournir un alt_name=*
Pourquoi alt_name ? J'attends de mon GPS vocal qu'il utilise le name,
puisque c'est lui qui figure sur les panneaux en bord de route. Et si on
met la prononciation dans le alt_name parce qu'on sait que certains GPS
utilisent le alt_name d'une certaine manière, c'est qu'on tague pour le
GPS...
Il me paraît bien plus logique, du point de vue de la base de données
comme des utilisateurs, d'utiliser un champ spécifique, quel que soit son
nom (name:fr-fonapi, name:phonetics, name:fr:phonetics). Ensuite, celui qui
exporte les données OSM vers un GPS pourra toujours, le cas échéant, mettre
ce champ là où ce sera le plus utile pour le GPS (ou pour tel lecteur
d'écran).
D'autant qu'on n'est pas obligé d'exiger la saisie en API. Une saisie
approximative (Quimpère, George 5) pourrait faire l'affaire. Il y a
aussi X-SAMPA, version ASCII de l'API, mais je ne sais pas si c'est
vraiment une simplification, surtout pour la langue française.
--
Thierry B.
___
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] Chiffres romains
Bref aucune erreur dans waikipedua c'est bien toi qui te plantes même en
allant a la source que tu n'as pas lue ou pas comprise...
Le 27 juin 2015 18:22, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :
@Thierry : Tu as résumé le fond du problème.
Je n'ai pas encore traité du X-SAMPA mais j'ai plus l'impression que c'est
un parallèle ASCII de l'IPA Unicode
d'ailleurs il y a des types phonétiques qui sont dans X-SAMPA et qui ne
sont pas dans l'IPA
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi et
le fameux codage BCP47
Celui est mentionné par Philippe Verdy :
- http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/72406
Ducoup je sais qu'Eric nous parle OsmAnd sur android ;-)
L'alphabet phonétique international (IPA est l'abréviation anglaise)
répond est un standard iso (15924)
Je suis allé faire un tour sur la doc BCP 47
https://tools.ietf.org/html/bcp47 et donc la structure n'est pas encore
la bonne car en me tapant la doc je viens de voir qu'on parle d'un suffixe
*fonipa*. Surement une erreur involontaire dans la page de Wikipedia. En
même temps je préfère avoir les informations à la source.
*An example of such a no-prefix variant is the subtag 'fonipa', which
represents the*
* International Phonetic Alphabet, a scheme that can be used to
transcribe many languages*
Je suis allé sur du code Android et j'ai trouvé ça comme variante de language
1. FONIPA{alphabet phonétique international}
2. FONUPA{alphabet phonétique ouralique}
name:fonipa est valable pour une traduction international
name:fr-fonipa pour la France en respect à la RFC 5646
https://tools.ietf.org/html/rfc5646
Le 27 juin 2015 16:33, Thierry Bézecourt thie...@thbz.org a écrit :
Bonjour,
En ce qui concerne les chiffres romains, je vois mal comment une
détection automatisée pourrait fonctionner. Quelle expression régulière
pourra-t-elle deviner que George V utilise un chiffre romain mais pas
Avenue D (à Manhattan), Quai C ou Escalier I ?
Exemple : cette requête Overpass (certes imparfaite) essaie de détecter
les cas d'utilisation de nombres en chiffres romains. Difficile de séparer
les cas où c'est vraiment des chiffres romains (pas si nombreux) de ceux où
c'est une lettre : http://overpass-turbo.eu/s/a8O
Et surtout, comme le signalait Jérôme Seigneuret, le problème des
chiffres romains n'est que l'arbre qui cache la forêt des prononciations
locales ou irrégulières. Un GPS m'a un jour conseillé de prendre la
direction Kimpé lors d'un voyage en Bretagne...
En fait, c'est même plus général que le GPS. La prononciation des données
d'OSM est une question générale d'accessibilité (malvoyants, etc.), que
seul un champ spécifique peut résoudre. Il n'y a pas des réflexions à ce
sujet ?
Le 27/06/2015 03:41, Philippe Verdy a écrit :
Bref on revient à la solution de fournir un alt_name=*
Pourquoi alt_name ? J'attends de mon GPS vocal qu'il utilise le name,
puisque c'est lui qui figure sur les panneaux en bord de route. Et si on
met la prononciation dans le alt_name parce qu'on sait que certains GPS
utilisent le alt_name d'une certaine manière, c'est qu'on tague pour le
GPS...
Il me paraît bien plus logique, du point de vue de la base de données
comme des utilisateurs, d'utiliser un champ spécifique, quel que soit son
nom (name:fr-fonapi, name:phonetics, name:fr:phonetics). Ensuite, celui qui
exporte les données OSM vers un GPS pourra toujours, le cas échéant, mettre
ce champ là où ce sera le plus utile pour le GPS (ou pour tel lecteur
d'écran).
D'autant qu'on n'est pas obligé d'exiger la saisie en API. Une saisie
approximative (Quimpère, George 5) pourrait faire l'affaire. Il y a
aussi X-SAMPA, version ASCII de l'API, mais je ne sais pas si c'est
vraiment une simplification, surtout pour la langue française.
--
Thierry B.
___
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: [OSM-talk-fr] Chiffres romains
Non tu te plantes deux fois. car la RFC que tu cites qui n'est qu'elle
version et une partie de BCP 47, fait référence a son enregistrement comme
variante dans un label de langue.
Fonapi ne peut donc pas être utilisé seul et pas en tant que premier
sous-label d'un label de langue. Un peu DD recherche et tu serais tombe sur
son enregistrement dans la base de donnée IANA pour les labels de langues
BCP 47.
Tu ne fais que survoler un truc en sortant du contexte de sa norme qui
définit clairement l'usage.
Enfin deuxième erreur, fr-fonapi ne fait pas référence a la France mais à
la langue française... Une approximation grossière donc.
Pour une prononciation internationale multilingue le label BCP47 standard
est mul-fonapi. Pour une utilisation monolingue dans une langue
indéterminée ou un fallback neutre le label est und-fonapi.
Bref pas de name:fonapi=* puisque fonapi seul n'est pas un label de langue
BCP47 standard.
Mais name:und-fonapi=* est correct.
Le 27 juin 2015 18:22, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :
@Thierry : Tu as résumé le fond du problème.
Je n'ai pas encore traité du X-SAMPA mais j'ai plus l'impression que c'est
un parallèle ASCII de l'IPA Unicode
d'ailleurs il y a des types phonétiques qui sont dans X-SAMPA et qui ne
sont pas dans l'IPA
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi et
le fameux codage BCP47
Celui est mentionné par Philippe Verdy :
- http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/72406
Ducoup je sais qu'Eric nous parle OsmAnd sur android ;-)
L'alphabet phonétique international (IPA est l'abréviation anglaise)
répond est un standard iso (15924)
Je suis allé faire un tour sur la doc BCP 47
https://tools.ietf.org/html/bcp47 et donc la structure n'est pas encore
la bonne car en me tapant la doc je viens de voir qu'on parle d'un suffixe
*fonipa*. Surement une erreur involontaire dans la page de Wikipedia. En
même temps je préfère avoir les informations à la source.
*An example of such a no-prefix variant is the subtag 'fonipa', which
represents the*
* International Phonetic Alphabet, a scheme that can be used to
transcribe many languages*
Je suis allé sur du code Android et j'ai trouvé ça comme variante de language
1. FONIPA{alphabet phonétique international}
2. FONUPA{alphabet phonétique ouralique}
name:fonipa est valable pour une traduction international
name:fr-fonipa pour la France en respect à la RFC 5646
https://tools.ietf.org/html/rfc5646
Le 27 juin 2015 16:33, Thierry Bézecourt thie...@thbz.org a écrit :
Bonjour,
En ce qui concerne les chiffres romains, je vois mal comment une
détection automatisée pourrait fonctionner. Quelle expression régulière
pourra-t-elle deviner que George V utilise un chiffre romain mais pas
Avenue D (à Manhattan), Quai C ou Escalier I ?
Exemple : cette requête Overpass (certes imparfaite) essaie de détecter
les cas d'utilisation de nombres en chiffres romains. Difficile de séparer
les cas où c'est vraiment des chiffres romains (pas si nombreux) de ceux où
c'est une lettre : http://overpass-turbo.eu/s/a8O
Et surtout, comme le signalait Jérôme Seigneuret, le problème des
chiffres romains n'est que l'arbre qui cache la forêt des prononciations
locales ou irrégulières. Un GPS m'a un jour conseillé de prendre la
direction Kimpé lors d'un voyage en Bretagne...
En fait, c'est même plus général que le GPS. La prononciation des données
d'OSM est une question générale d'accessibilité (malvoyants, etc.), que
seul un champ spécifique peut résoudre. Il n'y a pas des réflexions à ce
sujet ?
Le 27/06/2015 03:41, Philippe Verdy a écrit :
Bref on revient à la solution de fournir un alt_name=*
Pourquoi alt_name ? J'attends de mon GPS vocal qu'il utilise le name,
puisque c'est lui qui figure sur les panneaux en bord de route. Et si on
met la prononciation dans le alt_name parce qu'on sait que certains GPS
utilisent le alt_name d'une certaine manière, c'est qu'on tague pour le
GPS...
Il me paraît bien plus logique, du point de vue de la base de données
comme des utilisateurs, d'utiliser un champ spécifique, quel que soit son
nom (name:fr-fonapi, name:phonetics, name:fr:phonetics). Ensuite, celui qui
exporte les données OSM vers un GPS pourra toujours, le cas échéant, mettre
ce champ là où ce sera le plus utile pour le GPS (ou pour tel lecteur
d'écran).
D'autant qu'on n'est pas obligé d'exiger la saisie en API. Une saisie
approximative (Quimpère, George 5) pourrait faire l'affaire. Il y a
aussi X-SAMPA, version ASCII de l'API, mais je ne sais pas si c'est
vraiment une simplification, surtout pour la langue française.
--
Thierry B.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Re: [OSM-talk-fr] Chiffres romains
Pour info
Il y a une valeur avec *fonetic*
https://taginfo.openstreetmap.org/search?q=fonetic
Un peu plus avec *phonetic*
https://taginfo.openstreetmap.org/search?q=phonetic
;-)
Le 27 juin 2015 18:19, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit
:
@Thierry : Tu as résumé le fond du problème.
Je n'ai pas encore traité du X-SAMPA mais j'ai plus l'impression que c'est
un parallèle ASCII de l'IPA Unicode
d'ailleurs il y a des types phonétiques qui sont dans X-SAMPA et qui ne
sont pas dans l'IPA
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi et
le fameux codage BCP47
Celui est mentionné par Philippe Verdy :
- http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/72406
Ducoup je sais qu'Eric nous parle OsmAnd sur android ;-)
L'alphabet phonétique international (IPA est l'abréviation anglaise)
répond est un standard iso (15924)
Je suis allé faire un tour sur la doc BCP 47
https://tools.ietf.org/html/bcp47 et donc la structure n'est pas encore
la bonne car en me tapant la doc je viens de voir qu'on parle d'un suffixe
*fonipa*. Surement une erreur involontaire dans la page de Wikipedia. En
même temps je préfère avoir les informations à la source.
*An example of such a no-prefix variant is the subtag 'fonipa', which
represents the*
* International Phonetic Alphabet, a scheme that can be used to
transcribe many languages*
Je suis allé sur du code Android et j'ai trouvé ça comme variante de language
1. FONIPA{alphabet phonétique international}
2. FONUPA{alphabet phonétique ouralique}
name:fonipa est valable pour une traduction international
name:fr-fonipa pour la France en respect à la RFC 5646
https://tools.ietf.org/html/rfc5646
Le 27 juin 2015 16:33, Thierry Bézecourt thie...@thbz.org a écrit :
Bonjour,
En ce qui concerne les chiffres romains, je vois mal comment une
détection automatisée pourrait fonctionner. Quelle expression régulière
pourra-t-elle deviner que George V utilise un chiffre romain mais pas
Avenue D (à Manhattan), Quai C ou Escalier I ?
Exemple : cette requête Overpass (certes imparfaite) essaie de détecter
les cas d'utilisation de nombres en chiffres romains. Difficile de séparer
les cas où c'est vraiment des chiffres romains (pas si nombreux) de ceux où
c'est une lettre : http://overpass-turbo.eu/s/a8O
Et surtout, comme le signalait Jérôme Seigneuret, le problème des
chiffres romains n'est que l'arbre qui cache la forêt des prononciations
locales ou irrégulières. Un GPS m'a un jour conseillé de prendre la
direction Kimpé lors d'un voyage en Bretagne...
En fait, c'est même plus général que le GPS. La prononciation des données
d'OSM est une question générale d'accessibilité (malvoyants, etc.), que
seul un champ spécifique peut résoudre. Il n'y a pas des réflexions à ce
sujet ?
Le 27/06/2015 03:41, Philippe Verdy a écrit :
Bref on revient à la solution de fournir un alt_name=*
Pourquoi alt_name ? J'attends de mon GPS vocal qu'il utilise le name,
puisque c'est lui qui figure sur les panneaux en bord de route. Et si on
met la prononciation dans le alt_name parce qu'on sait que certains GPS
utilisent le alt_name d'une certaine manière, c'est qu'on tague pour le
GPS...
Il me paraît bien plus logique, du point de vue de la base de données
comme des utilisateurs, d'utiliser un champ spécifique, quel que soit son
nom (name:fr-fonapi, name:phonetics, name:fr:phonetics). Ensuite, celui qui
exporte les données OSM vers un GPS pourra toujours, le cas échéant, mettre
ce champ là où ce sera le plus utile pour le GPS (ou pour tel lecteur
d'écran).
D'autant qu'on n'est pas obligé d'exiger la saisie en API. Une saisie
approximative (Quimpère, George 5) pourrait faire l'affaire. Il y a
aussi X-SAMPA, version ASCII de l'API, mais je ne sais pas si c'est
vraiment une simplification, surtout pour la langue française.
--
Thierry B.
___
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-us] Mapping Southern Maryland: A new local group
Eric, I'm not ready to join your group but I'm willing to put in a couple hours armchair mapping once you have a specific task. Just let me know. Thanks for posting. Alan Bragg Bedford MA Message: 1 Date: Fri, 26 Jun 2015 21:57:54 -0400 From: Eric H. Christensen e...@christensenplace.us To: talk-us@openstreetmap.org Cc: mappin...@googlegroups.com Subject: [Talk-us] Mapping Southern Maryland: A new local group Message-ID: 20150627015754.gb3...@eric.home.christensenplace.us Greetings, A couple of weeks ago I reached out to many of the OSM account holders that are in my area hoping they would be interested in creating a local community for mapping southern Maryland. I found a few victims and so we're pressing on! I'm still working on all the logistics (website, listserv, etc) but I have created a wiki page[0] where I'll start collecting information regarding the community. If you'd like to join us please put your name on the wiki page. I hope to have all the infrastructure figured out over the coming days. [0] https://wiki.openstreetmap.org/wiki/Mapping_Southern_Maryland Thanks! - --Eric -- Message: 2 Date: Fri, 26 Jun 2015 19:13:29 -0700 From: Clifford Snow cliff...@snowandsnow.us To: Eric H. Christensen e...@christensenplace.us Cc: mappin...@googlegroups.com, talk-us talk-us@openstreetmap.org Subject: Re: [Talk-us] Mapping Southern Maryland: A new local group Eric, Way to go! If you need any help organizing let us know. There is a good lighting talk at this years SOTM-US on conducting a Mapathon by Robin Tolochko, UW Madison. The talk is online at http://stateofthemap.us/lightning-talks-sun/ Clifford ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-es] Charla en el IGN, deberes para OSM.es
Enhorabuena por la charla y el buen resultado obtenido. Quise asistir pero he tenido unos días muy malos. Ahora que voy a tener una temporada (ojalá que no muy larga) sin trabajo puedo colaborar activamente en este tema, en lo que pueda. El 26 de junio de 2015, 18:45, Raúl Jiménez Ortega hhk...@gmail.com escribió: Yo soy el último gato aquí xd, pero... contad con mi espada para echar una mano en lo que buenamente pueda ;). Mi especialidad es hacer comunidad, por lo que si puedo ayudar en esa parte (o en la que sea)... no tenéis más que decirlo :) P.D: sorry si soy escueto, estoy en el móvil ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [OSM-legal-talk] Using OSM data without modifying - are there any guidelines?
Am 27.06.2015 um 17:02 schrieb Tom Lee: But of course OSM extracts and snapshots are available all over the web, and from interfaces that don't introduce or even mention any contractual relationship with OSMF as a condition of download (whether the user is an OSM contributor or has used OSMF-owned services directly might be relevant here). A condition of having a valid licence to use OSM data is providing a suitable way of pointing out the conditions of use of said data to your users/customers/etc (which is relaxed a bit for produced works). Don't provide that, you don't have a valid licence with all the related consequences. If you have information that this obligation is not being fulfilled by distributors of OSM based products, please report it to the OSMF/LWG. In any case the point was, and that was the matter of longish debate prior to the licence change, that both copyright and similar rights and the contractual terms would be brought forward in the case that there was actual dispute and having one does not weaken the other. As you point out, in practice this seems unlikely to matter here: the Fairhurst Doctrine is a useful and thoughtful policy statement from the community about what it intends to do with the property rights it does have, and it seems to clearly indicate that OSMF isn't interested in asserting claims over trivial use of IDs, whether or not the rights underlying such claims exist. The Fairhurst doctrine is, at this point in time, not a formal policy of the OSMF nor has it actually been turned in to useful language yet. There is an effort under way by yours truly to do exactly that, but it is quite a long way away from being approved by the OSMF board which would actually put it in place as an underlying principle. Simon PS: I really don't think the OSMF will go after anybody for publishing a list of OSM ids :-) signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
je pense qu'en résonnant comme ça, il faut supprimé pas mal des intégration possible dans osmose. exemple, les pharmacies, les stations services, même les écoles, c'est pas toujours facile de savoir ce que c'est su la photo aérienne (parce que c'est bien ça le problème, que la photo aérienne ne nous aide pas beaucoup pour placé la boite au lettre). Moi je proposerai seulement de modifié le commentaire en rouge dans osmose, là il n'y a que l'adresse, pour certains éléments à intégré, il y a géocodé a la rue ... peut être ajouter quelque chose du genre qui fait comprendre que c'est pas la position exact. Le 27 juin 2015 18:09, Vincent de Château-Thierry v...@laposte.net a écrit : Le 27/06/2015 17:54, Frédéric Rodrigo a écrit : Je trouve que tu fait à l'intégration le même procès que à l'import. L'intégration n'a de sens que si entre le clic de souris et la chaise il y un cerveau, je suis d'accord. Mais c'est justement pour cela que l'on passe par une intégration et non une importation. Je ne souhaite pas limite un outil sous prétexte qu'il est trop facile (et rapide) à utiliser. Pour lever un possible doute, mon message n'est surtout pas un procès envers Osmose. Ce que je veux pointer, et qui différencie la démarche de celle des imports (essentiellement celui du bâti), c'est qu'on ne dispose pas de sources opposables à celle proposée dans Osmose, vu la faible emprise des objets sur le terrain. Donc le jugement de chacun, (aka le cerveau), n'est finalement pas si central dans la démarche. Et même l'adresse postale, s'agissant d'un géocodage, est d'une aide très moyenne, quand on parle d'équipements de la voie publique, et non de caractéristiques d'un bâtiment (commerce, ERP, etc). Ok la boîte aux lettres est rttachée, disons administrativement, à une adresse, mais ça ne dit pas du tout précisément où elle se situe sur le terrain. Dit autrement : quand la seule source disponible hors OpenData est le terrain, faut-il proposer l'intégration, ou juste suggérer une vérification sur place ? vincent ___ 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
[OSM-talk-fr] Opération Libre du 25 au 27 septembre à Chéméré
A noter dans vos agendas ! La 3e Opération Libre, après Brocas en 2013 et Gérardmer en 2014, aura lieu à Chéméré en Loire-Atlantique, du 25 au 27 septembre 2015. Elle est organisée par l'association Libertic et le Conseil Général de Loire-Atlantique. L'association OpenStreetMap France sera présente, les contributrices et les contributeurs sont bien sûr invité.e.s à participer. Chéméré (http://www.openstreetmap.org/relation/93963) est une commune de 2500 habitants, située entre Nantes (35 km) et Pornic (15 km). La mairie de Chéméré souhaite fortement impliquer les habitants, et nous prévoyons de communiquer localement sur l'évènement lors du forum des associations le 28 août. OpenStreetMap permet d'imaginer des animations variées, qui permettront d'impliquer les habitants selon leurs centres d'intérêt. Le programme du week-end est à construire ensemble. Nous avons commencé, lors d'une rencontre de contributeurs nantais, à énumérer quelques idées sur ce pad : https://semestriel.framapad.org/p/Operation_Libre_Chemere_OpenStreetMap. N'hésitez pas à y contribuer, en suggérant animations, conférences ou ateliers, en proposant votre aide pour collecter ou valoriser les données ... ou pour coorganiser le week-end. Cela nous permettra d'ébaucher un programme pour le bon déroulement de l'opération. D'ici là ... passez un bon été ! Antoine (mandataire OSM France pour la Loire-Atlantique) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] Mappers and apps should focus on relations at the very start
This is surely going to spur controversy, but here I go. Imagine a world in which a new mapper opens its (newly-discovered) favourite editor and is presented with the following message the first time they edit anything: You can map using points and relations. Relations are groups of things with specific roles: groups of points make lines, groups of lines can make things like routes bus routes, city boundaries, hollow buildings, turn restrictions, etc., groups of routes can make route networks. Mappers rarely group further, but they could. Because lines are very common, you can draw them by simply adding many points one after another. If you want to make more complex relations such as routes and boundaries, check out the relation editor. Of course, such an editor would have to be designed with that philosophy in mind from the start. Is this a rant? Not really, this a sincere impression I've had for a very long time. Many novice users are confused by relations because they need to build their understanding later, often when someone complains they've made some mistake. When this notion of grouping is presented at the very beginning, I believe people will easily understand it for all of the advanced scenarios (the most common being routes and boundaries). It would just be didactic. Some people have even proposed abolishing the way entity from OSM's API and replacing it with a relation type=way with node members. Some logic (such as checking for empty ways/empty relations and checking membership across different entities) would be simplified, which would be good for database maintenance. It would also be good for app development, apps would have to understand relations from the very start and would thus be encouraged to support advanced features. That would be very little extra development overhead compared to just points and lines. I understand that very big relations with lots of nodes and a single role for all of them would be undesirable. Apps like the editor can still make the way entity transparent to the user, so an API change is not really required for a change in editor/mapper mindset. Still, I raise this aspect because, in an abstract sense that mappers do need to develop, ways are simply a type of relation, and they could be concretely so. Relations cannot be abolished (there is no other way to represent bus/car/hiking/boat routes, or hollow polygons). Ways, in theory, can. -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Chiffres romains
En France on parle français(Une seule langue officielle) dans tout les cas
donc fr ou fr_FR comme français de France. Le problème n'est pas là.
Bref c'est pas une mauvaise interprétation est c'est utilisé comme tel dans
les API et dans le système Android (système sur lequel est installé OsmAnd)
Je ne l'invente pas non plus
http://www.iana.org/assignments/lang-subtags-templates/fonipa.txt
fonapi ne renvoi pas de résultat sur IANA mais fonipa comme fonupa
https://www.iana.org/assignments/lang-subtags-templates/lang-subtags-templates.txt
Et ça fait bien référence à la RFC5646 https://www.ietf.org/rfc/rfc5646.txt
En effet il doit y avoir un prefix. Pas de problème!
Le 27 juin 2015 18:46, Philippe Verdy verd...@wanadoo.fr a écrit :
Bref aucune erreur dans waikipedua c'est bien toi qui te plantes même en
allant a la source que tu n'as pas lue ou pas comprise...
Le 27 juin 2015 18:22, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :
@Thierry : Tu as résumé le fond du problème.
Je n'ai pas encore traité du X-SAMPA mais j'ai plus l'impression que
c'est un parallèle ASCII de l'IPA Unicode
d'ailleurs il y a des types phonétiques qui sont dans X-SAMPA et qui ne
sont pas dans l'IPA
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi
et le fameux codage BCP47
Celui est mentionné par Philippe Verdy :
- http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/72406
Ducoup je sais qu'Eric nous parle OsmAnd sur android ;-)
L'alphabet phonétique international (IPA est l'abréviation anglaise)
répond est un standard iso (15924)
Je suis allé faire un tour sur la doc BCP 47
https://tools.ietf.org/html/bcp47 et donc la structure n'est pas
encore la bonne car en me tapant la doc je viens de voir qu'on parle d'un
suffixe *fonipa*. Surement une erreur involontaire dans la page de
Wikipedia. En même temps je préfère avoir les informations à la source.
*An example of such a no-prefix variant is the subtag 'fonipa', which
represents the*
* International Phonetic Alphabet, a scheme that can be used to
transcribe many languages*
Je suis allé sur du code Android et j'ai trouvé ça comme variante de language
1. FONIPA{alphabet phonétique international}
2. FONUPA{alphabet phonétique ouralique}
name:fonipa est valable pour une traduction international
name:fr-fonipa pour la France en respect à la RFC 5646
https://tools.ietf.org/html/rfc5646
Le 27 juin 2015 16:33, Thierry Bézecourt thie...@thbz.org a écrit :
Bonjour,
En ce qui concerne les chiffres romains, je vois mal comment une
détection automatisée pourrait fonctionner. Quelle expression régulière
pourra-t-elle deviner que George V utilise un chiffre romain mais pas
Avenue D (à Manhattan), Quai C ou Escalier I ?
Exemple : cette requête Overpass (certes imparfaite) essaie de détecter
les cas d'utilisation de nombres en chiffres romains. Difficile de séparer
les cas où c'est vraiment des chiffres romains (pas si nombreux) de ceux où
c'est une lettre : http://overpass-turbo.eu/s/a8O
Et surtout, comme le signalait Jérôme Seigneuret, le problème des
chiffres romains n'est que l'arbre qui cache la forêt des prononciations
locales ou irrégulières. Un GPS m'a un jour conseillé de prendre la
direction Kimpé lors d'un voyage en Bretagne...
En fait, c'est même plus général que le GPS. La prononciation des
données d'OSM est une question générale d'accessibilité (malvoyants, etc.),
que seul un champ spécifique peut résoudre. Il n'y a pas des réflexions à
ce sujet ?
Le 27/06/2015 03:41, Philippe Verdy a écrit :
Bref on revient à la solution de fournir un alt_name=*
Pourquoi alt_name ? J'attends de mon GPS vocal qu'il utilise le name,
puisque c'est lui qui figure sur les panneaux en bord de route. Et si on
met la prononciation dans le alt_name parce qu'on sait que certains GPS
utilisent le alt_name d'une certaine manière, c'est qu'on tague pour le
GPS...
Il me paraît bien plus logique, du point de vue de la base de données
comme des utilisateurs, d'utiliser un champ spécifique, quel que soit son
nom (name:fr-fonapi, name:phonetics, name:fr:phonetics). Ensuite, celui qui
exporte les données OSM vers un GPS pourra toujours, le cas échéant, mettre
ce champ là où ce sera le plus utile pour le GPS (ou pour tel lecteur
d'écran).
D'autant qu'on n'est pas obligé d'exiger la saisie en API. Une saisie
approximative (Quimpère, George 5) pourrait faire l'affaire. Il y a
aussi X-SAMPA, version ASCII de l'API, mais je ne sais pas si c'est
vraiment une simplification, surtout pour la langue française.
--
Thierry B.
___
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] Chiffres romains
Le 27 juin 2015 19:15, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Bref c'est pas une mauvaise interprétation est c'est utilisé comme tel dans les API et dans le système Android (système sur lequel est installé OsmAnd) Android utilise les tags BCP47 standards, sauf pour la nomination interne des fichiers de ressource dans les sources de ses bundles inclus dans les archives APK ou dans les répertoires applicatifs créés dans /system quand l'appli est installée. Dans l'API elle-même utilisée par les applis on n'utilise pas ces codes. L'APÏ supporte aussi quelques extensions obsolètes venant des premières versions de Java (par exemple iw au lieu de he pour l'hébreu), parce que les kits de développement d'Android sont encore basés sur Java meˆme si Android utilise ensuite sa propre VM différente (Dalvik ou la nouvelle VM pour Android 5+ qui n'utilise plus la compilation JIT mais une précompilation à l'installation et qui supporte aussi des extensions de l'ABI non compatibles avec le JNI standard de Java mais permettant de livrer aussi du code natif ou s'interfacer dans le noyau avec du code propriétaire avec un accès direct au chargeur de code binaire et au linker). Et pas la peine de parler d'Android quands la base OSM n'est pas faite pour Android mais pour être neutre, ses tags ne sont pas plus destinés à Windows que MacOS ou iOS ou BlackBerry, qu'on développe en Java, en PHP, en Ruby, en Perl, en C/C++ ou C# pour .net ou dans les divers dialectes SQL et shcémas XML qui peuvent intégrer des données OSM. On ne parle pas non plus des derniers codes spécifiques de Wikipédia (qui vont tous disparaitre, tous remplacés un par un par BCP 47; bref pas de name:als=* pour l'alsacien même s'il y a encore des liens Wikipédia utilisant als dans Wikidata; même chose pour nrm qui va devenir nrf, zh-classical qui va devenir lzh: ces codes incompatibles ne doivent pas être utilisés dans OSM, qui n'admet psa non plus tout un tas de codes ISO 649 volontairement omis de la base IANA pour BCP47, comme l'explique une de ses RFC dans le détail) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Aggiornamento dei distributori di carburante
dieterdreist wrote non capisco perché dovremmo insistere in un modo di taggare che non funziona e che non è documentato bene Perchè è un dato utilizzato potenzialmente da vari applicativi ed è una metodologia di tag diffusa ad un po' tutto il mondo. fino a quando non sarà stata avviata la discussione e deciso il dafarsi dobbiamo continuare nel taggare con un metodo *che funziona* (almeno fino a quando non ci saranno ambiguità dovute alla comparsa di un brand chiamato Indipendent) ma che purtroppo è concettualmente scorretto e non documentato (in realtà a parte 2 esempi non ho visto brand documentati) http://wiki.openstreetmap.org/wiki/Key:brand (non c'è riferimento) http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel (nemmeno) http://taginfo.openstreetmap.org/keys/?key=brand#values documentato o no (come moltissime cose) ci sono parecchi brand Indipendent (e alcuni indipendent) diffusi in un po' tutto il mondo:http://taginfo.openstreetmap.org/tags/brand=Independent#map quindi, ripeto, prima di modificare una cosa , secondo me, in questo caso, è fondamentale avviare la discussione nel luogo apposito per proporre un cambio di tag...essendo poi un elemento di interesse stradale personalmente considero ancora più importante l'avvio della discussione se si vuole cambiare...continuare a discuterne qui è secondo me inutile e al massimo porterebbe ad uno stile di mappatura applicato solo in Italia che però nel frattempo aumenterebbe ulteriormente l'ambiguità dell'utilizzo di brand=Indipendent nel resto del mondo. - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Aggiornamento-dei-distributori-di-carburante-tp5848265p5849068.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: [Talk-br] Limite de cidades com distritos
Em 27 de junho de 2015 14:46, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Vejam, o que é melhor? Fazer 10 com 1 ou 1 com 10? Às vezes tal escolha não está disponível. Um soft com 500 linhas de código, ou um com 390, se ambos fazem a mesma coisa? Mesmo fazendo a mesmíssima coisa, há casos em que o software de 500 linhas será melhor; por questões de linguagem, legibilidade ou estilo, documentação, arquitetura etc. Vejam que não sei quase nada de osm, mas já colaboro há quase um ano, com mais de 2000 edições, e mesmo assim tive dúvidas. Imagina para um usuário que vai pesquisar a primeira vez e se depara com um resultado desses. A receita para a não confusão é respeitar a realidade, pois quase sempre será a saída de melhor lógica. E quando eu falo de lógica eu não falo apenas de fazer sentido em nossas cabeças, eu falo de consistência, completude, de não contradições, e de somente fazermos casos de exceção estritamente necessários. Se Dois Irmãos do Buriti tivesse apenas 1 adm_level=9 (Palmeiras/distrito) e 1 adm_level=8 (Dois Irmãos do Buriti/cidade), o cara iria pensar... Poxa, essa cidade tem um distrito, e pronto. Nada de complicado. É como comparar português coloquial com português na norma culta. Não existe uma gramática coloquial precisamente porque a boca do povo não tem regras. A *base de dados* OSM precisa estar fundada em regras, esquemas, semântica representativa de todo o essencial da realidade. Agora, como é, olha a reação dele: que confusão, essa cidade tem 2 distritos, sendo que um é a própria cidade e mais a cidade que também tem o mesmo nome do distrito... não entedi nada... O brasileiro que fala muito errado e não consegue raciocinar coisas simples precisa ser alfabetizado. Não é o sistema de educação que deve se adequar a ele. Se o cara quer pesquisar os distritos (digamos) de uma cidade que tenha 5 distritos, além da sede. Ele vai achar os 5 distritos com adm_level=9 e a cidade com adm_level=8. Pronto, a cidade tem 6 divisões administrativas. Isso pode ser uma facilidade implementada na ferramenta de pesquisa. Mas a base de dados deve conhecer o todo. Logo, devemos colocar nela *toda a informação*, íntegra, sem as simplificações do dia-a-dia. Alexandre ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-cat] Fwd: Llibertat de panorama
Per OSMcatala i peö meu perfil vaig fet difussió. Crec que ja se n'han assabentat. Igualment li enviaré al pau Den 27 jun 2015 19:36 skrev yo paseopor yopaseo...@gmail.com: Animo a que es contacti amb la gent de Mapillary, si el que fotografien comença a tenir drets d'autor el projecte estarà mort. Salut i panorames (els que siguin) yopaseopor 2015-06-25 12:55 GMT+02:00 Konfrare Albert lakonfrariadelav...@gmail.com : Ep! Reenvio això. Estaria bé que ens posicionéssim i veiéssim com podem ajudar. No estaria de més contactar amb altres grups d'OSM. Salut! PD: Jo com a col·laborador d'OSM estic completament a favor de recolzar la campanya ja que penso que és prou important. -- Missatge reenviat -- De: David Parreño Mont Data: 25 de juny de 2015, 11:45 Assumpte: Llibertat de panorama Bon dia company, Com sabràs, des d'Amical Wikimedia vam engegar a finals de la setmana passada una campanya pública a favor de la llibertat de panorama davant l'amenaça que el Parlament Europeu aprovi el 9 de juliol un informe que inclou una esmena que posaria punt final a la llibertat de panorama, tot afectant greument la Viquipèdia, creadors de continguts, fotògrafs o mitjans de comunicació. Al nostre web i xarxes socials, podeu veure explicada la campanya extensament. Tanmateix, estem en un punt on ens hem adonat que cal ser una campanya coral, sobretot de cara a convèncer els mitjans. És per això que estem buscant suports externs a la campanya. Sabries si podríem comptar amb el suport d'OpenStreetMaps o altres comunitats de coneixement/programari lliure? Això suposaria mostrar públicament (a través de les xarxes socials, web, ...) el vostre posicionament i que puguem informar que comptem amb el vostre suport. Som conscients que estem treballant a contra-rellotge, per això us demanaríem una resposta tan aviat com ho hagueu decidit. Moltes gràcies, David Parreño Mont -- *KONFRARE ALBERT* La Konfraria de la Vila del Pingüí de La Palma de Cervelló www.konfraria.org • @La_Konfraria http://twitter.com/La_Konfraria ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] vissri3 i fils de conversa, era Re: Editors d'Osona i majúscules en noms de carrers
Creus que les majúscules al nom del carrer de vissir3 estan patentades o és que barreges fils de conversa? Sent from Yahoo Mail on Android From:Simó Albert i Beltran s...@probeta.net Date:ds., juny 27, 2015 at 16:51 Subject:vissri3 i fils de conversa, era Re: [Talk-cat] Editors d'Osona i majúscules en noms de carrers Com està el tema de llicència amb el Vissir3 del ICGC? D'altre banda, Josep, si us plau, t'agrairia que respectessis els fils de conversa. ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Well, this was not targeted at iD since Potlatch and Merkaator (and probably others) suffer from the same problem. Making the user understand the simple membership logic would be a great first step. The second one would be to develop apps (in particular, editors) that support all the variations you mentioned. Maybe they can even contain themselves. Actually no, the server checks for circular dependencies, and a relation pointing to itself is a cycle. Try it, the server returns a validation error. Almost all of the time, a relation with zero members is a mistake, except for one case where it isnt. That's misleading. The article [4] clearly says that such cases are either mistakes or placeholders (which could be considered mistakes as well). The distinction between relations as a bug in the data and as a legitimate, complex semantic statement is not something we can autodetect, so use your judgment. Not quite. JOSM's relation editor will show you when a route relation is broken and exactly where. It will also show you when the relation is a closed cycle, as expected from boundaries. So multipolygons and boundaries must have closed cycles and routes cannot be broken, this is easy to verify (just check if members are ways and if their start and endpoints match). JOSM also includes an algorithm to automatically sort members. That algorithm could even be used to automatically place a new member at the correct position, or to prevent an unconnected member from being added to the route. That would make sense in a basic editor where people are not expected to do advanced editing. JOSM prefers to let the relation get broken to let you work and issue a warning when validating data before submission in case you forgot something. Cool: let's start editing relations. Well, first, earlier we said that relations aren't spatial. The meaning of the vast majority of relations is spatial. Are lines spatial without their points? Is an empty line spatial? Well, some are, some aren't. Maybe half and half. Some are used to structure multipolygon geometries. Okay, but most relations are invisible. Great, so relations are groups of things that can be zero or many, for technical reasons, spatial relationships, or abstract relationships. Now we're getting started. Relations, unlike sets in math, are ordered. Unlike ordered sets, they also have special ways in which each element is contained. So they're kind of like ordered, semantic sets of potentially anything. And, typically, invisible. Now that we've discussed the basics of relations, let's cover each of the different kinds, including each kind's stipulations of what is contained, whether order matters, and the role tags that are unique to each use-case. ...You can see where this is going: I haven't started to explain what you use relations for, and we've already seen the sort of mountain of unpredictable complexity they add to the OpenStreetMap data model - one of the fundamental things that makes it both more powerful than most data models and incompatible with all other data models. Relations are lists of objects, each with an assigned role. They are used to represent areas with holes (called multipolygons), large boundaries, routes (roads, railroads, buses, trams, ferries, hiking, cycling, and waterways), and turn restrictions. [2][3] Multipolygons, boundaries and routes (including waterways) are all very common relations and they all represent spatial concepts do get rendered - at least by popular renderers like Carto. Restrictions are far less common (1/5th of occurences when compared to multipolygons, surely fewer than routes+boundaries combined). It's hard to say they do not represent a spatial/directional concept since the vast majority have a via point around which the restriction is placed. The remaining common types [1] that are also approved by the community [3] essentially fall in the category of invisible unordered sets: public_transport, route_master. It's hard to say that public_transport is not spatial, since the bounds of its members usually occupy a very narrow area. route_master is seldom broken because users rarely edit its member relations. You're editing the map, but the relation is for routing software or maybe a very large polygon which is limited by some technical limits that we'll get into later. If that's your view, why is that iD (and Potlatch) has a turn restriction editor? Isn't the interest in turn restrictions limited to routing software? Another very practical use of relations is to avoid having to overlap lines that match exactly. Editing areas and lines that overlap is very cumbersome in any editor, even in JOSM. Regardless, when you break those kinds of relations, you won't know, because you can't see the breakage on the map, only in some software that you probably aren't using. Which map are you talking about? The one the editor displays, the one on the main website, or some other apps'
[OSM-talk-fr] Un GPS pour guider les aveugles en randonnee
Cet exemple d application je l aurais bien vu a base de donnees OSM. Je pense que la FFRP a du faire du micro-mapping pour recenser les obstacleshttps://fr.news.yahoo.com/gps-guider-aveugles-randonn%C3%A9e-143514508.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
On 27.06.2015 18:58, Fernando Trebien wrote: When this notion of grouping is presented at the very beginning, I believe people will easily understand it for all of the advanced scenarios The notion of grouping would at least be more intuitive the common relationship between things, which is very remote from how relations are often used. Still, it isn't really a natural fit for some relation types, e.g. building, bridge, tunnel, ... relations. So if we are discussing to re-frame relations in a more understandable fashion, I wonder if we shouldn't turn relations into *objects*. From the current OSM environment, it seems clear that preset-based user interfaces are popular. Mappers tend to grasp the concept of creating an object, then adding more information to it quite easily. So what if we base the data model around this? Imagine mapping a building. Currently, there is a stark contrast between the outline and the height of the building: One is a tag, and the other is a way, i.e. geometry. Values can be many things - text, distances, speed limits - but they cannot be geometry. If the building was an object, then both the height and the outline could be added as values of tags. Naturally, there could also be multiple keys with geometry values, resulting in the same expressive power as our relations - but in a much less scary wrapping. Of course, behind the scenes this would still look like a relation with tags and members. It's all in the presentation and ubiquity. I believe (a hypothesis that would be interesting to test) that this would make the more complex features of OSM significantly more accessible. So should we target this for API 0.7? Not really. I'm under no illusion that something like this could happen anytime soon. But imo it's an fascinating idea to think about. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-br] Desenho de vias não-pavimentadas
Pessoal, Tem uma proposta de estilo visual pra vias não pavimentadas que parece bem promissora, dêm uma olhada, comentem, mostrem apoio pra que essa feature se torne realidade logo! https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-116145329 Pra quem quiser pular o texto: https://cloud.githubusercontent.com/assets/899988/8393921/9ea34920-1d23-11e5-86b3-c1896c2f0964.png -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-cat] vissri3 i fils de conversa, era Re: Editors d'Osona i majúscules en noms de carrers
He entès que còpies els noms dels carrers del vissri3, d'aquí la meva pregunta. Pel que tinc entès les obres no són domini públic fins 70 anys de la mort de l'autor a no ser que aquest especifiqui el contrari. Crec que no barrejo fils de conversa, perquè he tret aquest tema en el fil que s'ha comentat l'us del vissrir3. Potser preferiu que obri un altre fil? signature.asc Description: PGP signature ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] Majúscules i minúscules
Una tercera via que actualment no es pot desenvolupar (federalisme?) fora que OSM permetés indicar qualsevol tipus de via (torrent, rambla, ...) a highway i deixar name (en majúscules) pel nom propi de la via. Josep Sent from Yahoo Mail on Android From:Joan Montané j...@montane.cat Date:ds., juny 27, 2015 at 22:41 Subject:Re: [Talk-cat] Majúscules i minúscules Hola, tot seguit, la meva *opinió* sobre l'ús de majúscules i minúscules. És un tema en el que he rumiat una mica. Resum curt: Una cosa són les dades, i l'altra l'ús que en fem. OSM és una base de dades, no un mapa, per tant els articles inicials dels topònims amb article (el Prat de Llobregat, l'Hospitalet, el Vendrell...) hauriem de tenir-los en minúscula. També els terme genèric que designa el tipus de via (carrer, passeig, avinguda, plaça...). Resum llarg: En català, tradicionalment, l'article inicial dels topònims amb article es mostra en minúscula en els mapes. Vaig fer una correcció en molts topònims seguint aquesta lina, amb una petita macro, però només amb els que tenen article, no pas tots els topònims!!! Barcelona i Manacor s'escriuren en majúscula, el Prat i la Seu d'Urgell tenen la 1a lletra en minúscula. En les plaques dels carrers, tradicionalment, s'han usat només tot majúscules (PLAÇA DE LA FONT). De fet, si no vaig errat, així estan codificats al cadastre espanyol. Bé, pitjor, els tenen codificats tot en majúscules i sense accents. Coses d'haver fet la digitalització amb una sabata i una espardenya, quan treballar amb minúscules i accents era perillós. Es pot argumentar que la majúscula dels noms de via és per la posició inicial (en la placa). Bé, jo he vist totes les combinacions. TOT MAJÚSCULA, Primera en Majúscula i primera en minúscula. Espero que a ningú se li acudeixi sol·licitar que ho posem TOT EN MAJÚSCULA perquè és la forma més estesa al territori. Perquè sóc contrari a posar la Carrer de Doncs perquè no hem de cartografiar per al rendertizador. Aquesta majúscula inicial és un cas (molt subtil, certament) de mapeig per al renderitzador. La majúscula inicial de Carrer no forma part de les dades. Si la posem a l'etiqueta name de l'OSM apareixerà així a tots els serveis, també quan no toca, com per exemple en unes indicacions d'adreces, o en un munt de llocs més. El projecte OSM és molt més que un mapa generat automàticament. És una base de dades cartogràfica, amb múltiples usos. Les dades de la base de dades haurien de ser independents del servei. Vissir potser usa majúscules en els noms de vies, però el *Carrerer*, també de l'ICGC usa minúscules [1]. Suposo que tots dos xuclen de la mateixa base de dades, com creieu que ho tenen codificat? Tot aquest maldecap és a causa que la tecnologia i eines que usem estan focalitzades en un entorn anglosaxó. L'ús que fan en anglès de la majúscula és sensiblement diferent al que fem en les llengües llatines. Els anglòfons foten majúscules en casos on nosaltres no les fotem (Baker Street, per exemple els noms de llengües), i per això aquest petits desajustaments. Ells no necessiten un paràmetre al renderitzador per a forçar (o no) la majúscula al tipus de via. Ja hi foten la majúscula directament a les dades perquè sempre usen majúscula, sigui quin sigui el context (en un mapa, en unes indicacions o en un paràgraf). Jo, si he de triar entre: 1.- o bé un mapa on els tipus de via surti en minúscula (com surt ara al carrerer de l'ICGC) i no apareguin majúscules on no toca en altres serveis; 2.- o bé un mapa on el tipus de via surti en majúscula (com Vissir de l'ICGC) i apareguin majúscules sempre en tots els altres serveis; trio la 1a opció. Dit això, m'agradaria intentar consensuar el tema de la majúscula/minúscula dels tipus de via. No vull fer-ne una guerra santa. Si el consens és cap a majúscules doncs unifiquem cap allà, i si és cap a minúscula doncs uinifiquem cap aquí. HO escribim al wiki i qui editi en contra del consens, doncs tibada (amable) d'orelles. Atentament, Joan Montané [1] http://mercuri.icc.cat/website/guia/carrerer.html ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [OSM-talk-fr] Intégration des Boites Postale dans Osmose
Le 27/06/2015 18:24, Jérôme Amagat a écrit : je pense qu'en résonnant comme ça, il faut supprimé pas mal des intégration possible dans osmose. exemple, les pharmacies, les stations services, même les écoles, c'est pas toujours facile de savoir ce que c'est su la photo aérienne (parce que c'est bien ça le problème, que la photo aérienne ne nous aide pas beaucoup pour placé la boite au lettre). Moi je proposerai seulement de modifié le commentaire en rouge dans osmose, là il n'y a que l'adresse, pour certains éléments à intégré, il y a géocodé a la rue ... peut être ajouter quelque chose du genre qui fait comprendre que c'est pas la position exact. Un point commun des 3 que tu cites, et qui les différencie des boîtes aux lettres et des hydrants, c'est le sens de l'adresse associée. Dans les 3 cas on sait qu'on cherche à renseigner un bâtiment, on a donc 3 sources à dispo : celle configurée dans Osmose (pour l'adresse), bing (pour le bâtiment, la cour...), et le cadastre (pour l'adresse et le bâtiment). Il y a moyen de recouper, fiabiliser. C'est une différence majeure avec une source de boîtes aux lettres, d'hydrants, ou autres petits éléments. Comme tu le suggères, dans le cas des BAL, rajouter un avertissement quand le n° d'adresse est à 0 ( = pas de numéro) irait dans le bon sens. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-us] Mapping Southern Maryland: A new local group
EricDid you contact Univ of MD Eastern Shore? If not I can put you in contact with their GIS professor? Tom MuellerSent from Yahoo Mail for iPad From: Alan Bragg alan.d.br...@gmail.com; To: talk-us@openstreetmap.org; Subject: Re: [Talk-us] Mapping Southern Maryland: A new local group Sent: Sat, Jun 27, 2015 5:08:40 PM Eric, Im not ready to join your group but Im willing to put in a couple hours armchair mapping once you have a specific task. Just let me know.Thanks for posting.Alan BraggBedford MA Message: 1 Date: Fri, 26 Jun 2015 21:57:54 -0400 From: Eric H. Christensen e...@christensenplace.us To: talk-us@openstreetmap.org Cc: mappin...@googlegroups.com Subject: [Talk-us] Mapping Southern Maryland: A new local group Message-ID: 20150627015754.gb3...@eric.home.christensenplace.us Greetings, A couple of weeks ago I reached out to many of the OSM account holders that are in my area hoping they would be interested in creating a local community for mapping southern Maryland. I found a few victims and so were pressing on! Im still working on all the logistics (website, listserv, etc) but I have created a wiki page[0] where Ill start collecting information regarding the community. If youd like to join us please put your name on the wiki page. I hope to have all the infrastructure figured out over the coming days. [0] https://wiki.openstreetmap.org/wiki/Mapping_Southern_Maryland Thanks! - --Eric -- Message: 2 Date: Fri, 26 Jun 2015 19:13:29 -0700 From: Clifford Snow cliff...@snowandsnow.us To: Eric H. Christensen e...@christensenplace.us Cc: mappin...@googlegroups.com, talk-us talk-us@openstreetmap.org Subject: Re: [Talk-us] Mapping Southern Maryland: A new local group Eric, Way to go! If you need any help organizing let us know. There is a good lighting talk at this years SOTM-US on conducting a Mapathon by Robin Tolochko, UW Madison. The talk is online at http://stateofthemap.us/lightning-talks-sun/ Clifford ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk-fr] Chiffres romains
Le 28 juin 2015 00:58, Thierry Bézecourt thie...@thbz.org a écrit : Le 28/06/2015 01:19, Jérôme Seigneuret a écrit : J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi et le fameux codage BCP47 Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples et compréhensibles. Personne n'utilisera des balises aux noms aussi absc ons que fr-fonapi ou und-fonapi... fr-fonipa n'est abscond que pour ceux qui ne savent pas qu'une telle norme existe et qui la lisent mal ou en diagonale express (en ne lisant qu'une phrase piquée dans le texte hors de son contexte et des définitions qui précèdent concernant les termes utilisés). Quand on a compris que ce qui suit name:*=* est un code BCP47, on a accès à toutes ses variantes et on n'est pas réduit aux seul codes à 2 lettres venus de l'ISO 649-1. Et sionon pour beaucoup même name:fr=* est abscond puisqu'ils croient à tord que cela désigne un nom pour la France (ils confondent codes langues et codes pays et ça donne des trucs aussi infames que name:jp=*, ou encore name:als=* et name:zh-classical venus d'une confusion grossière entre un nom de sous-domaine spécifique à une édition de Wikipédia et un véritable code langue) BCP47 est en fait très simple et très clair, d'autant plus qu'il est universel (ce qui n'est pas du tout le cas de pas mal de codifications dans OSM qui nécessitent un apprentissage spécifique et où il n'y a aucune cohérence entre tags pourtants similaires !). Ce n'est pourtant pas compliqué: le premier code avant le premier tiret est toujours un code langue, les autres sont des extensions dans l'ordre - un code d'extension pour accéder à un code langue primaire quand le premier code n'est pas suffisant et que toutes les langues de cette famille ne sont pas mutuellement compréhensibles (code de famille linguistique, tels que roa): cette extension n'est plus utilisée depuis que plus de 7000 langues ont été codées dans ISO 639-3, et dans certains cas ces codes de regroupement étaient même faux (exemple avec zh-min-nan) ou de format incorrect (zh-classical, en-simple). - un code d'écriture (ex. ur-Arab contre ur-Deva qui est en fait pratiquement équivalent à hi-Deva pour le Hindi; meilleur exemple avec tk-Latn et tk-Arab) - un code de région (ex. en-US contre en-GB) - un code de variante orthographique ou linguistique (e.g. en-bootling): fonipa peut être utilisé ici quelque soit les codes qui précèdent, les variantes phonétiques sont nommées simplement par convention avec le sous-code fon* - des codes supplémentaires d'extension pour autre chose que la langue ou la convention orthographique (par exemple le tri, une préférence de format de dates ou de monnaie) utilisant un premier code à 1 lettre suivi d'un code à 2 caractères alphanum ou plus - des extension totalement privées et libres avec le code x suivi d'un autre code jsuqu'à 8 alphanum Ce format est immuable (il n'a en fait pas réellement bougé depuis près de 40 ans meˆme s'il a eu des extensions, il est resté compatible; il est beaucoup plus utilisé qu'OSM qui est encore extrèmement jeune et même plus encore que l'UCS d'Unicode et ISO/CEI 10646, ou *les* normes ISO 639 qui sont incompatibles entre leurs éditions sucessives, y compris depuis l'ISO 639-3 qui a rajouté de la complexité et de l'ambiguité que BCP 47 résoud complètement tout en préservant la compatibilité ascendante). L'algo pour résoudre les resources dans des jeux de traductions disponible est standardisé par BCP47 et par les données présentes dans la base IANA (qui définit les alias et codes préférés), ce qui permet aux applis de fonctionner même avec des traductions incomplètes sans avoir à chaque fois à afficher uniquement de l'anglais ni même obliger les applis à fournir une traduction anglaise complète. OSM reste une base de données quji sera utilisée par des outils techniques et les éditeurs peuvent très bien prendre en charge le nom des tags (iD le fait déjà sans qu'on soit obligé au prermier abord de coder ça correctement). OSM est destiné à être utilisé par des outils techniques qui feront des analyses automatiques. Autant donc choisir les techniques d'automatisation standarisées (déjà implantées dans de très nombreux logiciels pour ne pas avoir à les réécrire ou les corriger au fur et à mesure ce qui double le travail pour rien) car de toute façon on ne peut pas se passer d'une codification technique. Si on a des éditeurs pour OSM c'est justement pour ne pas avoir à tout coder à la main, les éditeurs se chargent de contrôler et proposer une interface facile. Mais sinon name:fr-fonipa=* reste tout à fait lisible une fois qu'on a compris ce que ça représente en ayant lu *seulement* que le code qui suit un name:* est un code BCP47 standard: si le code ne correspond pas à cette norme, il ne sera tout bonnement pas lu correctement par les outils techniques, et la donnée ne sert plus à rien d'autre, c'est du commentaire, qui ne sera même pas utilisé dans un rendu avant
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
On 6/27/2015 1:14 PM, Fernando Trebien wrote: Actually no, the server checks for circular dependencies, and a relation pointing to itself is a cycle. Try it, the server returns a validation error. Nothing in the OSM data model prohibits a relation that references itself, or relations that form a cycle. As an example, see https://www.openstreetmap.org/relation/1368401 which contains itself twice. Longer cycles are also possible. I can't imagine a case where a cycle is sensible, and they are often difficult to delete, first requiring modifying the relations to remove the cycle, then deleting the relations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cat] Majúscules i minúscules
http://www20.gencat.cat/docs/ptop/Home/Serveis%20i%20tramits/Biblioteca%20i%20documentacio/Planificacio%20territorial/Publicacions/Cartografia%20i%20toponimia/Criteris%20per%20a%20la%20toponimia%20dambit%20municipal_Criteris/docs/criteris_escriptura.pdf Hola, tot seguit, la meva *opinió* sobre l'ús de majúscules i minúscules. És un tema en el que he rumiat una mica. Resum curt: Una cosa són les dades, i l'altra l'ús que en fem. OSM és una base de dades, no un mapa, per tant els articles inicials dels topònims amb article (el Prat de Llobregat, l'Hospitalet, el Vendrell...) hauriem de tenir-los en minúscula. També els terme genèric que designa el tipus de via (carrer, passeig, avinguda, plaça...). Resum llarg: En català, tradicionalment, l'article inicial dels topònims amb article es mostra en minúscula en els mapes. Vaig fer una correcció en molts topònims seguint aquesta lina, amb una petita macro, però només amb els que tenen article, no pas tots els topònims!!! Barcelona i Manacor s'escriuren en majúscula, el Prat i la Seu d'Urgell tenen la 1a lletra en minúscula. En les plaques dels carrers, tradicionalment, s'han usat només tot majúscules (PLAÇA DE LA FONT). De fet, si no vaig errat, així estan codificats al cadastre espanyol. Bé, pitjor, els tenen codificats tot en majúscules i sense accents. Coses d'haver fet la digitalització amb una sabata i una espardenya, quan treballar amb minúscules i accents era perillós. Es pot argumentar que la majúscula dels noms de via és per la posició inicial (en la placa). Bé, jo he vist totes les combinacions. TOT MAJÚSCULA, Primera en Majúscula i primera en minúscula. Espero que a ningú se li acudeixi sol·licitar que ho posem TOT EN MAJÚSCULA perquè és la forma més estesa al territori. Perquè sóc contrari a posar la Carrer de Doncs perquè no hem de cartografiar per al rendertizador. Aquesta majúscula inicial és un cas (molt subtil, certament) de mapeig per al renderitzador. La majúscula inicial de Carrer no forma part de les dades. Si la posem a l'etiqueta name de l'OSM apareixerà així a tots els serveis, també quan no toca, com per exemple en unes indicacions d'adreces, o en un munt de llocs més. El projecte OSM és molt més que un mapa generat automàticament. És una base de dades cartogràfica, amb múltiples usos. Les dades de la base de dades haurien de ser independents del servei. Vissir potser usa majúscules en els noms de vies, però el *Carrerer*, també de l'ICGC usa minúscules [1]. Suposo que tots dos xuclen de la mateixa base de dades, com creieu que ho tenen codificat? Tot aquest maldecap és a causa que la tecnologia i eines que usem estan focalitzades en un entorn anglosaxó. L'ús que fan en anglès de la majúscula és sensiblement diferent al que fem en les llengües llatines. Els anglòfons foten majúscules en casos on nosaltres no les fotem (Baker Street, per exemple els noms de llengües), i per això aquest petits desajustaments. Ells no necessiten un paràmetre al renderitzador per a forçar (o no) la majúscula al tipus de via. Ja hi foten la majúscula directament a les dades perquè sempre usen majúscula, sigui quin sigui el context (en un mapa, en unes indicacions o en un paràgraf). Jo, si he de triar entre: 1.- o bé un mapa on els tipus de via surti en minúscula (com surt ara al carrerer de l'ICGC) i no apareguin majúscules on no toca en altres serveis; 2.- o bé un mapa on el tipus de via surti en majúscula (com Vissir de l'ICGC) i apareguin majúscules sempre en tots els altres serveis; trio la 1a opció. Dit això, m'agradaria intentar consensuar el tema de la majúscula/minúscula dels tipus de via. No vull fer-ne una guerra santa. Si el consens és cap a majúscules doncs unifiquem cap allà, i si és cap a minúscula doncs uinifiquem cap aquí. HO escribim al wiki i qui editi en contra del consens, doncs tibada (amable) d'orelles. Atentament, Joan Montané [1] http://mercuri.icc.cat/website/guia/carrerer.html ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [OSM-talk-fr] Chiffres romains
Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi
et le fameux codage BCP47
Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples et
compréhensibles. Personne n'utilisera des balises aux noms aussi abscons
que fr-fonapi ou und-fonapi...
Il n'y a aucune raison des suivre un standard à la lettre dans un format
interne de base de données. C'est lors de l'échange avec des logiciels
tiers que les standards ont un sens.
Donc la structure interne de la base OSM doit rendre cet échange
possible : par exemple, il vaut mieux suivre les standards pour les
codes de langue (fr, en...), qui sont d'ailleurs largement connus.
Mais pour le reste on fait ce qu'on veut.
Je ne crois pas qu'on ait cité ici le débat sur l'ajout de champs du
type name:lang:phonetics ou name:phonetics:lang :
http://wiki.openstreetmap.org/wiki/Proposed_features/Phonetics
Certains utilisent aussi pronunciation :
https://taginfo.openstreetmap.org/search?q=pronunciation
Thierry
Celui est mentionné par Philippe Verdy :
- http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/72406
Ducoup je sais qu'Eric nous parle OsmAnd sur android ;-)
L'alphabet phonétique international (IPA est l'abréviation anglaise)
répond est un standard iso (15924)
Je suis allé faire un tour sur la doc BCP 47
https://tools.ietf.org/html/bcp47 et donc la structure n'est pas
encore la bonne car en me tapant la doc je viens de voir qu'on parle
d'un suffixe *fonipa*. Surement une erreur involontaire dans la page de
Wikipedia. En même temps je préfère avoir les informations à la source.
/An example of such a no-prefix variant is the subtag 'fonipa', which
represents the/
/International Phonetic Alphabet, a scheme that can be used to
transcribe many languages/
/
/
Je suis allé sur du code Android et j'ai trouvé ça comme variante de language
1. FONIPA{alphabet phonétique international}
2. FONUPA{alphabet phonétique ouralique}
name:fonipa est valable pour une traduction international
name:fr-fonipa pour la France en respect à laRFC 5646
https://tools.ietf.org/html/rfc5646
Le 27 juin 2015 16:33, Thierry Bézecourt thie...@thbz.org
mailto:thie...@thbz.org a écrit :
Bonjour,
En ce qui concerne les chiffres romains, je vois mal comment une
détection automatisée pourrait fonctionner. Quelle expression
régulière pourra-t-elle deviner que George V utilise un chiffre
romain mais pas Avenue D (à Manhattan), Quai C ou Escalier I ?
Exemple : cette requête Overpass (certes imparfaite) essaie de
détecter les cas d'utilisation de nombres en chiffres romains.
Difficile de séparer les cas où c'est vraiment des chiffres romains
(pas si nombreux) de ceux où c'est une lettre :
http://overpass-turbo.eu/s/a8O
Et surtout, comme le signalait Jérôme Seigneuret, le problème des
chiffres romains n'est que l'arbre qui cache la forêt des
prononciations locales ou irrégulières. Un GPS m'a un jour conseillé
de prendre la direction Kimpé lors d'un voyage en Bretagne...
En fait, c'est même plus général que le GPS. La prononciation des
données d'OSM est une question générale d'accessibilité (malvoyants,
etc.), que seul un champ spécifique peut résoudre. Il n'y a pas des
réflexions à ce sujet ?
Le 27/06/2015 03:41, Philippe Verdy a écrit :
Bref on revient à la solution de fournir un alt_name=*
Pourquoi alt_name ? J'attends de mon GPS vocal qu'il utilise le
name, puisque c'est lui qui figure sur les panneaux en bord de
route. Et si on met la prononciation dans le alt_name parce qu'on
sait que certains GPS utilisent le alt_name d'une certaine manière,
c'est qu'on tague pour le GPS...
Il me paraît bien plus logique, du point de vue de la base de
données comme des utilisateurs, d'utiliser un champ spécifique, quel
que soit son nom (name:fr-fonapi, name:phonetics,
name:fr:phonetics). Ensuite, celui qui exporte les données OSM vers
un GPS pourra toujours, le cas échéant, mettre ce champ là où ce
sera le plus utile pour le GPS (ou pour tel lecteur d'écran).
D'autant qu'on n'est pas obligé d'exiger la saisie en API. Une
saisie approximative (Quimpère, George 5) pourrait faire
l'affaire. Il y a aussi X-SAMPA, version ASCII de l'API, mais je ne
sais pas si c'est vraiment une simplification, surtout pour la
langue française.
--
Thierry B.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org mailto: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
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Interesting, I remember long ago trying to upload (by accident) a set of relations with a cyclic dependency and receiving a server error. Maybe the message was phrased in a misleading way but the error was actually generated by JOSM. Will try again. Dependency checking must be aware of cycles, otherwise it may end up running an infinite loop. There are some other scenarios, such as retrieving a relation's incomplete members, where a self-reference can be problematic, but that's not the server's responsibility. I can't imagine right now any scenario where self-references or cyclic references woud be necessary to represent any information. (Not suggesting the the server should implement that check.) On Sat, Jun 27, 2015 at 9:03 PM, Paul Norman penor...@mac.com wrote: On 6/27/2015 1:14 PM, Fernando Trebien wrote: Actually no, the server checks for circular dependencies, and a relation pointing to itself is a cycle. Try it, the server returns a validation error. Nothing in the OSM data model prohibits a relation that references itself, or relations that form a cycle. As an example, see https://www.openstreetmap.org/relation/1368401 which contains itself twice. Longer cycles are also possible. I can't imagine a case where a cycle is sensible, and they are often difficult to delete, first requiring modifying the relations to remove the cycle, then deleting the relations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Chiffres romains
Merci pour ces explications détaillées qui m'aident à mieux comprendre
BCP47.
Mais l'un des problèmes que rencontre Wikipédia actuellement, c'est que
le code wiki est devenu trop compliqué, au point apparemment de rebuter
de nombreux utilisateurs. Donc ils ont développé un éditeur visuel, qui
est lourd et qui marche plus ou moins bien.
Ce serait dommage qu'OSM suive le même chemin en imposant des balises
aux noms non intuitifs. Cela conduirait à une clubbisation d'OSM, où
seuls les experts pourraient comprendre comment cela fonctionne ;
d'autant que, les projets collaboratifs étant ce qu'ils sont, on ne peut
pas espérer que le système sera stable un jour.
L'utilisateur moyen d'OSM ne lira jamais une RFC en entier. De même, il
serait exagéré d'exiger que le contenu soit saisi en IPA (tant qu'à
faire, on pourrait proposer que le name soit saisi en HTML ou en RTF
pour mieux respecter la typographie). Il faut fournir une possibilité de
le saisir en langage plus simple.
Il y a des outils conviviaux, certes. C'est sans doute bien pour les
utilisateurs occasionnels, mais cela complique la tache pour les
utilisateurs aguerris (libellés différents d'un outil à l'autre, mise à
jour incertaine des outils par rapport aux règles mouvantes d'OSM...).
Bref, choisir des noms de balise compliqués parce qu'ils sont standards,
cela revient à favoriser le développeur qui utilise les données de la
base de données par rapport au contributeur moyen d'OSM.
Et encore, cela revient à privilégier le développeur paresseux. Si
j'exporte les données d'OSM vers une base externe, je vais tout de même
vérifier un peu que les données sont correctes. Le nom des tags étant
libre dans OSM, le développeur sérieux ne va pas supposer que toute
balise lang-... est une balise BCP-47. Il devra bien faire des
vérifications sur le format du tag, donc ça ne constituera pas une
complexité supplémentaire pour lui de convertir :phonetics en
-fonapi au besoin.
On pourrait envisager un système à deux niveaux :
- name:lang:pronunciation : prononciation approximative (Quimpère,
George 5)
- name:tag_bcp7 : prononciation IPA pour les plus motivés
Quant à X-SAMPA, ça n'est pas à la portée du premier venu... Exemple
(indice : c'est de l'anglais) :
| @Up@n stri:t m{p s bIlt baI @ k@mju:nIti @v m{p drA:p@rz D@t
k@ntrIbju:t @nd meInteIn deIt@ @baUt r@Udz | treIlz | k{feIz |
reIlweI steISn=z | @nd mVtS mO: | O:l @Uv@ D@ w3:ld |
Thierry
Le 28/06/2015 09:05, Philippe Verdy a écrit :
Le 28 juin 2015 00:58, Thierry Bézecourt thie...@thbz.org
mailto:thie...@thbz.org a écrit :
Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :
J'ai pas encore trouvé une seule valeur utilisant le tag
name:fr-fonapi
et le fameux codage BCP47
Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples
et compréhensibles. Personne n'utilisera des balises aux noms aussi
absc
ons que fr-fonapi ou und-fonapi...
fr-fonipa n'est abscond que pour ceux qui ne savent pas qu'une telle
norme existe et qui la lisent mal ou en diagonale express (en ne lisant
qu'une phrase piquée dans le texte hors de son contexte et des
définitions qui précèdent concernant les termes utilisés).
Quand on a compris que ce qui suit name:*=* est un code BCP47, on a
accès à toutes ses variantes et on n'est pas réduit aux seul codes à 2
lettres venus de l'ISO 649-1. Et sionon pour beaucoup même name:fr=*
est abscond puisqu'ils croient à tord que cela désigne un nom pour la
France (ils confondent codes langues et codes pays et ça donne des trucs
aussi infames que name:jp=*, ou encore name:als=* et
name:zh-classical venus d'une confusion grossière entre un nom de
sous-domaine spécifique à une édition de Wikipédia et un véritable code
langue)
BCP47 est en fait très simple et très clair, d'autant plus qu'il est
universel (ce qui n'est pas du tout le cas de pas mal de codifications
dans OSM qui nécessitent un apprentissage spécifique et où il n'y a
aucune cohérence entre tags pourtants similaires !).
Ce n'est pourtant pas compliqué: le premier code avant le premier tiret
est toujours un code langue, les autres sont des extensions dans l'ordre
- un code d'extension pour accéder à un code langue primaire quand le
premier code n'est pas suffisant et que toutes les langues de cette
famille ne sont pas mutuellement compréhensibles (code de famille
linguistique, tels que roa): cette extension n'est plus utilisée
depuis que plus de 7000 langues ont été codées dans ISO 639-3, et dans
certains cas ces codes de regroupement étaient même faux (exemple avec
zh-min-nan) ou de format incorrect (zh-classical, en-simple).
- un code d'écriture (ex. ur-Arab contre ur-Deva qui est en fait
pratiquement équivalent à hi-Deva pour le Hindi; meilleur exemple avec
tk-Latn et tk-Arab)
- un code de région (ex. en-US contre en-GB)
- un code de variante orthographique ou linguistique (e.g. en-bootling):
fonipa peut être utilisé ici quelque
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
On Sat, Jun 27, 2015 at 10:49 AM, Tom MacWright t...@macwright.org wrote: Okay, but most relations are invisible. Relations are visible* if the editor makes them visible.* The iD editor introduced an entirely synthetic primitive: the area. Thus, in iD, the area is visible. The iD editor, or an editor like it, could introduce a grouping, and make it visible. Relations are not only possible to visualize, they're interesting, Click on Main Street and see the 12 bus lines that use Main street? Interesting. Click on a line and learn it forms the USA/Canadian Border, 8,891 km long, consisting of 5000 odd line segments? Interesting and instructive. A series of iD plugins for visualizing specific types of relations would rock. And of course in iD style they'd be called something different, like, say, Turn Restrictions or a Public Transit Route or Site or a Level 8 Administrative Boundary between X and Y. The word relation need never come into it. -- By all-but-ignoring relation editing, Potlach and iD only make it easy to ignore or even *damage* relations. It's all downside. That's not what you want for entry level editing. A good experience for a starting user is they made a positive contribution, they saw the results rendered, and they did not mess anything up. When the editor makes messing up an invisible single click (or inadvertent click) operation, it leads to stress all around. Relations are invisible only in editors that* leave them in the shadows.* An editor that ignores or tries to hide a thing is unlikely to be the best way to edit (or preserve) the invisible thing. It's a form of fake simplicity: making a given edit seem to be simpler than it really can be. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] Bruxelles centre : nouveau piétonnier
Zou iemand zo vriendelijk (en politiek correct) willen zijn om er ook de Nederlandse naam bij te zetten? On 25-06-15 14:24, Jo wrote: Cela me semble préférable à une nuit passé à resoudre des conflits... 2015-06-25 16:11 GMT+02:00 Matthieu Gaillet matth...@gaillet.be mailto:matth...@gaillet.be: Alors si personne n’est contraire j’uploade ce soir. Il est vrai que le temps que les serveurs propagent la mise à jour et que les utilisateurs le fassent également ça nous laisse de la marge. On 25 Jun 2015, at 16:07, Jo winfi...@gmail.com mailto:winfi...@gmail.com wrote: En fait, il ne serait même pas si grave si nous sommes un peu trop tôt... 2015-06-25 16:00 GMT+02:00 Matthieu Gaillet matth...@gaillet.be mailto:matth...@gaillet.be: Merci Jo. Comme je m’ennuyais hier soir, j’ai commencé le boulot, essentiellement changer des tags aux routes existantes, des sens de circulation, et tracer des areas pedestrian. Le reste (pistes cyclables notamment, elle sont entrain d’être tracées) pourra être fait par après. L’idée est de faire en sorte qu’OSM soit prêt à minuit pile ;) Si ça marche on pourrait d’ailleurs en faire un communiqué de presse... J’espère que cette partie au moins ne posera pas trop de souci. Je vous ferai un retour d’expérience. Matthieu On 25 Jun 2015, at 13:00, Jo winfi...@gmail.com mailto:winfi...@gmail.com wrote: Salut Matthieu, J'attendrai simplement le jour que ça change et puis je commencerais de changer petit à petit. Si tu vas préparer des fichiers une semaine à l'avance, tu risques d'avoir beaucoup de conflits à resoudre. Jo 2015-06-24 17:26 GMT+02:00 Matthieu Gaillet mgwebm...@fastmail.fm mailto:mgwebm...@fastmail.fm: Hello, Dans quelques jours, le centre-ville de Bruxelles va être bouleversé par la mise en place d’un piétonnier, et surtout de la fermeture des axes principaux aux voitures et de la mise en place d’un « mini-ring » ou « boucle de desserte ». La majeure partie des changements est déjà connue via le site officiel de la Ville : http://plandecirculation.be/ Questions : 1°) pouvons-nous utiliser ces informations pour mettre à jour OSM ? Remarquez l’usage de Mapbox au passage ! 2°) est-ce que cela vaut la peine de préparer un changeset et de l’uploader dans une petite semaine ? 3°) est-ce d’autres mappeurs travaillent déjà là-dessus ? Si oui, comment coordonner tout ça ? Cette question vaut de manière générale pour tout changement d’envergure et planifié... Merci de vos réponses ! Matthieu ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] Chiffres romains
oui mais en comparant: name:fr-fonipa et name:phonetic:fr lequel est le plus simple d'après toi ? Et demandera le moins de travail spécifiqure pour gérer les exceptions aux règles BCP47 qui sont déjà implémentées dans des bibliothèques partagées et qui ne demandent pas dêtre maintenaues séparément avec beaucoup moins de développeurs disponibles pour comprendre ce qu'il en est ? OSM s'est trop largement tenu à l'écart des normes existantes en voulant créer la sienne sans aucun bénéfice supplémentaire. Résultat: la lourdeur extrême d'utilisation de ses bases de données, les requêtes ultra compliquées pour chercher les features, des scripts d'export de plus en plus ingérables car les exceptions non maintenues (et souvent même pas dopcumentées ni réellement décidées) se sont multipliées de façon incohérente (et souvent même avec des incompatibilités entre elles!) Il n'y a strictement rien à gagner à s'écarter des normes quand elles sont suffisantes pour les problèmes à traiter. Bien au contraire ces écarts en s'accumulant deviennent de véritables boulets qu'on traine ensuite, et qui du fait des complications qu'ils impliquent, laissent des tas de cas oubliés, non testés, non gérés, et des anomalies ensuite à l'utilisation. Même Wikipédia s'en est rendu compte et maintenant uniformise ses codes langues propriétaires défaillants vers BCP47 (il n'en reste plus beaucoup à migrer, ils sont tous dans les tubes mais cela demande du travail non pas dans le code MediaWiki ou son paramétrage mais dans la conversion des stockages des bases de données, ce qui est énormément plus lourd à faire, et la conversion de tas de scripts shelle pour la maintenance, l'addittion de la prise en charge de divers alias pour la transition, la conservation si possible de noms de domaines pour limiter le nombre de liens brisés...) S'écarter des normes sans bonne raison justifiée par un bénéfice réel (alors qu'on est face uniquement çà une spécification technique) est toujours risquée. En fait cela n'aide même pas les utilisateurs qui au lieu de se fier à des normes qu'ils connaissent déjà et sont utilisées ailleurs, doivent apprendre à maitriser un tas d'exceptions purement locales : pour eux aussi c'est une perte de temps et pour nous aussi un gachis inutile de ressources et de moyen parce que cela aboutit ensuite à du temps perdu pour corriger, ou apporter un support technique supplémentaire ou de la formation. S'écarter des normes en fait les éloigne encore plus du projet (à commencer par tous les nouveaux arrivants, ou ceux qui ont décroché pendant un certain temps du projet et y reviennent sans être au courant qu'il y a de nouvelles exceptions à ce qui logiquement était supposé être une règle de base). Le bénéfice réel serait uniquement si cela apportait quelqurechose que la norme ne sait pas et ne peut pas gérer du tout dans son état actuel (même dans ses extensions privées autorisées, ce dont BCP47 dispose aussi avec les préfixes de sous-tags en -x-, mais là il n'est même pas question d'extension privée puisque la fonctionnalité est codifiée et déjà normalisée de façon suffisante pour exactement même but ; une transcription phonétique, en fait plutôt phonologique, n'est qu'une variante ortrhographique d'une langue, elle reste même spécifique à cette langue par rapport à son orthographe habituelle qui s'écarte souvent de la phonétiqure pure car phonétique et écriture n'évaluent pas au même rythme : la phonétique évolue beaucoup plus vite alors que les écrits restent là pour longtemps et existe alors une résistance normale à l'évolution orthographique qui fait alors apparaitre des lettres muettes, ou pas écrites de la façon ont elles sont prononcées, ou carrément omises de l'orthographe : orthographe et phonologie sont deux transcriptiosn de la même langue mais l'orthographe est plus figée et plus globale que la lange parlée réelle qui est nettement plus locale et plus restreinte dans le temps, même sans réelle évolution orale de la grammaire ou du vocabulaire morphologique). De fait il existe souvent des tas de réalisations phonologiques d'une même langue (surtout dans les langues très répandues dans le monde comme français et anglais) et donc l'apparition de tas de variété dialectales orales : pour simplifier un peu la phonologie tentent d'unifier certains sons et l'API n'est utilisée que sur une partie de ses capacités dans les transcrioptions (mais rien n'interdit pourtant d'utiliser une transcription non pas phonlogique mais phonétique de la langue y compris avec ses distinctions dialectales très locales, voire carrément personnelles) Mais pour nous en s'en tient juste à la phonologie moderne la plus cournate (celle des dictionnaires) qui devient alors une orthographe supplémentaire de cette langue (Le français a quatre orthographes officielles en France : - 1. traditionnelle (celle de l'Académie depuis sa création tardive), parfois avec des règles imposées juste pour limtier le nomb re de as même si
Re: [Talk-br] Desenho de vias não-pavimentadas
Também olha no https://github.com/OSMBrasil/mapnik-brasil que vai ser o estilo brasileiro. Voce pode ver como vai ficar se carregar o base.mapcss no estilos no JOSM Antes que este estilo vai ser rendericado precisamos resolver o hospede do estilo e tiles. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Limite de cidades com distritos
Como disse antes, o osm pode (como tem) quantas informações as pessoas queiram que ele tenha, embora nem sempre necessite. Será que o pensamento do quanto mais melhor deve nortear as linhas de um projeto, se o quanto menos melhor, ao final, é o que o usuário talvez realmente necessite? Temos ter em mente que as pessoas não existem por causa das coisas, mas o contrário: as coisas existem por causa (e para) as pessoas. Se a escola fechada não se adaptar ao brasileiro analfabeto, o que vai acontecer? Aumento do analfabetismo. De modo que a escola deve, sim - como tem ocorrido - se adaptar às pessoas, porque existe para elas e não o contrário. O analfabeto, que agora usa penas os dois polegares para operar os brinquedinhos, esse mesmo, que o sistema de educação pretende catequizar, é que será o usuário final das coisas, dos sistemas e das aplicações. Para finalizar, coloquei esse assunto em discussão aqui não com o objetivo de acabar com a vassalagem (desculpem o termo) do osm frente ao ibge, mas para mostrar que as vezes as regras absolutas podem gerar dúvidas e interpretação equivocada do resultado de uma pesquisa, que poderia ser mais simples, se fosse flexível. Aliás, regras sempre devem ser flexíveis e ter exceções. Quando isso não acontece, limita a criatividade, a melhoria. De modo que a intenção não foi, como pode ter parecido, querer mudar a forma como as coisa são feitas. Que fique como está. Mas fica o alerta. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limite de cidades com distritos
Em 27 de junho de 2015 23:41, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Temos ter em mente que as pessoas não existem por causa das coisas, mas o contrário: as coisas existem por causa (e para) as pessoas. Concordo. Se a escola fechada não se adaptar ao brasileiro analfabeto, o que vai acontecer? Aumento do analfabetismo. De modo que a escola deve, sim - como tem ocorrido - se adaptar às pessoas, porque existe para elas e não o contrário. É uma saída. Mas o ideal era que o aluno desenvolvesse o máximo dele. O analfabeto, que agora usa penas os dois polegares para operar os brinquedinhos, esse mesmo, que o sistema de educação pretende catequizar, é que será o usuário final das coisas, dos sistemas e das aplicações. É como dizer: eu atravesso a piscina mesmo sem nadar, porque alguém vai acabar me arremessando para o outro lado. Aliás, regras sempre devem ser flexíveis e ter exceções. Quando isso não acontece, limita a criatividade, a melhoria. Porém, a exceção não deve virar regra... Alexandre ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-be] Bruxelles centre : nouveau piétonnier
Zeker, maar waar bij? De Delhaize lijkt me tweetalig gemapt te zijn. Jo 2015-06-28 6:30 GMT+02:00 Karel Adams fa348...@skynet.be: Zou iemand zo vriendelijk (en politiek correct) willen zijn om er ook de Nederlandse naam bij te zetten? On 25-06-15 14:24, Jo wrote: Cela me semble préférable à une nuit passé à resoudre des conflits... 2015-06-25 16:11 GMT+02:00 Matthieu Gaillet matth...@gaillet.be: Alors si personne n’est contraire j’uploade ce soir. Il est vrai que le temps que les serveurs propagent la mise à jour et que les utilisateurs le fassent également ça nous laisse de la marge. On 25 Jun 2015, at 16:07, Jo winfi...@gmail.com wrote: En fait, il ne serait même pas si grave si nous sommes un peu trop tôt... 2015-06-25 16:00 GMT+02:00 Matthieu Gaillet matth...@gaillet.be: Merci Jo. Comme je m’ennuyais hier soir, j’ai commencé le boulot, essentiellement changer des tags aux routes existantes, des sens de circulation, et tracer des areas pedestrian. Le reste (pistes cyclables notamment, elle sont entrain d’être tracées) pourra être fait par après. L’idée est de faire en sorte qu’OSM soit prêt à minuit pile ;) Si ça marche on pourrait d’ailleurs en faire un communiqué de presse... J’espère que cette partie au moins ne posera pas trop de souci. Je vous ferai un retour d’expérience. Matthieu On 25 Jun 2015, at 13:00, Jo winfi...@gmail.com wrote: Salut Matthieu, J'attendrai simplement le jour que ça change et puis je commencerais de changer petit à petit. Si tu vas préparer des fichiers une semaine à l'avance, tu risques d'avoir beaucoup de conflits à resoudre. Jo 2015-06-24 17:26 GMT+02:00 Matthieu Gaillet mgwebm...@fastmail.fm: Hello, Dans quelques jours, le centre-ville de Bruxelles va être bouleversé par la mise en place d’un piétonnier, et surtout de la fermeture des axes principaux aux voitures et de la mise en place d’un « mini-ring » ou « boucle de desserte ». La majeure partie des changements est déjà connue via le site officiel de la Ville : http://plandecirculation.be/ Questions : 1°) pouvons-nous utiliser ces informations pour mettre à jour OSM ? Remarquez l’usage de Mapbox au passage ! 2°) est-ce que cela vaut la peine de préparer un changeset et de l’uploader dans une petite semaine ? 3°) est-ce d’autres mappeurs travaillent déjà là-dessus ? Si oui, comment coordonner tout ça ? Cette question vaut de manière générale pour tout changement d’envergure et planifié... Merci de vos réponses ! Matthieu ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
