Re: [Talk-de] SotM.us güstige Flüge
On Thursday 19 February 2015, Peter Barth wrote: dass sich der Termin zig mal verschoben hat, hab ich mitbekommen. Aber woher hast du die Info, dass es gar keine SOTM geben wird? http://wiki.osmfoundation.org/wiki/Board/Minutes/2015-02-16 Dass man solche Informationen quasi Im Keller hinter einer Tür mit der Aufschrift 'Vorsicht, bissiger Leopard!' findet ist natürlich alles andere als eine kommunikative Meisterleistung... Wäre ja eigentlich sinnvoll, wenn es dann auch wieder 'ne SotM-EU gäbe, aber natürlich nicht wieder in Deutschland. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-es] Red Natura 2000
Buenas noches, Acerca del punto referido al Aspecto Legal: Los datos geográficos de la red Natura 2000 [1] están sometidos a la Directiva INSPIRE, por lo que son públicos. El responsable de publicar y compartir esos datos al ciudadano en España es el Ministerio de Agricultura y Medio Ambiente (MAGRAMA) Las condiciones que veo más importantes a tener en cuenta con los datos publicados por el MAGRAMA [1] son: Los contenidos, organización y elección de enlaces de las páginas de www.magrama.gob.es http://www.magrama.gob.es han sido seleccionados y coordinados por el Ministerio de Agricultura, Alimentación y Medio Ambiente. Esta información puede ser utilizada en parte o en su integridad, sin necesidad de autorización expresa, siempre que se cite la fuente de los documentos objeto de la reutilización, con excepción de los contenidos sobre los que existan derechos de propiedad intelectual o industrial por parte de terceros. En caso de duda consultar a las Oficinas de Información mencionadas anteriormente. No se podrá indicar, insinuar o sugerir que los órganos administrativos, organismos o entidades del sector público estatal titulares de la información reutilizada participan, patrocinan o apoyan la reutilización que se lleve a cabo con ella. Se conservarán y no se alterarán ni suprimirán los metadatos sobre la fecha de actualización y las condiciones de reutilización aplicables incluidos, en su caso, en el documento puesto a disposición para su reutilización por la Administración u organismo del sector público Podéis ver el resto de condiciones en [2] Es decir, solo hay que citar la fuente y la fecha de los datos. Un saludo, Alejandro Zappala [1] http://www.magrama.gob.es/es/biodiversidad/servicios/banco-datos-naturaleza/informacion-disponible/rednatura2000_descargas.aspx [2] http://www.magrama.gob.es/es/atencion-al-ciudadano/aviso-legal.aspx El 17/02/15 a las 16:03, Manu El escribió: Hola compañeros: Vuelvo a reabrir este tema. Allá por 2012-2013 ya se trató varias veces con hilos titulados Red Natura 2000 (iniciado por mi) Parques Naturales y Parques Naturales (RESPUESTA MINISTERIO). Aparentemente el asunto quedó parado después de una reunión con alguien del Ministerio de Medio Ambiente de la que yo no tengo información concreta. En el wiki de OSM hay una página al respecto con algo de info sobre esta iniciativa.[1] La razón de reflotar este asunto es que como miembro de Wikimedia España (capítulo de la Fundación Wikimedia) estamos organizando un concurso fotográfico que se desarrollará el mes de junio llamado Wiki Loves Earth. Hemos considerado recurrir a los Lugares de Importancia Comunitaria (LICs) como espacios que entrarán dentro del concurso. Los LIC son, junto a las Zonas de Especial Protección para las Aves, los espacios que integran la Red Natura 2000. Los LIC son unos 1500 para toda España, repartidos por todas las comunidades autónomas y paisajísticamente muy variados (desde lugares de alta montaña a espacios submarinos). Podéis dar un vistazo a los listados por comunidades autónomas que hemos venido realizando este último mes en Wikipedia.[2] ¿Qué tiene que ver esto con OSM? El objetivo del concurso es documentar mediante fotografías parte del patrimonio natural de España (el concurso es internacional, organizado en otros países por otros capítulos de la Fundación Wikimedia). Aspiramos a recopilar fotografías de muchos espacios (por eso hemos escogido la figura del LIC), algunos muy conocidos, muy turísticos, pero otros no tanto. Se hace indispensable disponer de una ayuda cartográfica que permita a los fotógrafos participantes moverse por los espacios y tomar sus instantáneas. Como podéis ver en los anexos, disponemos de las coordenadas ) de todos los espacios, pero evidentemente un espacio natural es un polígono, no un punto. Como ya se comentó en su momento, hay cartografía tanto del Ministerio como de la Unión Europea sobre los espacios Red Natura 2000. Nuestra inquietud como wikipedistas (y la mia también como mapeador de OSM) sería incorporar esos datos a OSM para beneficio mutuo. Las consideraciones son las siguientes: 1º) Aspecto legal. Aquí nos quedamos en 2013. Determinar si los datos espaciales publicados bien por el Ministerio[3] o por la Agencia de Medio Ambiente de la Unión Europea[4] han sido publicados con una licencia/condiciones de uso compatibles con OSM. En caso contrario, conseguir que sí lo estén. Desde Wikimedia España, como asociación que está funcionando y que cuenta con el respaldo de la Fundación Wikimedia, trabajamos muy activamente el área de liberación de datos y ya hemos tenido experiencias exitosas con algunos organismos. No tendríamos problema en reunirnos con quien sea necesario para aportar seriedad a la petición que se haga apoyando la petición de OSM. 2º) Aspecto técnico. Ejecutar la importación. Hay tiempo hasta junio, por
Re: [Talk-it] civici di ferrara - adesso open
L'import lo potrei preparare io (con calma) ma le verifiche sul campo le deve fare qualcun altro. Per quelle ci penso io. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] civici di ferrara - adesso open
2015-02-19 15:03 GMT+01:00 Stefano Droghetti stefano.droghe...@gmail.com: Il 19/02/2015 13:00, Simone Cortesi ha scritto: Ciao, segnalo che ora i civici di Ferrara adesso sono open: http://www.comune.fe.it/index.phtml?id=3513 un grazie a Piergiorgio Cipriano per il lavoro dietro le quinte... :) Spettacolare! Grazie a tutti. Io non ho mai fatto un import in vita mia: qualcuno si vuole occupare di questo import? Volendo posso provare io ma non so fare :-) L'import lo potrei preparare io (con calma) ma le verifiche sul campo le deve fare qualcun altro. Ciao, Andrea ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] Comment tagger un abattoir municipal
Comme le cas des noms des boulangeries et WC a été débattu récemment ( http://gis.19327.n5.nabble.com/Changements-massif-sur-les-noms-generiques-de-shop-et-amenity-td5828133.html ), je ne vois pas pourquoi un abattoir municipal ferait exception. La clé name n'est pas forcément adéquat ici, et le nom (abattoir municipal) devrait à mon sens (et d'après plusieurs intervenants de la discussion ci-dessus) plutôt être décrite par les autre tags. Une clé loc_name me paraît petu-être plus adéquat. D'ailleurs la discussion sur les boulangeries me fait aussi poser la question pour un temple que j'ai rencontré récemment, simplement appelé Temple de Thonon. Cependant cette dénomination n'est pas présente sur place. Dans ce genre de cas, faut-il mettre une clé name=* ou même loc_name=* ou c'est quelque chose de dispensable ? Cordialement, Félix Marty Le jeudi 29 janvier 2015, 23:33:05 althio a écrit : Je rajouterais : building=public ou building=civic et puis aussi owner=ville de Lannion name=abattoir municipal organic=yes ;) ___ 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] Incluindo Hot Spots Wi-fi
Se estiverem, haverá alguma renderização? Referências: - Pt-br:Key:internet_access http://wiki.openstreetmap.org/wiki/Pt-br:Key:internet_access - Tag:internet_access=wlan http://wiki.openstreetmap.org/wiki/Tag:internet_access%3Dwlan Alexandre Magno Em 19 de fevereiro de 2015 15:27, Nelson A. de Oliveira nao...@gmail.com escreveu: 2015-02-19 16:21 GMT-02:00 Marcelo Pereira pereirahol...@gmail.com: Além disso, esses pontos não estão associados a nenhuma amenity, por isso não serão renderizadas, entendi certo ? Não estão localizados em praças ou outros locais abertos? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] Aide correction d'une note de carte
Parfois certaines modifs ne sont pas détectées, ça arrive à certaines périodes de panne de serveur, ou parce que le flux de suivi des modifs a été parteillement corrompu, empêchant de marquer des tuiles comme invalides. Tu peux toujours forcer le rafraichissement d'une tuile sur un rendu basé sur Mapnik en ouvrant la tuile dans un onglet du navigateur puis modifiant l'URL en y ajoutant /dirty : tu verras alors un statut de ta demande et quelques minutes après la nouvelle tuile sera affichée quand tu rafraichis la page affichant la tuile toute seule (quelques voisines sont également raffraichies en même temps : Mapnik calcule par défaut des supertuiles de 8x8 tuiles (de 256 pixels de côté chacune, de sorte qu'il retrace une image carrée de 2046 pixels de côté, même si en suite il distribue des morceaux plus petits à la demande). Tu peux savoir où sont situées les supertuiles en regardant leurs numéros de positions X et Y : ce sont les multiples de 8 qui débute la supertuile suivante. Mapnik est réglable sur la taille de ses supertuiles, certains rendus pourraient ne pas créer de supertuiles et les dessiner juste 1 par une. C'est peu probable sur les serveurs faisant des rendus sur de larges zones contenant de nombreuses tuiles, mais ça l'est sur les zones très étendues géographiquement (faibles niveaux de zoom), qui ne sont pas non plus rafraîchies souvent (pour ces tuiles d'ailleurs, la requête en /dirty ne fait rien, Mapnik se contente d'afficher la date de la dernière mise à jour, car elles sont tellement riches en données que leur calcul prend énormément de temps et nécessite des resssources importantes en capturant les données dans une base interne de travail et travaillant ensuite par morceau ou par bandes de façon incrémentale). D'ailleurs sur les faibles zooms, la plupart des changements sont quasiment invisibles et des tas de détails sont ignorés pour faciliter le travail: Leur rendu est même simplifié, et peux même utiliser des images de fond statiques (qui seront calculées ailleurs, puis importées manuellement, et que Mapnik utilisera telles quelles : pour les lignes de côte elles provienne d'une extraction statique et il peut se passer plusieurs mois pour que les nouvelles plus précises soient prises en compte, même aux niveaux de zoom élevés où ces extractions anciennes pourraient être ignorées au profit des données venant de la base actuelle, d'autant plus que les lignes de côte sont toujours orientées avec le côté mer à droite par rapport à un parcourt vers l'avant dans le sens du tracé). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nantes-en-Rat(t)ier
Quelqu'un a créé une note pour évoquer une erreur manifeste dans un nom officiel : http://www.openstreetmap.org/note/319200 Exacement le même problème qu'à Vers-sur-Selle(s) : http://www.openstreetmap.org/relation/114372 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] roteamento na páginas principal do OSM
Pessoal, Para quem desconhece, Lua é uma linguagem de programação de scripts projetada para que sua interpretação seja de alta eficiência. Lua foi desenvolvida no Brasil (PUC-Petrobras), utilizada mundialmente e famosa pela ampla amplicação para automatizar o comportamento de personagens em jogos, o que demanda eficiência. Aqui na Petrobras a utilizamos para que os geólogos e geofísicos eles mesmos consigam automatizar fluxos de trabalho e criar fórmulas sem precisar pedir que programadores façam alterações nos programas. Artigo no Wiki: http://pt.wikipedia.org/wiki/Lua_%28linguagem_de_programa%C3%A7%C3%A3o%29 Lua é uma linguagem fracamente tipada, derivada do Pascal e com poucas estruturas de dados para conhecer, portanto fácil de aprender. []s Paulo Em 18 de fevereiro de 2015 19:32, Lists li...@gimnechiske.org escreveu: Gerald Investigei um pouco Primeiro precisamos um servidor que pode hospedar nosso OSRM, como o OSRM não aceita atualizações de crescimento precisamos um outro fonte do dados do OSM, por exemplo baixar Brasil como PBF do servidor do geofrabrik.de, e rodar o script de importação. Depende de tamanho do banco dados, mas acho que podemos rodar isso semanalmente. Segundo precisamos criar perfis de roteamento, olhei um pouco no github como eles fiz no OSRM, cada perfil e um arquivo em formata LUA, que indicando os tipos de restrições, que tipo prioridade, e penalidade por vários obstáculos. Olhei o perfil car.lua “car (fastest)” e bicycle.lua “bicycle”. Ambos dar penalidade por coisas diferente, tem obstaculos que deixar passar e que bloquear, etc. Com um pouco entendimento do LUA podemos criar perfis certos para nosso OSRM, como velocidade maxima no diferente classificações das ruas, suprefise, penalidade por semáforos, pare, dê preferencia, curvas fechadas e muito mais. Podemos sim tambem criar roteamento que evitar estradas da terra ou pedágio. Viu que pelo github, o OSRM não faz roteamento da balsas com carro, mas faz para bicicleta. Aun Johnsen On Feb 18, 2015, at 18:23, Gerald Weber gwebe...@gmail.com wrote: Conversei la no IRC, e vi que ja tem algum países oferecendo OSRM com somente dados nacionais, acho um OSRM do somente Brasil vai ser mais rápido atualizar, e se ha um servidor próprio podemos ter nosso roteamento nacional. Um OSRM-BR seria algo fantástico. Atualmente o OSRM só tem um perfil car (fastest), seria legal se tivessesmos várias opções como por exemplo para evitar (ou preferir) estradas de terra. Qual seria o caminho para se fazer isto? A instalação do software não me pareceu complicada e editar os perfís também parece bem simples. 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: [OSM-talk-fr] BANO : Reconnaissance des voies
Le 19/02/2015 00:39, « Ano59 » a écrit : Bonjour, Contribuant régulièrement dans la région NPDC, je fais partie de la mailing-list de cette région. On m'a redirigé ici afin que je puisse mettre quelques questions / suggestions concernant BANO, en particulier en ce qui concerne la reconnaissance des voies. Je vais faire ça un peu en vrac au fil des problèmes rencontrés. Déjà première suggestion : serait-il possible que BANO reconnaisse les voies OSM portant un tag name:left ou name:right ? En mappant certaines rues entre deux villes, je me suis rendu compte que le cas arrivait souvent (la rue a deux noms différents selon la ville). Ces voies ne sont pas reconnues dans BANO : au mieux seule la portion avec un seule nom est reconnue, si elle existe. En créant 2 relations associatedStreet distincte les scripts BANO retrouveront leurs petits. Dans une moindre mesure, lié au cas précédent, j'ignore si BANO reconnaît correctement des références FANTOIR multiples sur une même rue, telles que ref:FR:FANTOIR=RefX;RefY. J'ai l'impression que non, je peux me tromper. Le ref:FR:FANTOIR est à mettre dans ce cas sur chacune des relations associatedStreet, il est donc unique pour la relation. Ensuite davantage une question : pourquoi parfois certaines voies dont on indique bien la référence FANTOIR ne sont toujours pas reconnues après MAJ ? Malheureusement je n'ai pas d'exemple sous la main, j'en fournirai si j'en retrouve. C'est tout pour l'instant, merci d'avance pour d'éventuelles réponses, Cordialement, « Ano59 ». Oui, un exemple serait utile pour comprendre ce qui se passe... -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons
Pour l'INSEE on ne verra sans doute pa de mise à jour des références avant le début de l'année prochaine avec la publication du nouveau référentiel annuel. A moins qu'il anticipe et publie un addendum sur cette seule partie du référentiel. A ce moment là on verra quelle codification il va utiliser. D'ici là, les planned:ref restent car c'est le seul élément qu'on peut rapprocher facilement des décrets. D'ailleurs l'INSEE affiche encore sur son site que le canton est une division de l'arrondissement (ce qu'il n'est plus, il n'est qu'une division du département puisque nombre de nouveaux cantons sont à cheval sur deux arrondissements) : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton.htm Ca n'empêche pas les communes d'organiser les élections et les nouveaux conseillers élus de siéger et travailler dans les conseils. L'Insee de toute façon n'a jamais été très fort sur les cartes de cantons, mais il faudra bien qu'il se mette à jour lui aussi pour fournir des statistiques par canton aux départements et voir comment il peut faire la transition des données pour les rapprochements et comparaisons au moins sur 2 années. Il continuera aussi à faire sa propre codification des cantons-ou-villes dans les communes découpées puisque sur de nombreux types de données il n'y a pas de découpage plus fin que la commune entière ou la commune déléguée; la référence Insee des cantons actuels est *déjà* impropre. en de nombreux endroits. Ce qu'on a mis en planned:ref au moins correspond aux décrets et aux cantons effectifs, mais on n'a pas les pseudos-cantons de l'Insee qui sont des espèces à part, à but statistique et non électoral (mais on pourrait ajouter ces pseudo-cantons dans OSM non pas avec boundary=political + political_division=canton, mais boundary=statistical + statistical_division=canton_ville : là les ref:INSEE=* ont un sens et en garderont aussi avec la mise à jour de l'INSEE pour les cantons de mars 2015. Je trouve tout de même étrange que depuis la publication des arrêtés il y a déjà un an, l'Insee n'a rien publié en janvier sur leur codification avec sa mise à jour annuelle (peut-être qu'il attends des commandes de statiques venant des nouveaux conseils et que les départements actuels ne lui ont encore rien de mandé à ce sujet étant donné que les cantons actuels sont plus fins que les nouveaux ?). Il est possible même que l'Insee reçoive des demandes des départements pour continuer à fournir des statistiques détaillées sur les actuels cantons-ou-villes, plutôt que les nouveaux deux fois plus grands (mais je pense que les actuels vont encore être utilisés en référence car on en a encore besoin pour interpréter correctement bon nombre de textes législatifs et réglementaires qui sont basés sur les actuels cantons pour définir leur champ d'application. Et les clients de l'Insee ne sont pas que des collectivités publiques ou l'Etat et ses administrations. Le 18 février 2015 19:12, Jérôme Amagat jerome.ama...@gmail.com a écrit : J'ai fait les modif sur toute la France sur les relations des anciens cantons et nouveaux cantons. j'ai modifié boundary=political , political_division=canton , start et end_date. Je n'ai pas touchez aux ref : ni planned:ref (ref créé dans osm à partir de chose réel : département et numéro dans les décrets) ni ref:INSEE (est ce qu'il vont disparaître?). ___ 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-GB] OS OpenData now OGL
On 18/02/15 13:52, Robert Whittaker (OSM lists) wrote: In the immediate future, it won't have much effect, since we already had separate permission to use all but one of the OS Open Data products. The exception was CodePoint Open. Once OS updates their licence page (http://www.ordnancesurvey.co.uk/business-and-government/licensing/using-creating-data-with-os-products/os-opendata.html still refers to the OS OpenData Licence) then we should be able to make use of CodePoint Open too. Hallelujah! Does that mean that openstreetmap.org would finally be able to find postcodes when I type them in? The lack of reliably good results in this, is the one feature which keeps me using Google Maps much the time. Gerv ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] OS OpenData now OGL
On 19/02/15 10:58, Gervase Markham wrote: On 18/02/15 13:52, Robert Whittaker (OSM lists) wrote: In the immediate future, it won't have much effect, since we already had separate permission to use all but one of the OS Open Data products. The exception was CodePoint Open. Once OS updates their licence page (http://www.ordnancesurvey.co.uk/business-and-government/licensing/using-creating-data-with-os-products/os-opendata.html still refers to the OS OpenData Licence) then we should be able to make use of CodePoint Open too. Hallelujah! Does that mean that openstreetmap.org would finally be able to find postcodes when I type them in? Why would it make any difference? As far as I know Nominatim already uses the Codepoint Open data? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-fr] Vie et mort des magasins
Les créations/fermeture d'entreprises et leur enregistrement au RC se base sur le SIREN; les créations/fermeture d'établissements c'est le SIRET que le RC ne suit pas. La seule source possible pour les établissements serait l'Insee ou le fisc (les régimes sociaux ne sont pas vraiment concernés, du moins pas tant qu'il y a changement d'activité et de convention collective applicable au personnel. Pour certains commerces la création de l'établissement peut se faire aussi des mois avant leur ouverture, quand l'implantation des commerces est réglementée, le temps d'obtenir les autorisations... ou pas, puis de faire les travaux (qui eux aussi peuvent prendre des retards. Dans le cas des liquidations, c'est même encore plus long même si l'établissement est fermé (on ne sait pas s'il va réouvrir ni quand, ni avec quelle enseigne). Un même établissement peut aussi changer d'enseigne et avoir des services différents d'une saison à l'autre. Dans les galeries marchandes de grande surfaces, il s'ouvre aussi des commerces temporaires juste pour quelques semaines dans des locaux assez génériques ne nécessitant pas de grandes transformations (ces locuax peuvent aussi être loués comme extension temporaire d'une autre boutique ou de la grande surface pour certaines promos. Beaucoup de choses changent avant la période des fêtes et après et le reste de l'année ce sont des locaux vides. Le 16 février 2015 12:34, Christian Quest cqu...@openstreetmap.fr a écrit : Ces données proviennent de la base SIRENE de l'INSEE, donc droits réservés. C'est un des enjeux de la loi Macron, libérer ces données sur les entreprises via les greffes des tirbunaux de commerces, l'INPI et aussi l'INSEE. Ceci nous aidera mais pas forcément autant qu'on peut espérer car la création d'une entreprise et sa liquidation ne coincident pas forcément avec les ouvertures et fermetures des commerces. Il peut s'écouler du temps entre les deux. En plus une entreprise (personne morale) peut avoir de multiples établissements... l'un peut ouvrir, fermer, mais l'entreprise existe toujours... Le 16/02/2015 12:21, Tyndare a écrit : Quelle est la licence d'utilisation de ces données ? Bonjour Le 16/02/2015 11:55, David Crochet a écrit : Existe t'il l'inverse, c'est à dire l'enregistrement d'une entreprise ? Ha oui, je viens de trouver : http://www.score3.fr/liste-creations-entreprises.shtml O_o Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://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: [Talk-GB] OS OpenData now OGL
On 19/02/15 11:11, Tom Hughes wrote: Why would it make any difference? As far as I know Nominatim already uses the Codepoint Open data? Well, if it did, wouldn't it be able to find every postcode in Britain? The Results from OpenStreetMap Nominatim section of the search results often turns up results for postcodes other than the one requested. Here are some neither FreeThePostcode nor Nominatim can find: * S9 3DJ (should be Fay Crescent, Sheffield) * EN1 2EE (should be Forsyth Place, Enfield) Here are some Nominatim seems unable to find: * EN2 0QG (gives a list of results for EN2 0QP) * YO11 2TT (gives a list of results for YO11 2HD) (Incidentally, when it does find an exact match, why on earth doesn't it, you know, take the map to that location? That doesn't seem an unreasonable expectation.) Gerv ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 18.02.2015 um 23:45 schrieb Garry: - Wichtige Infos wie maxspeed sind noch lückenhaft Sehe ich weniger problematisch, oder werden kurvenreiche Strecken auch berücksichtigt? maxspeed ist für den Router *ein* Element zur Abschätzung der Durchschnittsgeschwindigkeit (die ja in der Tat in OSM nicht gemappt wird). Bei einer primary mit maxspeed=50 kann der Router annehmen dass es sich um eine innerörtliche Hauptstraße handelt und z.B. mit einer AVS von 40 km/h kalkulieren. Während außerörtliche Bundesstraßen ja eher im Bereich 70 km/h AVS liegen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 18.02.2015 um 23:45 schrieb Garry: Am 18.02.2015 um 13:06 schrieb chris66: Weitere Probleme: ... - Wichtige Infos wie maxspeed sind noch lückenhaft Sehe ich weniger problematisch, oder werden kurvenreiche Strecken auch berücksichtigt? Häufig sind doch diese nicht beschränkt, erlauben aber wegen der vielen Kurven nur geringe Geschwindigkeiten ??? es gilt in jedem Land ein generelles Maxspeed (in D außer Autobahnen) Ich versteh die Anmerkung nicht, es besteht doch nicht die Pflicht so schnell zu fahren - selbst wenn Schilder die Geschwindigkeit weiter beschränken ist die Geschwindigkeit keine Pflicht während gut ausgebaute, gerade Strecken zwar beschränkt sind, aber eine höhere Durchschnittsgeschwindigkeit erlauben. vielleicht erlauben *könnten* caronna ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Tagguer un centre de formation AFPA
amenity=training_center ? Cependant ça peut recouvrir pleins de centres de formation privés, dont bon nombre saisonniers dans des locaux génériques, qui n'ouvrent que s'ils ont des clients inscrits et des intervenants pour tenir les sesssions. L'AFPA en revanche est assez permanent même si ses formations changent. Les locaux privés (comme les centres de congrès et d'expo) peuvent aussi être loués pour des besoins publics (exemple, pour des sessions d'examen ou de concours). Les formations ne sont pas toutes non plus à but professionnel (pas de diplôme, par exemple des cours de cuisine d'une asso) Le 16 février 2015 14:26, Pieren pier...@gmail.com a écrit : Notez que vous pouvez lancer vous-même des recherches dans les archives de la liste de diffusion de plusieurs manières. L'une d'entre-elles est de taper afpa sur le Nabble de talk-fr: http://gis.19327.n5.nabble.com/France-f5380434.html On peut y voir ma réponse à cette même question en 2012. Aujourd'hui, je ne pense toujours pas que les centres de formation pour adultes doivent utiliser un tag amenity=* existant. Ca n'est pas une école classique, ça n'est pas universitaire non plus, ça n'est pas le même public ni les mêmes enseignants, ça n'est pas non plus géré par les mêmes administrations ni les mêmes ministères/budgets. Donc amha toutes les bonnes raisons pour créer un tag spécifique, distinct des amenity=school (et donc qui ne justifierait plus l'usage de school:FR) même si un sous-tag pourrait préciser les secteurs professionnels concernés. 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] BANO : Reconnaissance des voies
Bonjour, Le 19/02/2015 00:39, « Ano59 » a écrit : Déjà première suggestion : serait-il possible que BANO reconnaisse les voies OSM portant un tag name:left ou name:right ? En mappant certaines rues entre deux villes, je me suis rendu compte que le cas arrivait souvent (la rue a deux noms différents selon la ville). Ces voies ne sont pas reconnues dans BANO : au mieux seule la portion avec un seule nom est reconnue, si elle existe. En effet pour l'instant ce cas n'est pas géré, mais une autre modélisation est prise en compte dans ces situations : l'existence d'une relation associatedStreet par côté de voie, avec comme tags de la relation, un name et un ref:FR:FANTOIR. Dans une moindre mesure, lié au cas précédent, j'ignore si BANO reconnaît correctement des références FANTOIR multiples sur une même rue, telles que ref:FR:FANTOIR=RefX;RefY. J'ai l'impression que non, je peux me tromper. Non, pas de valeurs multiples pour le tag Fantoir. Et comme c'est une modélisation controversée, autant l'éviter quand d'autres solutions existent, comme celle ci-dessus : une associatedStreet par Fantoir. Ensuite davantage une question : pourquoi parfois certaines voies dont on indique bien la référence FANTOIR ne sont toujours pas reconnues après MAJ ? Malheureusement je n'ai pas d'exemple sous la main, j'en fournirai si j'en retrouve. Il n'y a pas de cas général pour cs anomalies, le meux est de pouvoir les indiquer au moyen d'un lieu vers la carte ou vers un objet OSM. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-GB] OS OpenData now OGL
This is really good news and thank you Rob for flagging it. Thanks also to the unknown folks at OS who have been working on this ... it follows through on a promise made to me in 2010 that they would look at. As cautioned by Rob, do wait until http://www.ordnancesurvey.co.uk/business-and-government/licensing/using-creating-data-with-os-products/os-opendata.html updates before jumping into CodePoint data with abandon ... it is from a not very open friendly third party and the OGL does allow exemptions for that. I believe also that this will be good news for ?English Heritage, (sorry, I live in Sweden), data users as it removes an ambiguity over which of their data is covered by OGL and which by the now retired OS OpenData license. On the change from OGL 2 to OGL 3, I am a bit less enthusiastic. I sat down with a large cup of coffee, compared them line by line and made the notes below. The thing to highlight is the change to the You definition which does possibly shift some of concern about the OS Opendata license into the OGL itself. The usual caveat: IANAL. Mike The non-trivial changes between OGL 2 and OGL 3 are as follows: Insertion: You must, where you do any of the above: acknowledge the source of the Information by including *or linking to* any attribution statement specified by the Information Provider(s) and, where possible, provide a link to this licence; This is good news. Additional wording: If you are using Information from several Information Providers and listing multiple attributions is not practical in your product or application, you may include a URI or hyperlink to a resource that contains the required attribution statements. This is good news, it follows practise that we have set up in OpenStreetMap. 'You',*'you' and 'your'* means the natural or legal person, or body of persons corporate or incorporate, acquiring rights *in the Information (whether the Information is obtained directly from the Licensor or otherwise)* under this licence. This could potentially imply that users of OpenStreetMap data for the UK, for example to make a map, might have to additionally attribute the OS, (or other bodies). Just being paranoid here but I think it is worth following up. On the other hand in both OGL 2 and OGL 3 is this explicit statement: These terms are compatible with the Creative Commons Attribution License 4.0 and the Open Data Commons Attribution License The wording of the latter is at http://opendatacommons.org/licenses/by/1-0/ Since the ODBL and Attribution License share common ancestry on attribution drafting, then quite likely we are compatible too by extension. But it needs some one to sit down and compare both licenses. Apologies but I lack time these days. On 18/02/2015 19:41, Owen Boswarva wrote: (I should clarify that by compatible I meant forward-compatible rather than interoperable. OGL data is suitable as an input to a OdBL dataset, but not vice versa.) -- Owen (@owenboswarva) On 18 February 2015 at 18:04, Jo Walsh metaz...@fastmail.net mailto:metaz...@fastmail.net wrote: I asked @owenboswarva on Twitter who is an active voice whom i trust on open government data issues, and he said this: IMO the only significant difference is v3 explicitly permits re-users to list multiple attributions via a URI or link. ...the differences are mostly just tidier syntax. If you are happy v2 is compatible with OdBL (IMO it is) then v3 is also. zx -- Jo Walsh metaz...@fastmail.net mailto:metaz...@fastmail.net On Wed, Feb 18, 2015, at 12:04 AM, Rob Nickerson wrote: On 17 February 2015 at 23:57, Matthijs Melissen i...@matthijsmelissen.nl mailto:i...@matthijsmelissen.nl wrote: I could imagine that OGL-3 has imported OS ODL's clause on sublicensing that caused incompatibility with ODbL, which would make OGL-3 incompatible with ODbL.Do we have confirmation that this is not the case, i.e. that OGL-3 and ODbL are compatible? -- Matthijs All the OGL versions are online. A comparison of v2 and v3 shows nothing to worry me. Hopefully Robert W will chip in as he's clued up on all this. Version 3: http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/ Version 2: http://www.nationalarchives.gov.uk/doc/open-government-licence/version/2/ _ Talk-GB mailing list Talk-GB@openstreetmap.org mailto:Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org mailto:Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-fr] BANO : Reconnaissance des voies
Ca me rappelle une discussion récente ici, où l'intervenant prétendait que ça n'existait pas, sous prétexte qu'il n'y en a pas dans les collectivités locales pour lesquelles il travaille ! J'ai eu beau lui expliquer, mais pas moyen de le faire changer d'avis (et il n'a même pas cherché hors de sa petite zone). mais le principal intervenant pour la BANO a décidé aussi de ne pas tenir compte de cette remarque (ou ne veut pas en tenir compte tout de suite et remet ça à plus tard sans même savoir quand, parce que dans un premier temps il ne veut pas y croire ou trouve ça aberrant par un préjugé, ou ne voit là qu'un détail mineur). Au moins ton message en est un autre témoignage (mais pour le NPDC je le savais déjà (et c'est le cas aussi pour de nombreuses routes frontalières internationales comme entre France et Belgique et Suisse), mais l'intervenant n'au aucune frontière internationale dans sa zone, seulement une frontière interrégionale) Cependant BANO est encore un chantier et loin d'être complet, et on peut comprendre que pour l'instant les plus grosses priorités sont ailleurs. BANO est encore récent et malgré le support public, il n'a pas encore toute l'expérience accumulée par des décennies de travail chez les diverses agences de l'Etat ou des collectivités (ou chez leurs fournisseurs de service). Le 19 février 2015 00:39, « Ano59 » news_advertis...@yahoo.fr a écrit : Bonjour, Contribuant régulièrement dans la région NPDC, je fais partie de la mailing-list de cette région. On m'a redirigé ici afin que je puisse mettre quelques questions / suggestions concernant BANO, en particulier en ce qui concerne la reconnaissance des voies. Je vais faire ça un peu en vrac au fil des problèmes rencontrés. Déjà première suggestion : serait-il possible que BANO reconnaisse les voies OSM portant un tag name:left ou name:right ? En mappant certaines rues entre deux villes, je me suis rendu compte que le cas arrivait souvent (la rue a deux noms différents selon la ville). Ces voies ne sont pas reconnues dans BANO : au mieux seule la portion avec un seule nom est reconnue, si elle existe. Dans une moindre mesure, lié au cas précédent, j'ignore si BANO reconnaît correctement des références FANTOIR multiples sur une même rue, telles que ref:FR:FANTOIR=RefX;RefY. J'ai l'impression que non, je peux me tromper. Ensuite davantage une question : pourquoi parfois certaines voies dont on indique bien la référence FANTOIR ne sont toujours pas reconnues après MAJ ? Malheureusement je n'ai pas d'exemple sous la main, j'en fournirai si j'en retrouve. C'est tout pour l'instant, merci d'avance pour d'éventuelles réponses, Cordialement, « Ano59 ». ___ 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-de] heise berichtet ueber osm.org-Routing integration
Hi! Am 19. Februar 2015 um 10:46 schrieb Eifelhunde eifelhu...@gmx.de: Sehe ich weniger problematisch, oder werden kurvenreiche Strecken auch berücksichtigt? Häufig sind doch diese nicht beschränkt, erlauben aber wegen der vielen Kurven nur geringe Geschwindigkeiten ??? es gilt in jedem Land ein generelles Maxspeed (in D außer Autobahnen) Ich versteh die Anmerkung nicht, es besteht doch nicht die Pflicht so schnell zu fahren - selbst wenn Schilder die Geschwindigkeit weiter beschränken ist die Geschwindigkeit keine Pflicht Kein professioneller Router geht davon aus, dass man die maximal erlaubte Geschwindigkeit auch tatsächlich fahren kann. Je nach Verlauf der Straße werden deutlich niedrigere Geschwindigkeiten angenommen. Auf einer völlig geraden Autobahn im ebenen Gebiet nimmt ein guter Router eine Geschwindigkeit nahe der erlaubten an, idR ca. 5%-10% darunter. Auf einer Passstraße, wo sich eine Serpentine an die nächste reiht, interessiert einen professionellen Router die maximal erlaubte Geschwindigkeit nur noch am Rande und es werden so Geschwindigkeiten z.B. im Bereich von 20-50km/h unterstellt, selbst wenn dort 100km/h erlaubt ist. Diese Geschwindigkeiten werden dann für die Routenfindung verwendet. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Mapillary et les panneaux
Mais là, je veux bien aider, mais est-ce que les sources de leur algo sont dispo sous licence libre ? ils utilisent OPENCV : http://opencv.org http://opencv.org/ Leur algo n'est probablement pas Open Source mais il doit en exister d’autres. Recherche «traffic sign recognition opencv https://www.google.fr/?q=traffic%20sign%20recognition%20opencvgws_rd=ssl» sur google… — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nantes-en-Rat(t)ier
J'ai ajouté sur la note un lien vers le résumé de Pieren : http://gis.19327.n5.nabble.com/quot-Vers-sur-Selle-quot-ou-comment-OSM-aide-un-peu-a-corriger-une-erreur-dans-le-nom-officiel-d-un-e-td5821937.html#a5822437 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-ph] Tagging bridges and tunnels
Hi Pierre, On Thu, Feb 19, 2015 at 9:24 AM, Pierre Béland pierz...@yahoo.fr wrote: Taginfo shows that tags such as bridge:name and bridge_name are used in other countries, but not in Philippines. bridge:name=* is definitely used in the Philippines. I and a couple or so other mappers have been using it. I have downloaded the latest OSM XML file from Geofabrik, did a grep, and came up with the following numbers: 12121 objects have a bridge=* tag 369 objects have a bridge:name=* tag 42 objects have a bridge_name=* tag See also: http://wiki.openstreetmap.org/wiki/Key:bridge:name ~Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-fr] Nantes-en-Rat(t)ier
C'est marrant. Sur les panneaux d'entrée-sortie du village, j'ai noté avec 2 t. Je ne sais pas où j'ai pris cette info car je ne retrouve pas de photo des panneaux. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-it] [OT] Quale distanza minima tra navigatori satellitari?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scrivo qui perchè forse qualcuno ha avuto a che fare con problemi simili. Sto preparando delle slide sul navigatore GPS, per poi finire col caricamento delle tracce su OSM. Però mi sono posto il problema, di un'eventuale camminata tra due persone in un sentiero, e tutti e due hanno un navigatore gps da trekking, per cui, dopo aver fatto ricerca per cercare di capire quale sia la distanza minima generica tra due navigatori affinché non si disturbino, e non cavandone un ragno dal buco, chiedo qui se qualcuno mi può indirizzare a qualche sito che lo spiega, o può portare le proprie esperienze in merito. Penso sia interessante anche per altri visto che non sempre si và da soli a mappare. Grazie a chi mi risponderà. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5da8AAoJEMTPIIVov0ZtR20IAIRS3XXCLrEA3ahtQqZCW7vK U/nF1qGOzl5flK8Xppi6pp9hA8hTh0Roj28njodx+IhReTiFRbRHf3J3kEffrDGy dSKeurNWLimNOo52GLdVsFKWtVeKgkEH8/lysSUhaYqaLYSihr/OP0qfl5/E5EWt p5BCbgc2uK9URlEEojR5/mTK0hnZ4XCmbOH5RMiZ7/3mCxktPBvpvW0XAtLpfMeC lzpB+2IyVm4bVwvM6+jpUL5RiDzfMouw5kEvVFHhW81zgpOrUI/2bmCIqhEDc1iR 4bC2+b38i8nncdp0WC8TmSdlj6i7+j83MpvyWwTGingl14ucu+c3rb1eOaVFR/A= =LBv1 -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Differenza no_left_turn only_straight_on
Il 17/02/2015 14:20, Andrea De Gradi ha scritto: Ciao a tutti, io sono dega180, l'utente che ha generato questa discussione insieme ad emmexx. Ciao Secondo me ai fini del routing, mettere il no_left_tourn è equivalente a mettere only_straight_on quando la svolta a destra è vietata dalla presenza di un senso unico. Inoltre, questo tipo di relazioni sembrano avere l'obiettivo di indicare all'utente gli obblighi di svolta e non il tipo di cartello presente che invece io avrei mappato usando un punto taggato con traffic_sign=*. Ovvio che poi uno dice: Se c'è una relazione per ogni tipo di cartello, non costa nulla far combaciare la relazione con il cartello. Secondo me la questione trattata similmente a quella riguardante il oneway=no, se lo si inserisce la mappatura risulta più precisa, se non lo si inserisce l'efficacia nella pratica è la stessa. Dunque utilizzare tutti i tipi di restriction è consigliabile ma non strettamente necessario. Teniamo anche conto che finché l'editor di default nell'interfaccia di osm.org http://osm.org (cioè iD) permetterà di inserire solo i no_left/right_turn, non potremmo certamente considerare come sbagliato il metodo che ho utilizzato. Altrimenti uno dei tool ufficiali di modifica di OSM sarebbe inutilizzabile per i tourn restriction perché agirebbe contro il nostro consenso, sarebbe un paradosso non vi pare? Senza entrare nel merito di quale relazione sia meglio utilizzare nel caso specifico, vedo che anche in iD oltre alle relazioni di divieto di svolta sono presenti anche quelle di obbligo, tra le quali c'è direzione obbligatoria dritto. Ciao Marcello ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Domande su primo import (un po' urgente)
On Thursday 19 of February 2015 06:07:54 cascafico wrote: Ciao. direi che caricare i dati raccolti da un gruppo di persone non sia propiramente un import e non implichi le relative linee guida (verifica licenza, script di tagging ecc). Se i dati sono raccolti da persone, la licenza si applica eccome. Con che licenza le persone hanno concesso l'uso dei dati raccolti? Ciao -- Luigi ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] Quale distanza minima tra navigatori satellitari?
Quando le slide saranno pronte, le pubblichi su qualche sito? Dario Inviato da Samsung Mobile Il 19/feb/2015 13:28 girarsi_liste liste.gira...@gmail.com ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scrivo qui perchè forse qualcuno ha avuto a che fare con problemi simili. Sto preparando delle slide sul navigatore GPS, per poi finire col caricamento delle tracce su OSM. Però mi sono posto il problema, di un'eventuale camminata tra due persone in un sentiero, e tutti e due hanno un navigatore gps da trekking, per cui, dopo aver fatto ricerca per cercare di capire quale sia la distanza minima generica tra due navigatori affinché non si disturbino, e non cavandone un ragno dal buco, chiedo qui se qualcuno mi può indirizzare a qualche sito che lo spiega, o può portare le proprie esperienze in merito. Penso sia interessante anche per altri visto che non sempre si và da soli a mappare. Grazie a chi mi risponderà. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5da8AAoJEMTPIIVov0ZtR20IAIRS3XXCLrEA3ahtQqZCW7vK U/nF1qGOzl5flK8Xppi6pp9hA8hTh0Roj28njodx+IhReTiFRbRHf3J3kEffrDGy dSKeurNWLimNOo52GLdVsFKWtVeKgkEH8/lysSUhaYqaLYSihr/OP0qfl5/E5EWt p5BCbgc2uK9URlEEojR5/mTK0hnZ4XCmbOH5RMiZ7/3mCxktPBvpvW0XAtLpfMeC lzpB+2IyVm4bVwvM6+jpUL5RiDzfMouw5kEvVFHhW81zgpOrUI/2bmCIqhEDc1iR 4bC2+b38i8nncdp0WC8TmSdlj6i7+j83MpvyWwTGingl14ucu+c3rb1eOaVFR/A= =LBv1 -END PGP SIGNATURE- ___ 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] [OT] Quale distanza minima tra navigatori satellitari?
Al massimo la differenza tra i due può essere data dalla precisione e dalla stabilità del segnale ricevuto, soprattutto in ambienti con scarsa ricezione (vedi supporto per GPS da solo oppure l'accoppiata GPS+GLONASS). Il giorno 19 febbraio 2015 13:38, Fabrizio Tambussa ftambu...@gmail.com ha scritto: Ciao. I ricevitori GPS ricevono solo il segnale, non trasmettono nulla. Fintanto che un ricevitore non copre fisicamente l'altro (uno sopra l'altro a contatto per intenderci), non ci sono problemi di interferenza. Saluti Il giorno 19 febbraio 2015 13:27, girarsi_liste liste.gira...@gmail.com ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scrivo qui perchè forse qualcuno ha avuto a che fare con problemi simili. Sto preparando delle slide sul navigatore GPS, per poi finire col caricamento delle tracce su OSM. Però mi sono posto il problema, di un'eventuale camminata tra due persone in un sentiero, e tutti e due hanno un navigatore gps da trekking, per cui, dopo aver fatto ricerca per cercare di capire quale sia la distanza minima generica tra due navigatori affinché non si disturbino, e non cavandone un ragno dal buco, chiedo qui se qualcuno mi può indirizzare a qualche sito che lo spiega, o può portare le proprie esperienze in merito. Penso sia interessante anche per altri visto che non sempre si và da soli a mappare. Grazie a chi mi risponderà. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5da8AAoJEMTPIIVov0ZtR20IAIRS3XXCLrEA3ahtQqZCW7vK U/nF1qGOzl5flK8Xppi6pp9hA8hTh0Roj28njodx+IhReTiFRbRHf3J3kEffrDGy dSKeurNWLimNOo52GLdVsFKWtVeKgkEH8/lysSUhaYqaLYSihr/OP0qfl5/E5EWt p5BCbgc2uK9URlEEojR5/mTK0hnZ4XCmbOH5RMiZ7/3mCxktPBvpvW0XAtLpfMeC lzpB+2IyVm4bVwvM6+jpUL5RiDzfMouw5kEvVFHhW81zgpOrUI/2bmCIqhEDc1iR 4bC2+b38i8nncdp0WC8TmSdlj6i7+j83MpvyWwTGingl14ucu+c3rb1eOaVFR/A= =LBv1 -END PGP SIGNATURE- ___ 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-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] Quale distanza minima tra navigatori satellitari?
Il 19/feb/2015 13:28 girarsi_liste liste.gira...@gmail.com ha scritto: Però mi sono posto il problema, di un'eventuale camminata tra due persone in un sentiero, e tutti e due hanno un navigatore gps da trekking, per cui, dopo aver fatto ricerca per cercare di capire quale sia la distanza minima generica tra due navigatori affinché non si disturbino, e non cavandone un ragno dal buco, chiedo qui se qualcuno mi può indirizzare a qualche sito che lo spiega, o può portare le proprie esperienze in merito. Penso sia interessante anche per altri visto che non sempre si và da soli a mappare. Se ho capito bene la domanda, ti poni il problema di eventuali interferenze tra due ricevitori GPS collocati a breve distanza. Ritengo che non ci siano interferenze. L'antenna dei GPS è un'antenna passiva (non trasmette, riceve e basta) per cui non aggiunge alcun segnale né disturbo rispetto a quelli già presenti. Un ipotetico disturbo potrebbe dipendere dal fatto che il ricevitore ha al suo interno un quarzo che genera una oscillazione per l orologio interno. A parte il fatto che ogni componente elettronico moderno ha lo stesso quarzo e quindi potrebbe disturbare alla stessa maniera. (radio per cui viene approvato dalla FCC prima di essere commercializzato). In ogni caso, questo disturbo è talmente ininfluente da non riuscire a disturbare neppure la propria antenna (posta ad una distanza certamente inferiore rispetto all'antenna di qualunque altro ricevitore presente nei paraggi) e comunque la potenza del segnale di disturbo è inversamente proporzionale al quadrato della distanza per cui bastano piccole differenze nella distanza per forti diminuzioni del disturbo. Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] Quale distanza minima tra navigatori satellitari?
--Simone Girardelli-- Inviato dal mio smartphone. -Original Message- From: Dario Zontini dario.zont...@gmail.com To: openstreetmap list - italiano talk-it@openstreetmap.org Sent: Gio, 19 Feb 2015 13:47 Subject: Re: [Talk-it] [OT] Quale distanza minima tra navigatori satellitari? Quando le slide saranno pronte, le pubblichi su qualche sito? Dario In teoria su slideshare, peró devo capire se accetta gli effetti che ho messo, oltre alla licenza, ma sulla licenza mi pare non ci siano provlemi. Ciao. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] civici di ferrara - adesso open
Ciao, segnalo che ora i civici di Ferrara adesso sono open: http://www.comune.fe.it/index.phtml?id=3513 un grazie a Piergiorgio Cipriano per il lavoro dietro le quinte... :) -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] Quale distanza minima tra navigatori satellitari?
Ciao. I ricevitori GPS ricevono solo il segnale, non trasmettono nulla. Fintanto che un ricevitore non copre fisicamente l'altro (uno sopra l'altro a contatto per intenderci), non ci sono problemi di interferenza. Saluti Il giorno 19 febbraio 2015 13:27, girarsi_liste liste.gira...@gmail.com ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scrivo qui perchè forse qualcuno ha avuto a che fare con problemi simili. Sto preparando delle slide sul navigatore GPS, per poi finire col caricamento delle tracce su OSM. Però mi sono posto il problema, di un'eventuale camminata tra due persone in un sentiero, e tutti e due hanno un navigatore gps da trekking, per cui, dopo aver fatto ricerca per cercare di capire quale sia la distanza minima generica tra due navigatori affinché non si disturbino, e non cavandone un ragno dal buco, chiedo qui se qualcuno mi può indirizzare a qualche sito che lo spiega, o può portare le proprie esperienze in merito. Penso sia interessante anche per altri visto che non sempre si và da soli a mappare. Grazie a chi mi risponderà. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5da8AAoJEMTPIIVov0ZtR20IAIRS3XXCLrEA3ahtQqZCW7vK U/nF1qGOzl5flK8Xppi6pp9hA8hTh0Roj28njodx+IhReTiFRbRHf3J3kEffrDGy dSKeurNWLimNOo52GLdVsFKWtVeKgkEH8/lysSUhaYqaLYSihr/OP0qfl5/E5EWt p5BCbgc2uK9URlEEojR5/mTK0hnZ4XCmbOH5RMiZ7/3mCxktPBvpvW0XAtLpfMeC lzpB+2IyVm4bVwvM6+jpUL5RiDzfMouw5kEvVFHhW81zgpOrUI/2bmCIqhEDc1iR 4bC2+b38i8nncdp0WC8TmSdlj6i7+j83MpvyWwTGingl14ucu+c3rb1eOaVFR/A= =LBv1 -END PGP SIGNATURE- ___ 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
[OSM-talk-fr] cadastre.openstreetmap et import d'adresses
Bonjour à tous, Pour aller plus loin dans l'import des adresses dans OSM via l'outil cadastre.openstreetmap, on ne peut choisir entre 2 options, créer une relation de type associatedStreet et y mettre les tronçons de voies et les adresses, ou importer seulement les adresses avec le tag addr:street (et donc sans les relations). Ne pourrait-on pas avoir les 2 car, même s'il y a redondance dans l'information, les personnes qui souhaite exploiter cette donnée pourraient préférer l'une ou l'autre. En y mettant les deux, on rendrait service à 2 fois plus de monde. Du coup, si on a déjà importer les adresses avec la méthode des relations associatedStreet, peut-on y ajouter les tags addr:street de manière automatique (en les récupérant du nom de la relation associatedStreet) ? - 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/cadastre-openstreetmap-et-import-d-adresses-tp5834244.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-it] Domande su primo import (un po' urgente)
Ciao. direi che caricare i dati raccolti da un gruppo di persone non sia propiramente un import e non implichi le relative linee guida (verifica licenza, script di tagging ecc). Da quel che ho capito, l'import riguarda dataset strutturati, prodotti da enti e di mole notevole. Nel tuo caso basterebbe insegnare al tuo gruppo come usare gli editor di OSM, a cominciare da quelli sul browser e distribuire il lavoro, perchè i dati migliori sono quelli di chi ha fatto il sopralluogo.. Come dire, crea nuovi OSMappers! - -- cascafico.altervista.org twitter.com/cascafico -- View this message in context: http://gis.19327.n5.nabble.com/Domande-su-primo-import-un-po-urgente-tp5833836p5834245.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] [OT] Quale distanza minima tra navigatori satellitari?
Il 19 febbraio 2015 13:52:22 CET, Francesco Pelullo f.pelu...@gmail.com ha scritto: Il 19/feb/2015 13:28 girarsi_liste liste.gira...@gmail.com ha scritto: Però mi sono posto il problema, di un'eventuale camminata tra due persone in un sentiero, e tutti e due hanno un navigatore gps da trekking, per cui, dopo aver fatto ricerca per cercare di capire quale sia la distanza minima generica tra due navigatori affinché non si disturbino, e non cavandone un ragno dal buco, chiedo qui se qualcuno mi può indirizzare a qualche sito che lo spiega, o può portare le proprie esperienze in merito. Penso sia interessante anche per altri visto che non sempre si và da soli a mappare. Le antenne normalmente cominciano ad avere prestazioni inferiori quando ci sono parti metalliche entro ad 1/2 della lunghezza d'onda. Residui dell oscillatore di media frequenza possono essere presenti sull'antenna e con un' antenna molto (ma molto) vicina possono rientrare nell'altra antenna e disturbare il ricevitore. In pratica quando 2 persone passeggiano insieme non ci sono di questi problemi. Il problema che si presenta più spesso è il riflesso del segnale sul terreno o su una parete vicina che arriva in ritardo rispetto a quando sarebbe dovuto arrivare ( fenomeno noto come multipath), in queste condizioni il gps continua ad indicare una precisione elevata quando invece non è così, e ci si può trovare la traccia spostata anche di 50 metri. Ciao -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Domande su primo import (un po' urgente)
Luigi Toscano wrote Se i dati sono raccolti da persone, la licenza si applica eccome. Con che licenza le persone hanno concesso l'uso dei dati raccolti? Scusa, avrei dovuto citare la Santarelli: [SNIP] tra le altre cose è richiesto ai partecipanti che condividano su OSM dei dati da loro raccolti. [SNIP] - -- cascafico.altervista.org twitter.com/cascafico -- View this message in context: http://gis.19327.n5.nabble.com/Domande-su-primo-import-un-po-urgente-tp5833836p5834251.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-GB] OS OpenData now OGL
In my view the additional bit about acquiring rights in the Information (whether the Information is obtained directly from the Licensor or otherwise) is a clarification; not a change to the effect of the licence (when comparing the versions). You applies to persons acquiring rights in the information indirectly under all versions of OGL. The additional wording in Version 3 just makes that explicit. Otherwise Version 3 would not be backward compatible with Version 2. Owen On 19 February 2015 at 11:42, Michael Collinson m...@ayeltd.biz wrote: This is really good news and thank you Rob for flagging it. Thanks also to the unknown folks at OS who have been working on this ... it follows through on a promise made to me in 2010 that they would look at. As cautioned by Rob, do wait until http://www.ordnancesurvey.co.uk/business-and-government/licensing/using-creating-data-with-os-products/os-opendata.html updates before jumping into CodePoint data with abandon ... it is from a not very open friendly third party and the OGL does allow exemptions for that. I believe also that this will be good news for ?English Heritage, (sorry, I live in Sweden), data users as it removes an ambiguity over which of their data is covered by OGL and which by the now retired OS OpenData license. On the change from OGL 2 to OGL 3, I am a bit less enthusiastic. I sat down with a large cup of coffee, compared them line by line and made the notes below. The thing to highlight is the change to the You definition which does possibly shift some of concern about the OS Opendata license into the OGL itself. The usual caveat: IANAL. Mike The non-trivial changes between OGL 2 and OGL 3 are as follows: Insertion: You must, where you do any of the above: acknowledge the source of the Information by including *or linking to* any attribution statement specified by the Information Provider(s) and, where possible, provide a link to this licence; This is good news. Additional wording: If you are using Information from several Information Providers and listing multiple attributions is not practical in your product or application, you may include a URI or hyperlink to a resource that contains the required attribution statements. This is good news, it follows practise that we have set up in OpenStreetMap. 'You',* 'you' and 'your'* means the natural or legal person, or body of persons corporate or incorporate, acquiring rights *in the Information (whether the Information is obtained directly from the Licensor or otherwise)* under this licence. This could potentially imply that users of OpenStreetMap data for the UK, for example to make a map, might have to additionally attribute the OS, (or other bodies). Just being paranoid here but I think it is worth following up. On the other hand in both OGL 2 and OGL 3 is this explicit statement: These terms are compatible with the Creative Commons Attribution License 4.0 and the Open Data Commons Attribution License The wording of the latter is at http://opendatacommons.org/licenses/by/1-0/ Since the ODBL and Attribution License share common ancestry on attribution drafting, then quite likely we are compatible too by extension. But it needs some one to sit down and compare both licenses. Apologies but I lack time these days. On 18/02/2015 19:41, Owen Boswarva wrote: (I should clarify that by compatible I meant forward-compatible rather than interoperable. OGL data is suitable as an input to a OdBL dataset, but not vice versa.) -- Owen (@owenboswarva) On 18 February 2015 at 18:04, Jo Walsh metaz...@fastmail.net wrote: I asked @owenboswarva on Twitter who is an active voice whom i trust on open government data issues, and he said this: IMO the only significant difference is v3 explicitly permits re-users to list multiple attributions via a URI or link. ...the differences are mostly just tidier syntax. If you are happy v2 is compatible with OdBL (IMO it is) then v3 is also. zx -- Jo Walsh metaz...@fastmail.net On Wed, Feb 18, 2015, at 12:04 AM, Rob Nickerson wrote: On 17 February 2015 at 23:57, Matthijs Melissen i...@matthijsmelissen.nl wrote: I could imagine that OGL-3 has imported OS ODL's clause on sublicensing that caused incompatibility with ODbL, which would make OGL-3 incompatible with ODbL.Do we have confirmation that this is not the case, i.e. that OGL-3 and ODbL are compatible? -- Matthijs All the OGL versions are online. A comparison of v2 and v3 shows nothing to worry me. Hopefully Robert W will chip in as he's clued up on all this. Version 3: http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/ Version 2: http://www.nationalarchives.gov.uk/doc/open-government-licence/version/2/ *___* Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [talk-ph] Tagging bridges and tunnels
On Thu, Feb 19, 2015 at 1:10 PM, Ronny Ager-Wick ro...@ager-wick.com wrote: What do the rest of you think of renaming all ref tags to ref:ph? I know it would make sense here, and probably everywhere outside of Metro Manila, but what about Manila? OSM already has a standard set of alternative ref=* tags: int_ref=* (international reference) nat_ref=* (national reference) reg_ref=* (regional reference) loc_ref=* (local reference) See here: http://wiki.openstreetmap.org/wiki/Key:ref I prefer that we use nat_ref=* instead of inventing ref:ph=* ~Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [Talk-br] BR-116 split and cleanup
Reorganizei a divisão da BR-116 por região, em três partes: Nordeste (CE, PB, BA), Sudeste (MG, RJ, SP) e Sul (PR, SC, RS), para facilitar a edição dentro de cada estado. Corrigi também os links no Wiki, de forma que eles não estão mais quebrados. Se algum lugar ainda estiver com os links antigos, as relações novas são 4551466, 4551468 e 4551469, respectivamente. A página com a lista das rodovias federais agora mostra a BR-116 dividida em três: https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Rodovias_Federais Pretendo fazer o mesmo com a BR-101, que é a outra rodovia problemática, atualmente com 3134 segmentos. Em 13 de fevereiro de 2015 00:21, Lists li...@gimnechiske.org escreveu: Tem uns 2 ou 3 rodovias mais que teoricamente pode ser divido similares, mas estes passa principalmente nas areas com pouco mapeamento, e assim as trechos mais logos e menus atividade. Aun Johnsen On Feb 12, 2015, at 23:13, Flavio Bello Fialho bello.fla...@gmail.com wrote: Entendo que o histórico estava muito longo e que a rodovia tem muitos segmentos. Entretanto, dividir a rodovia em relações pequenas prejudica o controle. Quando eu vejo que uma rodovia ficou descontínua, eu baixo a rodovia no JOSM e conserto o que ficou errado. Geralmente, aproveito para corrigir a rodovia no trecho afetado, detalhando os cruzamentos e colocando as restrições de conversão, de forma que a rodovia fique correta e o usuário não precise mexer de novo. Assim, é bom que os trechos sejam longos, pois eu verifico uma grande extensão numa tacada só. Se for para dividir, proponho que seja dividido por região (Sul, Sudeste, Nordeste, Norte e Centro-Oeste). Assim, a BR-116 ficaria dividida em 3 relações (NE, SE e S) e fica mais fácil para as equipes de cada estado trabalharem. Dessa forma, quando eu verificasse a integridade da BR-116, já o faria em 3 estados (RS, SC e PR). Até agora, as únicas rodovias realmente grandes (em número de segmentos) são a BR-116 e a BR-101. 2015-02-12 22:48 GMT-02:00 Nelson A. de Oliveira nao...@gmail.com: A separação que o Paul fez foi emergencial (para remover alguns dados do OSM). Foi caso isolado. ___ 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 ___ 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-cz] ŘOPíky
Zdravim, jak to s problematikou vypada, uz nekdo napsal? Popripadne mohu zkontaktovat ja, pokud se jiz nekdo nenasel. Mejte se, L. __ Od: Kamenitxan kamenit...@me.com Komu: talk-cz@openstreetmap.org Datum: 15.01.2015 10:10 Předmět: Re: [Talk-cz] ŘOPíky Ahoj, Lukáš vyhrabal email vedouciho od ROPiku. Najde se dobrovolník, který to s ním zkusí vyjednat, nebo mu mám napsat já? Kamenitxan 11. 1. 2015 v 13:00, talk-cz-requ...@openstreetmap.org: Jj urcite by nejaky posveceni cele akce stalo za to... L. __ Od: Lukáš Gebauer gebyl...@mlp.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 10.01.2015 13:13 Předmět: Re: [Talk-cz] ŘOPíky Dne 10.1.2015 v 12:44 Karel Volný napsal(a): no, víme něco jiného, než že ropiky.net nás ignorují? - http://forum.ropiky.net/tema.php?id=1244118437 a když se Da se rict, ze vsechny ROPiky jsou na nasem uzemi zmapovane (od dochovanych, pres poskozene, rozestavene, az po planovane, co se ani stavet nezacaly). Takze mit v mape ty dochovane a poskozene, by asi rozumne bylo. Zbytek uz moc orientacni prvek neni, a zajimat to bude jen pro bunkrology, kteri si to najdou jinde. Ony ty ropiky.net bezi uz nejakou dobu vlastne samospadem. Tam se asi zadne reakce nedockas. Nicmene data tak uplne nedostupna nejsou. Treba me se podarilo narazit na jednoho z hlavnich lidi a vyjednat toto: http://www.geocaching.cz/blog/25/entry-219-%C5%99op%C3%ADkat%C3%BD-geoget-ii/ Tu databazi z toho Geogetu lze exportovat do GPX, nebo cehokoliv jineho, ma to uzivatelsky definovane exportni skripty. Takze ja za soucasne situace verim, ze ziskani dat pro OSM nebude neprekonatelny problem. Mam se pokusit vyhrabat email na toho cloveka? Lukas. -- ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-it] civici di ferrara - adesso open
Il 19/02/2015 13:00, Simone Cortesi ha scritto: Ciao, segnalo che ora i civici di Ferrara adesso sono open: http://www.comune.fe.it/index.phtml?id=3513 un grazie a Piergiorgio Cipriano per il lavoro dietro le quinte... :) Spettacolare! Grazie a tutti. Io non ho mai fatto un import in vita mia: qualcuno si vuole occupare di questo import? Volendo posso provare io ma non so fare :-) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-ja] 基盤地図情報のインポートについて
としです． 私が意見を言って良いのかどうか（そう言う趣旨で いいださんが投稿されたの か）分かりませんが空気を読まずに :-) ■原則 まず、最も厳格な適用の場合を述べます。 ... ■いいだとしてはどうしたいのか データを削除したほうがよいと考えています。 僕は厳し目の見方をしているかもしれません。 まずはご意見いただきたいです。 厳格も何も，入れるべきではないデータが入ったのなら削除するより他は無い と思います． 後は削除範囲をどうするかかなと思っています． ではこれにて． On 2015/02/19 23:50, Satoshi IIDA wrote: いいだです。 解説いただきありがとうございます。 ■原則 まず、最も厳格な適用の場合を述べます。 データの改変を実施していても、入力したデータを削除すべき、という適用です。 何故ならば、今回は基本測量成果である基盤地図情報を元データとしており、 測量法の適用範疇内である点が課題である以上、 提供元 (この場合、国土地理院) としても法律運用に基づく利用可否の判断はできず、 可否判断が可能な組織は司法である、という認識を持っています。 つまり、単に提供元に後追いで許諾を貰えばOK、という性質のものではないという認識です。 また、OSMとして、法律に抵触し、なおかつそもそも、 以前に地理院との話し合いの内容に反する状況を維持することは あまりよい事態ではないと考えています。 ■海南町について 現在削除が行われているようです。 作業者とみられるかたからコンタクトあり、削除する方向で進めています。 ■徳島について インポートを実施した範囲が不明確ですので、確認させてください。 徳島県ほぼ全域を作業されているようですが、それで認識はあっていますか？ インポート作業に利用されたアカウントは以下の2つでよいですか？ * 徳島県オープンデータ * mitsurukikkawa ■削除方法について 現状、いつぐらいからインポート作業をされているか不明確であり、 明確な開始時期と範囲の判断がつかないという状態だと認識しています。 それであれば、当該のアカウントから入力された building=yesデータはすべて削除することが望ましいと考えます。 インポートではない、吉川さんが入力されたbuilding=yesデータが巻き込まれる可能性はありますが、 ライセンスと法律を順守する観点から、この場合は疑わしきであっても削除したほうがよいと思っています。 (インポート専用アカウントの作成が求められているのはこういうことが主な理由です。。。) 例えば以下のようなクエリで抽出が可能です。 http://overpass-turbo.eu/s/7Kt ■削除する以外の選択肢について インポートデータの保存・投稿を行う 前に 衛星画像等による加筆編集がデータに対して行われていれば、 まだこれは「もともとのデータは基盤地図情報ではない」といえるかもしれません。 消さないで済む方法として、なにかよいアイデアがあればいただけると嬉しいです。 ただこれは、法律の抜け道を探すことにも直結しかねない問題であり、 後々の法的な禍根を残すことになりかねません。。。 ■いいだとしてはどうしたいのか データを削除したほうがよいと考えています。 僕は厳し目の見方をしているかもしれません。 まずはご意見いただきたいです。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-it] Domande su primo import (un po' urgente)
Ciao Andrea, le due licenze secondo http://opendatacommons.org/faq/licenses/#db-versus-contents possono convivere For non-homogenous DB (need to distinguish “Database and Contents”): 2 -Share-alike: use ODbL for Database qua Database + whatever license you want/can for Contents D'altronde a noi importa poco la licenza d'uso, basta che sia libera, almeno per quanto riguarda i contenuti. Quanto al modo in cui, è un plugin, si chama meshup qualcosa, e poi se non funziona, e a volte accade, usiamo manualmente questo geocoder http://geocoder.opencagedata.com/demo.html Il problema non è tecnico ma concettuale: a OSM semplicemente non servono i nostri dati. Il giorno 19 febbraio 2015 16:12, Andrea Musuruane musur...@gmail.com ha scritto: Ciao, 2015-02-19 15:24 GMT+01:00 francesca santarelli sant.france...@gmail.com : Grazie, il nostro è un sito in cui non noi (salvo rari casi) ma chiunque, per lo più persone a me sconosciute, inseriscono informazioni su eventi e luoghi della cultura (che vengono poi geolocalizzati dal sistema a partire dall'indirizzo fornit), uno alla volta, come gli pare. Quegli inserimenti diventano post in CC BY SA. Mi pare di avere capito insomma che non sono dati utili a OSM, perché su OSM è meglio caricare gli open data al completo dell'anagrafe delle biblioteche (che già c'è a quanto mi pare di vedere) che qualche biblioteca. Il problema che vedo io è che la licenza dei dati (CC-BY-SA) non è compatibile con quella di OSM (ODbL). Quindi i dati non possono essere importati. Inoltre non è chiaro come avviene la geolocalizzazione a partire dall'indirizzo fornito. Se viene usato un servizio di terze parti (tipo Google) per trasformare l'indirizzo in coordinate geografice, allora i dati non possono essere importati perché indirettamente importeremmo dei dati di Google. Ciao, Andrea ___ 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: [OSM-ja] 基盤地図情報のインポートについて
いいださん、みなさん 山下です。お手数をお掛けします。 現状、いつぐらいからインポート作業をされているか不明確であり、 明確な開始時期と範囲の判断がつかないという状態だと認識しています。 これは徳島市の件ですね？ 和歌山市、海南市に関しては、 別途お伝えしたアカウント／チェンジセット以降が対象です。 最近のチェンジセットは、ご自身で削除されたチェンジセットですので、 それまでリバートすると、消されたものが蘇ってきます。 ご注意いただければと思います。 よろしくお願いします In message cagexurbpqzfbp-abwy1du5ro7gg9tou7qortrswou9bepxs...@mail.gmail.com Satoshi IIDA nyamp...@gmail.com writes --===8107317433539273325== Content-Type: multipart/alternative; boundary=001a11376e640b453d050f720f67 --001a11376e640b453d050f720f67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 いいだです。 解説いただきありがとうございます。 ■原則 まず、最も厳格な適用の場合を述べます。 データの改変を実施していても、入力したデータを削除すべき、という適用です。 何故ならば、今回は基本測量成果である基盤地図情報を元データとしており、 測量法の適用範疇内である点が課題である以上、 提供元 (この場合、国土地理院) としても法律運用に基づく利用可否の判断はできず、 可否判断が可能な組織は司法である、という認識を持っています。 つまり、単に提供元に後追いで許諾を貰えばOK、という性質のものではないという認識です。 また、OSMとして、法律に抵触し、なおかつそもそも、 以前に地理院との話し合いの内容に反する状況を維持することは あまりよい事態ではないと考えています。 ■海南町について 現在削除が行われているようです。 作業者とみられるかたからコンタクトあり、削除する方向で進めています。 ■徳島について インポートを実施した範囲が不明確ですので、確認させてください。 徳島県ほぼ全域を作業されているようですが、それで認識はあっていますか？ インポート作業に利用されたアカウントは以下の2つでよいですか？ * 徳島県オープンデータ * mitsurukikkawa ■削除方法について 現状、いつぐらいからインポート作業をされているか不明確であり、 明確な開始時期と範囲の判断がつかないという状態だと認識しています。 それであれば、当該のアカウントから入力された building=yesデータはすべて削除することが望ましいと考えます。 インポートではない、吉川さんが入力されたbuilding=yesデータが巻き込まれる可能性はありますが、 ライセンスと法律を順守する観点から、この場合は疑わしきであっても削除したほうがよいと思っています。 (インポート専用アカウントの作成が求められているのはこういうことが主な理由です。。。) 例えば以下のようなクエリで抽出が可能です。 http://overpass-turbo.eu/s/7Kt ■削除する以外の選択肢について インポートデータの保存・投稿を行う 前に 衛星画像等による加筆編集がデータに対して行われていれば、 まだこれは「もともとのデータは基盤地図情報ではない」といえるかもしれません。 消さないで済む方法として、なにかよいアイデアがあればいただけると嬉しいです。 ただこれは、法律の抜け道を探すことにも直結しかねない問題であり、 後々の法的な禍根を残すことになりかねません。。。 ■いいだとしてはどうしたいのか データを削除したほうがよいと考えています。 僕は厳し目の見方をしているかもしれません。 まずはご意見いただきたいです。 -- 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-ja] 基盤地図情報のインポートについて
いいだです。 現状、いつぐらいからインポート作業をされているか不明確であり、 明確な開始時期と範囲の判断がつかないという状態だと認識しています。 これは徳島市の件ですね？ はい、そうです。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
On Wed, Feb 18, 2015 at 01:06:12PM +0100, chris66 wrote: Am 18.02.2015 um 12:09 schrieb Alexander Lehner: ... wenngleich auch etwas kritisch: Die Qualität unserer Daten in Bezug auf Routing ist in der Tat verbesserungswürdig. So wird man mitunter zu verbotenen Abbiegemanövern aufgefordert oder über Privatgrundstücke gelotst. Weitere Probleme: - Routinginseln - Anliegerverbote werden ignoriert - Wichtige Infos wie maxspeed sind noch lückenhaft Routinginseln sind ein Problem der präprozessierung. Die müssten eigentlich vom resultierenden Graph entfernt werden. Ich mache viel mit OSRM und habe auch das Problem das es reichlich Marktplätze etc gibt die keine Anbindung an das restliche Straßennetz haben. Anliegerverbote sind ein extrem schwieriges Thema zu dem auch noch anderes gehört wie z.b. Tracks. Am Ende werden alle verbote zu einem access=destination. Selbst wenn auf einer Straße ein access=no oder das nur ein Fußweg ist muss der router das dingen benutzen wenn das Ziel an diesem Weg liegt. Deshalb macht OSRM auch murks wenn ich nach Hause möchte. Ich liege an einem Waldweg - nicht asphaltiert, forstwirtschaftlicher Verkehr frei - typ track/grade4. Ja - den muss man befahren um zu mir zu kommen. OSRM lotst mich zu einer service road die semi-in-der-nähe ist und gibt dann auf. Dazu kommt das aneinandergrenzende Wege mit accessbeschränkungen zusammengefasst werden müssen - also access beschränkte Inseln deren Einfahrt reguliert ist. maxspeed finde ich ziemlich uninteressant. Durchschnittsgeschwindigkeiten kann man auch über heuristiken annähern. Ein großes Problem finde ich das die entscheidungen die Graphhopper, Mapquest und OSRM treffen SEHR unterschiedlich sind. Mir sind die entscheidungswege überhaupt nicht transparent ( Abiegepenalty? Maxspeed?, Gewichtung von highway klassen? Nutzung von Bebauungsinformation?). Wenn könnte man ja durch entsprechendes tagging dahinwirken das die Routen sich verbessern. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] [OT] Quale distanza minima tra navigatori satellitari?
2015-02-19 14:10 GMT+01:00 Michele iw1gfv iw1...@yahoo.it: Il problema che si presenta più spesso è il riflesso del segnale sul terreno o su una parete vicina che arriva in ritardo rispetto a quando sarebbe dovuto arrivare +1, particolarmente forte fuori i centri abitati è per esempio il disturbo dalle foglie degli alberi, sopratutto quando sono bagnate. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-ja] 基盤地図情報のインポートについて
吉川さん いいださん 皆さん 三浦です。 状況の共有と、対応案の提案ありがとうございます。 大変でも、対応しなくちゃ、な感じですね。 OpenStreetMapのオープンなデータを守るために、ライセンスや規約、 入力方法に問題がでちゃったデータは、一切合切問題が無いように 戻す必要があります。 そうでないと、みんなで地道に作ってきた、とってもオープンなデータが、 オープンにできなくなるからです。 問題が無いようにするために、どうしたらいいか みなさんで相談しながら、 リカバーをできればと思います。 ■削除方法について 現状、いつぐらいからインポート作業をされているか不明確であり、 明確な開始時期と範囲の判断がつかないという状態だと認識しています。 それであれば、当該のアカウントから入力された building=yesデータはすべて削除することが望ましいと考えます。 インポートではない、吉川さんが入力されたbuilding=yesデータが巻き込まれる可能性はありますが、 ライセンスと法律を順守する観点から、この場合は疑わしきであっても削除したほうがよいと思っています。 (インポート専用アカウントの作成が求められているのはこういうことが主な理由です。。。) 例えば以下のようなクエリで抽出が可能です。 http://overpass-turbo.eu/s/7Kt ■削除する以外の選択肢について インポートデータの保存・投稿を行う 前に 衛星画像等による加筆編集がデータに対して行われていれば、 まだこれは「もともとのデータは基盤地図情報ではない」といえるかもしれません。 消さないで済む方法として、なにかよいアイデアがあればいただけると嬉しいです。 ただこれは、法律の抜け道を探すことにも直結しかねない問題であり、 後々の法的な禍根を残すことになりかねません。。。 ■いいだとしてはどうしたいのか データを削除したほうがよいと考えています。 僕は厳し目の見方をしているかもしれません。 まずはご意見いただきたいです。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-de] Straßenbahngleise auf Brücken (Rendering)
Moin, kann es sein, dass Mapnik Straßenbahngleise auf Brücken unter die Straße zeichnet? http://www.openstreetmap.org/way/194083416#map=19/50.92851/11.59543layers=N Sowohl railway=tram als auch highway=tertiary sind mit bridge=yes gekennzeichnet. Viele Grüße Andreas -- Andreas Neumann http://Map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-br] Incluindo Hot Spots Wi-fi
Srs, A prefeitura do Recife liberou via seu portal de dados abertos uma lista dos Hot Spots do Conecta Recife ( http://portalconecta.recife.pe.gov.br/index.php ). Me interessei em incluí-los no mapa do OSM já que são poucos, cerca de 70, e estou tentando achar um conjunto de tags apropriado. Até agora achei os seguintes : internet_access:fee=no internet_access:operator=Conecta Recife internet_access:ssid=CONECTARECIFE internet_access=wlan source = Dados Abertos Prefeitura do Recife - http://goo.gl/aAluVE source:date=2015/02/13 Além desses, existe uma informação de que cada acesso feito por essa rede será mediante cadastro no site e limitado a 1 hora de cada vez, renovável via login. Como tagear essas informações adicionais? Além disso, esses pontos não estão associados a nenhuma amenity, por isso não serão renderizadas, entendi certo ? Agradeço a paciência. Att, Marcelo Pereira -- São Pedro recebe Seu Lunga no céu perguntando: Morreu, Seu Lunga? Não, vim passar o Natal! ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Incluindo Hot Spots Wi-fi
Acho bom, pode incluir um note também note=Public Hotspot Aun Johnsen On Feb 19, 2015, at 15:21, Marcelo Pereira pereirahol...@gmail.com wrote: Srs, A prefeitura do Recife liberou via seu portal de dados abertos uma lista dos Hot Spots do Conecta Recife ( http://portalconecta.recife.pe.gov.br/index.php http://portalconecta.recife.pe.gov.br/index.php ). Me interessei em incluí-los no mapa do OSM já que são poucos, cerca de 70, e estou tentando achar um conjunto de tags apropriado. Até agora achei os seguintes : internet_access:fee=no internet_access:operator=Conecta Recife internet_access:ssid=CONECTARECIFE internet_access=wlan source = Dados Abertos Prefeitura do Recife - http://goo.gl/aAluVE http://goo.gl/aAluVE source:date=2015/02/13 Além desses, existe uma informação de que cada acesso feito por essa rede será mediante cadastro no site e limitado a 1 hora de cada vez, renovável via login. Como tagear essas informações adicionais? Além disso, esses pontos não estão associados a nenhuma amenity, por isso não serão renderizadas, entendi certo ? Agradeço a paciência. Att, Marcelo Pereira -- São Pedro recebe Seu Lunga no céu perguntando: Morreu, Seu Lunga? Não, vim passar o Natal! ___ 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-at] Flurnamenimport in Vorarlberg
Okay, der User hat jetzt die Nodes leicht ausgeduennt, wobei immer noch jede Menge Nodes mit ungeklaerter Lizenzsituation stehen geblieben sind (auf die Changeset-Notiz hat er nicht reagiert). Falls ihn niemand anders noch per PN kontaktieren will, wuerde ich ansonsten alle Flurnamen-Nodes von ihm (und die auch von niemandem anderen bearbeitet wurden) rausloeschen. lg, Jens ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-br] Incluindo Hot Spots Wi-fi
2015-02-19 16:21 GMT-02:00 Marcelo Pereira pereirahol...@gmail.com: Além disso, esses pontos não estão associados a nenhuma amenity, por isso não serão renderizadas, entendi certo ? Não estão localizados em praças ou outros locais abertos? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] Nantes-en-Rat(t)ier
Bizarre, le site internet est enregistré avec un seul T, mais la bannière d'accueil et tous le site en met deux, ainsi que les panneaux installés en photo. Bref même si c'est une erreur historique, ça a été entériné et même la mairie utilise l'orthographe à 2 T sans que ça la dérange. A moins d'une décision municipale pour ré-officialiser l'ancienne orthographe, on peut toujours mettre un alt_name avec un seul T : si cette décision survient, on pourra toujours faire l'échange entre name et alt_name (et sur Wikipedia et Wikidata on pourra juste renommer la page et conserver une redirection synonyme (pour les autres langues que le français, peut importe puisque les orthographes sont souvent altérées ou simplifiées pour une lecture plus facile dans ces langues uniquement sur une base phonologique propre à l'usage de ces langues et de leur écriture quand elle n'est pas latine). Le 19 février 2015 16:13, Régis Bouguin regis.boug...@wanadoo.fr a écrit : Là peut-être ? http://nantes-en-ratier.com/ Cordialement Le 19/02/2015 13:55, Eric SIBERT a écrit : C'est marrant. Sur les panneaux d'entrée-sortie du village, j'ai noté avec 2 t. Je ne sais pas où j'ai pris cette info car je ne retrouve pas de photo des panneaux. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] Straßenbahngleise auf Brücken (Rendering)
Andreas Neumann wrote on 2015-02-19 19:35: Moin, kann es sein, dass Mapnik Straßenbahngleise auf Brücken unter die Straße zeichnet? http://www.openstreetmap.org/way/194083416#map=19/50.92851/11.59543layers=N Sowohl railway=tram als auch highway=tertiary sind mit bridge=yes gekennzeichnet. Sieht so aus. Hier ein Beispiel bei dem nur die Strasse bridge=yes hat, aber beiden den gleichen layer=1 http://www.openstreetmap.org/#map=18/52.44842/13.57431 Hier ein Beispiel bei dem die Strasse layer=1 und die tram layer=2 getaggt ist, ich weiss nicht ob das berücksichtigt wird, aber an den Enden der Brücke gibt es Artefakte. Macht du ein Ticket auf? https://github.com/gravitystorm/openstreetmap-carto tom ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-ja] 基盤地図情報のインポートについて
返信が遅くなり失礼します。 せっかくの機会ですので，以下の考えに対して， 何かコメントを頂けばと思います。 私は，昨日教えて頂いた次のURLは存じ上げず， http://wiki.openstreetmap.org/wiki/JA:GSI_KIBAN 国土地理院の地図の利用手続 http://www.gsi.go.jp/LAW/2930-index.html を読み，可能かと判断いたしました。 ただ，全くのアウト，完全なセーフではなく， 最終的な判断は，法的な判断が入るような内容であるため， 一度相談させて頂ければ，このようにことにならなかったのだと反省しております。 ★ [ご参考] 国土地理院の地図の利用手続 http://www.gsi.go.jp/LAW/2930-index.html 「特に過去3年以内の基本測量成果に関して， 全く同じもの（独自データの付加、データの一部切り出し等がされていないもの）を複製しようとする場合には，承認が認められない。」 また下段： 「承認を得ず利用できる範囲 次に該当する場合は、利用方法が複製・使用いずれであっても、承認を得ずに利用することが可能です。 ・一時的な資料として利用する場合 ・イラスト的に利用する場合」 となっていることからOSMへアップロードする前に， 後に編集すれば，当該地図の「複製」とはならない。 （→一時的な資料として利用） 実際，県南部海陽町 １．OSM： http://www.openstreetmap.org/#map=16/33.6097/134.3526 ２．電子国土基本図（国土地理院） http://portal.cyberjapan.jp/help/development/update_std/#zoom=16lat=33.60661lon=134.35707layers=BTT 見比べていただければ、かなり異なることが分かると思います。 これは地図の複製とは見なされない。 単なる，作業手順効率化のため，ファイルのインポートを利用。 ★ OSMを本格的にやり始めたのは，10月の下旬で， 当初は，基本iDによる衛星写真の手書き，次にJOSMによる基盤地図情報のトレース。 ファイルのインポートの作業を伴い，作業し始めたのは，今年に入ってだと思います。 ファイルのインポート作業においても， 単なる建物ばかり(building=yes)であると，見栄えが悪いので， 別途目立つ・建物工場等をトレースにより，書いておりました。 2015年2月20日 0:24 talk-ja-requ...@openstreetmap.org: Talk-ja メーリングリストへの投稿は以下のアドレスに送ってください． talk-ja@openstreetmap.org Webブラウザを使って入退会するには以下のURLにどうぞ． https://lists.openstreetmap.org/listinfo/talk-ja メールを使う場合，件名(Subject:)または本文に help と書いて以下の アドレスに送信してください． talk-ja-requ...@openstreetmap.org メーリングリストの管理者への連絡は，以下のアドレスにお願いします. talk-ja-ow...@openstreetmap.org 返信する場合，件名を書き直して内容がわかるようにしてください． そのままだと，以下のようになってしまいます． Re: Talk-ja まとめ読み, XX 巻 XX 号 本日の話題: 1. Re: 基盤地図情報のインポートについて (Satoshi IIDA) 2. Re: 基盤地図情報のインポートについて (Hiroshi Miura(@osmf)) 3. Re: 基盤地図情報のインポートについて (yasun...@yamasita.jp) 4. Re: 基盤地図情報のインポートについて (Toshihisa Tanaka) 5. Re: 基盤地図情報のインポートについて (Satoshi IIDA) -- Message: 1 Date: Thu, 19 Feb 2015 23:50:36 +0900 From: Satoshi IIDA nyamp...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Subject: Re: [OSM-ja] 基盤地図情報のインポートについて Message-ID: cagexurbpqzfbp-abwy1du5ro7gg9tou7qortrswou9bepxs...@mail.gmail.com Content-Type: text/plain; charset=utf-8 いいだです。 解説いただきありがとうございます。 ■原則 まず、最も厳格な適用の場合を述べます。 データの改変を実施していても、入力したデータを削除すべき、という適用です。 何故ならば、今回は基本測量成果である基盤地図情報を元データとしており、 測量法の適用範疇内である点が課題である以上、 提供元 (この場合、国土地理院) としても法律運用に基づく利用可否の判断はできず、 可否判断が可能な組織は司法である、という認識を持っています。 つまり、単に提供元に後追いで許諾を貰えばOK、という性質のものではないという認識です。 また、OSMとして、法律に抵触し、なおかつそもそも、 以前に地理院との話し合いの内容に反する状況を維持することは あまりよい事態ではないと考えています。 ■海南町について 現在削除が行われているようです。 作業者とみられるかたからコンタクトあり、削除する方向で進めています。 ■徳島について インポートを実施した範囲が不明確ですので、確認させてください。 徳島県ほぼ全域を作業されているようですが、それで認識はあっていますか？ インポート作業に利用されたアカウントは以下の2つでよいですか？ * 徳島県オープンデータ * mitsurukikkawa ■削除方法について 現状、いつぐらいからインポート作業をされているか不明確であり、 明確な開始時期と範囲の判断がつかないという状態だと認識しています。 それであれば、当該のアカウントから入力された building=yesデータはすべて削除することが望ましいと考えます。 インポートではない、吉川さんが入力されたbuilding=yesデータが巻き込まれる可能性はありますが、 ライセンスと法律を順守する観点から、この場合は疑わしきであっても削除したほうがよいと思っています。 (インポート専用アカウントの作成が求められているのはこういうことが主な理由です。。。) 例えば以下のようなクエリで抽出が可能です。 http://overpass-turbo.eu/s/7Kt ■削除する以外の選択肢について インポートデータの保存・投稿を行う 前に 衛星画像等による加筆編集がデータに対して行われていれば、 まだこれは「もともとのデータは基盤地図情報ではない」といえるかもしれません。 消さないで済む方法として、なにかよいアイデアがあればいただけると嬉しいです。 ただこれは、法律の抜け道を探すことにも直結しかねない問題であり、 後々の法的な禍根を残すことになりかねません。。。 ■いいだとしてはどうしたいのか データを削除したほうがよいと考えています。 僕は厳し目の見方をしているかもしれません。 まずはご意見いただきたいです。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire -- next part -- HTMLの添付ファイルを保管しました... URL: http://lists.openstreetmap.org/pipermail/talk-ja/attachments/20150219/529b9483/attachment-0001.html -- Message: 2 Date: Fri, 20 Feb 2015 00:12:50 +0900 From: Hiroshi Miura(@osmf) miur...@osmf.jp To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Subject: Re: [OSM-ja] 基盤地図情報のインポートについて Message-ID: 54e5fd72.80...@osmf.jp Content-Type: text/plain; charset=utf-8 吉川さん いいださん 皆さん 三浦です。 状況の共有と、対応案の提案ありがとうございます。 大変でも、対応しなくちゃ、な感じですね。 OpenStreetMapのオープンなデータを守るために、ライセンスや規約、 入力方法に問題がでちゃったデータは、一切合切問題が無いように 戻す必要があります。 そうでないと、みんなで地道に作ってきた、とってもオープンなデータが、 オープンにできなくなるからです。 問題が無いようにするために、どうしたらいいか みなさんで相談しながら、 リカバーをできればと思います。 ■削除方法について 現状、いつぐらいからインポート作業をされているか不明確であり、 明確な開始時期と範囲の判断がつかないという状態だと認識しています。 それであれば、当該のアカウントから入力された building=yesデータはすべて削除することが望ましいと考えます。 インポートではない、吉川さんが入力されたbuilding=yesデータが巻き込まれる可能性はありますが、 ライセンスと法律を順守する観点から、この場合は疑わしきであっても削除したほうがよいと思っています。 (インポート専用アカウントの作成が求められているのはこういうことが主な理由です。。。) 例えば以下のようなクエリで抽出が可能です。 http://overpass-turbo.eu/s/7Kt ■削除する以外の選択肢について インポートデータの保存・投稿を行う 前に 衛星画像等による加筆編集がデータに対して行われていれば、 まだこれは「もともとのデータは基盤地図情報ではない」といえるかもしれません。 消さないで済む方法として、なにかよいアイデアがあればいただけると嬉しいです。 ただこれは、法律の抜け道を探すことにも直結しかねない問題であり、 後々の法的な禍根を残すことになりかねません。。。 ■いいだとしてはどうしたいのか データを削除したほうがよいと考えています。 僕は厳し目の見方をしているかもしれません。 まずはご意見いただきたいです。 -- Message: 3
Re: [OSM-talk-fr] cadastre.openstreetmap et import d'adresses
Bon, je n'ai plus quà me plonger un peu plus dans BANO pour faire mes extractions d'adresses. Pour info, nous avons eu une réunion aujourd'hui avec les chefs des services techniques de la collectivité afin de leur présenter l'état d'avancement du projet de référentiel de voirie. Ils ont adhérés au projet et nous continuerons de qualifier la donnée de manière plus fine. Par contre, nous avons eu un nouveau défi, celui de recenser toute la partie hydraulique du territoire (depuis les cours d'eau jusqu'à la petite vanne). - 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/cadastre-openstreetmap-et-import-d-adresses-tp5834244p5834297.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] BANO : Reconnaissance des voies
Bonjour, Le 19/02/2015 11:42, Christian Quest a écrit : Le 19/02/2015 00:39, « Ano59 » a écrit : Bonjour, Contribuant régulièrement dans la région NPDC, je fais partie de la mailing-list de cette région. On m'a redirigé ici afin que je puisse mettre quelques questions / suggestions concernant BANO, en particulier en ce qui concerne la reconnaissance des voies. Je vais faire ça un peu en vrac au fil des problèmes rencontrés. Déjà première suggestion : serait-il possible que BANO reconnaisse les voies OSM portant un tag name:left ou name:right ? En mappant certaines rues entre deux villes, je me suis rendu compte que le cas arrivait souvent (la rue a deux noms différents selon la ville). Ces voies ne sont pas reconnues dans BANO : au mieux seule la portion avec un seule nom est reconnue, si elle existe. En créant 2 relations associatedStreet distincte les scripts BANO retrouveront leurs petits. C'est un peu dommage dans la mesure où créer à la main les relations associatedStreet et ajouter chaque adresse est très chronophage par rapport à un ajout name:left et name:right... Bon cela dit merci, ça m'aide pour mes propres modifs. Du coup la rue en question est incluse dans deux relations associatedStreet ? Dans une moindre mesure, lié au cas précédent, j'ignore si BANO reconnaît correctement des références FANTOIR multiples sur une même rue, telles que ref:FR:FANTOIR=RefX;RefY. J'ai l'impression que non, je peux me tromper. Le ref:FR:FANTOIR est à mettre dans ce cas sur chacune des relations associatedStreet, il est donc unique pour la relation. En fait aux débuts de BANO, j'ajoutais pas mal de relations associatedStreet et quand la référence FANTOIR devait être indiquée, je la plaçais dans ladite relation. Seulement ce n'était jamais reconnu, quand je m'en suis aperçu j'ai dû mettre la référence FANTOIR directement sur la rue. Etait-ce normal à l'époque, et est-ce que ça a vraiment changé maintenant ? Ensuite davantage une question : pourquoi parfois certaines voies dont on indique bien la référence FANTOIR ne sont toujours pas reconnues après MAJ ? Malheureusement je n'ai pas d'exemple sous la main, j'en fournirai si j'en retrouve. C'est tout pour l'instant, merci d'avance pour d'éventuelles réponses, Cordialement, « Ano59 ». Oui, un exemple serait utile pour comprendre ce qui se passe... J'en mettrai un quand j'en retrouverai, ça arrive épisodiquement mais pas si souvent que ça donc pour l'instant j'ai rien. Merci ! Cordialement, « Ano59 ». ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : Reconnaissance des voies
Le 19/02/2015 22:39, « Ano59 » a écrit : En créant 2 relations associatedStreet distincte les scripts BANO retrouveront leurs petits. C'est un peu dommage dans la mesure où créer à la main les relations associatedStreet et ajouter chaque adresse est très chronophage par rapport à un ajout name:left et name:right... Pour t'économiser il y a l'outil de génération d'adresses : http://cadastre.openstreetmap.fr/?type=adresses Bon cela dit merci, ça m'aide pour mes propres modifs. Du coup la rue en question est incluse dans deux relations associatedStreet ? Oui En fait aux débuts de BANO, j'ajoutais pas mal de relations associatedStreet et quand la référence FANTOIR devait être indiquée, je la plaçais dans ladite relation. Seulement ce n'était jamais reconnu, quand je m'en suis aperçu j'ai dû mettre la référence FANTOIR directement sur la rue. Etait-ce normal à l'époque, et est-ce que ça a vraiment changé maintenant ? Sur ce point là non. Le code Fantoir est géré sur les relations depuis le tout début de BANO. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] OpenAerialMap - Catalog Tech Challenge
Hi everyone! As you may have heard (we hope you have) the Humanitarian OpenStreetMap Team is actively developing the relaunched OpenAerialMap project, an effort to make aerial imagery easier to organize, share and use. https://github.com/hotosm/OpenAerialMap Toward that goal, project leader Cristiano Giovando has published the first Tech Challenge to develop a core component of the system, the imagery catalog. http://hot.openstreetmap.org/get_involved/openaerialmap_catalog_tech_challenge If you are a developer who is interested in the project, we really hope you will review the challenge and submit a proposal. Applications must be received by March 5th, 2015. Please pass this along to any individual or group you think might be interested. Cheers, Blake Girardot HOT Volunteer ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 19.02.2015 um 10:46 schrieb Eifelhunde: Am 18.02.2015 um 23:45 schrieb Garry: Am 18.02.2015 um 13:06 schrieb chris66: Weitere Probleme: ... - Wichtige Infos wie maxspeed sind noch lückenhaft ??? es gilt in jedem Land ein generelles Maxspeed (in D außer Autobahnen) Ich versteh die Anmerkung nicht, es besteht doch nicht die Pflicht so schnell zu fahren - selbst wenn Schilder die Geschwindigkeit weiter beschränken ist die Geschwindigkeit keine Pflicht Sorry, war vielleicht missverständlich - ich meine die expliziten streckenabschnittsbezogenen Limits, nicht die generellen landesspezifischen. während gut ausgebaute, gerade Strecken zwar beschränkt sind, aber eine höhere Durchschnittsgeschwindigkeit erlauben. vielleicht erlauben *könnten* Nein, durchaus können. Eine gut ausgebaute Bundesstraße die aber auf 80km/beschränkt ist erlaubt in der Regel eine deutlich höhere Geschwindigkeit als z.B. eine Passstraße die nicht explizit(!) beschränkt ist. Von daher sehe ich weniger die fehlenden maxspeed-Tags als Problem als vielleicht zu grob erfasste Straßenverläufe die den realen Verlauf zu sehr begradigen. Garry Garry ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 19.02.2015 um 11:31 schrieb Martin Vonwald: Kein professioneller Router geht davon aus, dass man die maximal erlaubte Geschwindigkeit auch tatsächlich fahren kann. Je nach Verlauf der Straße werden deutlich niedrigere Geschwindigkeiten angenommen. Auf einer völlig geraden Autobahn im ebenen Gebiet nimmt ein guter Router eine Geschwindigkeit nahe der erlaubten an, idR ca. 5%-10% darunter. Auf einer Passstraße, wo sich eine Serpentine an die nächste reiht, interessiert einen professionellen Router die maximal Woher hat er die Information? Aus dem Preprocessing, Tags oder schaut er sich jedesmal den Verlauf an? Letzteres könnte langwierig werden, oder? Garry ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
On Thu, Feb 19, 2015 at 11:04:11PM +0100, Garry wrote: 80km/beschränkt ist erlaubt in der Regel eine deutlich höhere Geschwindigkeit als z.B. eine Passstraße die nicht explizit(!) beschränkt ist. Von daher sehe ich weniger die fehlenden maxspeed-Tags als Problem als vielleicht zu grob erfasste Straßenverläufe die den realen Verlauf zu sehr begradigen. Gibt es stand heute irgendeine Routingengine für OSM die Geometrien der Straße (Also ausser länge) auswertet? Ich kenne derzeit keine. Man könnte durchaus da ja noch deutlich mehr machen so wie viele Gebäude in der nähe in landuse=residential etc um via heuristik die Geschwindigkeit zu ermitteln. Defakto sind alle router heute total stumpf: switch(highway) trunk) avgspeed=75 residential) avgspeed=10 So zur Veranschaulichung. Selbst der Maxspeed wird nicht in jedem fall zu rate gezogen. Damit lassen sich auch für 90-95% aller fälle sehr passable resultate erzielen. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-ja] 基盤地図情報のインポートについて
松澤です。 * 2015年1月以降 (way._(newer:--MM-DDThh:mm:ssZ) ) のデータを抽出したいのですが、うまくクエリを組み立てることができませ ん。。。 データ全部確認できてないのだけどとりあえずクエリの実行できた。 http://overpass-turbo.eu/s/7Lq 日付を2/10ぐらいにすると見えなくなるので多分大丈夫だと思う。 で、飯田さんのはたぶん、 --MM ^^ --じゃなくて-にすればいいだけだと思ったのだけど。 取り急ぎ。 On 2015/02/20 13:17, Satoshi IIDA wrote: いいだです。 「特に過去3年以内の基本測量成果に関して， 全く同じもの（独自データの付加、データの一部切り出し等がされていない もの）を複製しようとする場合には，承認が認められない。」 こちらですが、正確には以下の文言かな、と思います。 刊行している最新の基本測量成果（過去３年以内に刊行されたものを含む） に対し、何ら手を加えずに全く同じもの（独自データの付加、データの一部切り 出し 等がされていないもの）を複製しようとする場合など、国土交通大臣が行 う地図等の刊行及びインターネット提供を害するおそれがあると認められるもの 等（基盤地図情報は除く） 基盤地図情報を除く、ともあり、基盤地図情報は別のルールであることが明記さ れています。 この場合、基盤地図情報をデータのまま利用する場合、 「3年以上経過していたとしても」「手を加えたとしても」測量法に基づいて 基本測量成果の利用申請を行ったうえで利用することが必要、と考えます。 また、・一時的な資料として利用する場合については、 としさんから言及いただいている内容と同意見であり、 複製の元データとして利用することは想定されていないように読めます。 少なくとも、古橋さんが提示くださっているとおり、国土地理院との調整・確認 が必要な事項と考えます。 イラスト的に利用に基づく、OSMでの利用方法 (トレース) については 古橋さんが解説してくださっているとおりです。 Overpass Turboのクエリについて 2015年1月以降、ということが明確になったので、 * bbox範囲内に存在する * building=yesの 閉じたウェイについて (way[building=yes]) * ユーザは 徳島県オープンデータ あるいは mitsurukikkawaが編集を行っ た (user:徳島県オープンデータ) * 2015年1月以降 (way._(newer:--MM-DDThh:mm:ssZ) ) のデータを抽出したいのですが、うまくクエリを組み立てることができません。。。 こちら、どなたか組み立てていただくことって可能ですか？ http://wiki.openstreetmap.org/wiki/JA:Overpass_API/Overpass_QL http://overpass-turbo.eu/s/7Kt もし削除を行ったとして、その後 みんなでもういちど描画するのは賛成です。 対象地域の分割にあたって、僕の管理するTask Managerでよければ、よろこんで 機能提供します。 Missing MapsはHOT活動が対象ですが、つなげられるとよいですね。 ドキュメンテーションについて マップの描き方のドキュメントもそうなのですが、 OSMコミュニティ内の決め事などを、わかりやすい場所にまとめが必要ですね。。。 osm.jp http://osm.jpか、OSM wikiの日本地域ページかなぁ。 ・○○をしたい(例: インポート、商業利用、タイル利用、等々)のだけど、 どうしたらよいのか みたいなかんじでまとまっていると見やすいのですよね、たぶん。 -- Satoshi IIDA mail: nyamp...@gmail.com mailto:nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Taro Matsuzawa Georepublic Japan mail: t...@georepublic.co.jp web: http://georepublic.co.jp ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 基盤地図情報のインポートについて
むらかみ（centree) です。 マッパー暦も浅く、地理院データの取り扱いについてもおおよそ素人なので恐縮ですが 個人的な意見を述べさせていただきます。 すでに幾人かの方がコメントしておられますが、 （書いている間にも多くの方がコメントされていて議論はかなりつまってきているとも感じますが…） やはりインポートしたデータはあとでいくら目視で手加工、手修正したとしても、削除対象 とすべきなのかなと思います。 OSMJと国土地理院の合意事項は、いわゆる第3者から疑義をかけられても釈明できるような、 幾ばかりかの安全余裕を見ての合意事項のように思われます。 今回のケースのように、インポートしたデータを参考にしていると公言された場合においては 特に国土地理院さん側が何も言わない場合であったとしても、 第3者から『測量法に則って許諾を得ているのか』という指摘を受けることも想定されますし、 『そうではない』ことを第3者に分かっていただくために費やす労力の問題もあります。 そういうリスクの回避と、国土地理院との良好な関係の維持などを考えると 疑われる余地のあるものは、貢献度とデータの量を考えると残念ですが、削除してしまうか 、 疑われないためのそれ相応の理由付けが必要と思います。 一つ前の投稿で どの地域においても、インポートのみはなく、トレースを行っております。 とおっしゃっていたのと思うのですが、 http://www.openstreetmap.org/#map=19/33.59226/134.35871 この辺の区域は建物のポリゴンに特徴があり インポートデータのようにも見えてしまうのですが、トレースも行なっておられますか？ また、作業IDは別ですが https://www.openstreetmap.org/#map=19/34.05012/134.58325 では複数の建物に 縦方向・横方向に規則的な分割線が現れています。 これは通常のタイルからのトレースによっては現れないように思うので、こちら付近も インポートデータに手が加わっていないのではないかなと想定されます。 （間違っていたら申し訳ありません…） インポートされた生デー タがもしそのままアップロードされているとしたら こちらは議論の余地なく、削除対象となると思います。 時代の流れ速いので、やがては国土地理院の方向性も変わって、このようなことで議論が起こっていたことが 笑い話になるときもくるかもしれませんが、現状ではもったいないですが削除して、疑いのより少ない方法で データ再作成が安全と思われます。 かくいう私もマッピングの際はいろんなことが抜けてしまうのでたいそうなことはいえないのですが、 ・手間ではあるが各リレーションごとにソースをつける、または付け加える ・マッピング直前に某大手地図会社の地図を見てしまったときは （不用意にそちらで見た情報がOSMに反映されないよう）普段以上に気を使う ・不明な点があれば（ある程度まとめた上で）MLで質問 など努力しています…。 もし、データ再作成が必要になったときは、たいしたことはできませんが、何かの形で助けになれればとおもいます。 --- むらかみ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk] Quality of OSM Notes
On Thu, Feb 19, 2015 at 11:20 PM, Mateusz Konieczny matkoni...@gmail.com wrote: OSM is easy to edit - I think that it is better to avoid false information. OSM is not easy to edit for beginners (iD is a bit better for start, but it is also quite hard) A fair number of the notes in my areas were people (usually correctly) identifying the business at a given location. Perhaps an easy form could prompt them to enter complete data. This would unburden the note system. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] BANO : Reconnaissance des voies
Le 19 février 2015 22:39, « Ano59 » news_advertis...@yahoo.fr a écrit : Bonjour, Le 19/02/2015 11:42, Christian Quest a écrit : Le 19/02/2015 00:39, « Ano59 » a écrit : Bonjour, Contribuant régulièrement dans la région NPDC, je fais partie de la mailing-list de cette région. On m'a redirigé ici afin que je puisse mettre quelques questions / suggestions concernant BANO, en particulier en ce qui concerne la reconnaissance des voies. Je vais faire ça un peu en vrac au fil des problèmes rencontrés. Déjà première suggestion : serait-il possible que BANO reconnaisse les voies OSM portant un tag name:left ou name:right ? En mappant certaines rues entre deux villes, je me suis rendu compte que le cas arrivait souvent (la rue a deux noms différents selon la ville). Ces voies ne sont pas reconnues dans BANO : au mieux seule la portion avec un seule nom est reconnue, si elle existe. En créant 2 relations associatedStreet distincte les scripts BANO retrouveront leurs petits. C'est un peu dommage dans la mesure où créer à la main les relations associatedStreet et ajouter chaque adresse est très chronophage par rapport à un ajout name:left et name:right... Ce n'est pas si chronophage que ça car il y a en fait peu de voies où c'est nécessaire. Et on l'a vu, les name:left et name:right ne suffisent pas pour les noeuds d'adresse (à moins que sur chacun d'eux on renseigne aussi addr:street, voire même addr:postcode (qui feraient mieux d'être dans la relation associated Street correcte pour chaque commune (ou secteur postal en cas de changement de code postal, y compris au sein d'une même commune, car les facteurs font les deux côtés en même temps même si ces côtés ont des noms du rue différents et sont en fait sur des communes différentes). Là où il n'y a pas de problème de confusion (nom de rue unique, une seule commune, un seul code postal) taguer uniquement les noeuds et way suffit. Les names:left et name:right sont à bannir absolument ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Quality of OSM Notes
I been meaning to write up an email about this subject last week but never got to it. The problem with osm notes i have is scout. The last week I've been trying to close a lot of scout notes and have found that at least 75 of them are app errors. Of which i can doing nothing but close. Just a huge waste of my and other mappers time. Must of them just say app won't pin my location down or i hate this app! Very long list. But in the end it's not a map issue but a app issue. On Feb 19, 2015 11:34 PM, Bryce Nesbitt bry...@obviously.com wrote: In preparation for a project, I made a concerted effort to clear notes in areas I know well. There were a few gems in there, but mostly it was pretty rough going. Many open notes were not actionable: 1) Pure junk (empty, scribbles) 2) Unsolvable wishes 3) Incomplete information (with no way to contact the poster). 4) Requests to add a particular business, which did not interest me. 5) Private notes made by note author for themselves. 6) Lazy Requests to do cleanup that the note writer did not want to do themselves. 7) Gripes about other mappers. 8) Stuff that had already been done. What could be done to make notes better? The current top page introduction reads: *Spotted a mistake or something missing? Let other mappers know so we can fix it. Move the marker to the correct position and type a note to explain the problem. (Please don't enter personal information or information from copyrighted maps or directory listings.)* Could there be a multi step form? Or an extended description: Spotted a mistake or something missing? Let other mappers know so a volunteer can have a look. Move the marker to the correct position and type a note to explain the problem. * Please don't enter personal information or information from copyrighted maps or directory listings. * Please do include references to websites, photos or other documentation. * Please try to be complete, and write with the reader in mind. * For adding features, consider adding them yourself, rather than leaving a note. OSM is easy to edit, and your fellow mappers and community members value contributions. If the number of notes grows faster than the number of mappers, that's a problem. Notes will cease to be useful. There are two solutions: 1) Get more experienced mappers to process notes 2) Increase the friction of creating a note, in hopes that means less notes of higher quality. Your thoughs? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Objet affiché dans rendu OSM mais n'est plus dans la base depuis des semaines?
Bonjour Le 20/02/2015 02:31, Shohreh a écrit : Invisible en zoom 17, visible en zoom 16… http://www.openstreetmap.org/#map=16/48.8458/2.2379layers=C Il faut laisser le temps au temps... Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 03.11.2014 um 00:45 schrieb Alex Barth: I have two questions on the Collective DB alternative: The derivative database consists of the data that has been used as the input data for the geocoding process, as well as the data that has been gained from OpenStreetMap in the process. Any additional data that may be linked to this data, even sitting in the same logical database table, is however not considered to be part of the derivative database (instead it forms a collective database together with the derivative database) and therefore, does not have to be shared under the ODbL. http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative 1. Why is the input data part of the Derivative Database? There is an underlying assumption that the input data will match, in the best case exactly, an object in the OSM dataset, and that you are extracting further information about it (aka its geographic location) from the OSM data. Note that in this model we are treating the input data as a key in to the geocoded dataset. Treating the geocoded results plus input data as a derivative DB sidesteps various issues. They have their roots in, on the one hand, the most popular OSM based geocoder not just returning a pair of coordinates and, on the other hand, us having no control over how geocoding is technically implemented. It further makes clear if that you are using more attributes to improve the geocoding that they are subject to the same terms. 2. This language is not explicit about Geocoding Results from other databases that are stored in the same database. Would they be part of the Derivative Database? I believe that is a not an issue as formulated. You would need a clear way of keeping the data separate. For lack of a better example: two tables: addresses geocoded with OSM, addresses geocoded with here, but IMHO labelling the geocoding source could be considered enough (given that you may want to provide dynamically displayed attribution you would likely want to do this in any case). The real underlying issue is the fallback issue: can a set of negative results (no geocoding result from OSM) form a derivative database? On the fly it is IMHO a non-issue, however in the bulk/permament geocoding scenario it is. Simon signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-ja] 基盤地図情報のインポートについて
いいだです。 「特に過去3年以内の基本測量成果に関して， 全く同じもの（独自データの付加、データの一部切り出し等がされていないもの）を複製しようとする場合には，承認が認められない。」 こちらですが、正確には以下の文言かな、と思います。 刊行している最新の基本測量成果（過去３年以内に刊行されたものを含む）に対し、何ら手を加えずに全く同じもの（独自データの付加、データの一部切り出し 等がされていないもの）を複製しようとする場合など、国土交通大臣が行う地図等の刊行及びインターネット提供を害するおそれがあると認められるもの等（基盤地図情報は除く） 基盤地図情報を除く、ともあり、基盤地図情報は別のルールであることが明記されています。 この場合、基盤地図情報をデータのまま利用する場合、 「3年以上経過していたとしても」「手を加えたとしても」測量法に基づいて 基本測量成果の利用申請を行ったうえで利用することが必要、と考えます。 また、・一時的な資料として利用する場合については、 としさんから言及いただいている内容と同意見であり、 複製の元データとして利用することは想定されていないように読めます。 少なくとも、古橋さんが提示くださっているとおり、国土地理院との調整・確認が必要な事項と考えます。 イラスト的に利用に基づく、OSMでの利用方法 (トレース) については 古橋さんが解説してくださっているとおりです。 Overpass Turboのクエリについて 2015年1月以降、ということが明確になったので、 * bbox範囲内に存在する * building=yesの 閉じたウェイについて (way[building=yes]) * ユーザは 徳島県オープンデータ あるいは mitsurukikkawaが編集を行った (user:徳島県オープンデータ) * 2015年1月以降 (way._(newer:--MM-DDThh:mm:ssZ) ) のデータを抽出したいのですが、うまくクエリを組み立てることができません。。。 こちら、どなたか組み立てていただくことって可能ですか？ http://wiki.openstreetmap.org/wiki/JA:Overpass_API/Overpass_QL http://overpass-turbo.eu/s/7Kt もし削除を行ったとして、その後 みんなでもういちど描画するのは賛成です。 対象地域の分割にあたって、僕の管理するTask Managerでよければ、よろこんで機能提供します。 Missing MapsはHOT活動が対象ですが、つなげられるとよいですね。 ドキュメンテーションについて マップの描き方のドキュメントもそうなのですが、 OSMコミュニティ内の決め事などを、わかりやすい場所にまとめが必要ですね。。。 osm.jpか、OSM wikiの日本地域ページかなぁ。 ・○○をしたい(例: インポート、商業利用、タイル利用、等々)のだけど、 どうしたらよいのか みたいなかんじでまとまっていると見やすいのですよね、たぶん。 -- 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] Quality of OSM Notes
OSM is easy to edit - I think that it is better to avoid false information. OSM is not easy to edit for beginners (iD is a bit better for start, but it is also quite hard) 2015-02-20 7:33 GMT+01:00 Bryce Nesbitt bry...@obviously.com: In preparation for a project, I made a concerted effort to clear notes in areas I know well. There were a few gems in there, but mostly it was pretty rough going. Many open notes were not actionable: 1) Pure junk (empty, scribbles) 2) Unsolvable wishes 3) Incomplete information (with no way to contact the poster). 4) Requests to add a particular business, which did not interest me. 5) Private notes made by note author for themselves. 6) Lazy Requests to do cleanup that the note writer did not want to do themselves. 7) Gripes about other mappers. 8) Stuff that had already been done. What could be done to make notes better? The current top page introduction reads: *Spotted a mistake or something missing? Let other mappers know so we can fix it. Move the marker to the correct position and type a note to explain the problem. (Please don't enter personal information or information from copyrighted maps or directory listings.)* Could there be a multi step form? Or an extended description: Spotted a mistake or something missing? Let other mappers know so a volunteer can have a look. Move the marker to the correct position and type a note to explain the problem. * Please don't enter personal information or information from copyrighted maps or directory listings. * Please do include references to websites, photos or other documentation. * Please try to be complete, and write with the reader in mind. * For adding features, consider adding them yourself, rather than leaving a note. OSM is easy to edit, and your fellow mappers and community members value contributions. If the number of notes grows faster than the number of mappers, that's a problem. Notes will cease to be useful. There are two solutions: 1) Get more experienced mappers to process notes 2) Increase the friction of creating a note, in hopes that means less notes of higher quality. Your thoughs? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-ja] 基盤地図情報のインポートについて
ikiyaです。 としさん 話の流れを見るに、基盤地図情報を元に、Bing 画像で修正（トレース） してコミットされているようですが、すべてのオブジェクトで修正が必要 ならば、そもそも基盤地図を使うメリットがあまり無いように感じます 同意です。別レイヤで背景表示、参照して描く程度でＯＫかと思います。 複数のアカウントがみうけられ作業が続いているので、徳島の作業全体が把握できないので、 あくまで海陽町周辺でＯＳＭアカウント「徳島オープンデータ」で編集されている内容についてのですが、 １．基盤地図情報を一時的な資料として使うなら、ＪＯＳＭで基盤地図情報を背景表示して 別レイヤでデータ入力すればインポートの必要はなく、効率的に編集できます。 ２．編集のsourceタグですがチェンジセットにほとんど「source=GSImaps/std」が付いています。 https://www.openstreetmap.org/changeset/28969562 このタグは地理院地図の標準タイルを参照した場合に使うタグです。 http://wiki.openstreetmap.org/wiki/JA:GSImaps 基盤地図情報を参照した場合は、source=GSI/KIBANをつけるというルールです。 http://wiki.openstreetmap.org/wiki/JA:GSI_KIBAN ３．海陽町周辺の編集について http://www.openstreetmap.org/#map=19/33.60112/134.36098 実際に上記の地域の編集を見ると、Bing画像をもとに編集を続けて いるようですが、ソースタグはGSImaps/stdが使われています。 地理院地図の標準タイルと重ね合わせて見ても、道路、建物等は合わず 地理地図を参照しているとは見えません。 Bing画像参照で描いているならソースタグから地理院地図のGSImaps/stdは外して source=Bingにしていただきたいと思います。 - Original Message - From: Toshihisa Tanaka tosih...@netfort.gr.jp To: talk-ja@openstreetmap.org Date: 2015/2/20, Fri 12:36 Subject: Re: [OSM-ja] 基盤地図情報のインポートについて としです。 On 2015年02月20日 02:44, 徳島県オープンデータ wrote: ... 「承認を得ず利用できる範囲 ... ・一時的な資料として利用する場合 ・イラスト的に利用する場合」 となっていることからOSMへアップロードする前に， 後に編集すれば，当該地図の「複製」とはならない。 （→一時的な資料として利用） http://www.gsi.go.jp/LAW/2930-qa.html#01 からの引用ですが、 === 3.「一時的な資料として利用する」とは？ 打ち合わせ等で一時的に利用し、利用後は保管することなく処分する場合 === 上記のように記されているので、処分している（削除している）なら良いと 思いますが、処分していないならば一時的な資料とはならないように思います。 実際，県南部海陽町 １．OSM： http://www.openstreetmap.org/#map=16/33.6097/134.3526 ２．電子国土基本図（国土地理院） http://portal.cyberjapan.jp/help/development/update_std/#zoom=16lat=33.60661lon=134.35707layers=BTT 見比べていただければ、かなり異なることが分かると思います。 この「異なる」点、本題とはそれますが、気になっています。 これは、地物(事実)としてはどちらがより正確なのでしょう？ 話の流れを見るに、基盤地図情報を元に、Bing 画像で修正（トレース） してコミットされているようですが、すべてのオブジェクトで修正が必要 ならば、そもそも基盤地図を使うメリットがあまり無いように感じます。 初めからトレースのみで良いように思うのですが、トレースのみの場合と、 基盤地図情報を元に修正するのでは、後者の方がどれくらい効率が良いの か気になっています。 もし、トレース不要なくらいに一致してて、そのままコミットすると、 結果は同じでも元ソースが違うので、基盤地図情報をそのままインポート したともなってしまいます。 これは本題とは少し違うのですが、どっちがより正確なんだろう？と ふと疑問に思ったもので記しました。 ではこれにて。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk-fr] BANO : Reconnaissance des voies
Le 20/02/2015 05:46, Philippe Verdy a écrit : Le 19 février 2015 22:39, « Ano59 » news_advertis...@yahoo.fr mailto:news_advertis...@yahoo.fr a écrit : Bonjour, Le 19/02/2015 11:42, Christian Quest a écrit : Le 19/02/2015 00:39, « Ano59 » a écrit : Bonjour, Contribuant régulièrement dans la région NPDC, je fais partie de la mailing-list de cette région. On m'a redirigé ici afin que je puisse mettre quelques questions / suggestions concernant BANO, en particulier en ce qui concerne la reconnaissance des voies. Je vais faire ça un peu en vrac au fil des problèmes rencontrés. Déjà première suggestion : serait-il possible que BANO reconnaisse les voies OSM portant un tag name:left ou name:right ? En mappant certaines rues entre deux villes, je me suis rendu compte que le cas arrivait souvent (la rue a deux noms différents selon la ville). Ces voies ne sont pas reconnues dans BANO : au mieux seule la portion avec un seule nom est reconnue, si elle existe. En créant 2 relations associatedStreet distincte les scripts BANO retrouveront leurs petits. C'est un peu dommage dans la mesure où créer à la main les relations associatedStreet et ajouter chaque adresse est très chronophage par rapport à un ajout name:left et name:right... Ce n'est pas si chronophage que ça car il y a en fait peu de voies où c'est nécessaire. Et on l'a vu, les name:left et name:right ne suffisent pas pour les noeuds d'adresse (à moins que sur chacun d'eux on renseigne aussi addr:street, voire même addr:postcode (qui feraient mieux d'être dans la relation associated Street correcte pour chaque commune (ou secteur postal en cas de changement de code postal, y compris au sein d'une même commune, car les facteurs font les deux côtés en même temps même si ces côtés ont des noms du rue différents et sont en fait sur des communes différentes). Là où il n'y a pas de problème de confusion (nom de rue unique, une seule commune, un seul code postal) taguer uniquement les noeuds et way suffit. Les names:left et name:right sont à bannir absolument ! Je ne sais pas si on se comprend bien en fait. En faisant les rapprochements BANO je rapproche des voies à la pelle, souvent en dehors du tag source=* j'ajoute tout simplement name=* au way qui constitue la rue, le rapprochement est ainsi fait. Parfois il faut rajouter ref:FR:FANTOIR=[RefX]. Mais je ne mappe pas les adresses, c'est à dire que je ne crée pas les relations associatedStreet ni les nodes comportant addr:housenumber, sauf cas exceptionnel. Ma demande / proposition, c'était que BANO reconnaisse les name:right et name:left sur un way avec un tag highway=* au même titre qu'il reconnaît les name tout court. Probablement une mauvaise compréhension de mes propos, donc. Car effectivement je vois pas l'intérêt d'ajouter name, name:left ou name:right sur un noeud d'adresse. Ou bien si c'était bien ce qui avait été compris, c'est moi qui ne percute pas. Le 19/02/2015 23:04, Vincent de Château-Thierry a écrit : Le 19/02/2015 22:39, « Ano59 » a écrit : En créant 2 relations associatedStreet distincte les scripts BANO retrouveront leurs petits. C'est un peu dommage dans la mesure où créer à la main les relations associatedStreet et ajouter chaque adresse est très chronophage par rapport à un ajout name:left et name:right... Pour t'économiser il y a l'outil de génération d'adresses : http://cadastre.openstreetmap.fr/?type=adresses Merci, je l'utilise déjà toutefois. ;-) C'est juste un peu lourd à dégainer quand d'ordinaire je passe en coup de vent sur une commune après l'autre en ajoutant des tags name=* à tout va. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] Quality of OSM Notes
In preparation for a project, I made a concerted effort to clear notes in areas I know well. There were a few gems in there, but mostly it was pretty rough going. Many open notes were not actionable: 1) Pure junk (empty, scribbles) 2) Unsolvable wishes 3) Incomplete information (with no way to contact the poster). 4) Requests to add a particular business, which did not interest me. 5) Private notes made by note author for themselves. 6) Lazy Requests to do cleanup that the note writer did not want to do themselves. 7) Gripes about other mappers. 8) Stuff that had already been done. What could be done to make notes better? The current top page introduction reads: *Spotted a mistake or something missing? Let other mappers know so we can fix it. Move the marker to the correct position and type a note to explain the problem. (Please don't enter personal information or information from copyrighted maps or directory listings.)* Could there be a multi step form? Or an extended description: Spotted a mistake or something missing? Let other mappers know so a volunteer can have a look. Move the marker to the correct position and type a note to explain the problem. * Please don't enter personal information or information from copyrighted maps or directory listings. * Please do include references to websites, photos or other documentation. * Please try to be complete, and write with the reader in mind. * For adding features, consider adding them yourself, rather than leaving a note. OSM is easy to edit, and your fellow mappers and community members value contributions. If the number of notes grows faster than the number of mappers, that's a problem. Notes will cease to be useful. There are two solutions: 1) Get more experienced mappers to process notes 2) Increase the friction of creating a note, in hopes that means less notes of higher quality. Your thoughs? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-cz] WeeklyOSM CZ
Ahoj, uz to tady bylo - existuje tydenni shrnuti deni ve svete OSM: http://www.weeklyosm.eu/ s dalsima lidma jsme zacali delat ceske preklady jednotlivych issues: http://www.weeklyosm.eu/cz/page/2 Je s tim prace, takze by nam pomohlo vedet, kolik lidi a) cte weekly OSM v originale (anglictina) b) kolik ma zajem o ceske vydani prosim hlasujte zde: http://www.poll-maker.com/poll244493x88Ff4679-9 c) jestli by byl nekdo dalsi ochotny pomoci aby jsme se mohli u jednolivych cisel vic stridat a mit je tak rychleji k dispozici (ted mame skluz) Diky moc tom.k ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] WeeklyOSM CZ
Ahoj, všiml jsem si, že poslední dvě čísla nic a už jsem se chtěl včera zeptat, ale nedostal jsem se k tomu ;-) S pomocí to vidím bledě, času málo, momentálně nestíhám ani mapovat :-( K anketě: co mám vybrat, když sice čtu v angličtině, ale češtinu mám raději? Marián -- Původní zpráva -- Od: TK tomas.kaspa...@gmail.com Datum: 20. 2. 2015 8:04:07 Předmět: [Talk-cz] WeeklyOSM CZ Ahoj, uz to tady bylo - existuje tydenni shrnuti deni ve svete OSM: http://www.weeklyosm.eu/ s dalsima lidma jsme zacali delat ceske preklady jednotlivych issues: http://www.weeklyosm.eu/cz/page/2 Je s tim prace, takze by nam pomohlo vedet, kolik lidi a) cte weekly OSM v originale (anglictina) b) kolik ma zajem o ceske vydani prosim hlasujte zde: http://www.poll-maker.com/poll244493x88Ff4679-9 c) jestli by byl nekdo dalsi ochotny pomoci aby jsme se mohli u jednolivych cisel vic stridat a mit je tak rychleji k dispozici (ted mame skluz) Diky moc tom.k ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-at] Flurnamenimport in Vorarlberg
On Thu, 19 Feb 2015 23:54:51 +0100 Friedrich Volkmann b...@volki.at wrote: On 19.02.2015 19:50, Jens Steinhauser wrote: Okay, der User hat jetzt die Nodes leicht ausgeduennt, wobei immer noch jede Menge Nodes mit ungeklaerter Lizenzsituation stehen geblieben sind (auf die Changeset-Notiz hat er nicht reagiert). Falls ihn niemand anders noch per PN kontaktieren will, wuerde ich ansonsten alle Flurnamen-Nodes von ihm (und die auch von niemandem anderen bearbeitet wurden) rausloeschen. Na Moment. Solang du nicht belegen kannst, dass eine Lizenz verletzt wurde, hast du kein Recht, deswegen auf eigene Faust zum Löschen anzufangen. Dass ein User nicht antwortet, ist auch keine Rechtfertigung, erst recht nicht wenn du nur 1 Tag zugewartet hast. Du musst ihm schon mindestens eine Woche Zeit zum Antworten geben, schließlich ist es eine private Kommunikation und keine Supporthotline. Ein Massenimport wie dieser (ohne vorherige Absprache), ist auch ohne Lizenzprobleme mit Recht (i.e. community rules) zu reverten, wenn die Nachteile überwiegen. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] BANO : Reconnaissance des voies
Le 19/02/2015 23:04, Vincent de Château-Thierry a écrit : Le 19/02/2015 22:39, « Ano59 » a écrit : En fait aux débuts de BANO, j'ajoutais pas mal de relations associatedStreet et quand la référence FANTOIR devait être indiquée, je la plaçais dans ladite relation. Seulement ce n'était jamais reconnu, quand je m'en suis aperçu j'ai dû mettre la référence FANTOIR directement sur la rue. Etait-ce normal à l'époque, et est-ce que ça a vraiment changé maintenant ? Sur ce point là non. Le code Fantoir est géré sur les relations depuis le tout début de BANO. C'est donc probablement que la source que j'utilisais pour BANO était pas mise à jour en temps réel. Intéressante à savoir pour la suite, la validité du tag dans ces relations, merci. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] [OT] Quale distanza minima tra navigatori satellitari?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 19/02/2015 15:54, Martin Koppenhoefer ha scritto: 2015-02-19 14:10 GMT+01:00 Michele iw1gfv iw1...@yahoo.it: Il problema che si presenta più spesso è il riflesso del segnale sul terreno o su una parete vicina che arriva in ritardo rispetto a quando sarebbe dovuto arrivare +1, particolarmente forte fuori i centri abitati è per esempio il disturbo dalle foglie degli alberi, sopratutto quando sono bagnate. ciao, Martin Ringrazio tutti per le risposte, per quel che mi riguarda questa discussione la considero chiusa, in quanto er il quesito posto, mi avete risposto direi ottimamente. Tenete conto che le slide che sto preparando (praticamente ho già finito aspettavo questa vostra), sono rivolte ad un'utenza di pubblico gnurantdi conseguenza mi limito al puro funzionamento di massima a spanne e questo anche per il sistema di riferimento, mi limito alla pura informazione insomma. grazie ancora. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU5gjeAAoJEMTPIIVov0ZtAmcIALuLnGPlLgrKW20/y4DCkxhx erztZWs52T/rXBjAb5VSIfEPZUZAWhveUEh0XZoOZEWLuhw+9IV9EJ81zWsNE/rS M8L2VHNRaw28J6s61pIRwWEblFPaqJnr42eZAeRUgvLe52e0I39CeM+RsfWpPF0H ACpu4+7EoZcUo6dnP0AONOulZROsWKBzBtGPYjYPR46qX+U8c4T9FuBj1I+6LDjZ DaUofRLs+nJC2COmHa0NmoDC3poxNbzeTd3Y+wGMGHPDFRVROMUDusJaT6MXPMu5 MyxuzlSsAl0Ju3k5SPSwNHp4oGTJdZU5LXwcx9OwA5/V57SeNSntbNiyfaxmzzY= =KI2Y -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
On Thu, 19 Feb 2015, Florian Lohoff wrote: Anliegerverbote sind ein extrem schwieriges Thema zu dem auch noch anderes gehört wie z.b. Tracks. Am Ende werden alle verbote zu einem access=destination. Selbst wenn auf einer Straße ein access=no oder das nur ein Fußweg ist muss der router das dingen benutzen wenn das Ziel an diesem Weg liegt. Deshalb macht OSRM auch murks wenn ich nach Hause möchte. Ich liege an einem Waldweg - nicht asphaltiert, forstwirtschaftlicher Verkehr frei - typ track/grade4. Ja - den muss man befahren um zu mir zu kommen. Dem kann ich mich nur anschliessen, ich wohne aehnlich 'privilegiert' (Sackgasse, Schotterweg, Privatweg). Bis vor ein paar Jahren haben kommerzielle Navis das ueberhaupt nicht gefunden, OSM schon. Inzwischen sagen sie 'die Route beinhaltet nicht-befestigte Teile' oder so... Wenn es keine alternative Zufahrt gibt, muss man da halt durch. A. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Big Lakes
On Thu, 19 Feb 2015 04:29:53 +0100, Paul Norman wrote: The Great Lakes have been discussed a few times on the local lists and the conclusion has been arrived at that they are best represented with natural=coastline. Could you give a short overview of the reasoning leading to the decision? I am fine with it and would be glad if Lake Nasser could be mapped this way, too, because of the big amount of Relation Members. But since the Great Lakes are mapped with coastlines: what are the MPs good for? The collection relations I removed yesterday. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] civici di ferrara - adesso open
http://servizi.comune.fe.it/index.phtml?id=453 almeno qui si potrebbe togliere gmaps? :( Il giorno 19 febbraio 2015 15:49, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2015-02-19 13:00 GMT+01:00 Simone Cortesi sim...@cortesi.com: segnalo che ora i civici di Ferrara adesso sono open: http://www.comune.fe.it/index.phtml?id=3513 ottima notizia, peccato la licenza, non volevano pubblicare con qualcosa più open? Tutte le recenti discussioni hanno sottolineato che dati in ODbL (o in questo caso la IODL che è simile) non si dovrebbe importare per motivo delle CT (evventuale cambio licenza). Infine, con lo stato attuale delle CT [1], gli utenti sono chiesto di garantire anche la possibilità di cambio licenza per i dati da loro caricati: ODbl 1.0 per quanto riguarda il database e DdCL 1.0 per i contenuti individuali del database; CC-BY-SA 2.0; o una altra licenza gratuita e di carattere aperto. I membri di OMSF potranno scegliere altre licenze gratuite e di carattere aperto, le quali si intenderanno approvate con il voto della maggioranza dei 2/3 dei voti dei contributori attivi. ciao, Martin [1] http://www.osmfoundation.org/wiki/License/Contributor_Terms/IT ___ 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: [OSM-ja] 道路規制
yuu hayashi wrote: 何度も何度も申し上げている通り原付は「原動機付自転車」__という括りの「車 両」であり,__自転車でも軽車両で も自動二輪ではないという理解ですが,__伝わって いませんでしょうか。 この件については、私以外の方からも同様な指摘がなされておりますし、前回の メールで詳しく説明していますので、繰り返しませんが、 「５０ｃｃバイクの法的分類の問題は世間一般に広く知れ渡った問題であり、す でに司法、行政の面から答えが出ている」 ということをご理解いただきたい。 私からのお願いとして、どうか交通標識の「自転車」に”原付”が含まれているか どうかご自身で調べていただきたいです。 わたしに読解力がないのでしょうか。交通法でも車両法でも原付は原動機付き自 動車としか解釈することができません。車両法には自転車の規定がないのでどっ ちでもなく(軽車両の規定(法 2条4項と施行令 1条)があるが該当しない),交通法 では自転車に原付は含まれない(法 2条8項から2条11の3項),以前からこの考えは 変わっていない。伝わっていないのであれば謝罪をします。 標識令 別表2 備考1 1の6では普通自転車の略称として「自転車」を表示してい るので,原付は該当しないと考えています。 最後に,これ以上コミュニティーに余計な負荷をかけるの心苦しいので当件のこ とはなかったことにしていただければ幸いでございます。お手数をおかけして申 し訳ありませんでした。 - surgical21 e-mail : surgicalmask...@gmail.com twitter : @surgical21 live in : Tokorozawa,Kantô,JP -- ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk-fr] cadastre.openstreetmap et import d'adresses
A mon avis, si on veut vraiment exploiter des données adresse, il vaut mieux repartir de BANO qui est bien plus complet et où tout est homogénéisé. Lorsqu'on veut exploiter des données brutes OSM, il faut s'adapter à leur variations (exemple simple avec le oneway=yes et oneway=-1). Si l'on commence à doublonner associatedStreet avec addr:street, on aura toujours des données qui ne le seront pas et donc si on veut exploiter comme il faut le tout, il faut de toute façon gérer ces variations. C'est à ça que servent les exports thématiques des données OSM, simplifier l'usage et homogénéiser, comme le fait geofabrik avec ses shapefile, ou BANO pour les adresses. Le 19/02/2015 14:05, Tony Emery a écrit : Bonjour à tous, Pour aller plus loin dans l'import des adresses dans OSM via l'outil cadastre.openstreetmap, on ne peut choisir entre 2 options, créer une relation de type associatedStreet et y mettre les tronçons de voies et les adresses, ou importer seulement les adresses avec le tag addr:street (et donc sans les relations). Ne pourrait-on pas avoir les 2 car, même s'il y a redondance dans l'information, les personnes qui souhaite exploiter cette donnée pourraient préférer l'une ou l'autre. En y mettant les deux, on rendrait service à 2 fois plus de monde. Du coup, si on a déjà importer les adresses avec la méthode des relations associatedStreet, peut-on y ajouter les tags addr:street de manière automatique (en les récupérant du nom de la relation associatedStreet) ? - 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/cadastre-openstreetmap-et-import-d-adresses-tp5834244.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-be] geoloket buurtwegen (Atlas der Buurtwegen)
I'm not sure if it's completely the same, but this should be a digitalisation of the same maps: http://www.geopunt.be/kaart?viewer_url=http%3A%2F%2Fmaps.geopunt.be%2Fresources%2Fapps%2FGeopunt-kaart_app%2Findex.html%3Fid%3Dff8080814b72bbd9014ba25177910025 However, these images are still protected AFAIK. People have put work into digitizing them, and more importantly, rectifying the images. The digitizing and rectifying step is about the same as for aerial imagery, so the protection on it is probably the same too. Regards, Sander 2015-02-19 15:32 GMT+01:00 hvdb henk...@gmail.com: Is it possible to look at this geoloket (Atlas der Buurtwegen) WITHOUT using silverlight from microsoft, because i don't have/want microsoft software on my computer, only linux (ubuntu 14.04) ? And i do not want wine or virtualbox to do a 'simulation' either ;P http://www.provincieantwerpen.be/aanbod/drom/dienst-stedenbouwkundige-beroepen/buurt-en-voetwegen.html I also have emailed the person on that link ; Steven Van Audekercke , with the question about this ... ___ 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] Domande su primo import (un po' urgente)
Ciao, 2015-02-19 15:24 GMT+01:00 francesca santarelli sant.france...@gmail.com: Grazie, il nostro è un sito in cui non noi (salvo rari casi) ma chiunque, per lo più persone a me sconosciute, inseriscono informazioni su eventi e luoghi della cultura (che vengono poi geolocalizzati dal sistema a partire dall'indirizzo fornit), uno alla volta, come gli pare. Quegli inserimenti diventano post in CC BY SA. Mi pare di avere capito insomma che non sono dati utili a OSM, perché su OSM è meglio caricare gli open data al completo dell'anagrafe delle biblioteche (che già c'è a quanto mi pare di vedere) che qualche biblioteca. Il problema che vedo io è che la licenza dei dati (CC-BY-SA) non è compatibile con quella di OSM (ODbL). Quindi i dati non possono essere importati. Inoltre non è chiaro come avviene la geolocalizzazione a partire dall'indirizzo fornito. Se viene usato un servizio di terze parti (tipo Google) per trasformare l'indirizzo in coordinate geografice, allora i dati non possono essere importati perché indirettamente importeremmo dei dati di Google. Ciao, Andrea ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] Nantes-en-Rat(t)ier
Là peut-être ? http://nantes-en-ratier.com/ Cordialement Le 19/02/2015 13:55, Eric SIBERT a écrit : C'est marrant. Sur les panneaux d'entrée-sortie du village, j'ai noté avec 2 t. Je ne sais pas où j'ai pris cette info car je ne retrouve pas de photo des panneaux. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] correção de nome de rua
Thiago, por acaso você está usando o editor JOSM ? Se sim, tem uma extensão muito boa para isto: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-it] Domande su primo import (un po' urgente)
Grazie, il nostro è un sito in cui non noi (salvo rari casi) ma chiunque, per lo più persone a me sconosciute, inseriscono informazioni su eventi e luoghi della cultura (che vengono poi geolocalizzati dal sistema a partire dall'indirizzo fornit), uno alla volta, come gli pare. Quegli inserimenti diventano post in CC BY SA. Mi pare di avere capito insomma che non sono dati utili a OSM, perché su OSM è meglio caricare gli open data al completo dell'anagrafe delle biblioteche (che già c'è a quanto mi pare di vedere) che qualche biblioteca. Insomma, grazie lo stesso. f Il giorno 19 febbraio 2015 14:27, cascafico cascaf...@gmail.com ha scritto: Luigi Toscano wrote Se i dati sono raccolti da persone, la licenza si applica eccome. Con che licenza le persone hanno concesso l'uso dei dati raccolti? Scusa, avrei dovuto citare la Santarelli: [SNIP] tra le altre cose è richiesto ai partecipanti che condividano su OSM dei dati da loro raccolti. [SNIP] - -- cascafico.altervista.org twitter.com/cascafico -- View this message in context: http://gis.19327.n5.nabble.com/Domande-su-primo-import-un-po-urgente-tp5833836p5834251.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] correção de nome de rua
Aun, John, John Packer wrote: por acaso você está usando o editor JOSM ? Se sim, tem uma extensão muito boa para isto: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses Obrigado por responder tão rapidamente. Estou usando o JOSM sim, vou experimentar esse plugin. -- []'s Thiago Jung Bauermann ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [talk-ph] Tagging bridges and tunnels
Hi Eugene the problem is that either bridge:name or bridge_name are osm standards. This is name that is recognized and rendered on the maps. Pierre De : Eugene Alvin Villar sea...@gmail.com À : Pierre Béland pierz...@yahoo.fr Cc : Ervin Malicdem schad...@gmail.com; OSM-PH talk-ph@openstreetmap.org Envoyé le : Jeudi 19 février 2015 7h55 Objet : Re: [talk-ph] Tagging bridges and tunnels Hi Pierre, On Thu, Feb 19, 2015 at 9:24 AM, Pierre Béland pierz...@yahoo.fr wrote: Taginfo shows that tags such as bridge:name and bridge_name are used in other countries, but not in Philippines. bridge:name=* is definitely used in the Philippines. I and a couple or so other mappers have been using it. I have downloaded the latest OSM XML file from Geofabrik, did a grep, and came up with the following numbers: 12121 objects have a bridge=* tag 369 objects have a bridge:name=* tag 42 objects have a bridge_name=* tag See also: http://wiki.openstreetmap.org/wiki/Key:bridge:name ~Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [Talk-it] civici di ferrara - adesso open
2015-02-19 13:00 GMT+01:00 Simone Cortesi sim...@cortesi.com: segnalo che ora i civici di Ferrara adesso sono open: http://www.comune.fe.it/index.phtml?id=3513 ottima notizia, peccato la licenza, non volevano pubblicare con qualcosa più open? Tutte le recenti discussioni hanno sottolineato che dati in ODbL (o in questo caso la IODL che è simile) non si dovrebbe importare per motivo delle CT (evventuale cambio licenza). Infine, con lo stato attuale delle CT [1], gli utenti sono chiesto di garantire anche la possibilità di cambio licenza per i dati da loro caricati: ODbl 1.0 per quanto riguarda il database e DdCL 1.0 per i contenuti individuali del database; CC-BY-SA 2.0; o una altra licenza gratuita e di carattere aperto. I membri di OMSF potranno scegliere altre licenze gratuite e di carattere aperto, le quali si intenderanno approvate con il voto della maggioranza dei 2/3 dei voti dei contributori attivi. ciao, Martin [1] http://www.osmfoundation.org/wiki/License/Contributor_Terms/IT ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] Quale distanza minima tra navigatori satellitari?
2015-02-19 13:46 GMT+01:00 Leonardo Frassetto kinetocor...@gmail.com: Al massimo la differenza tra i due può essere data dalla precisione e dalla stabilità del segnale ricevuto, soprattutto in ambienti con scarsa ricezione (vedi supporto per GPS da solo oppure l'accoppiata GPS+GLONASS). +1, e dal software interno di elaborazione (firmware), i GPS di livello consumer non rendono quasi mai disponibile il segnale grezzo ma registrano dei dati già elaborati internamente (per esempio basato sulle posizioni precendenti, la direzione e la velocità). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-br] correção de nome de rua
Olá novamente, Encontrei dois casos em que o nome da rua no OSM está diferente do nome nas placas na própria rua (erros pequenos, 'e' em vez de 'i' em um caso e um 'h' a mais no outro). Gostaria de corrigir, mas fico na dúvida se tem algum node ou area referenciando esse nome com addr:street para corrigir junto. Tem algum jeito de verificar isso? -- []'s Thiago Jung Bauermann ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] correção de nome de rua
Tem sim, depende um pouco do como voce trabalhando, voce pode fazer um busca dentro o editor, ou pelo ferramentas externas como Overpass. O resposta certa depende disso. Aun Johnsen On Feb 19, 2015, at 12:01, Thiago Jung Bauermann thiago.bauerm...@gmail.com wrote: Olá novamente, Encontrei dois casos em que o nome da rua no OSM está diferente do nome nas placas na própria rua (erros pequenos, 'e' em vez de 'i' em um caso e um 'h' a mais no outro). Gostaria de corrigir, mas fico na dúvida se tem algum node ou area referenciando esse nome com addr:street para corrigir junto. Tem algum jeito de verificar isso? -- []'s Thiago Jung Bauermann ___ 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] State of the Map US conference - June 6-8
Caros, Abaixo mensagem do Martijn Van Exel, membro da diretoria do local chapter US: Hey all, We've been pretty busy organizing the upcoming State of the Map US conference. Time for an update! Firstly, as of today the call for sessions is open. Please do submit your ideas for a talk, a lightning talk, or a different type of session. We welcome any and all topics related to OSM: your local community initiative, interesting uses and applications of OSM, your teaching project, a tech or cartographic deep dive...Too many possibilities to list! Head over to http://stateofthemap.us/ to submit your proposal. Also, a reminder that we're running a pretty great scholarship program. If you belong at State of the Map US but money is an issue, there's help. Applications for the scholarship program are open for a little while longer, again, head over to http://stateofthemap.us/ to learn more and apply. Speaking of $. We realize NYC can be an expensive place, so we've made a big effort to find affordable accommodations. Prices start at $45 a night but rooms / beds are limited, so head over to http://stateofthemap.us/ and book soon. I was not going to make this into a long email but one more thing..: registration is open for early bird tickets which are $90 only, this will not last long and considering what you'll get for this money it's a total bargain :) You know where to go by now! Let me know if you have any questions or ideas about SOTM US, and I hope to see many of you June 6-8 in NYC. -- Martijn Thierry Jean ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
