Re: [OSM-talk-fr] Contours des communes dans le Gard
Le 13/02/2015 10:14, Tony Emery a écrit : Il faudrait songer, du coup, à des clé en poupée russe, comme on a dans les GEOFLA où la commune porte les identifiant des découpages supérieurs dans lesquelles elle se trouve (départements, epci, région, arrondissement). Dans GEOFLA, tu as des attributs pour chaque commune qui t'indique sont appartenance au découpages supérieurs, mais le code INSEE d'une commune ne contient que le code du département en préfixe. Pour les EPCI, ma source c'est ça: http://www.collectivites-locales.gouv.fr/liste-et-composition-des-epci-a-fiscalite-propre Les fichiers indiquent à quel EPCI chaque commune appartient. Je viens de demander les données 2015. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Sicilia 01: un layer per il ricalco
aborruso wrote Ciao Aury, ti rispondo un po' di corsa e me ne scuso. Immagino che il problema per i 500 Mb sia non lo spazio disco, ma il lavoro del processore nel gestire il singolo file. Una cosa molto comoda e semplice che puoi fare e convertire il singolo file scaricato in una piramide di tasselli, esattamente come il rendering di OSM. Ci sono tanti modi per farlo: da riga di comando c'è il vecchio ed efficace gdal2tiles. A quel punto hai una source che puoi leggere anche un PC non potente, e che puoi usare come sfondo. Saluti, a grazie mille per l'informazione...non conoscevo neanche questa possibilità ma comunque i problemi che ho riscontrato sono ancora prima, cioè a livello di decompressione del pacchetto scaricato (un tar.bz) che il mio pc non riesce a completare. ora riprovo la decompressione da linea di comando e nel caso riporto l'errore/log in un forum di supporto per gli utenti linux ;) - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Sicilia-01-un-layer-per-il-ricalco-tp5828143p5833442.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] Utilisation d'OSM par des collectivités
Le 13 févr. 2015 à 04:46, Philippe Verdy verd...@wanadoo.fr a écrit : Il y a deux pages françaises liées à la même page anglaise (mais l'anglaise ne se lie qu'à la première). (1) fr:Sites en ligne utilisant OSM (2) fr:Autres cartes en ligne Les deux ont des listes très similaires (la première disposant du lien de redirection interlangue basé sur le titre anglais List of OSM-based services (qui dans le passé avait une typographie un peu différente et a été renommée, donc on ne naviguait déjà plus correctement entre les langues). Là une fusion s'impose entre les deux pages françaises (la deuxième très mal nommée sans critère signifiant) On garde alors la première (dont je viens de corriger la navigabilité des liens de redirection interlangue entre les 4 existantes de:, en:, fr: et uk: ; je n'ai pas regardé s'il pouvait en exister des traductions non liées par la box interlangue)... Mais aucune des deux pages françaises ne correspond à la présentation plus internationale (et plus générique) de la version anglaise (qui montre des vignettes de captures, mais dans une table pas vraiment classée non plus). En fin de compte toutes ces pages ne sont pas des traductions mutuelles (et peut-être n'ont-elles pas à l'être et se centrer sur les sites adaptés à chaque langue. Ayant créé ces deux pages et ayant trouvé que la dissymétrie s'imposait, car la page en angalis était trop fourre-tout, je souligne que j'ai voulu, comme les noms l'indiquent, essayer de distinguer les sites ou parties de site dans lesquels la carte OSM est un ingrédient majeur et ceux dans lesquels elle n'est qu'un simple ornement. Geovélo est dans la première catégorie, une applicationFix my city aussi, une carte papier également, mais, pas un site où la carte ne sert qu'à localiser quelques points sans interactivité est une autre carte de moindre intérêt. Autres cartes est imprécis et on n'a pas trouvé mieux même après en avoir parlé sur cette liste. La fusion rendrait la page beaucoup trop longue. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation d'OSM par des collectivités
Le 13 février 2015 10:21, Christian Rogel christian.ro...@club-internet.fr a écrit : Ayant créé ces deux pages et ayant trouvé que la dissymétrie s'imposait, car la page en angalis était trop fourre-tout, je souligne que j'ai voulu, comme les noms l'indiquent, essayer de distinguer les sites ou parties de site dans lesquels la carte OSM est un ingrédient majeur et ceux dans lesquels elle n'est qu'un simple ornement. Geovélo est dans la première catégorie, une applicationFix my city aussi, une carte papier également, mais, pas un site où la carte ne sert qu'à localiser quelques points sans interactivité est une autre carte de moindre intérêt. Autres cartes est imprécis et on n'a pas trouvé mieux même après en avoir parlé sur cette liste. La fusion rendrait la page beaucoup trop longue. Justement, tu lis juste la première partie (du message fusion) La seconde concerne la séparation thématique (en commençant par les collectivités et administrations publiques (Autre cartes en lignes n'a pas de sens si c'est celle que tu as ajoutée) Et là on peut scinder non pas sur un mot Autres qui n'a pas aucun sens par lui-même et faire des sous-pages thématiques (quitte mˆme à ce que la page principale consiste juste en la transclusion des sous-pages thématiques (dans ce cas pas besoin non plus de remettre l'entête de navigation dans les sous-pages (ou alors juste en section noinclude) et donc pas besoin de naviguer d'une page à l'autre pour voir la liste globale ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] LGV Lyon-Turin (était Article - La Voix du Nord)
Au delà des descenderies qui sont des ouvrages périphériques, il y a également les galeries de reconnaissance. Elles ont été percées au diamètre du futur tunnel sur plusieurs kilomètres. Les Italiens sont les plus avancés, le percement du côté Français devrait intervenir d'ici mars je crois. http://www.openstreetmap.org/#map=17/45.23068/6.44992 http://www.openstreetmap.org/#map=17/45.20205/6.59797 http://www.openstreetmap.org/#map=18/45.21141/6.69478 A+ *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux Le 12 février 2015 20:34, Christian Rogel christian.ro...@club-internet.fr a écrit : Le 12 févr. 2015 à 20:10, THEVENON Julien julien_theve...@yahoo.fr a écrit : Salut, Il me semble que certains tunnels de service ou d acces aux chantiers sont en cours de creusement meme si le projet n est pas defintivement valide donc certains elements doivent avoir une realite sur le terrain Jalk-fr mailing list Les Italiens ont commencé à creuser une descenderie à Chaumont-Chiomonte. Le chantier a été attaqué en 2011 par 200 personnes qui ont blessé 180 policiers. Quelques-uns ont été jugés avec des peines de prison de 4 ans et demi à la clé. Il n'est pas douteux que le tunnel sera creusé, car le traité international a été confirmé. Ce qui peut retarder, c'est que c'est l'Italie qui paye le plus et elle manque d'argent. Christian R. ___ 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] Contours des communes dans le Gard
Pour les EPCI, j'avais utilisé ce qui était dispo sur data.gouv.fr (origine DGCL), mais je ne pense pas que ça soit désormais à jour, c'est pour ça que je n'ai pas republié les EPCI par exemple. Le 13/02/2015 08:51, Tony Emery a écrit : cquest wrote Pour ton cas, j'ai mis à jour le découpage des communes le 1er janvier, par contre je n'ai pas regénéré les autres (qu'on peut faire facilement en regroupant les découpages de communes si on a besoin). C'est vrai pour les communes vers les départements mais ça va être plus compliqué des communes vers les régions ou des communes vers les EPCI. Donc on va essayer de récupérer une table de correspondance quelque part. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Contours-des-communes-dans-le-Gard-tp5832948p5833438.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Ne perd pas ton temps avec Philippe... il voudra toujours avoir le dernier mot, symptôme du troll en puissance... et il ne faut pas tomber dans ce jeu là. Le 13/02/2015 09:37, Tony Emery a écrit : verdy_p wrote Là c'est toi qui 'rigole des genoux en étendant trop librement ma réponse en prenant un autre exemple. Je donnais un exemple correct pour l'exemple que tu donnais (tu ne parlais pas d'Avignon dans la phrase que je cite en réponse. L'autre agglo d'Avignon utilisera son tag à elle. Est-ce que les deux utilisent toujours la même codification commune quand elles sont en collision ? Nous aurons la même structure d’identifiant car nous avons choisis de travailler de la même manière. Donc oui, ils seront identiques. Quant à ton histoire de « collision », je ne vois même pas de quoi tu parles vu que la CCPRO ne travaille pas sur les voies de la COGA et vice-versa. verdy_p wrote Je n'ai pas parlé de code mais de codification, dont font partie les identifiants uniques de toute base de données. Peu import esi je n'ai pas travaillé pour une collectivité j'ai travaillé et travaille encore sur d'autres bases de données qui ont elles aussi leur codification propre. Et là encore il faut gérer des codifications de références externes multiples (et pas synchronisées nécessairement entre elles). Et donc quel est ton problème si on arrive à mettre en place un projet qui permet d’identifier de manière unique les voies dès leurs créations ? Ne penses-tu pas que ça facilitera la réutilisation de la donnée et évitera de recréer des bases indépendantes ? verdy_p wrote Je parlais de la valeur de ton tag, même dans l'explication que te donnes puisque tu dis bien que cela utilise le code INSEE (pas le code CCPRO ou autre agglo) de la commune (laquelle ? ce n'est pas expliqué dans ta doc m^me si ici tu l'as décrit mais plus tard). Cette collectivité ne code pas tout en tout cas ne codifie pas elle-même la/les communes concernées. Pourquoi il existe des codes INSEE différents ? Pour moi, le code INSEE de la commune c’est le code INSEE. Il n’y en a qu’un. Donc on utilise le code INSEE de la commune sur laquelle se trouve la voie et qui a délibéré sur la création de sa voie. C’est simple. verdy_p wrote Je ne l'ai pas fait par hasard, si je suis tombé sur ce chemin c'est parce qu'il était rompu et qu'il ma fallu réparer les relations autour (et oui cela allait beaucoup plus loin que la CCPRO, j'ai fait le tour des différentes relations brisées et pour certaines ait du en retracer des petits morceaux manquants, et refusionner là où deux segments successifs n'étaient pas nécessaires. Cette erreur, que j’ai déjà reconnu mainte fois, n’a rien à voir avec l’intégration de l’identifiant unique. C’est juste une mauvaise manip de ma part quand j’ai voulu recaler les limites des communes. Donc, pour ce point tu es encore une fois, hors sujet. Arrêtes donc de revenir là-dessus car ça ne fait pas avancer les choses. Après pour le reste, si tu veux redessiner les voies, et bien, ma foi, fais-toi plaisir. Cela dit, pour la CCPRO, il ne doit pas rester beaucoup de boulot à faire. Alors juste saches que, si tu travailles dans le coin, nous avons intégré les adresses et créé des relations pour (presque) toutes les voies. Il faut donc faire attention en redécoupant ou en créant des voies. cf http://wiki.openstreetmap.org/wiki/Vaucluse/voirie http://wiki.openstreetmap.org/wiki/Vaucluse/voirie pour voir où on en est. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833441.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-it] [JOSM] Relazione: ruolo forward sconosciuto
Ho editato delle way in una relazione di una ciclovia [1]. Cosiderato l'esistenza di tratti in senso unico, ho impostato il tag forward nelle way percorribili. All'upload, JOSM 6502 mi avverte ruolo forward sconosciuto. Ricordo che ciò capitava anche un annetto fa quando editavo linee di autobus. Che fare? Devo veramente creare due relazioni [2], magari di centinaia di way di cui solo una dozzina sono diverse? [1] http://www.openstreetmap.org/changeset/28815938 [2] http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route - -- cascafico.altervista.org twitter.com/cascafico -- View this message in context: http://gis.19327.n5.nabble.com/JOSM-Relazione-ruolo-forward-sconosciuto-tp5833447.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] Contours des communes dans le Gard
Il faudrait songer, du coup, à des clé en poupée russe, comme on a dans les GEOFLA où la commune porte les identifiant des découpages supérieurs dans lesquelles elle se trouve (départements, epci, région, arrondissement). - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Contours-des-communes-dans-le-Gard-tp5832948p5833448.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contours des communes dans le Gard
Intéressant, ça veut dire qu'entre chaque fichier de la série, tu recommences les requêtes à la base OSM. N'y a-t-il pas moyen de requêter avec un numéro de version ou un timestamp donné, pour cherger une base locale synchrone (quitte à ce qu'ensuite tu y corriges les anomalies temporaires pour combler les trous, puis te servir de cette vue nettoyée pour exporter toutes les limites administratives avec cette vue stabilisée ? Ca veut dire alors une topologie compatible entre tous les types d'entités que tu veux exporter: * niveau admin 2; pays entier, * niveau admin 3: France métropolitaine ou COM, * niveau admin 4: régions métropolitaines (plus nouvelles régions pour 2016 bien que ce soit encore provisoire même pour les frontières jusqu'en juillet pour les départements limitrophes qui peuvent encore aller dans une région voisine, y compris les régions qui pour l'instant ne changent pas, avant le bouclage du projet de fusion) * niveau admin 6: ROM/DOM ou département métropolitain ou circonscription départementale (du Rhone) ou collectivité de Corse * niveau admin 7: arrondissements (y compris métropole de Lyon,) * niveau admin 8; communes * niveau admin 9: arrondissements municipaux de PLM uniquement (la question du niveau pour les communes déléguées (dans les communes-associées ou communes nouvelles) n'est pas encore réglée, on n'en a pas beaucoup dans la base mais elles sont nombreuses et un nombre significatif a aussi ses quartiers, mais je suis convaincu que c'est bien le niveau 9 et non le niveau 10 en conflit, le niveau 9 n'ayant aucun conflit puisqu'il ne peut pas y avoir dans une même commune à la fois des arrondissements municipaux et des communes déléguées, si ton script a besoin d'une distinction pour PLM, on peut facilement ajouter un tag de statut administratif, comme il y a en a un aussi pour les types d'intercommunalité) * niveau 10: quartiers administratifs (codifié dans le cadastre des communes concernées) * niveau 11: sous-quartiers (définis à Paris, mais il existent ailleurs, à Rennes par exemple où j'ai pratiquement fini le jeu de données à fusionner) * découpage coutumier dans certaines COM. Y compris les 3 royaumes coutumiers de Wallis-et-Futuna, ainsi que ses villages, en absence de toute communes, mais ces villages n'ont pas encore de niveau admin bien défini et le découpage coutumier est (comme aussi en Nouvelle-Calédonie) indépendant de découpage administratif de droit civil basé sur les 2 sous-archipels, puis les principales iles habitées, puis les divisions principales des 2 grandes iles (les ilots autour non habités sont rattachés à l'ile habitée la plus proche). Et au delà des découpages administratifs hiérarchiques ci-dessus: * pour l'intercommunalité (type=local_authority): * EPCI à fiscalité propre (CC, CA, CU, SAN, métropoles) * autres EPCI sans fiscalité (pôles métropolitains, syndicats mixtes, aires d'adhésion des parcs naturels) * divisions des EPCI (par ex. pôles de proximité de Nantes Métropole, qui avant utilisaient un niveau en conflit avec celui des quartiers de Nantes) * découpages électoraux (type=political): * cantons (les actuels incomplets dans certaines villes faute de source précise pour le découpage, et prochains presque finis) * cantons-ou-villes (comme l'INSEE: sans découpage infracommunal) * carte des bureaux de vote * circonscriptions législatives (et sénatoriales, pas nécessairement synchrones quand les élections et mandats ne sont pas synchrones) * secteurs régionaux * circonscriptions europénnes * découpage postal géographique (type=postal_area) (si possible, hors des codes postaux spéciaux faiblement ou pas du tout géolocalisés, comme les CEDEX et codes de l'armée) * découpage religieux (type=religious) catholique (signifiant administrativement uniquement dans l'Archevêché de Strasbourg, le seul en France qui soit un établissement public de l'Etat, selon le statut spécial d'Alsace-Moselle depuis le concordat, ailleurs ce n'est pas vraiment pertinent et pas plus que les autres religions) A voir aussi: * découpage statistique (les IRIS et ilots de population de l'INSEE, voire aussi les districts de recensement) * découpage maritime des eaux territoriales (divisées en régions marimes) et des ZEE * découpage économique * découpage urbain * découpage judiciaire (qui n'est plus basé sur les cantons depuis très longtemps et ne suit plus les découpages électoraux mais s'arrête sur les limites administratives) * découpage policier (zones de compétence des gendarmeries et commissariats, préfecture de police de Paris et sa petite couronne) * découpage académique et scolaire (type=educational) (on a les académies, mais pas la carte scolaire infracommunale ou multicommunale: n'est-ce pas auourd'hui de la compétence des intercommunalités et plus des communes ?) * découpage sanitaire et hospitalier public (type=public_health ?) (zones de compétence des CHR et leurs établissements pas toujours dans la même région) * découpage
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Le 13 février 2015 09:37, Tony Emery tony.em...@yahoo.fr a écrit : verdy_p wrote Je parlais de la valeur de ton tag, même dans l'explication que te donnes puisque tu dis bien que cela utilise le code INSEE (pas le code CCPRO ou autre agglo) de la commune (laquelle ? ce n'est pas expliqué dans ta doc m^me si ici tu l'as décrit mais plus tard). Cette collectivité ne code pas tout en tout cas ne codifie pas elle-même la/les communes concernées. Pourquoi il existe des codes INSEE différents ? Pour moi, le code INSEE de la commune c’est le code INSEE. Il n’y en a qu’un. Donc on utilise le code INSEE de la commune sur laquelle se trouve la voie et qui a délibéré sur la création de sa voie. C’est simple. Non car tu ne lis pas le mot important: tu dis la commune, je réponds laquelle quand il peut y en avoir plusieurs. Depuis le début j'insiste sur ce point et c'est la source même de cette discussion. Tu réponds pas de problème dans les collectivités sur lesquelles je travaille sauf que même ces collectivités n'incluent pas toutes les communes de France et donc celles qui sont sur leur périmètre (et c'erst là que ton idée d'étendre ton système à d'autres collectivités ne peut pas marcher tel quel (et déjà on a des voiries partagées par plusieurs communes qui ont des noms et longueurs différentes selon le côté, et c'est pris en compte même dans le FANTOIR où il y a bien des voies avec deux codes FANTOIR... voire peut-être plus, le découpage des voies par commune n'étant pas identique entre elles, certaines n'ayant pas les mêmes sections listées). Je n'ai jamais dit qu'une même commune avait plusieurs codes INSEE (hormis les codes historiques suite à leur propre changement de périmètre). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-de] Wochennotiz Nr. 238 3.2.–9.2.2015
Hallo, die Wochennotiz Nr. 238 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2015/02/wochennotiz-nr-238/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Utilisation d'OSM par des collectivités
Le nombre de collectivités qui utilisent OSM commence à être intéressant. Ça manque un peu de continuité territoriale mais j'espère que le prochain SOTM à Brest va relancer la dynamique de ce côté. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Utilisation-d-OSM-par-des-collectivites-tp586p5833455.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation d'OSM par des collectivités
Le 13 févr. 2015 à 10:43, Philippe Verdy verd...@wanadoo.fr a écrit : (Autre cartes en lignes n'a pas de sens si c'est celle que tu as ajoutée) Et là on peut scinder non pas sur un mot Autres qui n'a pas aucun sens par lui-même et faire des sous-pages thématiques (quitte mˆme à ce que la page principale consiste juste en la transclusion des sous-pages thématiques (dans ce cas pas besoin non plus de remettre l'entête de navigation dans les sous-pages (ou alors juste en section noinclude) et donc pas besoin de naviguer d'une page à l'autre pour voir la liste globale La page Autres a été faite à une époque où très peu d'organismes utilisaient OSM et avait un but de propagande. Pour moi, elle était destinée à disparaître, dès qu'on constaterait que les données OSM sont utilisées de manière réellement interactive. A mon sens, on arrive à ce moment où elle peut être jugée inutile, la première page évoluant vers un sélection dans l'esprit des meilleures cartes. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
verdy_p wrote Non car tu ne lis pas le mot important: tu dis la commune, je réponds laquelle quand il peut y en avoir plusieurs. Depuis le début j'insiste sur ce point et c'est la source même de cette discussion. Si tu considères la dénomination de la voie, je te dis non. Il n'y a qu'une seule commune qui délibère pour dénommer la voie, même si elle est une limite de commune. Après, trouves-moi un contre-exemple concret et je t'apporte une solution concrète. Mais je ne perdrais pas de temps à essayer de répondre à une hypothèse. verdy_p wrote Tu réponds pas de problème dans les collectivités sur lesquelles je travaille sauf que même ces collectivités n'incluent pas toutes les communes de France et donc celles qui sont sur leur périmètre (et c'erst là que ton idée d'étendre ton système à d'autres collectivités ne peut pas marcher tel quel (et déjà on a des voiries partagées par plusieurs communes qui ont des noms et longueurs différentes selon le côté, et c'est pris en compte même dans le FANTOIR où il y a bien des voies avec deux codes FANTOIR... voire peut-être plus, le découpage des voies par commune n'étant pas identique entre elles, certaines n'ayant pas les mêmes sections listées). Et c'est là que tu te trompe parce que tu pars du principe que c'est la DGFiP qui gère les voies. La DGFiP a trouver une astuce pour palier à son problème de gestion des voies en limite de commune. Mais ce problème n'a rien à voir avec les communes qui, elles, savent très bien si la voie fait partie de son territoire ou non. Donc, en écoutant les conseils de Christian, soit on a un débat constructif pour faire avancer le projet, soit c'est même pas la peine de répondre à mon post. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833459.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contours des communes dans le Gard
Ajoute à ça que les EPCI à FP (et même les autres EPCI) ne sont ps restreints à 1 seul département, mais peuvent être interdépartementaux voire même interrégionaux. On ne peut donc pas coder en poupée russe puisqu'on aura des communes avec un code département différent de celui de l'EPCI (qui n'a pas de codification hiérarchique mais juste la codification nationale du SIREN, ignorant le code département, De même les codes SIREN des communes ne peuvent pas être déduits partout du code commune (c'est faux dans certains départements en métropole et en outremer le mode de formation est différent de celui le plus communément utilisé en métropole) Les SIREN n'étant pas des codes géographiques non plus mais des codes d'identité de la personne morale, ils ne sont attribués dans des tranches par département que sur leur siège est restreint à un seul département et ne peut pas en changer. Même les nouveaux cantons ne peuvent plus réutiliser un codage en poupée russe par département-arrondissement-canton puisqu'ils sont à cheval sur les arrondissements Dans le passé déjà, il y a longtemps, le codage en poupée russe des communes par canton a aussi été abandonné (les fractions cantonales de communes sont déjà très vieux et se sont poursuivis avec les fusions de communes tombant à cheval sur plusieurs cantons, et les cantons historiques, judiciaires ne sont plus utilisés par le découpage judiciaire qui prend des communes entières, l'INSEE ayant alors créé les cantons-ou-villes, ainsi que les pseudo-cantons plus restreints que les cantons électoraux, et qui excluent les communes fractionnées codées à part en canton-ou-ville distinct avec un code canton spécial) Le code géographique de l'INSEE (aussi simple qu'il paraisse) pourrait être abandonné pour ne plus utiliser que les codes SIREN des personnes morales : 9 chiffres pour toutes les collectivités (communes, départements, régions, EPCI à FP ou non) et tous les établissements publics de l'Etat (préfectures et sous-préfectures, représentations de la république dans les COM) et n'identifiera plus le type/statut qui devra donc être codé à part. (L'Insee codifie déjà les types de communes). Il ne restera alors que les codes ISO 3166-2 (pas sûr qu'ils soient mis à jour avec les nouvelles régions...) Que serait un code en poupée russe juxtaposant les séries de 9 chiffres et d'autres codes pour des entités (arrondissements, cantons) qui ne sont pas des personnes morales (et n'ont donc pas de SIREN) ? Indigeste en plus que cela ne marche pas ! Il faut des clés séparées et faire un codage relationnel (non hiérarchique), utilisant une table annexe de correspondance des clés pour les cas de relations M:N et pas seulement 1:N (les lignes de la table annexe ne sont pas des entités; 3 tables en tout pour gérer deux types d'entités) c'est un principe universel de modélisation des bases de données (même avec la veille méthode française Merise qui était enseignée il y a encore une vingtaine d'années mais ça doit être fini je pense, ou avec la norme UML actuelle beaucoup plus riche). Le 13 février 2015 10:51, Christian Quest cqu...@openstreetmap.fr a écrit : Le 13/02/2015 10:14, Tony Emery a écrit : Il faudrait songer, du coup, à des clé en poupée russe, comme on a dans les GEOFLA où la commune porte les identifiant des découpages supérieurs dans lesquelles elle se trouve (départements, epci, région, arrondissement). Dans GEOFLA, tu as des attributs pour chaque commune qui t'indique sont appartenance au découpages supérieurs, mais le code INSEE d'une commune ne contient que le code du département en préfixe. Pour les EPCI, ma source c'est ça: http://www.collectivites-locales.gouv.fr/liste-et-composition-des-epci-a-fiscalite-propre Les fichiers indiquent à quel EPCI chaque commune appartient. Je viens de demander les données 2015. -- 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
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Le 13 février 2015 11:19, Tony Emery tony.em...@yahoo.fr a écrit : verdy_p wrote Non car tu ne lis pas le mot important: tu dis la commune, je réponds laquelle quand il peut y en avoir plusieurs. Depuis le début j'insiste sur ce point et c'est la source même de cette discussion. Si tu considères la dénomination de la voie, je te dis non. Il n'y a qu'une seule commune qui délibère pour dénommer la voie, même si elle est une limite de commune. Après, trouves-moi un contre-exemple concret et je t'apporte une solution concrète. Mais je ne perdrais pas de temps à essayer de répondre à une hypothèse. Ce n'est PAS une hypothèse, même en se limitant à des frontières entre deux entités françaises. Tu n'as pas cherché beaucoup. Les exemples sont pourtant facile à retrouver (même s'il n'y en a pas dans ton coin... à ta connaissance). Recherche par exemple dans OSM les ways marqués avec des tags FANTOIR mutiples, distingués avec un prefixe (ou suffixe...) en left et right ou des tags name avec des préfixes ou suffixes left et right. Ensuite révise ta position. Ca ne change rien au fait que les communes peuvent nommer les voies comme elles le veulent sans être obligé de se mettre d'accord avec la voisine sur la dénomination, et même si elles se mettent d'accord pour partager la gestion elles peuvent continuer à avoir des dénominations distinctes. (tels que les frais d'entretien, le jour où une d'elle a besoin de faire des travaux et demander une participation de l'autre, qui peut le refuser pour remettre ça à plus tard, ou peut n'accepter qu'en échange de la prise en charge par l'autre commune de la gestion d'autres secteurs, ou peut ne trouver aucune arrangement et obtenir des participations des intercommunalités, départements, régions ou de l'Etat voire de l'Europe, ou de la part d'autres agences publiques ou même des riverains ou de gros usagers commerciaux et industriels ou sociétés publiques ou mixtes ou de groupements européens type GIE, ou de la part d'assos et fondations volontaires). verdy_p wrote Tu réponds pas de problème dans les collectivités sur lesquelles je travaille sauf que même ces collectivités n'incluent pas toutes les communes de France et donc celles qui sont sur leur périmètre (et c'est là que ton idée d'étendre ton système à d'autres collectivités ne peut pas marcher tel quel (et déjà on a des voiries partagées par plusieurs communes qui ont des noms et longueurs différentes selon le côté, et c'est pris en compte même dans le FANTOIR où il y a bien des voies avec deux codes FANTOIR... voire peut-être plus, le découpage des voies par commune n'étant pas identique entre elles, certaines n'ayant pas les mêmes sections listées). Et c'est là que tu te trompe parce que tu pars du principe que c'est la DGFiP qui gère les voies. JAMAIS DE LA VIE je n'ai utilisé ce principe. je ne l'ai dit nulle part. Tu veux juste le faire croire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-hr] Walking papers?
Walking papers se odavno prestao razvijati. Filed papers je nastavak http://fieldpapers.org/ On 02/13/2015 11:40 AM, valent.turko...@gmail.com wrote: Pozdrav, koliko mi se čini kao da je servis Walking papers prestaio raditi prije dva mjeseca. Niti moj novi print ne prolazi niti vidim noviji print od 63 dana unatrag. Zna li netko nešto više? Ima li kakva alternativa? v. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 has only 35 rows. 2015-02-13 8:22 GMT+01:00 Imre Samu pella.s...@gmail.com: There's one more face to iD and mistakes users make: translations. Bad translations cause bad tagging. Example: track was translated to Polish . Good translation is very important for the beginners. and _now_ not so easy to check the quality of the iD translations. I would like to inform you, that I am working on a new *iD Editor translation QA tool * for helping translators detecting translator bugs ... I have created an experimental, manually formatted QA metadata reports for Polish language :) https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 Maybe you can use. ( 4 Sheets : - meta_pl : meta data ... - iDups,- duplicated/same translations - iPresets,- presets ( 2028 ) [ translations from transifex + presets.json https://github.com/openstreetmap/iD/blob/master/data/presets/presets.json ] - iFields -fields (261 ) [translations from transifex + fields.json https://github.com/openstreetmap/iD/blob/master/data/presets/fields.json ] ) Freshly generated raw reports exists for every other iD languages ( de,pl,es,ru, cz,pt, ... ) ( but not formated ) see : https://github.com/ImreSamu/ideditor_translation_test_reports find your xlsx - ./qadata/ (LangCode)/id_presets_translation_(LangCode).xlsx for example: ./qadata/af/id_presets_translation_af.xlsx ./qadata/ar/id_presets_translation_ar.xlsx ./qadata/ar-AA/id_presets_translation_ar-AA.xlsx ./qadata/ast/id_presets_translation_ast.xlsx ./qadata/bg-BG/id_presets_translation_bg-BG.xlsx ./qadata/bn/id_presets_translation_bn.xlsx ./qadata/bs/id_presets_translation_bs.xlsx ./qadata/ca/id_presets_translation_ca.xlsx ./qadata/cs/id_presets_translation_cs.xlsx ./qadata/da/id_presets_translation_da.xlsx ./qadata/de/id_presets_translation_de.xlsx ... My favorite problems type is the same/duplicated translations ( https://github.com/openstreetmap/iD/issues/2448 ) Now the status by languages -here : id_langDups_all.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/id_langDups_all.md For example German language. But be careful, Experimental report! Not every line is problematic - please check the other columns like - geometry metadata ( area,point,line,vertex,relation ) - searchable ( id_presets_translation_duplicates_de.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/de/id_presets_translation_duplicates_de.md ) nameTransl nameEn presetKey Administrative Grenze Administrative Boundary type/boundary/administrative Administrative Grenze Administrative Boundary boundary/administrative Bahnsteig Platform public_transport/platform Bahnsteig Railway Platform railway/platform Boutique Boutique shop/boutique Boutique Fabric Store shop/fabric Campingplatz Camp Site tourism/camp_site Campingplatz RV Park tourism/caravan_site Drogerie Chemist shop/chemist Drogerie Cosmetics Store shop/cosmetics Eisenbahn Rail railway/rail Eisenbahn Railway railway Fährenroute Ferry Route route/ferry Fährenroute Ferry Route type/route/ferry Friedhof Graveyard amenity/grave_yard Friedhof Cemetery landuse/cemetery Garagen Garages building/garages Garagen Garages landuse/garages Gemischtwarenhandel Convenience Store shop/convenience Gemischtwarenhandel Variety Store shop/variety_store Graben Ditch barrier/ditch Graben Ditch waterway/ditch Hütte Hut building/hut Hütte Cabin building/cabin Kehrtwendeverbot No Turns type/restriction/only_straight_on Kehrtwendeverbot No U-turn type/restriction/no_u_turn Kirche Church amenity/place_of_worship/christian Kirche Church building/church Radweg Cycle Path highway/cycleway Radweg Cycle Route type/route/bicycle Seilbahn Cable Car aerialway/cable_car Seilbahn Aerialway aerialway Uhrmacher Clockmaker craft/clockmaker Uhrmacher Watchmaker craft/watchmaker Wald Wood natural/wood Wald Forest landuse/forest Zebrastreifen Crosswalk footway/crosswalk Zebrastreifen Crosswalk highway/crosswalk And the Translation status by languages : id_langData_all.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/id_langData_all.md Imre ( from the Hungarian OSM community ) 2015-02-13 3:43 GMT+01:00 Michał Brzozowski www.ha...@gmail.com: Whoops. Good to know. Though it's still rudimentary ;) Not long ago I tried to do intentionally do stupid things in iD demo in order to see if it would stop me - it didn't. There's one more face to iD and mistakes
Re: [Talk-hr] Walking papers?
Hvala. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
has only 35 rows. 17 word pair + 1 header record There are other worksheets , you can switch/change at the bottom of the page: Direct links: *meta_pl : meta data ...* https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=2147407685 *iDups,- duplicated/same translations ( 34 rows )* https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 *iPresets,- presets ( 2028 rows )* https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1125791958 *iFields -fields (261 rows ) * https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=661789118 Imre 2015-02-13 11:54 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com: https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 has only 35 rows. 2015-02-13 8:22 GMT+01:00 Imre Samu pella.s...@gmail.com: There's one more face to iD and mistakes users make: translations. Bad translations cause bad tagging. Example: track was translated to Polish . Good translation is very important for the beginners. and _now_ not so easy to check the quality of the iD translations. I would like to inform you, that I am working on a new *iD Editor translation QA tool * for helping translators detecting translator bugs ... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-GB] Scenic or not?
Hi all, I just saw an announcement that mySociety will be mothballing some of their old projects. One of them is Scenic or not? - it's a project to gather a freely available nation-wide dataset of scenicness for the UK. http://scenic.mysociety.org/ So, well I never heard about it until now, but now it's shutting down, or at least going into read-only mode. Why do I mention it? * It provides open crowdsourced data about scenicness (ODBL licence) - hundreds of thousands of votes cast. Surely one of you might do something interesting with it? * Would you like to run ScenicOrNot yourself? asks the website. Maybe you would...? Dan ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-be] Brussels by bicycle
On 2015-02-13 08:58, Jo wrote: http://www.nieuwsblad.be/cnt/dmf20150212_01525728 [1] both hilarious and incredibly sad at the same time. It's not that they're not trying. Bicycle infrastructure has improved a lot over the past 10 years, but not quite there yet. I'm confident this will become another 'belgenmop' in The Netherlands... I think the belgenmop will be that all belgian cyclists are blind. Seriously, after seeing him fall 3 times I got the message: don't be blind and ride a bicycle. Look where you're going. Bicycleinfrastructure seems bad there (and is, even in Limburg which purports to be _the_ cyclearea of Belgium) but I see no difference with Germany. And I've never bumped into anything there. In some ways it is even better then in the Netherlands. The major obstacles over here are the other cyclists and they are a lot more unpredictable than stationary objects. Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
verdy_p wrote Là c'est toi qui 'rigole des genoux en étendant trop librement ma réponse en prenant un autre exemple. Je donnais un exemple correct pour l'exemple que tu donnais (tu ne parlais pas d'Avignon dans la phrase que je cite en réponse. L'autre agglo d'Avignon utilisera son tag à elle. Est-ce que les deux utilisent toujours la même codification commune quand elles sont en collision ? Nous aurons la même structure d’identifiant car nous avons choisis de travailler de la même manière. Donc oui, ils seront identiques. Quant à ton histoire de « collision », je ne vois même pas de quoi tu parles vu que la CCPRO ne travaille pas sur les voies de la COGA et vice-versa. verdy_p wrote Je n'ai pas parlé de code mais de codification, dont font partie les identifiants uniques de toute base de données. Peu import esi je n'ai pas travaillé pour une collectivité j'ai travaillé et travaille encore sur d'autres bases de données qui ont elles aussi leur codification propre. Et là encore il faut gérer des codifications de références externes multiples (et pas synchronisées nécessairement entre elles). Et donc quel est ton problème si on arrive à mettre en place un projet qui permet d’identifier de manière unique les voies dès leurs créations ? Ne penses-tu pas que ça facilitera la réutilisation de la donnée et évitera de recréer des bases indépendantes ? verdy_p wrote Je parlais de la valeur de ton tag, même dans l'explication que te donnes puisque tu dis bien que cela utilise le code INSEE (pas le code CCPRO ou autre agglo) de la commune (laquelle ? ce n'est pas expliqué dans ta doc m^me si ici tu l'as décrit mais plus tard). Cette collectivité ne code pas tout en tout cas ne codifie pas elle-même la/les communes concernées. Pourquoi il existe des codes INSEE différents ? Pour moi, le code INSEE de la commune c’est le code INSEE. Il n’y en a qu’un. Donc on utilise le code INSEE de la commune sur laquelle se trouve la voie et qui a délibéré sur la création de sa voie. C’est simple. verdy_p wrote Je ne l'ai pas fait par hasard, si je suis tombé sur ce chemin c'est parce qu'il était rompu et qu'il ma fallu réparer les relations autour (et oui cela allait beaucoup plus loin que la CCPRO, j'ai fait le tour des différentes relations brisées et pour certaines ait du en retracer des petits morceaux manquants, et refusionner là où deux segments successifs n'étaient pas nécessaires. Cette erreur, que j’ai déjà reconnu mainte fois, n’a rien à voir avec l’intégration de l’identifiant unique. C’est juste une mauvaise manip de ma part quand j’ai voulu recaler les limites des communes. Donc, pour ce point tu es encore une fois, hors sujet. Arrêtes donc de revenir là-dessus car ça ne fait pas avancer les choses. Après pour le reste, si tu veux redessiner les voies, et bien, ma foi, fais-toi plaisir. Cela dit, pour la CCPRO, il ne doit pas rester beaucoup de boulot à faire. Alors juste saches que, si tu travailles dans le coin, nous avons intégré les adresses et créé des relations pour (presque) toutes les voies. Il faut donc faire attention en redécoupant ou en créant des voies. cf http://wiki.openstreetmap.org/wiki/Vaucluse/voirie http://wiki.openstreetmap.org/wiki/Vaucluse/voirie pour voir où on en est. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833441.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-ph] Fwd: Invitation to the Workshop on Governance Model for National Exposure Information System
Hello all, Project NOAH would like to help you with this. Can you tell about more about this invitation? Thanks, Feye On Thu, Feb 12, 2015 at 5:08 AM, Eugene Alvin Villar sea...@gmail.com wrote: I'd love to come and talk about OSM, but unfortunately I will be out of the country on those dates. On Wed, Feb 11, 2015 at 8:21 PM, maning sambale emmanuel.samb...@gmail.com wrote: Dear everyone, We received this invitation to do a 20 minute presentation on OpenStreetMap to the Office of Civil Defense' Exposure Information System Workshop. Details below. Anyone willing to present? My schedule these days are very fluid hence, I cannot immediately commit. -- Forwarded message -- Date: Wed, 11 Feb 2015 10:52:00 +0800 Subject: Invitation to the Workshop on Governance Model for National Exposure Information System To: emmanuel.samb...@gmail.com Dear Mr. Sambale, Please find enclosed an invitation letter signed by USEC Pama for the Workshop on Governance Model for National Exposure Information System to be held on February 23-25, 2015 at Summit Ridge Hotel, Tagaytay City. We would appreciate acknowledgement of receipt of this email and look forward to your affirmative response to this invitation. Thanks, Kiko -- Morito Gonzales Francisco Project Coordinator RAP (Phase II) Bridging Project DFAT- Australian Aid Program-OCD, Project Management Office, 3/F OCD Bldg., Camp Gen. Emilio Aguinaldo, Q.C. Philippines Telefax: +63 2 9120138 Celfone: +63 908 8162854 -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] Brussels by bicycle
Le 2015-02-13 8:58, Jo a écrit : http://www.nieuwsblad.be/cnt/dmf20150212_01525728 [1] both hilarious and incredibly sad at the same time. It's not that they're not trying. Bicycle infrastructure has improved a lot over the past 10 years, but not quite there yet. indeed. As a daily cyclist, I encounter many such situations. I am willing to organize soon a cycling map day in Brussels to improve the Brussels cycling map and spot such locations that need attention. Who would be willing to participate ? have a good day, Nicolas Links: -- [1] http://www.nieuwsblad.be/cnt/dmf20150212_01525728 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Oi Flávio 2015-02-13 0:03 GMT-02:00 Flavio Bello Fialho bello.fla...@gmail.com: Não sei como é em Minas. No RS, a BR-287 tem trechos em que é federal (BR-287) e trechos em que é estadual (RSC-287), mas nunca ambos. Na relação, fica o tag ref=BR-287, mas no trecho, o tag é ref=RSC-287 ou ref=BR-287 (mas não os dois). pois então, *são ambos sim*, é aí que você está se confundindo, portanto deve ser algo como ref=RSC-287;BR-287 o código BR não implica em administração federal, apenas indica que a rodovia pertence a uma malha com lógica nacional. O C aqui é de coincidente. RSC significa que está sob administração estadual mas que pertence à malha federal das BRs. O certo então é possuir ambos os códigos para facilitar a orientação do usuário. Vou repetir aqui o que o Claiton levantou da legislação *2.5 - RODOVIA ESTADUAL OU MUNICIPAL COINCIDENTESão rodovias construídas pelos Estados ou Municípios sobre a diretriz de uma Rodovia Federal Planejada.As diretrizes das Rodovias Federais planejadas muitas vezes coincidem com trechos de Rodovias Estaduais ou Municipais, entretanto o traçado definitivo da Rodovia Federal somente será estabelecido após estudos técnicos e econômicos que serão realizados por ocasião de sua construção.Assim tais trechos de rodovias Estaduais ou Municipais superpostas, apesar de listados e codificados como BR’s, não se encontram sob jurisdição federal e constituem as denominadas rodovias coincidentes (ex.: Rodovias Estaduais Transitórias).* abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] Contours des communes dans le Gard
C'est pas à jour ya eu deux corridors qui ont été créés pour la métropole de Lyon l'un a été mis dans OSM pour l'autre il va falloir attendre on a pas d'infos Florian Le Vendredi 13 février 2015 10h01, Christian Quest cqu...@openstreetmap.fr a écrit : Pour les EPCI, j'avais utilisé ce qui était dispo sur data.gouv.fr (origine DGCL), mais je ne pense pas que ça soit désormais à jour, c'est pour ça que je n'ai pas republié les EPCI par exemple. Le 13/02/2015 08:51, Tony Emery a écrit : cquest wrote Pour ton cas, j'ai mis à jour le découpage des communes le 1er janvier, par contre je n'ai pas regénéré les autres (qu'on peut faire facilement en regroupant les découpages de communes si on a besoin). C'est vrai pour les communes vers les départements mais ça va être plus compliqué des communes vers les régions ou des communes vers les EPCI. Donc on va essayer de récupérer une table de correspondance quelque part. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Contours-des-communes-dans-le-Gard-tp5832948p5833438.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- 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
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
2015-02-12 23:01 GMT+01:00 Tony Emery tony.em...@yahoo.fr: Tu rigoles des genoux ? Tiens, comme je ne connaissais pas cette expression, j'ai essayé divers postures mais n'y suis pas arrivé. Quelqu'un a un mode d'emploi ? Sinon, Tony, laisse tomber les remarques de Philippe. Je préfère de loin, comme d'autres intervenants, le tag ref:FR:commune qui aura la même clé pour toutes les communes. Par contre, je reste sur ma position de ne l'utiliser qu'en l'absence de code FANTOIR pour éviter d'alourdire inutilement les objets dans OSM. Il faut aussi penser aux autres contributeurs. Pour ton travail local, il reste facile de retrouver le code unique local si le code FANTOIR est connu, à la condition que les codes correspondent géographiquement à 100%. Est-ce bien le cas ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article - La Voix du Nord
On Fri, Feb 13, 2015 at 2:17 PM, J.-Lys jacq...@famille-lys.com wrote: Bonjour, Pour info et pour répondre au challenge du journaliste de la VDN, j'ai ajouté le parking silo en question, ainsi que l'hyper Leclerc qui justifie l'existence de ce parking à Aulnoye-Aymeries. https://www.openstreetmap.org/#map=18/50.19913/3.84259 Génial. Merci pour ce travail d'actualisation. J'avais vu que le cadastre était à jour mais pas l'imagerie Bing. L'article de presse mentionnait une voie piétonne qui traverse le parking pour joindre deux rues. Ca serait bien que ça soit ajouté aussi dans OSM (par quelqu'un qui connait son tracé). Surtout que maintenant, cette zone est surveillée de près par un journaliste ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] guide to vandalism” in OSM?
After having looked at a few @osmthis notes, my conclusion is that it rarely helps: the location of the note is not precise enough, and the photo cannot help with finding the poi location. Should use photo + manual location. Still wondering about this « presume good faith » thing. If every note should be resurveyed on the ground, why not just replace the creator text with « please come survey here » ? And then, just randomly create them around everywhere, just to encourage mappers get out ? Sure, you got someone give an example of two bad faith notes in France, out of 21000 created, 19000 closed ? Are the statistics really worse than that of vandalism ? JB. Le 12.02.2015 19:38, Pierre Béland a écrit : We have to think of OSM as a global community where not all countires are equal with access to internet and computers. Often, people have smartphones and could contribute. Adding a note with photo would greatly help. The @osmthis Twitter tag let's do this. But it is uneasy then to communicate with these persons.adding @osmthis. The same functionality in OSM would be fantastic. But with anonymous notes, we cannot contact these people and obtain clarification. Then the risk that notes stay open for a long period since incompleted. Pierre - DE : Maarten Deen md...@xs4all.nl À : talk@openstreetmap.org ENVOYÉ LE : Jeudi 12 février 2015 12h43 OBJET : Re: [OSM-talk] guide to vandalism in OSM? On 2015-02-12 18:23, Pieren wrote: On Thu, Feb 12, 2015 at 4:29 PM, Michał Brzozowski www.ha...@gmail.com wrote: @Pieren: You switch topics so easily that I'm not sure what are you talking about precisely. Is your stance Someone showed that it is easy to add fake notes, therefore we must assume that every single POI added from notes is fake unless we prove it 100%? I'm just saying that a note is not good enough as a single source for contribution. Especially when it is easy to verify like in the two reported examples (a bank and a bakery). And in case of doubt, you just leave the note open for others instead of compulsive close notes contributions. I agree. Especially new notes, just wait a while until someone who maybe has local knowledge picks it up. Another thought: give the possibility to add photo's to notes. That way you have more confirmation that there is something. You still don't know if it is there unless there are GPS coordinates in the picture, but it's something. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [1] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Percorsi sovrapposti
Il 13/02/2015 00:19, Federico Cortese ha scritto: Purtroppo però con l'ultimo edit ha toccato 227 way e 2438 nodi, la vedo molto difficile una correzione manuale, quindi credo che l'unica soluzione sia un revert. Bisognerebbe contattarlo e spiegargli che per creare una relazione basta usare le geometrie già presenti! Grazie per la risposta. Lo ho contatttato poco fa, ora attendo una sua risposta. Preferirei evitare il revert perchè ha aggiunto alcuni dati rigruardanti la larghezza e la pavimentazione, però la vedo una cosa lunga da risolvere a mano. Vi farò sapere -- Ciao Michele iw1gfv attachment: iw1gfv.vcf___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[OSM-talk-fr] JOSM 7995 - pb chargement opendata et fr.toulouse
Bonjour Aprés l'installation de la dernière version (Windows 7 - JOSM 7995) j'ai deux messages d'erreur de chargement : Chargement du module fr.toulouse. A supprimer de vos préférences et Impossible de Charger le greffon opendata. Voulez-vous le supprimer des préférences ? J'ai mis à jour java (1.8.0_3), mais les messages sont identiques. Faut-il les supprimer et les remettre où y a-t-il un problème sur le greffon et le module ? cordialement Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-de] Pistenkarte für Garmin?
Moin, gibt es einen speziellen Garmin Kartenstil für Skipisten oder alternativ einen Stil, der auch gutes Rendering für Skipisten hat. Gefunden habe ich einen von Gramin selbst. Taugt der auch für meinen alten Gpsmap? Gruss Sven -- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. (Anselm Lingnau in de.comp.os.unix.discussion) /me ist giggls@ircnet, http://sven.gegg.us/ im WWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Utilisation d'OSM par des collectivités
Bonjour, En effet la distinction n'est pas évidente (je ne l'avais pas comprise ;-) et, de fait, certains sites se retrouvent sur les deux pages tel Géovélo, que pensez-vous de préciser les titres : FR:Autres cartes en ligne FR:Services cartographiques en ligne basés sur OSM FR:Sites en ligne utilisant OSM FR:Sites web intégrant, parmi d'autres sujets, de l'information OSM et alors mieux rédiger les phrases de renvoi de l'une vers l'autre. Il restera nécessairement une zone grise mais si des sites sont cités sur les deux pages, ce n'est pas bien grave ! Brice Le 13/02/2015 10:21, Christian Rogel a écrit : Le 13 févr. 2015 à 04:46, Philippe Verdy verd...@wanadoo.fr a écrit : Ayant créé ces deux pages et ayant trouvé que la dissymétrie s'imposait, car la page en angalis était trop fourre-tout, je souligne que j'ai voulu, comme les noms l'indiquent, essayer de distinguer les sites ou parties de site dans lesquels la carte OSM est un ingrédient majeur et ceux dans lesquels elle n'est qu'un simple ornement. Geovélo est dans la première catégorie, une applicationFix my city aussi, une carte papier également, mais, pas un site où la carte ne sert qu'à localiser quelques points sans interactivité est une autre carte de moindre intérêt. Autres cartes est imprécis et on n'a pas trouvé mieux même après en avoir parlé sur cette liste. La fusion rendrait la page beaucoup trop longue. Christian R. ___ 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-ph] Community Mapping for DRR publication
Sharing with you a recent publication by GFDRR WB on mapping tools for DRR. Much of the content was based on our experience working with 3 LGUs in Pampanga. Big thanks to all the mappers and the 3 LGUs. https://www.gfdrr.org/sites/gfdrr/files/publication/Community-Mapping-for-Disaster-Risk-Reduction-and-Management.pdf Maning Sambale (mobile) ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Eu falo sempre com base em exemplos no RS, que é a realidade que mais conheço. A rodovia RSC-287 não é uma rodovia federal administrada pelo estado do RS. É uma rodovia construída e administrada pelo estado do RS e que foi construída sobre a diretriz de uma rodovia federal planejada (que, quando implementada, segundo o DNIT, pode ter o traçado definitivo diferente do traçado da rodovia estadual). Tendo clara essa diferença, não considero desnecessária uma relação para a RSC-287 (assim como para as outras RSC-XXX). Pelo contrário, acho que deveríamos ter uma relação para a RSC-287 e outra para a BR-287. E nos trechos onde elas são coincidentes colocaríamos a tag ref=RSC-287;BR-287. Além disso, acho que existe outro problema. Hoje a Rodovia RSC-287 está nomeada com o nome da rodovia BR-287 (name=Rodovia da Integração), apesar de, legalmente, a RSC-287 não ter denominação. Daí, acho que os trechos coincidentes não deveriam ter a tag name=Rodovia da Integração. Fazer essas diferenças, e expressa-las nos dados do OSM, podem não parecer é importante. Mas são, especialmente. no município de Santa Maria onde as rodovias RSC-287 e BR-287 (implementada) se encontram. *** Placas e marcos ao longo da rodovia indicam RSC-287 ou, a denominação antiga RST-287. Mas, como existe essa confusão entre RSC e BR não é possível garantir que ao longo do trajeto da RSC-287 não existam placas indicando-a como BR-287. Enfim, minha proposta é: - As rodovias RSC-XXX que foram construídas sobre diretrizes de rodovias federais planejadas terem as suas próprias relações; - RSC-XXX deve constar na primeira posição, seguido de BR-XXX, na tag ref dos trechos coincidentes; - A denominação da BR-XXX, caso possua, não deve constar nos trechos coincidentes nem na relação da RSC-XXX. Atenciosamente, Claiton Neisse 55 8147 1030 Em 13 de fevereiro de 2015 11:33, Gerald Weber gwebe...@gmail.com escreveu: Oi Flávio 2015-02-13 0:03 GMT-02:00 Flavio Bello Fialho bello.fla...@gmail.com: Não sei como é em Minas. No RS, a BR-287 tem trechos em que é federal (BR-287) e trechos em que é estadual (RSC-287), mas nunca ambos. Na relação, fica o tag ref=BR-287, mas no trecho, o tag é ref=RSC-287 ou ref=BR-287 (mas não os dois). pois então, *são ambos sim*, é aí que você está se confundindo, portanto deve ser algo como ref=RSC-287;BR-287 o código BR não implica em administração federal, apenas indica que a rodovia pertence a uma malha com lógica nacional. O C aqui é de coincidente. RSC significa que está sob administração estadual mas que pertence à malha federal das BRs. O certo então é possuir ambos os códigos para facilitar a orientação do usuário. Vou repetir aqui o que o Claiton levantou da legislação *2.5 - RODOVIA ESTADUAL OU MUNICIPAL COINCIDENTESão rodovias construídas pelos Estados ou Municípios sobre a diretriz de uma Rodovia Federal Planejada.As diretrizes das Rodovias Federais planejadas muitas vezes coincidem com trechos de Rodovias Estaduais ou Municipais, entretanto o traçado definitivo da Rodovia Federal somente será estabelecido após estudos técnicos e econômicos que serão realizados por ocasião de sua construção.Assim tais trechos de rodovias Estaduais ou Municipais superpostas, apesar de listados e codificados como BR’s, não se encontram sob jurisdição federal e constituem as denominadas rodovias coincidentes (ex.: Rodovias Estaduais Transitórias).* abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Staatliches Gesundheitsamt
Am 8. Februar 2015 um 20:02 schrieb Falk Zscheile falk.zsche...@gmail.com: -1, office trifft es m.E. nicht, dort finden (amts)ärztliche Untersuchungen statt, etc., das hat nicht (nur) mit Büro zu tun Behörden sind zunächst einmal aktenmäßiger Umgang mit Lebenssachverhalten. Ärztliche Untersuchungen sind nichts anderes als Tatsachenermitlungen für die Akte. An die festgestellten Tatsachen, wie sie in der Akte liegen, knüpft sich dann eine bestimmte Rechtsfolge, z.B. Erteilung eines Gesundheitszeugnisses etc. Also nichts, was einer Einordnung als Office entgegen stünde. passen Impfungen auch noch in diese Sicht? Oder zahnärztliche Behandlungen? Es geht nicht nur um Untersuchungen (wobei es auch schon seltsam ist m.E., eine ärztliche Untersuchung als eine Bürotätigkeit zu klassifizieren), sondern durchaus auch um Behandlungen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Utilisation d'OSM par des collectivités
Je pense que la distinction devrait se faire entre: - simple utilisation d'OSM en fond de carte - utilisation de données OSM - contribution directe sur les données (amélioration du contenu OSM) Le 13/02/2015 13:53, Brice MALLET a écrit : Bonjour, En effet la distinction n'est pas évidente (je ne l'avais pas comprise ;-) et, de fait, certains sites se retrouvent sur les deux pages tel Géovélo, que pensez-vous de préciser les titres : FR:Autres cartes en ligne FR:Services cartographiques en ligne basés sur OSM FR:Sites en ligne utilisant OSM FR:Sites web intégrant, parmi d'autres sujets, de l'information OSM et alors mieux rédiger les phrases de renvoi de l'une vers l'autre. Il restera nécessairement une zone grise mais si des sites sont cités sur les deux pages, ce n'est pas bien grave ! Brice Le 13/02/2015 10:21, Christian Rogel a écrit : Le 13 févr. 2015 à 04:46, Philippe Verdy verd...@wanadoo.fr a écrit : Ayant créé ces deux pages et ayant trouvé que la dissymétrie s'imposait, car la page en angalis était trop fourre-tout, je souligne que j'ai voulu, comme les noms l'indiquent, essayer de distinguer les sites ou parties de site dans lesquels la carte OSM est un ingrédient majeur et ceux dans lesquels elle n'est qu'un simple ornement. Geovélo est dans la première catégorie, une applicationFix my city aussi, une carte papier également, mais, pas un site où la carte ne sert qu'à localiser quelques points sans interactivité est une autre carte de moindre intérêt. Autres cartes est imprécis et on n'a pas trouvé mieux même après en avoir parlé sur cette liste. La fusion rendrait la page beaucoup trop longue. Christian R. ___ 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
Re: [OSM-talk-fr] Article - La Voix du Nord
Bonjour, Pour info et pour répondre au challenge du journaliste de la VDN, j'ai ajouté le parking silo en question, ainsi que l'hyper Leclerc qui justifie l'existence de ce parking à Aulnoye-Aymeries. https://www.openstreetmap.org/#map=18/50.19913/3.84259 Cordialement. J.-Lys -- View this message in context: http://gis.19327.n5.nabble.com/Article-La-Voix-du-Nord-tp5833257p5833480.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Pieren wrote Tu rigoles des genoux ? Tiens, comme je ne connaissais pas cette expression, j'ai essayé divers postures mais n'y suis pas arrivé. Quelqu'un a un mode d'emploi ? Ah c'est TRES difficile et à mon âge (enfin selon ma souplesse), je n'y arrive plus. Pieren wrote Sinon, Tony, laisse tomber les remarques de Philippe. J'essayes vraiment mais laisser écrire des bêtises pareil, c'est trop dur... Pieren wrote Je préfère de loin, comme d'autres intervenants, le tag ref:FR:commune qui aura la même clé pour toutes les communes. Par contre, je reste sur ma position de ne l'utiliser qu'en l'absence de code FANTOIR pour éviter d'alourdire inutilement les objets dans OSM. Il faut aussi penser aux autres contributeurs. Pour ton travail local, il reste facile de retrouver le code unique local si le code FANTOIR est connu, à la condition que les codes correspondent géographiquement à 100%. Est-ce bien le cas ? Le code Fantoir contient le code INSEE de la commune, tout comme le ref:FR:commune. On a une table que l'on met à jour chaque année avec les données de la DGFiP pour récupérer les nouveaux codes Rivoli. Je vais mettre en lien le document de la ville d'Avignon sur le travail de la base de données voirie et dans lequel on a les infos sur cette référence (histoire de montrer que ça n'est pas que ma lubie). Seulement ce doc est un peu vieux et le code a évolué (notamment avec le V). - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833486.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article - La Voix du Nord
Si personne d'autre ne le fait avant, j'ai prévu de compléter les voies de service sur la gare. Denis -Message d'origine- De : Pieren [mailto:pier...@gmail.com] Envoyé : vendredi 13 février 2015 14:26 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Article - La Voix du Nord On Fri, Feb 13, 2015 at 2:17 PM, J.-Lys jacq...@famille-lys.com wrote: Bonjour, Pour info et pour répondre au challenge du journaliste de la VDN, j'ai ajouté le parking silo en question, ainsi que l'hyper Leclerc qui justifie l'existence de ce parking à Aulnoye-Aymeries. https://www.openstreetmap.org/#map=18/50.19913/3.84259 Génial. Merci pour ce travail d'actualisation. J'avais vu que le cadastre était à jour mais pas l'imagerie Bing. L'article de presse mentionnait une voie piétonne qui traverse le parking pour joindre deux rues. Ca serait bien que ça soit ajouté aussi dans OSM (par quelqu'un qui connait son tracé). Surtout que maintenant, cette zone est surveillée de près par un journaliste ;-) Pieren ___ 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] Article - La Voix du Nord
Merci Jacques Pour ma part, je suis en train de travailler sur le C.E.F. de Valenciennes (http://www.c-e-f.fr/) qui existe bel et bien lui déjà. J'ai discuté de cette affaire avec Yann Peterschmitt, cité dans l'article. On peut laisser le tracer du projet tel quel à partir du moment où l'information a été rendue publique dans le dossier de concertation. Si le tracé est opportun dans OSM est une question. Jacques, tu pourrais peut-être rajouter en note qu'il s'agit du tracé prévisionnel dit beta1 et mettre que la source provient du dossier de concertation du projet. Pour ceux que cela intéresse, je recommande la lecture du compte-rendu de la concertation (http://www.projet-ceef.fr/download/file/fid/426) pour comprendre la nature des réticences à c projet Christian, une petite com sur les moyens pour joindre efficacement OSM-Fr à destination du journaliste ? Denis -Message d'origine- De : J.-Lys [mailto:jacq...@famille-lys.com] Envoyé : vendredi 13 février 2015 14:17 À : talk-fr@openstreetmap.org Objet : Re: [OSM-talk-fr] Article - La Voix du Nord Bonjour, Pour info et pour répondre au challenge du journaliste de la VDN, j'ai ajouté le parking silo en question, ainsi que l'hyper Leclerc qui justifie l'existence de ce parking à Aulnoye-Aymeries. https://www.openstreetmap.org/#map=18/50.19913/3.84259 Cordialement. J.-Lys -- View this message in context: http://gis.19327.n5.nabble.com/Article-La-Voix-du-Nord-tp5833257p5833480.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Sicilia 01: un layer per il ricalco
fatto ma non riesco ad utilizzarle...a parte la risoluzione troppo bassa (speravo in qualcosa minimo tipo 1px= 5x5 m) le immagini sono TIFF sovrapponibili in scala di grigi che non so come gestire... gdal2tiles, che a questo punto comunque non mi serve, è oltre le mie capacità di utilizzo degli strumenti...come non detto quindi :-( aspetterò il rilascio delle ortofoto - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Sicilia-01-un-layer-per-il-ricalco-tp5828143p5833489.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-it] Mappatura: i negozi di paese
2015-02-12 13:51 GMT+01:00 Max1234Ita max1234...@gmail.com: Ciao a tutti, Il quesito che vorrei proporre oggi è: come mappare quei negozietti, spesso a gestione familiare, che si trovano nei piccoli centri rurali (almeno in Italia) e che contemporaneamente: - Non sono Alimentari, ma puoi comprare il pane (perchè arriva dal fornaio del paese vicino, la mattina) e trovi alcuni tipi di pasta, riso, olio ed acqua minerale Vendono o non vendono alimentari? Oltre a pasta, riso, ecc. hanno anche qualcosa di frutta e verdura? E soprattutto hanno il latte fresco? Insomma, quei piccoli empori che, se non ci fossero loro, i paesini di 50 abitanti o giù di lì sarebbero dei paesi fantasma! Qualche idea? Forse /shop=convenience?/ Non è che io abbia capito esattamente cosa vendono, comunque, sì direi che shop=convenience dovrebe andare bene (anche perché la definzione che riporta il wiki è talmente generica, che potrebbe rientrarci di tutto). http://wiki.openstreetmap.org/wiki/Tag:shop%3Dconvenience Altra cosa che trovo sul wiki è shop=general http://wiki.openstreetmap.org/wiki/Tag:shop%3Dgeneral ... ma il wiki stesso inizia dicendo che non è chiaro cosa sia ... AnyFile ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappatura: i negozi di paese
si..anche per me va bene convenience. In genere vendono frutta e verdura, a volte anche del luogo stesso. Il 13/02/2015 14:23, Any File ha scritto: 2015-02-12 13:51 GMT+01:00 Max1234Ita max1234...@gmail.com: Ciao a tutti, Il quesito che vorrei proporre oggi è: come mappare quei negozietti, spesso a gestione familiare, che si trovano nei piccoli centri rurali (almeno in Italia) e che contemporaneamente: - Non sono Alimentari, ma puoi comprare il pane (perchè arriva dal fornaio del paese vicino, la mattina) e trovi alcuni tipi di pasta, riso, olio ed acqua minerale Vendono o non vendono alimentari? Oltre a pasta, riso, ecc. hanno anche qualcosa di frutta e verdura? E soprattutto hanno il latte fresco? Insomma, quei piccoli empori che, se non ci fossero loro, i paesini di 50 abitanti o giù di lì sarebbero dei paesi fantasma! Qualche idea? Forse /shop=convenience?/ Non è che io abbia capito esattamente cosa vendono, comunque, sì direi che shop=convenience dovrebe andare bene (anche perché la definzione che riporta il wiki è talmente generica, che potrebbe rientrarci di tutto). http://wiki.openstreetmap.org/wiki/Tag:shop%3Dconvenience Altra cosa che trovo sul wiki è shop=general http://wiki.openstreetmap.org/wiki/Tag:shop%3Dgeneral ... ma il wiki stesso inizia dicendo che non è chiaro cosa sia ... AnyFile ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappatura: i negozi di paese
On 2015-02-13 at 14:23:17 +0100, Any File wrote: Non è che io abbia capito esattamente cosa vendono, comunque, sì direi che shop=convenience dovrebe andare bene fondamentalmente vendono tutto quello di cui gli abitanti del paese hanno bisogno in modo regolare http://wiki.openstreetmap.org/wiki/Tag:shop%3Dconvenience http://wiki.openstreetmap.org/wiki/Tag:shop%3Dgeneral la differenza tra questi due in effetti è sottile (e lo dicono loro stessi), nella pagina di convenience dicono che general with an even wider range of products including tools, building supplies. It sells everything because it is the only shop for miles around., che in italia non credo sia così diffuso, dato che in fondo le nostre distanze tendono ad essere più limitate. +1 per convenience -- Elena ``of Valhalla'' ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-ro] Hărți de munte
Salut! Lucrez la o colecție de hărți montane, pentru mobil, pe baza datelor din OpenStreetMap. http://haihui.grep.ro Când mai mergeți la munte, puteți să descărcați o hartă pe telefon (rămâne salvată în browser și e disponibilă offline), și să o folosiți pentru orientare. -- Alex ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [OSM-talk-be] roadsign plugin adapted for Belgium
Do we have car sharing traffic rules in Belgium? 2015-02-13 14:56 GMT+01:00 Jo winfi...@gmail.com: 2015-02-11 16:17 GMT+01:00 Sander Deryckere sander...@gmail.com: I tried it a bit, and I do have some concerns with both the mapping plugin and the style JOSM uses. First, I think that a traffic sign should only have tags like traffic_sign=BE:C21[7] and no tags like maxweight=7 Those legal implications of traffic signs should stay on way segments IMO. Fully agree with you, atm you can get the effect you want by ticking or unchecking the tick box. Then I've always had problem with tagging variable speed limits (f.e. those dynamic zone-30 signs). When mapping signs, there should be a clear difference between the variable sign and the fixed sign, and that setting should also apply to the tags on the way segments. same here Since we're tagging directions on road pieces too, allowing direction signs (f.e. F29) should also be possible. It's a matter of adding it to the XML file. Not hard to do, but it hadn't been high on my priority list. The icons are already present in the plugin's image files. One of the reasons I hadn't added them yet (apart from lack of time), is that I'm concerned they will take up a lot of space, so the plugin should be changed and have tabs for categories of signs. Now, wrt the specific Belgian case, I've also seen a few mistakes, though not that many, since the plugin isn't very usable before solving the above. C9 is translated to moped=no on the wiki, while it's mofa=no on the plugin. I know the difference is very fuzzy (and the relation to class A and B too), but we should at least use a uniform tagging. C9 seems to be meaningless if Class A or B are not mentioned. Changed to moped. C23 is translated to goods=no on the wiki, and hgv=no on the plugin, again, the difference is rather fuzzy. added both C24a and C24b are both tagged as hazmat=no on the plugin, again a difference with the wiki, and I'm not sure what the hazmat_ADR_tunnel sign is. conformed to the wiki, even though no information about access:explosives can be found there Sign combinations (like C5+C7) also aren't available in the plugin. Didn't readily know what to do with those. Added them now No-stopping signs are missing from the plugin, and no-parking signs have no tags attached (parking:lanes:right=no would be the default tag I guess). Added, it's work in progress. I skipped the ones I didn't feel sure enough about. The F1 sign (without buildings background) is deprecated and all need to be replaced against June 1st (see http://www.nieuwsblad.be/cnt/dmf20141120_01386508 as example), I don't think the plugin will be production-ready against that time. So I don't think it's worth to include the sign (at least not with that graphic). Leaving it for the time being. Feel free to contribute a better graphic for F1a. F9 should be translated to motorroad=yes instead of motorway=yes changed The F17 sign contains some strange defaults (conditional access restrictions?) copy pasted from wiki, I'll remove them. I didn't really check the validity of sub-signs, as I've often found sub-signs very confusing in real life. +1 Thanks!!! Jo ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-GB] Bus Depots
I’ve not read the whole thread but there was a tagging list discussion in 2010 which I found linked from http://wiki.openstreetmap.org/wiki/Community_Updates/2010-09-13#Depo ts_and_Garages Ed From: Antje (OpenStreetMap) [mailto:kurias...@gmail.com] Sent: 13 February 2015 16:46 To: talk-gb@openstreetmap.org Subject: [Talk-GB] Bus Depots Back in 2008, the recommendation for tagging bus depots, according to http://wiki.openstreetmap.org/wiki/Talk:Buses#Depots, was to use amenity=parking, access=private and landuse=industrial. However, I have seen other London depots use myriad other tags such as amenity=commercial and amenity=bus_station. Are there more relevant tags to this facility, or should the 2008 recommendation stand as it is? Amaroussi ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Le 13 février 2015 14:44, Tony Emery tony.em...@yahoo.fr a écrit : Pieren wrote Sinon, Tony, laisse tomber les remarques de Philippe. J'essayes vraiment mais laisser écrire des bêtises pareil, c'est trop dur... Reste poli, car je n'ai pas écrit de bêtise mais tu réponds à côté du problème et veux absolument faire croire des trucs que je n'ai PAS écrit. Et tu n'as toujours pas répondu au fait qu'il y a bel et plusieurs codes FANTOIR pour certaines voies limitrophes de plusieurs communes et plusieurs noms aussi selon la commune de chaque côté. Depuis le début tu passes à côté de cette question et tourne autour d'autre chose : plusieurs communes, plusieurs codes pour l'INSEE, c'est simple non ? Et ça se répercute aussi sur leur codification internes de voirie si elles ne se coordonnent pas. Je n'ai JAMAIS (je répète) dit que les communes avaient plusieurs codes INSEE (c'est une bêtise que tu as toi-même inventé en la mettant à mon crédit), hormis les codes historiques liés aux changements de périmètres (fusions/scissions de communes), et les codes de pseudo-communes pour les besoins particulier de l'INSEE pour grouper des communes ou pour des entités qui ne sont pas (ou ne sont plus) des communes. Des communes qui ne coordonnent pas leurs outils ou ne veulent pas le faire sur tout, c'est monnaie courante :les greffes de tribunaux administratifs (et du Conseil d'Etat), ou les archives préfectorales, sont remplis des dossiers de réglement de litiges intercommunaux. Mais aussi bien les préfets que les tribunaux n'ont eu à régler des cas de conflits sur un nom de voirie (tant que cela ne touche pas à des droits exclusifs dont les communes ne disposent pas, comme les droits des marques protégées et des appellations protégées) puisque chaque commune peut décider d'appeler ses voies comme elle veut même celles qu'elles partagent avec d'autres communes et même si elles ne gèrent pas la voirie physique ou en délègue la gestion par échange avec sa voisine. __ Exemple 1. Prend ce schéma par exemple d'un long boulevard frontière longeant 3 communes avec quelques virages modérés et un carrefour au milieu formant un Y : Commune A =[o]===// Commune B |Commune C || Commune C Au début tout le monde appelle la rue horizontale du même nom (par exemple Boulevard de Paris. Mais la commune C n'aime pas ce nom et décide que la rue venant du sud et se prolongeant vers l'ouest (par un carrefour symbolisé par le [o] forme un alignement et décide de l'appeler Rue de Comme A (ou choisit un nom politique comme Avenue Georges Marchais ou le nom d'un de ses anciens élus) et qu'elle vient d'aménager pour assurer une meilleure connexion avec cet axe intercommunal essentiel. La commune A n'y voit pas l'intérêt (ou carrément s'y oppose pour des questions politiques) et conserve le nom de son côté, elle ne change pas non plus son découpage de la voie, en revanche la comme C a opté un nom différent pour la branche Sud==Nord[o]==Nuest, et même utilisé un autre nom pour pour la branche [o]==Est. Elle a recodé pour ses besoins ses deux nouvelles rues (elle a pu en revanche conserver les numérotations existantes sur la branche [o]==Est. Rien n'a changé non plus sur la répartition de la gestion de la voie Ouest==[o]==Est par la commune A, bien que pour C il s'agit maintenant de deux rues distinctes. La commune A n'a besoin de rien changer dans ses usages comme sa propre nomination de la voie. La commune B non plus n'a besoin de faire aucune changement. Comment peut-on faire ? FANTOIR entérine et crée deux nouveaux codes pour la commune C, qui remplacent l'ancien code unique. Faute d'accord entre la commune C et la commune A sur le nom décidé par la commune C, on se retrouve avec deux codes FANTOIR et deux codes communaux internes distincts pour le segment voie Ouest==[o] ; et même chose pour le segment [o]==Est. __ Exremple 2. En plus de ça la partie est de la commune C pourrait être en fait la commune B - dans ce cas la voie unique de la commune A est lç encore scindé en trois sections, mais seule la section centrale porte deux codes simultanés et deux noms simultanés selon le côté alors que les parties est et ouest sont inchangées, totalement homonymes des deux cotés A et B, mais plus connectées (car la commune C utilise un nom différent seulement de son côté.. En quoi le droit de police du maire intervient-il ? Tu as voulu amener le sujet ce n'est pas le propos mais puisque tu y tiens, c'est l'usage de ce droit par la commune C qui pose problème __ Exemple 3. En réponse à ça d'ailleurs les communes A et B peuvent se mettre d'accord pour utiliser encore un nouveau nom, politiquement orienté face à la Avenue Georges Marchais décidé par la comme C, et remplacer le Boulevard de Paris par Avenue Georges Pompidou (mais sans que ni A ni B n'ait besoin de changer leur codification interne (seul le nom
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Fait toi plaisir, une main sur le comptoir \o/ Pierre De : Tony Emery tony.em...@yahoo.fr À : talk-fr@openstreetmap.org Envoyé le : Vendredi 13 février 2015 8h44 Objet : Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712 Pieren wrote Tu rigoles des genoux ? Tiens, comme je ne connaissais pas cette expression, j'ai essayé divers postures mais n'y suis pas arrivé. Quelqu'un a un mode d'emploi ? Ah c'est TRES difficile et à mon âge (enfin selon ma souplesse), je n'y arrive plus. Pieren wrote Sinon, Tony, laisse tomber les remarques de Philippe. J'essayes vraiment mais laisser écrire des bêtises pareil, c'est trop dur... Pieren wrote Je préfère de loin, comme d'autres intervenants, le tag ref:FR:commune qui aura la même clé pour toutes les communes. Par contre, je reste sur ma position de ne l'utiliser qu'en l'absence de code FANTOIR pour éviter d'alourdire inutilement les objets dans OSM. Il faut aussi penser aux autres contributeurs. Pour ton travail local, il reste facile de retrouver le code unique local si le code FANTOIR est connu, à la condition que les codes correspondent géographiquement à 100%. Est-ce bien le cas ? Le code Fantoir contient le code INSEE de la commune, tout comme le ref:FR:commune. On a une table que l'on met à jour chaque année avec les données de la DGFiP pour récupérer les nouveaux codes Rivoli. Je vais mettre en lien le document de la ville d'Avignon sur le travail de la base de données voirie et dans lequel on a les infos sur cette référence (histoire de montrer que ça n'est pas que ma lubie). Seulement ce doc est un peu vieux et le code a évolué (notamment avec le V). - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5833486.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
2015-02-13 13:09 GMT-02:00 Claiton Neisse claiton.nei...@gmail.com: Enfim, minha proposta é: - As rodovias RSC-XXX que foram construídas sobre diretrizes de rodovias federais planejadas terem as suas próprias relações; - RSC-XXX deve constar na primeira posição, seguido de BR-XXX, na tag ref dos trechos coincidentes; - A denominação da BR-XXX, caso possua, não deve constar nos trechos coincidentes nem na relação da RSC-XXX. Com o devido respeito, estou tendo problemas com raciocínio empregado no seu argumento. O que exatamente você entende por coincidentes? Para mim, quando alguém diz que o feriado coincide com um domingo, significa que é feriado e domingo, ambas as coisas. Não deixa de ser domingo por ser feriado. No seu argumento dá a entender que quando for coincidente, então não se usa ambos os códigos. Lamento, mas não entendi isto. Se a rodovia é coincidente (ou seja se são ambas as coisas) porque não devo colocar ambas as referências? No meu entendimento, RSC-XXX deve constar quando for de administração estadual, e somente se a administração faz mesmo esta distinção. Já BR-XXX deve, na minha opinião, constar *sempre*, sendo de administração estadual ou não, em adição a RSC-XXX. Em particular, não vejo que mal faz em relacionar ambos os códigos. É importante, por outro lado, não começar a inventar códigos RSC-XXX se a própria administração estadual não as emprega. Em Minas tem várias BRs que não tem um código MGC, mesmo sendo de administração estadual. Agora se você quiser se dar ao trabalho em construir duas relações separadas, uma para RSC-XXX e oura BR-XXX, não vejo problema algum nisto, muito embora manter estas relações de rota tenha se tornado uma tarefa bastante ingrata. um grande abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-be] Brussels by bicycle
Lang geleden dat ik zo'n belachelijk filmke had gezien. Als alle Brusselse fietsers zo stom waren als hier wordt voorgesteld zou ik voorstander zijn om fietsen in de stad absoluut en totaal te verbieden, tot nut van 't gemeen. Gelukkig weet ik wel beter. Wat denkt men toch te bereiken op deze manier? Ik vind het enkel contraproductief. Verder zijn het niet alleen de fietsers die van de overheid - in Brussel en elders - gekke situaties voorgeschoteld krijgen. Wanneer een bekwaamheidsdiploma voor planners en architecten van openbare infrastructuur? Met periodieke evaluatie? On 13-02-15 07:58, Jo wrote: http://www.nieuwsblad.be/cnt/dmf20150212_01525728 both hilarious and incredibly sad at the same time. It's not that they're not trying. Bicycle infrastructure has improved a lot over the past 10 years, but not quite there yet. I'm confident this will become another 'belgenmop' in The Netherlands... ___ 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-GB] Bus Depots
Back in 2008, the recommendation for tagging bus depots, according to http://wiki.openstreetmap.org/wiki/Talk:Buses#Depots http://wiki.openstreetmap.org/wiki/Talk:Buses#Depots, was to use amenity=parking, access=private and landuse=industrial. However, I have seen other London depots use myriad other tags such as amenity=commercial and amenity=bus_station. Are there more relevant tags to this facility, or should the 2008 recommendation stand as it is? Amaroussi signature.asc Description: Message signed with OpenPGP using GPGMail ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[OSM-talk-fr] Abc-Map - Découvrir le projet
Que pensez-vous de ce nouveau logiciel qui utilise OSM dans sa présentation ? Ily a de bons géographes en Bretagne ;-) abc-map.fr/project ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM n°235-236 en français
Je lis Osmose étend sa couverture aux Caraïbes. Cependant la version anglais du Twit est un peu trop optimiste et annonce en fait Now, full Caribbean coverage Ce qui n'est encore que partiellement vrai. Sinon bravo pour l'extension qui a du nécessiter l'ajout d'extension en espace disque (SSD pour la base la plus sollicitée pour lancer les analyses et recevoir les mises à jour) et ses backups réguliers (sur des disques dur d'un RAID réseau je suppose) 1. Détails 2. Un cloud international pour Osmose QA ? == 1. Détails == La Caraïbe (anglais : Caribbean) inclue aussi toutes les terres continentales bordant le Golfe du Mexique), ce qui incluerait alors au moins dans son sens le plus large : - les Etats côtiers des USA (par exemple la Floride ou la Louisiane ou encore le Texas), visiblement exclus saufs quels fragment résiduels ou station pétrolières américaines dans le Golfe - ceux du Mexique (couvert partiellement sur quelques éléments de base, mais c'est peut-être en cours de calcul ou de validation des tests sur quelques zones très limitées) - ceux de la côte nord de la Colombie, ceux du Venezuela, et tous les petits pays d'Amérique centrale (Panama inclu) : ils semblent bien couvert - aussi les Grandes Antilles en totalité (il y a bien Haïti depuis longtemps, plus récemment la République dominicaine, La Jamaïque et Porto Rico, mais pas encore Cuba) - et parfois par extension aussi les Bahamas (plus au nord-est mais pas dans le Golfe ni même en bordure, elles ne font pas partie de la couverture), et aussi au sud-est les 3 Guyanes (elles sont hors de la zone du Golfe, mais pas loin : on a seulement la française). Quand on utilise parfois le pluriel les Caraïbes (anglais: The Caribbeans), on sous-entend les îles de la Caraïbe mais alors ce serait nu peu trop restrictif puisqu'il y a une couverture des côtes Nord de la Colombie, du Vénezuela et de l'Amérique Centrale. Mais il manquerait encore Cuba (qui n'est pas couvert). Cependant aussi la traduction du Twitt utilise le pluriel (alors que l'anglais utilise le singulier). Du fait de l'absence pour l'instant de Cuba et seulement quelques tests de polygones au Mexique, ainsi que l'absence des côtes sud des Etats-Unis, devant le Golfe du Maxique on aurait pu dire la Caraïbe orientale (anglais : Estearn Caribbean), bien que l'expression est comprise (parfois, mais souvent à tord) comme un synonyme des Petites Antilles (lesquelles n'incluent normalement pas Porto Rico qui est couvert et mis en avant par le Twitt, ni les Etats néerlandais de Curaçao et Aruba sur de la côte nord du Venezuela, ni les dépendances vénézuéliennes), mais là ils sont tous couvert/ Du coup le mot le plus exact serait Antilles (anglais : Antillas) le terme pouvant inclure par extension la partie des Grandes Antilles limitée à l'Est par la Jamaïque, il est rarement utilisé pour Cuba et normalement jamais pour le Mexique (même pour la péninsule du Yucatan qui ferme en fait le sud-est du Golfe du Mexique dans son sens le plus restreint autour de Cancun) ni aucun des les Etats d'Amérique centrale qui sont couverts même sur leur côte Pacifique (du Guatemala à Panama), ni non plus la Colombie, ni le Venezuela (en dehors de ses Dépendances, et des Etats néerlandais d'Aruba et Curaça, tous attribués aux Petites d'Antilles) Mais l'ennui c'est que l'annonce en anglais a été plus optimiste que la version française en disant Full coverage. Et c'est ce qui peut tromper les américains du sud qui auraient pu y croire, voire aussi ceux des Bahamas (alors que pour avoir les Bahamas il charge de calcul et l'espace de données n'est pas du tout aussi conséquent que les USA ou même le Mexique. Je veux croire que pour atteindre la couverture complète de la Caraïbe il faille attendre l'achèvement du Mexique, mais surtout l'ajout de Cuba qui n'a rien du tout (si on doit aussi y inclure les Etats caribbéens du sud des Etats-Unis, là il faudra d'autres capacités, Osmose n'est peut-être pas encore taillé pour (et peut-être même il a du mal avec le Mexique) == 2. Un cloud international pour Osmose QA ? == Et il vaudrait mieux qu'il y ait un serveur Osmose séparé pour les USA, et les Bahamas. Voire même le Canada (mais là, plus de contrôle pour Saint-Pierre-et-Miquelon ni pour le Québec sauf si le polygone gardé pour le serveur français fixe une longitude, celle frontière avec les Territoires du Nord-Ouest, et une latitude limite entre Ottawa et Laval, du côté de Cornwall, afin le cadran nord-ouest reste sur le serveur France, en incluant donc tout le Québec (ainsi qu'Ottawa mais pas Toronto), tout Terre-Neuve-et-Labrador, et le Groenland. et une concertation avec le serveur américain pour synchroniser les règles applicables au Canada anglophone voire à tout le Canada. Y-a-t-il dans l'air prévu d'autres instances d'Osmose * aux USA pour l'Amérique du Nord (Québec et Mexique inclus, donc aussi avec Saint-Pierre-et-Miquelon) avec l'extension à tout l'est du Pacifique Nord pour
Re: [OSM-talk] guide to vandalism” in OSM?
Hi JB You are probably from a northern and developped country like me. But the reality is not the same everywhere. There was a discussion on the OSM Mali list today. People where discussing if it would be possible to meet this weekend with the electric planified shoutage. Plus it is not everybody that has access to a computer and internet. Go in the field? I mapped in the last few days in the northern part of Quebec, Canada (innuit territory). I was lucky to find imagery at some places. Our challenge is to innovate and let others participate differently. Nothing is perfect in our OSM world. We just try to find ways to move forward and let people participate in different ways. About come and survey? For the Haiyan Activation, people in the field added notes describing infrastructures. Badly these were anonymous notes and I could not contact them for more info. I replied to it and wait for an answer. After a year, somebody responded to me recently and corrected the map. This is a workflow to build. For anonymous notes, if there are too many, there could be a policy to remove them after a certain period of time. regard Pierre De : JB jb...@mailoo.org À : talk@openstreetmap.org Envoyé le : Vendredi 13 février 2015 9h50 Objet : Re: [OSM-talk] guide to vandalism” in OSM? After having looked at a few @osmthis notes, my conclusion is that it rarely helps: the location of the note is not precise enough, and the photo cannot help with finding the poi location. Should use photo + manual location.Still wondering about this « presume good faith » thing. If every note should be resurveyed on the ground, why not just replace the creator text with « please come survey here » ? And then, just randomly create them around everywhere, just to encourage mappers get out ?Sure, you got someone give an example of two bad faith notes in France, out of 21000 created, 19000 closed ? Are the statistics really worse than that of vandalism ?JB. Le 12.02.2015 19:38, Pierre Béland a écrit : We have to think of OSM as a global community where not all countires are equal with access to internet and computers. Often, people have smartphones and could contribute. Adding a note with photo would greatly help. The @osmthis Twitter tag let's do this. But it is uneasy then to communicate with these persons.adding @osmthis. The same functionality in OSM would be fantastic. But with anonymous notes, we cannot contact these people and obtain clarification. Then the risk that notes stay open for a long period since incompleted. Pierre De : Maarten Deen md...@xs4all.nl À : talk@openstreetmap.org Envoyé le : Jeudi 12 février 2015 12h43 Objet : Re: [OSM-talk] guide to vandalism in OSM? On 2015-02-12 18:23, Pieren wrote: On Thu, Feb 12, 2015 at 4:29 PM, Michał Brzozowski www.ha...@gmail.com wrote: @Pieren: You switch topics so easily that I'm not sure what are you talking about precisely. Is your stance Someone showed that it is easy to add fake notes, therefore we must assume that every single POI added from notes is fake unless we prove it 100%? I'm just saying that a note is not good enough as a single source for contribution. Especially when it is easy to verify like in the two reported examples (a bank and a bakery). And in case of doubt, you just leave the note open for others instead of compulsive close notes contributions. I agree. Especially new notes, just wait a while until someone who maybe has local knowledge picks it up. Another thought: give the possibility to add photo's to notes. That way you have more confirmation that there is something. You still don't know if it is there unless there are GPS coordinates in the picture, but it's something. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
2015-02-13 15:31 GMT-02:00 Claiton Neisse claiton.nei...@gmail.com: Dito isso, eu pergunto: como uma aplicação qualquer ira decidir que rodovia é essa? Afinal, os segmentos estão tageados com ref=RSC-287 e pertencem a uma relação de rota da BR-287. Qual tag ref prevalece? A tag ref da relação ou a tag ref do segmento? Por enquanto a maioria (se não todas) as implementações verificam as informações contidas no próprio caminho. Ficaria apenas RSC-287 no caso, sem nenhuma informação da BR. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-be] Brussels by bicycle
Het is natuurlijk bedoeld om wat misstanden aan te kaarten. 't Zal wel opgelost geraken. Helemaal te gek vond ik dat hij blijkbaar z'n fiets over dat hek moest tillen. Cross in zhe Brousse L :-) Jo Op 13 februari 2015 17:37 schreef Karel Adams fa348...@skynet.be: Lang geleden dat ik zo'n belachelijk filmke had gezien. Als alle Brusselse fietsers zo stom waren als hier wordt voorgesteld zou ik voorstander zijn om fietsen in de stad absoluut en totaal te verbieden, tot nut van 't gemeen. Gelukkig weet ik wel beter. Wat denkt men toch te bereiken op deze manier? Ik vind het enkel contraproductief. Verder zijn het niet alleen de fietsers die van de overheid - in Brussel en elders - gekke situaties voorgeschoteld krijgen. Wanneer een bekwaamheidsdiploma voor planners en architecten van openbare infrastructuur? Met periodieke evaluatie? On 13-02-15 07:58, Jo wrote: http://www.nieuwsblad.be/cnt/dmf20150212_01525728 both hilarious and incredibly sad at the same time. It's not that they're not trying. Bicycle infrastructure has improved a lot over the past 10 years, but not quite there yet. I'm confident this will become another 'belgenmop' in The Netherlands... ___ 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
Re: [OSM-talk] guide to vandalism” in OSM?
On 12 February 2015 at 13:55, Marc Gemis marc.ge...@gmail.com wrote: The comments were saying that vandalism is rare on OSM Wikipedia sensibly offers this advice: https://en.wikipedia.org/wiki/Wikipedia:Don%27t_stuff_beans_up_your_nose -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] roadsign plugin adapted for Belgium
Hallo Karel, Dat is niet helemaal hetzelfde. Bij car sharing mag je bepaalde rijstroken gebruiken als je een passagier bij je hebt. Autodelen zoals Cambio e.d. dat doen, is een vorm van 1 auto voor meerdere mensen die een soort abonnement hebben en dan onderling afspreken wie de wagen op welk moment ter beschikking heeft. Misschien heb ik de Engelse term wel verkeerd. Ben wat vermoeid. De data voor de plugin zit in een ticket van JOSM. Ik verwacht dat het er dan morgen wel bij zal zitten. Ik heb gezorgd dat we nu ook zones voor parkeren, parkeerverbod en alle mogelijke beperkingen kunnen toevoegen. Verder alle gevaarsborden toegevoegd en de meest relevante 'informatie'-borden. Aan wegwijzers ben ik nog niet toegekomen. En dan natuurlijk Sander z'n opmerkingen verwerkt. Wie zelf de laatste borden wil toevoegen, of Franse vertalingen, of verdere verbeteringen, be my guest: http://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium/Road_signs_plugin https://dl.dropboxusercontent.com/u/42418402/RoadSignsBE/RoadSignsBE.zip https://dl.dropboxusercontent.com/u/42418402/RoadSignsBE/roadsignpresetBE.xml De iconen zitten er al allemaal in, ze moeten enkel aan dat XML-bestand worden toegevoegd en dan zijn ze beschikbaar in de plugin. Wat tijd kost, is uitzoeken welke tags er dan van toepassing zijn. mvg, Jo 2015-02-13 18:46 GMT+01:00 Karel Adams fa348...@skynet.be: Op zijn minst bestaan er gereserveerde parkeerplaatsen. Voorbeeld aan station Nekkerspoel (Ontvoeringsplein). https://www.google.be/maps/@51.029946,4.489369,3a,30y,106.71h,86.96t/data=!3m4!1e1!3m2!1sJ2aKjl84Hyve3lEwG3UrVA!2e0?hl=nl On 13-02-15 17:03, Jo wrote: Do we have car sharing traffic rules in Belgium? 2015-02-13 14:56 GMT+01:00 Jo winfi...@gmail.com: 2015-02-11 16:17 GMT+01:00 Sander Deryckere sander...@gmail.com: I tried it a bit, and I do have some concerns with both the mapping plugin and the style JOSM uses. First, I think that a traffic sign should only have tags like traffic_sign=BE:C21[7] and no tags like maxweight=7 Those legal implications of traffic signs should stay on way segments IMO. Fully agree with you, atm you can get the effect you want by ticking or unchecking the tick box. Then I've always had problem with tagging variable speed limits (f.e. those dynamic zone-30 signs). When mapping signs, there should be a clear difference between the variable sign and the fixed sign, and that setting should also apply to the tags on the way segments. same here Since we're tagging directions on road pieces too, allowing direction signs (f.e. F29) should also be possible. It's a matter of adding it to the XML file. Not hard to do, but it hadn't been high on my priority list. The icons are already present in the plugin's image files. One of the reasons I hadn't added them yet (apart from lack of time), is that I'm concerned they will take up a lot of space, so the plugin should be changed and have tabs for categories of signs. Now, wrt the specific Belgian case, I've also seen a few mistakes, though not that many, since the plugin isn't very usable before solving the above. C9 is translated to moped=no on the wiki, while it's mofa=no on the plugin. I know the difference is very fuzzy (and the relation to class A and B too), but we should at least use a uniform tagging. C9 seems to be meaningless if Class A or B are not mentioned. Changed to moped. C23 is translated to goods=no on the wiki, and hgv=no on the plugin, again, the difference is rather fuzzy. added both C24a and C24b are both tagged as hazmat=no on the plugin, again a difference with the wiki, and I'm not sure what the hazmat_ADR_tunnel sign is. conformed to the wiki, even though no information about access:explosives can be found there Sign combinations (like C5+C7) also aren't available in the plugin. Didn't readily know what to do with those. Added them now No-stopping signs are missing from the plugin, and no-parking signs have no tags attached (parking:lanes:right=no would be the default tag I guess). Added, it's work in progress. I skipped the ones I didn't feel sure enough about. The F1 sign (without buildings background) is deprecated and all need to be replaced against June 1st (see http://www.nieuwsblad.be/cnt/dmf20141120_01386508 as example), I don't think the plugin will be production-ready against that time. So I don't think it's worth to include the sign (at least not with that graphic). Leaving it for the time being. Feel free to contribute a better graphic for F1a. F9 should be translated to motorroad=yes instead of motorway=yes changed The F17 sign contains some strange defaults (conditional access restrictions?) copy pasted from wiki, I'll remove them. I didn't really check the validity of sub-signs, as I've often found sub-signs very confusing in real life. +1 Thanks!!! Jo
Re: [Talk-br] FIXME
É, eu escrevi mal. Mas posso garantir a todos, inclusive ao Belnuovo, que eu não estava focando em criticá-lo. Realmente fiquei curioso a respeito do que estava acontecendo no caso. Realmente não entendera. Alexandre Magno Em 13 de fevereiro de 2015 07:39, John Packer john.pack...@gmail.com escreveu: Magno, por favor seja mais delicado futuramente. Belnuovo, se você clicar no botão com um ponto de interrogação no lado direito do site do OSM, dá pra clicar no mapa e ver uma lista de objetos próximos. Daí dá pra pegar um link direto para o objeto. Por exemplo, um dos objetos que você mencionou é http://www.openstreetmap.org/way/297938557/history Até onde eu vi, a alteração que você fez está correta: a linha parecem ser uma ligação de via terciária mesmo. Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Usei a palavra coincidentes entre aspas, porque, de fato elas não coincidem (no sentido de ambos os traçados das rodovias coincidirem). Basta ver como o DNIT define rodovias coincidentes. O termo coincidente quer dizer que uma rodovia estadual ou municipal coincide com a diretriz de uma rodovia federal planejada (repare nas palavras diretriz e planejada). Ou seja a rodovia federal ainda não foi implantada e, quando for, seu traçado definitivo pode ser diferente do traçado atual da rodovia RSC-287. Um bom exemplo pratico desse conceito de coincidente é a BR-392. Estão estudando traçados para implanta-la entre Santo Ângelo-RS e Santa Maria-RS mas, hoje, em um trecho a BR-392 coincide com a BR-158 e, segundo os estudos, pode, ou não, deixar de coincidir. http://www.openstreetmap.org/relation/406313#map=9/-28.9733/-53.9594 http://www.jornaldasmissoes.com.br/noticias/geral/id/1381/projeto-da-br392-preve-ate-quatro-tracados-diferen.html Não inventei códigos. Como disse, falo sobre o RS, não sobre os outros estados. E no RS a administração utiliza RSC-XXX para as rodovias estaduais que coincidem com a diretriz de uma rodovia federal planejada. E placas e marcos indicam como RSC-XXX. Consulte o site do DAER: http://www.daer.rs.gov.br/site/sistema_rodoviario_rodovias.php Veja, não disse que os códigos das BR-XXX não devam constar na tag ref da RSC-XXX. Você entendeu errado. Em trechos que uma rodovia estadual coincide com a diretriz de uma rodovia federal planejada a tag ref fica assim: ref=RSC-XXX;BR-XXX. Ficou claro? Não quero que se perca a informação de que a RSC-XXX foi construída sobre a diretriz de uma rodovia federal. Quanto as relações: acho que temos que discutir melhor isso! Porque? Para não gerar inconsistência nos dados do OSM. Vou tentar explicar melhor utilizando o caso das rodovias RSC-287 e BR-287. Friso novamente: falo sobre o RS e não sobre os outros estados da federação, apesar de poder se aplicar a outros estados. Vamos lá: - A rodovia RSC-287 sai de Montenegro-RS e vai até Santa Maria-RS ( http://www.daer.rs.gov.br/site/forca_download.php?arquivo=arquivos/sistemas/arquivo27_14.pdf ); - A rodovia BR-287 sai de Montenegro-RS e vai até São Borja-RS, passando por Santa Maria-RS (http://www.openstreetmap.org/relation/190857); - A rodovia BR-287 no trecho entre Montenegro-RS e Santa Maria-RS não esta implantada e coincide (no sentido explicado anteriormente) com a rodovia RSC-287. - A rodovia BR-287 entre Santa Maria-RS e São Borja-RS está implantada. Hoje a rodovia RSC-287 não possui relação própria e os segmentos tem, em geral, as tag's, entre outras: name=Rodovia da Integração ref=RSC-287 source:name=Lei 7003 Exemplos: http://www.openstreetmap.org/search?query=rsc-287#map=12/-29.6927/-52.6386 A Lei Federal 7003 nomeia a BR-287 como Rodovia da Integração ( http://www2.camara.leg.br/legin/fed/lei/1980-1987/lei-7003-24-junho-1982-357116-publicacaooriginal-1-pl.html )! No entanto, todos os segmentos da rodovia RSC-287 estão dentro da relação da RB-287 (http://www.openstreetmap.org/relation/190857). Dito isso, eu pergunto: como uma aplicação qualquer ira decidir que rodovia é essa? Afinal, os segmentos estão tageados com ref=RSC-287 e pertencem a uma relação de rota da BR-287. Qual tag ref prevalece? A tag ref da relação ou a tag ref do segmento? Eu vejo como solução, criar uma relação para a RSC-287 e outra para a BR-287. E nos trechos em que elas coincidem (no sentido explicado anteriormente) colocar ref=RSC-287;BR-287. Atenciosamente, Claiton Neisse 55 8147 1030 Em 13 de fevereiro de 2015 15:54, Gerald Weber gwebe...@gmail.com escreveu: 2015-02-13 13:09 GMT-02:00 Claiton Neisse claiton.nei...@gmail.com: Enfim, minha proposta é: - As rodovias RSC-XXX que foram construídas sobre diretrizes de rodovias federais planejadas terem as suas próprias relações; - RSC-XXX deve constar na primeira posição, seguido de BR-XXX, na tag ref dos trechos coincidentes; - A denominação da BR-XXX, caso possua, não deve constar nos trechos coincidentes nem na relação da RSC-XXX. Com o devido respeito, estou tendo problemas com raciocínio empregado no seu argumento. O que exatamente você entende por coincidentes? Para mim, quando alguém diz que o feriado coincide com um domingo, significa que é feriado e domingo, ambas as coisas. Não deixa de ser domingo por ser feriado. No seu argumento dá a entender que quando for coincidente, então não se usa ambos os códigos. Lamento, mas não entendi isto. Se a rodovia é coincidente (ou seja se são ambas as coisas) porque não devo colocar ambas as referências? No meu entendimento, RSC-XXX deve constar quando for de administração estadual, e somente se a administração faz mesmo esta distinção. Já BR-XXX deve, na minha opinião, constar *sempre*, sendo de administração estadual ou não, em adição a RSC-XXX. Em particular, não vejo que mal faz em relacionar ambos os códigos. É importante, por outro lado, não começar a inventar
Re: [OSM-talk-fr] Article - La Voix du Nord
Le 13/02/2015 14:28, HELFER Denis a écrit : Christian, une petite com sur les moyens pour joindre efficacement OSM-Fr à destination du journaliste ? Denis Le bon canal c'est cont...@openstreetmap.fr ou le formulaire de contact sur le site... mais on avait un problème de configuration de ce dernier et des comptes génériques president et secretaire. Ils étaient (mal) gérés par sympa, notre gestionnaire de liste de diffusion. Tout a été remis d'équerre hier soir avec Jocelyn. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-it] relazione modificata da utente
Ciao a tutti, la relazione http://www.openstreetmap.org/relation/2179960 è stata modificata ultimamente 2 volte dall'utente http://www.openstreetmap.org/user/surftrader. all'altezza del paese di San Carlo ( http://ra.osmsurround.org/analyzeMap?relationId=2179960 ) c'è una discontinuità che non riesco a chiudere (se ci provo JOSM mi dice che ci sono conflitti da risolvere, ma l'editor di conflitti non mi aiuta granché). qualche buon anima riesce a metterci mano? -- - Gianmario ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] guide to vandalism” in OSM?
On Fri, Feb 13, 2015 at 3:50 PM, JB jb...@mailoo.org wrote: Still wondering about this « presume good faith » thing. If every note should be resurveyed on the ground, why not just replace the creator text with « please come survey here » ? I'm not saying it has to be necessarily resurveyed on the ground. The information can be verified first by other sources. For the two examples, the bank and the bakery, it' easy to go on the bank web site and check if the branch exists in that town. And for the bakery, you can check if google - for instance - indexed any local press article or website talking about this shop. A no-result should raise an internal alarm and a comment on the note (like plz someone to survey on the ground because I find nothing about this bakery in the web). Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] roadsign plugin adapted for Belgium
Op zijn minst bestaan er gereserveerde parkeerplaatsen. Voorbeeld aan station Nekkerspoel (Ontvoeringsplein). https://www.google.be/maps/@51.029946,4.489369,3a,30y,106.71h,86.96t/data=!3m4!1e1!3m2!1sJ2aKjl84Hyve3lEwG3UrVA!2e0?hl=nl On 13-02-15 17:03, Jo wrote: Do we have car sharing traffic rules in Belgium? 2015-02-13 14:56 GMT+01:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: 2015-02-11 16:17 GMT+01:00 Sander Deryckere sander...@gmail.com mailto:sander...@gmail.com: I tried it a bit, and I do have some concerns with both the mapping plugin and the style JOSM uses. First, I think that a traffic sign should only have tags like traffic_sign=BE:C21[7] and no tags like maxweight=7 Those legal implications of traffic signs should stay on way segments IMO. Fully agree with you, atm you can get the effect you want by ticking or unchecking the tick box. Then I've always had problem with tagging variable speed limits (f.e. those dynamic zone-30 signs). When mapping signs, there should be a clear difference between the variable sign and the fixed sign, and that setting should also apply to the tags on the way segments. same here Since we're tagging directions on road pieces too, allowing direction signs (f.e. F29) should also be possible. It's a matter of adding it to the XML file. Not hard to do, but it hadn't been high on my priority list. The icons are already present in the plugin's image files. One of the reasons I hadn't added them yet (apart from lack of time), is that I'm concerned they will take up a lot of space, so the plugin should be changed and have tabs for categories of signs. Now, wrt the specific Belgian case, I've also seen a few mistakes, though not that many, since the plugin isn't very usable before solving the above. C9 is translated to moped=no on the wiki, while it's mofa=no on the plugin. I know the difference is very fuzzy (and the relation to class A and B too), but we should at least use a uniform tagging. C9 seems to be meaningless if Class A or B are not mentioned. Changed to moped. C23 is translated to goods=no on the wiki, and hgv=no on the plugin, again, the difference is rather fuzzy. added both C24a and C24b are both tagged as hazmat=no on the plugin, again a difference with the wiki, and I'm not sure what the hazmat_ADR_tunnel sign is. conformed to the wiki, even though no information about access:explosives can be found there Sign combinations (like C5+C7) also aren't available in the plugin. Didn't readily know what to do with those. Added them now No-stopping signs are missing from the plugin, and no-parking signs have no tags attached (parking:lanes:right=no would be the default tag I guess). Added, it's work in progress. I skipped the ones I didn't feel sure enough about. The F1 sign (without buildings background) is deprecated and all need to be replaced against June 1st (see http://www.nieuwsblad.be/cnt/dmf20141120_01386508 as example), I don't think the plugin will be production-ready against that time. So I don't think it's worth to include the sign (at least not with that graphic). Leaving it for the time being. Feel free to contribute a better graphic for F1a. F9 should be translated to motorroad=yes instead of motorway=yes changed The F17 sign contains some strange defaults (conditional access restrictions?) copy pasted from wiki, I'll remove them. I didn't really check the validity of sub-signs, as I've often found sub-signs very confusing in real life. +1 Thanks!!! Jo ___ 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: [Talk-it] relazione modificata da utente
2015-02-13 19:04 GMT+01:00 Gianmario Mengozzi gianmario.mengo...@gmail.com : all'altezza del paese di San Carlo ( http://ra.osmsurround.org/analyzeMap?relationId=2179960 ) c'è una discontinuità che non riesco a chiudere (se ci provo JOSM mi dice che ci sono conflitti da risolvere, ma l'editor di conflitti non mi aiuta granché). i conflitti in genere indicanno che nel frattempo che tu hai editato un'altro utente ha modificato e caricato uno o più degli oggetti che stai cercando di caricare ora. Quindi con il tuo upload soprascriveresti quella modifica senza averla nemmeno vista. (per esempio tu scarichi dal server la versione 1 di un oggetto e la modifichi, nel frattempo un altro utente anche scarica la versione 1 di questo oggetto e modifica e carica sul server, creandone la versione 2. Quando tu poi carichi la tua versione basata sulla versione 1 il server ti risponde (o meglio risponde a JOSM) che l'attuale versione di quel oggetto è la 2, e JOSM ti segnala un conflitto. Il mio consiglio è nel dubbio di sempre accettare la versione remota (quella sul server, dell'altro utente), e di applicare evventuali modifiche dopo in un secondo upload. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Pistenkarte für Garmin?
Servus, Am 13.02.2015 um 14:08 schrieb Sven Geggus: gibt es einen speziellen Garmin Kartenstil für Skipisten oder alternativ einen Stil, der auch gutes Rendering für Skipisten hat. Hm, meinst Du so etwas wie auf http://www.wasserstoffe.de/pistemap/ beschrieben ist? Grüße, Michael ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Eu uso sempre a informação do Ministério dos Transportes e do DAER-RS. Para mim, vale o que está lá. A BR-287/RSC-287 está assim (nos dois lugares): RSC-287: km 0 a 21,49 BR-287: km 21,49 a 28,03 RSC-287: km 28,03 a 232,54 BR-287: km 232,54 a 536,11 Os códigos das rodovias são excludentes, em cada trecho. Ou é BR ou é RSC. É redundante colocar os dois códigos, pois TODAS as RSC (antigas RST) pertence ao trajeto planejado da BR. Não se perde informação alguma deixando o código da BR fora dos trechos da RSC, e o mapa fica mais limpo. Sempre que eu vejo uma RSC, eu sei que ela faz parte do trajeto planejado de uma BR. Caso contrário, seria ERS ou VRS. O termo coincidente, apesar de ser a denominação oficial, pode estar causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve ser ref=RSC-153;RSC-287. Ficaria inconveniente etiquetar esse trecho como ref=BR-153;BR-287;RSC-153;RSC-287. O tag ref vai em dois lugares: 1. Na relação, em que o tag ref=BR-287 aparece uma única vez e vale para toda a relação. 2. Nos trechos da relação, em que cada trecho pode ser ref=BR-287 ou RSC-287 (ou ref=RSC-153;RSC-287, ref=BR-287;BR-386, etc.). Quanto à relação para a RSC-287, acho desnecessária, uma vez que ela seria um subconjunto da BR-287. Se eu encontrar alguma relação desse tipo, irei deixá-la quieta. Em 13 de fevereiro de 2015 13:54, Gerald Weber gwebe...@gmail.com escreveu: 2015-02-13 13:09 GMT-02:00 Claiton Neisse claiton.nei...@gmail.com: Enfim, minha proposta é: - As rodovias RSC-XXX que foram construídas sobre diretrizes de rodovias federais planejadas terem as suas próprias relações; - RSC-XXX deve constar na primeira posição, seguido de BR-XXX, na tag ref dos trechos coincidentes; - A denominação da BR-XXX, caso possua, não deve constar nos trechos coincidentes nem na relação da RSC-XXX. Com o devido respeito, estou tendo problemas com raciocínio empregado no seu argumento. O que exatamente você entende por coincidentes? Para mim, quando alguém diz que o feriado coincide com um domingo, significa que é feriado e domingo, ambas as coisas. Não deixa de ser domingo por ser feriado. No seu argumento dá a entender que quando for coincidente, então não se usa ambos os códigos. Lamento, mas não entendi isto. Se a rodovia é coincidente (ou seja se são ambas as coisas) porque não devo colocar ambas as referências? No meu entendimento, RSC-XXX deve constar quando for de administração estadual, e somente se a administração faz mesmo esta distinção. Já BR-XXX deve, na minha opinião, constar *sempre*, sendo de administração estadual ou não, em adição a RSC-XXX. Em particular, não vejo que mal faz em relacionar ambos os códigos. É importante, por outro lado, não começar a inventar códigos RSC-XXX se a própria administração estadual não as emprega. Em Minas tem várias BRs que não tem um código MGC, mesmo sendo de administração estadual. Agora se você quiser se dar ao trabalho em construir duas relações separadas, uma para RSC-XXX e oura BR-XXX, não vejo problema algum nisto, muito embora manter estas relações de rota tenha se tornado uma tarefa bastante ingrata. um grande abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-it] relazione modificata da utente
Quello in piazza in centro va bene. Grazie per la sistemazione :) -- sent by Nexus 5 Il 13/feb/2015 20:13 scratera piz...@alice.it ha scritto: ...ora come ora vedo una interruzione in piazza del popolo a cesena... -- View this message in context: http://gis.19327.n5.nabble.com/relazione-modificata-da-utente-tp5833513p5833519.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 ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
2015-02-13 15:31 GMT-02:00 Claiton Neisse claiton.nei...@gmail.com: Usei a palavra coincidentes entre aspas, porque, de fato elas não coincidem (no sentido de ambos os traçados das rodovias coincidirem). Basta ver como o DNIT define rodovias coincidentes. O termo coincidente quer dizer que uma rodovia estadual ou municipal coincide com a diretriz de uma rodovia federal planejada (repare nas palavras diretriz e planejada). Ou seja a rodovia federal ainda não foi implantada e, quando for, seu traçado definitivo pode ser diferente do traçado atual da rodovia RSC-287. Bom, coincidente sem coincidir o traçado não tinha pensado neste caso. Seria o caso do feriado no domingo, mas com ponto facultativo na segunda. Para mim RSC-XXX e BR-YYY, onde XXX=YYY, eram apenas dois códigos para a mesma rodovia. Na minha cabeça MGC-262 é a rodovia BR-262 nos trechos onde sua administração é estadual, mas continua pertencendo à malha lógica da BR-262. Até onde eu sei esses RSC, MGC começaram a aparecer com a estadualização das BRs. Sempre entendi isto como uma maneira de não colidir o código com as estaduais que já existiam. Por exemplo a MG-262 que não tem nada a ver com a atual MGC-262. Agora se existem esses casos onde a RSC-XXX passa por um caminho e a BR-XXX passa por outro, eu concordo plenamente que não devam ter a ref combinada. Aqui em Minas não me recordo de nenhum caso deste tipo. Um bom exemplo pratico desse conceito de coincidente é a BR-392. Estão estudando traçados para implanta-la entre Santo Ângelo-RS e Santa Maria-RS mas, hoje, em um trecho a BR-392 coincide com a BR-158 e, segundo os estudos, pode, ou não, deixar de coincidir. http://www.openstreetmap.org/relation/406313#map=9/-28.9733/-53.9594 http://www.jornaldasmissoes.com.br/noticias/geral/id/1381/projeto-da-br392-preve-ate-quatro-tracados-diferen.html Bom, para mim isto é outro caso. São rodovias que estão emprestando o traçado uma da outra mas cujo código não tem relação. Não me pareceu o caso que estamávamos analisando que são as coincidentes estaduais/federais. Mas você concorda que enquanto o traçado coincide elas devam ter as duas referências? Não inventei códigos. Como disse, falo sobre o RS, não sobre os outros estados. E no RS a administração utiliza RSC-XXX para as rodovias estaduais que coincidem com a diretriz de uma rodovia federal planejada. E placas e marcos indicam como RSC-XXX. Consulte o site do DAER: http://www.daer.rs.gov.br/site/sistema_rodoviario_rodovias.php Desculpe, não disse ou pelo menos não quis dizer que você estivesse inventando códigos. Apenas alertei para que não começassemos a criar códigos do nada. Veja, não disse que os códigos das BR-XXX não devam constar na tag ref da RSC-XXX. Você entendeu errado. Em trechos que uma rodovia estadual coincide com a diretriz de uma rodovia federal planejada a tag ref fica assim: ref=RSC-XXX;BR-XXX. Ficou claro? Não quero que se perca a informação de que a RSC-XXX foi construída sobre a diretriz de uma rodovia federal. OK, estamos de acordo então. Tudo esclarecido. Quanto as relações: acho que temos que discutir melhor isso! Porque? Para não gerar inconsistência nos dados do OSM. Vou tentar explicar melhor utilizando o caso das rodovias RSC-287 e BR-287. Friso novamente: falo sobre o RS e não sobre os outros estados da federação, apesar de poder se aplicar a outros estados. Sim, com certeza chegar num acordo de uma diretriz seria muito bom. Mas da minha parte é onde eu vou sair da discussão. Cheguei à conclusão que não vale a pena o (meu) esforço gasto no trabalho em manter estas relações de rota e vou dar prioridade para outras coisas, como mapear cidades que faltam, estradas que faltam etc. um grande abraço e bom feriado de carnaval Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Já existe Rodovias municipais hoje com 3 letras na REF e 4 digitos no numeral, com o (-) são 8 Caracteres, Não sei quanto as outras plataformas, mas nos GPS Garmin (com o Mkgmap) não sei se aceita mais que 7 caracteres. ___ Anor C. A. de Souza Concórdia SC 49-8808-4963 From: li...@gimnechiske.org Date: Fri, 13 Feb 2015 19:45:15 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Prioridades em rodovias com mais de uma ref= No meu opinião, o ref=RSC-xxx;BR-xxx somente se as placas no BR mesmo tem o ref RSC, se as placas e com o ref BR, basta ref=BR-xxx;RSC-xxx (como e o situação na minas pelo que observei e pelo que evidencias que conheço no Mapillary com placas BR alas ref=BR-xxx;MGC-xxx) Sobre nome do rodovia no trechos individuais, prefiro ter somente nome do rodovia no relação, e no cada trecho usar o nome local do trecho, ou deixa sem nome. Pelo que saiba não dar erro no camada noname porque nome ja tem no relação. Também renderizadores e roteadores deve pega nome do relação. Aun Johnsen On Feb 13, 2015, at 19:24, Gerald Weber gwebe...@gmail.com wrote: Os códigos das rodovias são excludentes, em cada trecho. Ou é BR ou é RSC. É redundante colocar os dois códigos, pois TODAS as RSC (antigas RST) pertence ao trajeto planejado da BR. Não se perde informação alguma deixando o código da BR fora dos trechos da RSC, e o mapa fica mais limpo. Sempre que eu vejo uma RSC, eu sei que ela faz parte do trajeto planejado de uma BR. Caso contrário, seria ERS ou VRS. Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos ambos as referências no trecho. Depois da discussão anterior fica assim para mim ref=RSC-XXX;BR-XXX significa que RSC-XXX segue o mesmo trajeto de BR-XXX ref=RSC-XXX (somente) significa que a RSC-XXX segue um trajeto mas a BR-XXX segue outro. Ter ambas as referências não polui o mapa, e eu como usuário, acho extremamente útil. Além do mais omitir informação para deixar o mapa mais limpo não é o procedimento adequado, é etiquetar para o renderizador. O renderizador é que decide se mostra uma, duas ou mais referências. O termo coincidente, apesar de ser a denominação oficial, pode estar causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve ser ref=RSC-153;RSC-287. Não. O significado é este mesmo, veja aquihttp://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes Rodovia Coincidente, levando um C adicional no código, como MGC ou RSC. A BR-040 e a BR-262 coincidem em certos trechos no anel rodoviário de BH, mas não estão relacionadas como rodovias coincidentes. Ficaria inconveniente etiquetar esse trecho como ref=BR-153;BR-287;RSC-153;RSC-287. É o que temos feito e não vejo problema algum nisto. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-it] relazione modificata da utente
Il giorno 13 febbraio 2015 19:04, Gianmario Mengozzi gianmario.mengo...@gmail.com ha scritto: Ciao a tutti, la relazione http://www.openstreetmap.org/relation/2179960 è stata modificata ultimamente 2 volte dall'utente http://www.openstreetmap.org/user/surftrader. all'altezza del paese di San Carlo ( http://ra.osmsurround.org/analyzeMap?relationId=2179960 ) c'è una discontinuità che non riesco a chiudere (se ci provo JOSM mi dice che ci sono conflitti da risolvere, ma l'editor di conflitti non mi aiuta granché). qualche buon anima riesce a metterci mano? L'ho fixato ora io, non mi ha dato errori... http://www.openstreetmap.org/changeset/28827808 -- - Gianmario Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-de] Engel für die FOSSGIS-Konferenz 2015 gesucht
Liebe Freunde und Teilnehmer der FOSSGIS-Konferenz 2015, die Vorbereitungen der FOSSGIS-Konferenz laufen auf Hochtouren, die Teilnehmer-Anmeldung läuft [1], das Programm steht [2], das Catering ist geordert. Die Teilnehmeranmeldezahlen bewegen sich auf ähnlichem Niveau wie 2014. Das freut uns sehr. Die Vorbereitung und Durchführung der Konferenz braucht viel Power von möglichst vielen Menschen, diese Menschen nennen wir Engel, es sind die, die sich während der Konferenz etwas Zeit nehmen und einen Helferjob übernehmen. Wir freuen uns, wenn du sowohl als Teilnehmer, als auch als Helfer zur FOSSGIS kommen. Es ist sicherlich möglich einen Vortragstrack zu verfolgen und gleichzeitig bei der Videoaufzeichnung zu helfen z.b. die Kamera zu führen. Das Catering soll geschmeidig laufen, besonders bei großem Andrang. Hier freuen wir uns über Helfer beim Vorbereiten, Austeilen und Aufräumen. Am Welcome Desk kann bei der T-Shirt-Größenfindung oder als Springer unterstützt werden. Auf der Wikiseite zum Helfersystem [3] finden Sie weitere Informationen.Wer Engel sein möchte, registriert sich im Engelsystem [4] und bucht eine passende Arbeitsschicht. Für Fragen, die im Wikitext [3] nicht beantwortet sind, stehen im System die Erzengel bereit (Ask an archangel). Freundliche Grüße FOSSGIS-Konferenz-Oranisationsteam Links: [1] Anmeldung zur Konferenz http://www.fossgis.de/konferenz/2015/anmeldung/ [2] Programm http://www.fossgis.de/konferenz/2015/programm/ [3] Wikiseite Engelsystem http://www.fossgis.de/wiki/Konferenz_2015/Helfer [4] Engelsystem http://helfer.fossgis.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] relazione modificata da utente
...ora come ora vedo una interruzione in piazza del popolo a cesena... -- View this message in context: http://gis.19327.n5.nabble.com/relazione-modificata-da-utente-tp5833513p5833519.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] Prioridades em rodovias com mais de uma ref=
Os códigos das rodovias são excludentes, em cada trecho. Ou é BR ou é RSC. É redundante colocar os dois códigos, pois TODAS as RSC (antigas RST) pertence ao trajeto planejado da BR. Não se perde informação alguma deixando o código da BR fora dos trechos da RSC, e o mapa fica mais limpo. Sempre que eu vejo uma RSC, eu sei que ela faz parte do trajeto planejado de uma BR. Caso contrário, seria ERS ou VRS. Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos ambos as referências no trecho. Depois da discussão anterior fica assim para mim ref=RSC-XXX;BR-XXX significa que RSC-XXX segue o mesmo trajeto de BR-XXX ref=RSC-XXX (somente) significa que a RSC-XXX segue um trajeto mas a BR-XXX segue outro. Ter ambas as referências não polui o mapa, e eu como usuário, acho extremamente útil. Além do mais omitir informação para deixar o mapa mais limpo não é o procedimento adequado, é etiquetar para o renderizador. O renderizador é que decide se mostra uma, duas ou mais referências. O termo coincidente, apesar de ser a denominação oficial, pode estar causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve ser ref=RSC-153;RSC-287. Não. O significado é este mesmo, veja aqui http://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes Rodovia Coincidente, levando um C adicional no código, como MGC ou RSC. A BR-040 e a BR-262 coincidem em certos trechos no anel rodoviário de BH, mas não estão relacionadas como rodovias coincidentes. Ficaria inconveniente etiquetar esse trecho como ref=BR-153;BR-287;RSC-153;RSC-287. É o que temos feito e não vejo problema algum nisto. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
2015-02-13 21:02 GMT-02:00 A. Carlos anorcar...@hotmail.com: Já existe Rodovias municipais hoje com 3 letras na REF e 4 digitos no numeral, com o (-) são 8 Caracteres, Não sei quanto as outras plataformas, mas nos GPS Garmin (com o Mkgmap) não sei se aceita mais que 7 caracteres. Tem também as rodovias estaduais de acesso em Minas, com 3 letras e 4 números. http://www.openstreetmap.org/#map=15/-19.7227/-43.6667 Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Pistenkarte für Garmin?
Am 13.02.2015 um 14:08 schrieb Sven Geggus: gibt es einen speziellen Garmin Kartenstil für Skipisten oder alternativ einen Stil, der auch gutes Rendering für Skipisten hat. http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download findet bei Piste nur Skidea, aber die wollen vermutlich teilweise $$$ sehen (Details kenne ich aber nicht )... Jedoch gab es im Forum einen Beitrag: http://forum.openstreetmap.org/viewtopic.php?id=20409 = 2013-03-11 15:40:02 hues Stelle Garmin Skikarte der Alpen zur Verfügung... Für alpine Skifahrer habe ich eine Anleitung und Karte mit Style und Type für Garmin Geräte gebastelt. Hier eine vollständige Anleitung. http://www.wasserstoffe.de/pistemap/index.html Die fertige Karte kann als gmapsupp.img hier (Amazon Cloud) runtergeladen werden. http://ec2-23-22-231-218.compute-1.amaz … 2013.02.10 Ich wünsche allen Interessierten viel Spass. Peter = Das hört sich wirklich sehr gut an! IMHO: kann prinzipiell auch als generelle Anleitung zur Selbsterstellung von Garminkarten durch Laien verwendet werden! Weitere Dinge zu finden via Tante Gx: http://forum.openstreetmap.org/viewtopic.php?pid=285552 Index users: Germany Loipenkarte für Garmin und QLandkarte http://forum.openstreetmap.org/viewtopic.php?id=20040 Index users: Germany Skitouren, MTB, Langlauf = 2. Seite ist interessant http://wiki.openstreetmap.org/wiki/User:Petrovsk/My_Garmin_map_styles Da gibt es auch Styles und Typ-Files für Ski! http://pinns.co.uk/osm/garmin.html Tools für Garmins und auch Doku zum TYP-File-Format, etc. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Carlos Acho este e por compilador, ou por stylesheet, algum que compilando mapas para GPS pode confirmar isso. Também pode ser que o firmware dentro GPS cortando o ref, se este e caso preciso ver com o fabricante (Garmin). Pelo o validador brasileiro do JOSM, LLL- e valido, também tem valido LL-NNN/NNN que dar 10 letras (este e caso no algum estaduais no SP Para nao ha problemas aqui no Brasil, precisamos ate 10 caracteres no ref Aun Johnsen On Feb 13, 2015, at 20:02, A. Carlos anorcar...@hotmail.com wrote: Já existe Rodovias municipais hoje com 3 letras na REF e 4 digitos no numeral, com o (-) são 8 Caracteres, Não sei quanto as outras plataformas, mas nos GPS Garmin (com o Mkgmap) não sei se aceita mais que 7 caracteres. ___ Anor C. A. de Souza Concórdia SC 49-8808-4963 From: li...@gimnechiske.org Date: Fri, 13 Feb 2015 19:45:15 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Prioridades em rodovias com mais de uma ref= No meu opinião, o ref=RSC-xxx;BR-xxx somente se as placas no BR mesmo tem o ref RSC, se as placas e com o ref BR, basta ref=BR-xxx;RSC-xxx (como e o situação na minas pelo que observei e pelo que evidencias que conheço no Mapillary com placas BR alas ref=BR-xxx;MGC-xxx) Sobre nome do rodovia no trechos individuais, prefiro ter somente nome do rodovia no relação, e no cada trecho usar o nome local do trecho, ou deixa sem nome. Pelo que saiba não dar erro no camada noname porque nome ja tem no relação. Também renderizadores e roteadores deve pega nome do relação. Aun Johnsen On Feb 13, 2015, at 19:24, Gerald Weber gwebe...@gmail.com mailto:gwebe...@gmail.com wrote: Os códigos das rodovias são excludentes, em cada trecho. Ou é BR ou é RSC. É redundante colocar os dois códigos, pois TODAS as RSC (antigas RST) pertence ao trajeto planejado da BR. Não se perde informação alguma deixando o código da BR fora dos trechos da RSC, e o mapa fica mais limpo. Sempre que eu vejo uma RSC, eu sei que ela faz parte do trajeto planejado de uma BR. Caso contrário, seria ERS ou VRS. Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos ambos as referências no trecho. Depois da discussão anterior fica assim para mim ref=RSC-XXX;BR-XXX significa que RSC-XXX segue o mesmo trajeto de BR-XXX ref=RSC-XXX (somente) significa que a RSC-XXX segue um trajeto mas a BR-XXX segue outro. Ter ambas as referências não polui o mapa, e eu como usuário, acho extremamente útil. Além do mais omitir informação para deixar o mapa mais limpo não é o procedimento adequado, é etiquetar para o renderizador. O renderizador é que decide se mostra uma, duas ou mais referências. O termo coincidente, apesar de ser a denominação oficial, pode estar causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve ser ref=RSC-153;RSC-287. Não. O significado é este mesmo, veja aqui http://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes http://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes Rodovia Coincidente, levando um C adicional no código, como MGC ou RSC. A BR-040 e a BR-262 coincidem em certos trechos no anel rodoviário de BH, mas não estão relacionadas como rodovias coincidentes. Ficaria inconveniente etiquetar esse trecho como ref=BR-153;BR-287;RSC-153;RSC-287. É o que temos feito e não vejo problema algum nisto. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-br https://lists.openstreetmap.org/listinfo/talk-br___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-it] Corsie riservate
Il 12/02/2015 10:41, Luca Sigfrido Percich ha scritto: Ciao Stefano, si, occhio che manca la p a psv. Sì, scusate il refuso. Ora ho provato ad aggiungere la modifica. Chi passasse per http://osm.org/go/xdVwFyCGW?m= a Ferrara (da via Costituzione verso viale Cavour) può vedere con OsmAnd se funziona :-) Ovviamente solo dopo che OsmAnd si aggiornerà da solo o solo dopo aver scaricato e prefabbricato la mappa per testarlo. Appena ho tempo per fare un test vi dico come va :-) Siete stati fondamentali, come sempre. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Update of german Aral petrol stations
Hi, Ich will euch nur vorschlagen, zum Abgleichen der Daten POIchecker ( http://poichecker.de/en )zu verwenden bzw es euch mal anzusehen. Grüße, Theodin Am 11.02.2015 um 16:21 schrieb Knut Büscher: Hi, I'd like to inform you that we are planning to *update the german Aral petrol stations* using a semi-automated process. *Why are we doing this?* BP, owner of the brand Aral, is offering their latest german petrol station coordinates and additional data for free. The data of approx. 2.350 german Aral petrol stations is made available to the public under the *Open Database License (ODbL)*. The data set is available for download at navads.nl, the only official supplier of BP petrol stations data. The data set contains *coordinates *collected and owned by BP and *additional data* (name, address, phone, opening hours and more) suitable for existing OSM tags. Useful additional information like opening hours can now be added to the corresponding OSM objects. *W**hat are we doing?* The goal is to match OSM's existing german Aral petrol stations with the latest data made available by the petrol station operator, then add missing petrol stations and add additional tags to existing stations. The process will only use common, existing tags. So it's not a bulk import, but a _rule-based semi-automated update process_. Not to falsify existing OSM content is the superior requirement. *Where is the data we use and what about the license?* *Data source site*: http://base.navads.eu/bpxml/ CSV dataset column description: http://base.navads.eu/bpxml/bp_petrol_stations_columns_documentation.csv *Data license*: http://opendatacommons.org/licenses/odbl/ ODbL Compliance verified: yes *Mirror* (manually updated): http://arnulf.us/BPXML Currently, the germany.osm file contains approx. 1.930 OSM objects tagged with amenity=fuel and name ilike '%aral%'. So the initial estimate is to _add approx. 420 Aral petrol stations_ (as new OSM objects or by editing existing OSM objects). * **Will this be a one-time update?* The downloadable BP petrol station file containing all Aral petrol stations in Germany will be updated occasionally. When leaving an email address for download, an email will be sent every time this csv file is updated. The update process might be executed every time the csv file is updated, depending on the amount of changes that were detected in comparison to the required update effort. So there's a good chance to keep all german Aral petrol stations in OSM up-to-date by running this process occasionally. *Where's the import page?* Information can also be found at the *import page* https://wiki.openstreetmap.org/wiki/Updating_german_Aral_petrol_stations *Who is working on it?* Our *team* consists of BasNavads (Bas van Kempen, NavAds B.V., Netherlands) Knutb (Knut Büscher, gb consite GmbH, Germany) Seven (Arnulf Christl, Metaspatial, Germany) Best regards, Knut Büscher Schnell und günstig den Standort seines Geschäfts analysieren“ *Financial Times Deutschland http://www.standortanalyse.biz/files/FTD-enable-20100601-Seite-22.pdf* über den „Online Standortcheck“, März 2010 Der Online Standortcheck http://www.geobusinessaward.org/GBA_2010.php Der Online Standortcheck http://www.de.o2.com/ext/o2/wizard/index?page_id=16979 Der Online Standortcheck http://www.imittelstand.de/themen/presse.html?boxid=489558 *Gewinner des GeoBusiness AWARD 2010* http://www.geobusinessaward.org/GBA_2010.php *Gewinner des o2-Gründerwettbewerbs 2011 * http://www.telefonica.de/ext/o2/wizard/index?page_id=16979 *Best of 2012 2013 - Innovationspreis IT der Initiative Mittelstand* http://www.imittelstand.de/themen/presse.html?boxid=489558 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Estava evitando comentar sobre esse assunto porque dificilmente mapeio rodovias, não dirijo, não uso GPS veiculares etc. Mas no meu entendimento, se o Garmin tem a limitação de caracteres no campo ref, o compilador deve realizar a alteração no momento da compilação. []s Em 13/02/2015 21:09, Lists li...@gimnechiske.org escreveu: Carlos Acho este e por compilador, ou por stylesheet, algum que compilando mapas para GPS pode confirmar isso. Também pode ser que o firmware dentro GPS cortando o ref, se este e caso preciso ver com o fabricante (Garmin). Pelo o validador brasileiro do JOSM, LLL- e valido, também tem valido LL-NNN/NNN que dar 10 letras (este e caso no algum estaduais no SP Para nao ha problemas aqui no Brasil, precisamos ate 10 caracteres no ref Aun Johnsen On Feb 13, 2015, at 20:02, A. Carlos anorcar...@hotmail.com wrote: Já existe Rodovias municipais hoje com 3 letras na REF e 4 digitos no numeral, com o (-) são 8 Caracteres, Não sei quanto as outras plataformas, mas nos GPS Garmin (com o Mkgmap) não sei se aceita mais que 7 caracteres. *___* *Anor C. A. de Souza Co* *ncórdia SC * 49-8808-4963 -- From: li...@gimnechiske.org Date: Fri, 13 Feb 2015 19:45:15 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Prioridades em rodovias com mais de uma ref= No meu opinião, o ref=RSC-xxx;BR-xxx somente se as placas no BR mesmo tem o ref RSC, se as placas e com o ref BR, basta ref=BR-xxx;RSC-xxx (como e o situação na minas pelo que observei e pelo que evidencias que conheço no Mapillary com placas BR alas ref=BR-xxx;MGC-xxx) Sobre nome do rodovia no trechos individuais, prefiro ter somente nome do rodovia no relação, e no cada trecho usar o nome local do trecho, ou deixa sem nome. Pelo que saiba não dar erro no camada noname porque nome ja tem no relação. Também renderizadores e roteadores deve pega nome do relação. Aun Johnsen On Feb 13, 2015, at 19:24, Gerald Weber gwebe...@gmail.com wrote: Os códigos das rodovias são excludentes, em cada trecho. Ou é BR ou é RSC. É redundante colocar os dois códigos, pois TODAS as RSC (antigas RST) pertence ao trajeto planejado da BR. Não se perde informação alguma deixando o código da BR fora dos trechos da RSC, e o mapa fica mais limpo. Sempre que eu vejo uma RSC, eu sei que ela faz parte do trajeto planejado de uma BR. Caso contrário, seria ERS ou VRS. Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos ambos as referências no trecho. Depois da discussão anterior fica assim para mim ref=RSC-XXX;BR-XXX significa que RSC-XXX segue o mesmo trajeto de BR-XXX ref=RSC-XXX (somente) significa que a RSC-XXX segue um trajeto mas a BR-XXX segue outro. Ter ambas as referências não polui o mapa, e eu como usuário, acho extremamente útil. Além do mais omitir informação para deixar o mapa mais limpo não é o procedimento adequado, é etiquetar para o renderizador. O renderizador é que decide se mostra uma, duas ou mais referências. O termo coincidente, apesar de ser a denominação oficial, pode estar causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve ser ref=RSC-153;RSC-287. Não. O significado é este mesmo, veja aqui http://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes Rodovia Coincidente, levando um C adicional no código, como MGC ou RSC. A BR-040 e a BR-262 coincidem em certos trechos no anel rodoviário de BH, mas não estão relacionadas como rodovias coincidentes. Ficaria inconveniente etiquetar esse trecho como ref=BR-153;BR-287;RSC-153;RSC-287. É o que temos feito e não vejo problema algum nisto. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-be] roadsign plugin adapted for Belgium
On 2015-02-13 18:46, Karel Adams wrote : On 13-02-15 17:03, Jo wrote: Do we have car sharing traffic rules in Belgium? Op zijn minst bestaan er gereserveerde parkeerplaatsen. Voorbeeld aan station Nekkerspoel (Ontvoeringsplein). https://www.google.be/maps/@51.029946,4.489369,3a,30y,106.71h,86.96t/data=!3m4!1e1!3m2!1sJ2aKjl84Hyve3lEwG3UrVA!2e0?hl=nl Nos avans chal on sistime wice qui dès dgins avou ine carte polèt apicî ine vwètûre https://www.google.be/maps/@50.536283,5.633851,3a,16.7y,294.12h,85.45t/data=%213m4%211e1%213m2%211s5PcVTon_HQPl6juVAUdvJw%212e0?hl=en qui passe èt qu'a ine carte avou, més dj' n' a måy polou trover dès fwért djusses tags http://www.openstreetmap.org/node/1666772596 po mète çoula so OSM. 2015-02-13 14:56 GMT+01:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: 2015-02-11 16:17 GMT+01:00 Sander Deryckere sander...@gmail.com mailto:sander...@gmail.com: I tried it a bit, and I do have some concerns with both the mapping plugin and the style JOSM uses. First, I think that a traffic sign should only have tags like traffic_sign=BE:C21[7] and no tags like maxweight=7 Those legal implications of traffic signs should stay on way segments IMO. Fully agree with you, atm you can get the effect you want by ticking or unchecking the tick box. Then I've always had problem with tagging variable speed limits (f.e. those dynamic zone-30 signs). When mapping signs, there should be a clear difference between the variable sign and the fixed sign, and that setting should also apply to the tags on the way segments. same here Since we're tagging directions on road pieces too, allowing direction signs (f.e. F29) should also be possible. It's a matter of adding it to the XML file. Not hard to do, but it hadn't been high on my priority list. The icons are already present in the plugin's image files. One of the reasons I hadn't added them yet (apart from lack of time), is that I'm concerned they will take up a lot of space, so the plugin should be changed and have tabs for categories of signs. Now, wrt the specific Belgian case, I've also seen a few mistakes, though not that many, since the plugin isn't very usable before solving the above. C9 is translated to moped=no on the wiki, while it's mofa=no on the plugin. I know the difference is very fuzzy (and the relation to class A and B too), but we should at least use a uniform tagging. C9 seems to be meaningless if Class A or B are not mentioned. Changed to moped. C23 is translated to goods=no on the wiki, and hgv=no on the plugin, again, the difference is rather fuzzy. added both C24a and C24b are both tagged as hazmat=no on the plugin, again a difference with the wiki, and I'm not sure what the hazmat_ADR_tunnel sign is. conformed to the wiki, even though no information about access:explosives can be found there Sign combinations (like C5+C7) also aren't available in the plugin. Didn't readily know what to do with those. Added them now No-stopping signs are missing from the plugin, and no-parking signs have no tags attached (parking:lanes:right=no would be the default tag I guess). Added, it's work in progress. I skipped the ones I didn't feel sure enough about. The F1 sign (without buildings background) is deprecated and all need to be replaced against June 1st (see http://www.nieuwsblad.be/cnt/dmf20141120_01386508 as example), I don't think the plugin will be production-ready against that time. So I don't think it's worth to include the sign (at least not with that graphic). Leaving it for the time being. Feel free to contribute a better graphic for F1a. F9 should be translated to motorroad=yes instead of motorway=yes changed The F17 sign contains some strange defaults (conditional access restrictions?) copy pasted from wiki, I'll remove them. I didn't really check the validity of sub-signs, as I've often found sub-signs very confusing in real life. +1 Thanks!!! Jo * Dutch - detected * English * French * Russian * English * French * Russian javascript:void(0); ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] Osmose
Le 9 février 2015 16:03, David Crochet david.croc...@free.fr a écrit : En toute logique, lors du passage de 60 à 50, dans la théorie, il n'y a aucun panneau à changer puisque c'est le panneau d'entrée de l’agglomération et de sortie de l'agglomération qui font office de limite légale. Sauf justement quand sur le même support d'entrée d'agglomération on trouve un panneau d'interdiction indiquant le 70 (cas encore fréquent sur les départementales traversant des bourgades alignant quelques maisons le long de la voie et où le reste de la commune ce sont des fermes isolées autour mais accessibles uniquement par des petites routes tertiaires ou quand le principal quartier centre n'est pas traversé mais juste longé par la départementale): Cas fréquent aussi sur les entrées d'agglomération importantes sur les rocades ou bretelles de raccordement des nationales ou voies express intercités. La limitation du panneau d''entrée d'agglomération n'est effective QUE par défaut d'une autre indication contraire sur le support. Les situations sont tellement nombreuses que le panneau d'agglomération ne suffit plus (et les touristes qui circulent en France n'apprécient pas de se voir verbaliser alors qu'ils n'ont vu aucun panneau explicite de limite de vitesse et ne suivent pas l'actualité française). Bref les communes ajoutent des panneaux donnant la vitesse même si c'est le 50. De même les autoroutes affichent le panneau 130 à l'entrée (avec aussi sur le support le détail pour les vitesse des poids lourds et les réductions à 110 en cas de précipitation. Sinon une fois rentrés chez eux, ils obtiennent facilement de leurs tribunaux locaux l'annulation des amendes car la France est jugée coupable de défaut d'information suffisante et les communes en sont pour leur frais (sans compter que les communes peuvent aussi être condamnées à payer des dommages et réparations de préjudice sur les désagrément subis en France pendant leur voyage). Cela arrive même pour des amendes aux conducteurs français qui les font annuler en France pour le même motif de défaut d'information suffisante. (En plus les collectivitéés ne touchent presque rien des amendes collectées par l'Etat, même quand il y a des panneaux explicites payés par les collectivités). Donc effectivement, changer une limite de vitesse légale nationale coûte cher aux collectivités qui doivent changer de grosses séries de panneaux (plusieurs centaines d'euros par panneau mais les normes à respecter sont compliquées et font monter les prix, plus les frais de pose et les heures de travail des employés ou les factures des fournisseurs de services) Elles préfèrent anticiper les problèmes et fixer elles-mêmes les limites selon leur propre calendrier et ne pas subir le changement inopiné par une loi nationale (ce qui arrive de plus en plus souvent et avec un calendrier très serré souvent même de moins d'un an : par exemple récemment concernant les journées scolaires et la difficulté à trouver des personnels pour juste une demi-journée par semaine mais aucun moyen fourni, ou encore la suppression des taxes professionnelles locales et tout ce qui touche aux normes de construction et de sécurité des bâtiments, et celles des zones à risque, inondables, submersibles, sismiques, ou voisines de certaines installations industrielles, ou la refonte du recyclage, la remise aux normes des cuisines, et tous les transferts de charge imposés par l'Etat aux collectivités, ou les changements de règles de répartition des dotations de l'Etat...). Les petites communes ou les communes résidentielles denses sans emploi locaux (avec des besoins sociaux énormes) ne peuvent plus suivre et ne veulent pas s'endetter ou monter leurs impôts locaux. Tant pis si la loi change et réduit la vitesse en ville de 60 à 50, il y a encore plein d'endroit où c'est indiqué le 70 ou le 60 et ça ne change pas tant que les résidents n'obtiennent pas une décision du conseil municipal entérinant la baisse de ces limites. (parfois ils obtiennent aussi la hausse aussi suite à des aménagements de protection pour les riverains: passages piétons avec feux et îlots, rond-point, passerelles piétons ou souterrains routiers, barrières ou glissières de sécurité le long des voies, murs antibruit, réduction du nombre de voies de circulation pour aménager des trottoirs plus large et des plantations ou emplacements de stationnement, interdiction seulement des poids lourds...). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] 奈良オープンデータソン(2/21)のご案内
石塚です。 インターナショナルオープンデータデイにあわせ、Code for Nara で 奈良市中心部の「ならまち」を対象に、OpenStreetMapマッピングと、JAUNTFUL 等を使った活用体験イベントを開催します。 奈良市、あるいは、ならまちに興味ある方の参加をお待ちしています。 インターナショナルオープンデータデイ 2015 第２回奈良オープンデータソン 日時 ： 2015年2月21日（土）13時-18時 場所 ： 会場：奈良女子大 奈良町セミナーハウス 申込 ： http://code4nara.doorkeeper.jp/events/20396 参考 ： https://www.facebook.com/events/487835681355962/ ※ 古い町屋での開催ですので防寒対策もお願いします！ -- Yasushi Ishizuka ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-de] Engel für die FOSSGIS-Konferenz 2015 gesucht
wn reader wnrea...@gmail.com wrote: Wer Engel sein möchte, registriert sich im Engelsystem [4] und bucht eine passende Arbeitsschicht. Ich bin eigentlich jemand, der so ziemlich auf jeder besuchten Veranstaltung auf-, abbauen oder sonstwie hilft, sofern erforderlich. Aber das hier begreife ich einfach nicht: Warum muss man heutzutage für jeden Furz einen zusätzlichen (später möglicherweise unbeaufsichtigt dahingammelnden und meist unlöschbaren) Account nebat zusätzlicher E-Mail Adresse anlegen und sich die beiden zugehörigen Passwörter merken? Ich möchte nicht wissen, wie viele Helfer man dadurch verliert. Es ginge doch auch anmeldefrei, z.B. mit einem Etherpad. Übrigens: Der Link funktioniert nicht: http://www.fossgis.de/konferenz/2015/anmeldung/helfer.fossgis.de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos ambos as referências no trecho. Por favor, me mostre um caso em que isso ocorre. Depois da discussão anterior fica assim para mim ref=RSC-XXX;BR-XXX significa que RSC-XXX segue o mesmo trajeto de BR-XXX ref=RSC-XXX (somente) significa que a RSC-XXX segue um trajeto mas a BR-XXX segue outro. Ter ambas as referências não polui o mapa, e eu como usuário, acho extremamente útil. Se todas as RSC coincidem com BR, é completamente inútil Além do mais omitir informação para deixar o mapa mais limpo não é o procedimento adequado, é etiquetar para o renderizador. O renderizador é que decide se mostra uma, duas ou mais referências. Não estou omitindo informação alguma, a menos que exista uma BR-XXX ter um trajeto diferente de uma RSC-XXX. Peço enfaticamente que me mostre um caso em que isso ocorre na prática (qual trecho de qual rodovia?). O termo coincidente, apesar de ser a denominação oficial, pode estar causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve ser ref=RSC-153;RSC-287. Não. O significado é este mesmo, veja aqui http://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes Rodovia Coincidente, levando um C adicional no código, como MGC ou RSC. A BR-040 e a BR-262 coincidem em certos trechos no anel rodoviário de BH, mas não estão relacionadas como rodovias coincidentes. É o que eu estou dizendo. Esses trechos da BR-040 e a BR-262 são rodovias que coincidem, mas não são coincidentes. Ficaria inconveniente etiquetar esse trecho como ref=BR-153;BR-287;RSC-153;RSC-287. É o que temos feito e não vejo problema algum nisto. Não estou convencido de que isso não é redundante (por favor me convença, me mostrando um contra-exemplo). abraço Gerald -- Flávio Bello Fialho ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-ja] 複数の信号機があるjunctionへのリレーション定義について
いいだです。 ページの翻訳をしました。 https://wiki.openstreetmap.org/wiki/JA:Proposed_features/traffic_signals_group ページにも明記されていますが、日本における信号機のレンダリング (複数の信号機があったとしても、1つの交差点へのレンダリングは1回) に対応することが目的のひとつとなっています。 ぜひぜひご意見くださいませ (*´ω｀*) 2015年2月12日 15:50 Satoshi IIDA nyamp...@gmail.com: いいだです。 同一住所の矩形ブロックの四隅の電信柱に付いている信号機に表記 されている認識です。 なるほどー！ では、あれは信号機の名前という扱いではなく、あくまで、 その住所の名称をあらわす看板のかわり、というかんじなのですね。 (交差点(junction)の名前は別に存在する) それであれば、まさにこのリレーションの出番になろうかと思いますので、 混乱はなさそうに思えます。 2015年2月11日 22:43 Hiroshi Miura(@osmf) miur...@osmf.jp: 三浦です。 On 2015年02月10日 08:57, Satoshi IIDA wrote: いいだです。 個人的には、北海道でよくある例 (1つの交差点にある信号機がそれぞれの名称を持っている。場合によっては1つの信号機の表と裏で2つの名前がある) に対応できるか？という観点があります。 地元にそういう交差点があるかたが、その交差点をどのような名称で認識・呼称しているか、教えていただけると嬉しいです。 良く、札幌に訪問していた時には、信号の表記の「南５西３」等は、 交差点の名称ではなく、ブロック表記と認識していました。 同一住所の矩形ブロックの四隅の電信柱に付いている信号機に表記されている 認識です。 もし交差点名称としてしまうと、４つの交差点が同一の名称になってしまう、＆ 一つの交差点が４つの名称を持つ、ので、おかしいですよね。 参考として、Yahoo知恵袋にそんな関連の質問がありました。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1383614183 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk-be] FW: Nieuw lid
Bedankt ! Van: Sander Deryckere [mailto:sander...@gmail.com] Verzonden: donderdag 12 februari 2015 16:34 Aan: OpenStreetMap Belgium Onderwerp: Re: [OSM-talk-be] FW: Nieuw lid Iedereen doet dit wat op zijn eigen manier. Meestal map ik het als een gebied met een tag (landuse=industrial, amenity=school, ...). Dat gebied krijgt dan ook bepaalde tags, zoals een naam, en eventueel adres- en contactgegevens (als een volledige firma dat adres krijgt). In het gebied kan je dan de andere zaken tekenen (grasvelden, gebouwen, ...). Gewoon door de geografische positie is het duidelijk dat die gebouwen tot het gebied behoren. Dat het gebied over een openbare weg gaat is volgens mij geen probleem. Als dit echt een brede weg is kan je het nog altijd als twee gebieden tekenen. Zie enkele voorbeelden: http://www.openstreetmap.org/way/301630280 http://www.openstreetmap.org/way/174891110 http://www.openstreetmap.org/relation/4175509 mvg, Sander Op 12 februari 2015 16:23 schreef Marc Deroep marc.der...@telenet.be: Hallo, Is er ergens een goed voorbeeld te vinden hoe ik een ingewikkeld samenhorend complex moet mappen bestaande uit verschillende gebouwen, parkings, pleinen, e.d. aan weerszijden van een openbare weg. Met dank, Marc ___ 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: [Talk-de] Engel für die FOSSGIS-Konferenz 2015 gesucht
Hallo Volker, die Adresse ist http://helfer.fossgis.de und dann Register Die Emailadresse und möglichst auch eine Handynummer ist dann nützlich, wenn wir mit dir kommunizieren wollen. Für mehrere Passwörter merken gibt es Programme, z.B. keepass oder 1Password...oder hundert andere. solltest du dir mal anschauen. Mfg Marc Tirkon mailto:tirko...@yahoo.de 14. Februar 2015 03:41 Ich bin eigentlich jemand, der so ziemlich auf jeder besuchten Veranstaltung auf-, abbauen oder sonstwie hilft, sofern erforderlich. Aber das hier begreife ich einfach nicht: Warum muss man heutzutage für jeden Furz einen zusätzlichen (später möglicherweise unbeaufsichtigt dahingammelnden und meist unlöschbaren) Account nebat zusätzlicher E-Mail Adresse anlegen und sich die beiden zugehörigen Passwörter merken? Ich möchte nicht wissen, wie viele Helfer man dadurch verliert. Es ginge doch auch anmeldefrei, z.B. mit einem Etherpad. Übrigens: Der Link funktioniert nicht: http://www.fossgis.de/konferenz/2015/anmeldung/helfer.fossgis.de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de wn reader mailto:wnrea...@gmail.com 13. Februar 2015 20:12 Liebe Freunde und Teilnehmer der FOSSGIS-Konferenz 2015, die Vorbereitungen der FOSSGIS-Konferenz laufen auf Hochtouren, die Teilnehmer-Anmeldung läuft [1], das Programm steht [2], das Catering ist geordert. Die Teilnehmeranmeldezahlen bewegen sich auf ähnlichem Niveau wie 2014. Das freut uns sehr. Die Vorbereitung und Durchführung der Konferenz braucht viel Power von möglichst vielen Menschen, diese Menschen nennen wir Engel, es sind die, die sich während der Konferenz etwas Zeit nehmen und einen Helferjob übernehmen. Wir freuen uns, wenn du sowohl als Teilnehmer, als auch als Helfer zur FOSSGIS kommen. Es ist sicherlich möglich einen Vortragstrack zu verfolgen und gleichzeitig bei der Videoaufzeichnung zu helfen z.b. die Kamera zu führen. Das Catering soll geschmeidig laufen, besonders bei großem Andrang. Hier freuen wir uns über Helfer beim Vorbereiten, Austeilen und Aufräumen. Am Welcome Desk kann bei der T-Shirt-Größenfindung oder als Springer unterstützt werden. Auf der Wikiseite zum Helfersystem [3] finden Sie weitere Informationen.Wer Engel sein möchte, registriert sich im Engelsystem [4] und bucht eine passende Arbeitsschicht. Für Fragen, die im Wikitext [3] nicht beantwortet sind, stehen im System die Erzengel bereit (Ask an archangel). Freundliche Grüße FOSSGIS-Konferenz-Oranisationsteam Links: [1] Anmeldung zur Konferenz http://www.fossgis.de/konferenz/2015/anmeldung/ [2] Programm http://www.fossgis.de/konferenz/2015/programm/ [3] Wikiseite Engelsystem http://www.fossgis.de/wiki/Konferenz_2015/Helfer [4] Engelsystem http://helfer.fossgis.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
