Re: [OSM-talk-fr] 26 futurs géomaticiens formés à OSM
@Nicolas. Oups j'ai un peu décroché ce WE. Je prévois de mettre les supports (fichiers .odp avec tout mon bavardage en notes) sur mon site, je peux aussi les mettre sur openstreetmap.fr : je veux bien que tu me précises où voire comment. Antoine. Le 30/01/2015 18:17, Nicolas Moyroud a écrit : Bonjour Antoine, Bravo pour ces deux présentations OSM. Super boulot ! Merci également pour le partage. J'interviens sur quelques modules géomatique à l'université Montpellier 2 et j'ai eu l'occasion de leur faire quelques présentations OSM. C'est dommage, je n'ai pas pensé comme toi à compter les étudiants. ;-) Il y a des choses intéressantes dans tes slides dont je vais pouvoir m'inspirer pour améliorer mes supports. :-) As-tu pensé à mettre en téléchargement les fichiers sources qui ont servis à faire ces présentations ? Si oui où peut-on les récupérer ? Ce serait peut-être intéressant de les mettre en téléchargement sur une plate-forme qui ne nécessite pas de compte, par exemple sur openstreetmap.fr. Sinon je peux les héberger avec les supports de présentations que je met en ligne sur mon site. Merci a+ Le 30/01/2015 10:04, Antoine Riche a écrit : Bonjour, Lundi 26 janvier j'ai formé 26 étudiants de Licence Pro GGAT (Génie Géomatique pour l'Aménagement du Territoire) à Auch à l'utilisation des données OpenStreetMap. La matinée consistait en deux cours dont les supports sont disponibles en cc-by-sa : * Introduction à OpenStreetMap : http://www.slideshare.net/cartocite/introduction-openstreetmap * OpenStreetMap pour les géomaticiens : http://www.slideshare.net/cartocite/openstreetmap-pour-les-gomaticiens L'après-midi était consacrée à un TP, au cours duquel les étudiants ont intégré dans QGis données OSM de diverses manières : export Geofabrik avec styles 3Liz, Overpass Turbo, plugin QuickOSM, extraction de données brutes avec osmconvert et osmfilter. Antoine. ___ 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] Détermination des communes littorales
Bonjour à tous, Avec mon approche simpliste, je trouve pour la Bretagne 262 communes après quelques requêtes spatialite.Visuellement cela me semble correct. Mon besoin est juste d'analyser la différence de pression d'observation des oiseaux entre le littoral et le reste de la Bretagne, je peux donc tolérer quelques inexactitudes. -- View this message in context: http://gis.19327.n5.nabble.com/Determination-des-communes-littorales-tp5832009p5832220.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] Rencontre parisienne OSM au Numa le 30 janvier 2015
Bonjour, > De: "Vincent de Château-Thierry" > > Autre questionnement hier, suite à une récente cartopartie au > Père-Lachaise : comment décrire, mieux qu'avec un simple tag name, > les subdivisions des cimetières ? Comme ici : > http://www.openstreetmap.org/way/177232497 Je tombe sur cette proposition en cours, avec déjà un peu d'usage (~2300 ways) : http://wiki.openstreetmap.org/wiki/Proposed_features/Cemetery_sector vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Base de données pour le développement
Bonjour à tous,
Je suis un nouvel inscrit à la liste et j'aimerais contribuer ce fabuleux
projet qu'est OSM :)
J'ai pour projet de faire un programme pour importer dans OSM une base de
données d'immeubles (PSS) afin de rajouter les informations de hauteur (ou
au moins le nombre d'étages) sur les bâtiments, ceci afin d'avoir des
rendus 3D plus réalistes (voir la liste des projets relatifs à la 3D:
http://wiki.openstreetmap.org/wiki/3D_Development).
J'ai commencé à faire le programme mais je me heurte à un problème tout
bête : il est fortement conseillé, si ça n'est obligatoire, d'utiliser les
serveurs de développement afin de faire ses tests, ce qui est plutôt
logique. On peut donc par ex utiliser celui ci :
http://master.apis.dev.openstreetmap.org (équivalent à
http://api06.dev.openstreetmap.org).
Mais le problème est qu'il n'y a visiblement aucune donnée dans la BD !
Quelque soit l'ID du node je me retrouve toujours avec une erreur 404 ("Not
found") dès que je fait un GET, alors que ce sont des IDs tout à fait
valides sur le serveur principale.
D'ailleurs en utilisant la fonctionnalité "Query feature" de la carte, si
on clique sur n'importe quel objet on a une erreur du type "Désolé, chemin
#116602263 n’a pas pu être trouvé."
Mes craintes se sont confirmées en voyant sur la page
http://wiki.openstreetmap.org/wiki/Sandbox_for_editing cette phrase :
"...but the database may be empty or populated with only some test data,
and non of them are currently hooked into a rendering stack, so you wont
see your data change on a map".
Mais s'il n'y a pas d’éléments dans la base de données de tests, comment on
teste ? :)
Merci d'avance pour votre aide,
Vincent.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base de données pour le développement
Dans ce cas tu télécharges une zone pour tes tests depuis la base
principale vers un fichier OSM, tu changes l'adresse de l'API ou tu
utilises une autre session JOSM pour le faire. Et tu envoies les données de
cette zone de test sur la base de test.
Après tu peux faire ce que tu veux...
Cette base de test ne garantie pas la conservation à long terme des données
il me semble (elle n'est pas taillée pour). Elle peut être purgée sans
prévenir si elle devient trop volumineuse dans sa config limitée). Elle ne
garantie pas non plus de bonnes performances (temporairement elle peut être
sollicitée par d'autres tests concurrents).
Elle peut aussi contenir des erreurs insérées volontairement pour tester le
comportement de certains logiciels.
S'il y a des données qui te gène dans ta zone de test (et qui ne sont assez
anciennes) tu peux les virer, mais choisis plutôt une zone vierge si tu
peux.
Aucune idée de l'échelle de ton test : toute une grande ville comme Paris,
Lyon, Marseille, Lille ou Bordeaux ? il y a des tas de trucs spécifiques
dans ces villes.
Après, à toi de faire tes tests de rendu.
Garde tes fichiers OSM que tu souhaites valider en test si ensuite tu
comptes les envoyer sur la base principale, mais attends toi à un travail
supplémentaire de fusion... et de résolutions des conflits si les données
OSM que tu as importées initialement en test ont été touchées sur la base
principale pendant que tu les modifiais pour tes tests.
En aucun cas tu ne doit réimporter directement les données brutes extraites
de la base de test vers la base principale (à cause des erreurs volontaires
et autres tests concurrents qui peuvent même avoir des données arbitraires
qui ne correspondent à rien dans la réalité).
Donc il vaut mieux que tu crées des fichiers OSM de petite taille pour
rendre gérable le travail de fusion et résolution des conflits sinon tu y
passeras un temps fou et certains pourrais faire des reverts de tes modifs
partielles suspendues à de nombreuses résolutions de conflits (et tu
devrais alors recommencer en tenant compte des conflits générés par les
reverts de tout ce que tu as partiellement envoyés mais qui ne sont plus là
pour continuer).
Il est possible aussi de créer ta propre base de test (c'est open-source)
et tu n'y seras pas gêné par les autres. A toi de la tailler selon tes
besoins.
Le 2 février 2015 19:08, Vincent Frison a écrit :
> Bonjour à tous,
>
> Je suis un nouvel inscrit à la liste et j'aimerais contribuer ce fabuleux
> projet qu'est OSM :)
>
> J'ai pour projet de faire un programme pour importer dans OSM une base de
> données d'immeubles (PSS) afin de rajouter les informations de hauteur (ou
> au moins le nombre d'étages) sur les bâtiments, ceci afin d'avoir des
> rendus 3D plus réalistes (voir la liste des projets relatifs à la 3D:
> http://wiki.openstreetmap.org/wiki/3D_Development).
>
> J'ai commencé à faire le programme mais je me heurte à un problème tout
> bête : il est fortement conseillé, si ça n'est obligatoire, d'utiliser les
> serveurs de développement afin de faire ses tests, ce qui est plutôt
> logique. On peut donc par ex utiliser celui ci :
> http://master.apis.dev.openstreetmap.org (équivalent à
> http://api06.dev.openstreetmap.org).
>
> Mais le problème est qu'il n'y a visiblement aucune donnée dans la BD !
> Quelque soit l'ID du node je me retrouve toujours avec une erreur 404 ("Not
> found") dès que je fait un GET, alors que ce sont des IDs tout à fait
> valides sur le serveur principale.
>
> D'ailleurs en utilisant la fonctionnalité "Query feature" de la carte, si
> on clique sur n'importe quel objet on a une erreur du type "Désolé, chemin
> #116602263 n’a pas pu être trouvé."
>
> Mes craintes se sont confirmées en voyant sur la page
> http://wiki.openstreetmap.org/wiki/Sandbox_for_editing cette phrase :
> "...but the database may be empty or populated with only some test data,
> and non of them are currently hooked into a rendering stack, so you wont
> see your data change on a map".
>
> Mais s'il n'y a pas d’éléments dans la base de données de tests, comment
> on teste ? :)
>
> Merci d'avance pour votre aide,
>
> 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: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 01/02/2015 21:12, Philippe Verdy a écrit : Note: le noms des deux relations (name=*) devrait être suffixé pour éviter l'homonymie. J’ai fait une recherche et je n'ai pas trouvé de description sur la manière de faire (séparation entre radical et suffixe et le suffixe lui-même - name, code insee ... - ). Est-ce : name = "Avenue des Chênes:Bordeaux" pour l'une et name = "Avenue des Chênes:Mérignac" pour l'autre ? On peut toujours indiquer le nom **non suffixé** de la rue dans le tag addr:street=* de la relation. Et puisque tous les membres (la voie notamment) ne sont pas dans le périmètre des communes, ils ne sont pas non plus dans le périmètre par défaut du code postal (qui n'est mentonné presque partout QUE dans la commune). Il faudra donc aussi compléter addr:postalcode=* dans la relation associatedStreet qui a des éléments à cheval de dexu communes ou sur la frontière communale. Ok ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 02/02/2015 20:20, lenny.libre a écrit : Le 01/02/2015 21:12, Philippe Verdy a écrit : Note: le noms des deux relations (name=*) devrait être suffixé pour éviter l'homonymie. J’ai fait une recherche et je n'ai pas trouvé de description sur la manière de faire (séparation entre radical et suffixe et le suffixe lui-même - name, code insee ... - ). Est-ce : name = "Avenue des Chênes:Bordeaux" pour l'une et name = "Avenue des Chênes:Mérignac" pour l'autre ? On peut toujours indiquer le nom **non suffixé** de la rue dans le tag addr:street=* de la relation. Si on en est là, autant laisser comme name=* de la relation le nom de terrain (sans nom de ville accolé) et ajouter à titre indicatif un tag addr:city à la relation, ou une note disant la même chose. Quand il existe (ce qui n'est en rien obligatoire), le tag name des relations associatedStreet sert dans BANO. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Espaces demi m....
Et quel bonheur de voir des commentaires aussi... incisifs sur le wiki, aussi: https://josm.openstreetmap.de/wiki/StartupPageSource?action=diff&version=1533 Heureusement que les contributeurs au wiki sont en général plus sympas sinon aucun développeur de JOSM ne continuerait à participer bénévolement. Le 1 février 2015 20:38, Philippe Verdy a écrit : > Et non ce n'est PAS un fichier de config de JOSM, JOSM se contente de lire > le HTML généré par une page wiki de JOSM. > > Si les fautes d'orthographe te plaisaient, mois pas. > > A ce sujet je ne sais pas qui a fait la traduction française de plein de > trucs dans JOSM mais elle est bourrée de fautes (et aussi de contre-sens et > faux-amis) ! > Ca commence à m'agacer de les voir en permanence dans l'interface depuis > un moement sans personne pour les corriger. > > Le 1 février 2015 20:32, Philippe Verdy a écrit : > > Quel espaces ??? Ce sont les indentations des puces de la page wiki et >> elles y sont comem sur les autres pages. >> Mes contribs sur cette page consistaient à corriger les "fôtes" de >> français. >> >> Le 1 février 2015 19:51, Marc Sibert a écrit : >> >> Bonjour, >>> >>> Il y a un personnage maladroit qui a ajouté des espaces de m... dans les >>> fichiers de config de JOSM. Des trucs qui sont placés avant les signes de >>> ponctuation double, un certain "verdy_p". S'il peut faire marche arrière >>> immédiatement, ça éviterait des (pas) jolis carrés dans mon JOSM. >>> >>> Merci... pour la correction (pas pour la contribution). >>> >>> A+ >>> >>> -- >>> Marc Sibert >>> mailto:m...@sibert.fr >>> >>> >> > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base de données pour le développement
Merci Philippe pour ta réponse. Je reste cependant surpris du fait que la base de test soit par défaut vide ou quasiment. Après qu'elle soit lente, instable et non durable ça c'est tout à fait normal mais je ne vois pas vraiment pourquoi il n'y aurait pas par défaut une copie des données de la vrai base.. Bon en suivant ton idée j'ai donc essayé de la remplir un peu avec JOSM. J'ai changé l'URL à http://api06.dev.openstreetmap.org/api, j'ai téléchargé une petite zone de test et fait quelques modifs mais dès que j'essaye d'uploader j'ai ce message d'erreur : Le serveur 'http://api06.dev.openstreetmap.org/api/0.6/' ne reconnaît pas un objet que vous essayez de lire, mettre à jour ou supprimer. Soit cet objet n’existe pas sur le serveur, soit vous utilisez une adresse web qui n’est pas valide pour y accéder. Veuillez vérifier l’adresse du serveur ' http://api06.dev.openstreetmap.org/api/0.6/'. En gros il peut pas faire de PUT sur une ressource qui n'existe pas.. ou alors il faudrait faire comprendre à JOSM que ce sont des nouveaux éléments à créer (et non pas des éléments existant à mettre à jour) ? Sinon mon programme devrait fonctionner de la manière suivante : 1) Pour chaque immeuble de la base à importer je calcule l'osmId du building correspondant à la position géographique de l'immeuble (grâce à une base PostGIS en local contenant les données OSM de la France). 2) Si un ID de building est trouvé je télécharge le way depuis l'API d'OSM et si le way ne contient pas d'informations sur la hauteur ou sur le nombre d'étages alors je les renseigne. 3) Je met à jour l'élément dans la foulée, il y a donc très peu de chance d'avoir des accès concurrents puisque le délai est de quelques millisecondes. La base de données concerne environ 40 000 immeubles répartie sur toute la France mais de toute façon je comptais bien lancer un nouveau sujet pour détailler et demander des conseils techniques voir légaux. Pour l'instant mon problème est juste sur la base de données de test... ++ Vincent Le 2 février 2015 19:27, Philippe Verdy a écrit : > Dans ce cas tu télécharges une zone pour tes tests depuis la base > principale vers un fichier OSM, tu changes l'adresse de l'API ou tu > utilises une autre session JOSM pour le faire. Et tu envoies les données de > cette zone de test sur la base de test. > Après tu peux faire ce que tu veux... > Cette base de test ne garantie pas la conservation à long terme des > données il me semble (elle n'est pas taillée pour). Elle peut être purgée > sans prévenir si elle devient trop volumineuse dans sa config limitée). > Elle ne garantie pas non plus de bonnes performances (temporairement elle > peut être sollicitée par d'autres tests concurrents). > > Elle peut aussi contenir des erreurs insérées volontairement pour tester > le comportement de certains logiciels. > > S'il y a des données qui te gène dans ta zone de test (et qui ne sont > assez anciennes) tu peux les virer, mais choisis plutôt une zone vierge si > tu peux. > > Aucune idée de l'échelle de ton test : toute une grande ville comme Paris, > Lyon, Marseille, Lille ou Bordeaux ? il y a des tas de trucs spécifiques > dans ces villes. > > Après, à toi de faire tes tests de rendu. > > Garde tes fichiers OSM que tu souhaites valider en test si ensuite tu > comptes les envoyer sur la base principale, mais attends toi à un travail > supplémentaire de fusion... et de résolutions des conflits si les données > OSM que tu as importées initialement en test ont été touchées sur la base > principale pendant que tu les modifiais pour tes tests. > > En aucun cas tu ne doit réimporter directement les données brutes > extraites de la base de test vers la base principale (à cause des erreurs > volontaires et autres tests concurrents qui peuvent même avoir des données > arbitraires qui ne correspondent à rien dans la réalité). > > Donc il vaut mieux que tu crées des fichiers OSM de petite taille pour > rendre gérable le travail de fusion et résolution des conflits sinon tu y > passeras un temps fou et certains pourrais faire des reverts de tes modifs > partielles suspendues à de nombreuses résolutions de conflits (et tu > devrais alors recommencer en tenant compte des conflits générés par les > reverts de tout ce que tu as partiellement envoyés mais qui ne sont plus là > pour continuer). > > Il est possible aussi de créer ta propre base de test (c'est open-source) > et tu n'y seras pas gêné par les autres. A toi de la tailler selon tes > besoins. > > > > Le 2 février 2015 19:08, Vincent Frison a > écrit : > >> Bonjour à tous, >> >> Je suis un nouvel inscrit à la liste et j'aimerais contribuer ce fabuleux >> projet qu'est OSM :) >> >> J'ai pour projet de faire un programme pour importer dans OSM une base de >> données d'immeubles (PSS) afin de rajouter les informations de hauteur (ou >> au moins le nombre d'étages) sur les bâtiments, ceci afin d'avoir des >> rendus 3D plus réalistes (voir la liste des projets relatifs à la 3D: >> http://w
Re: [OSM-talk-fr] Base de données pour le développement
Vincent, si tu copies dans une zone vide sur le serveur de test, il faudrait sans doute que tu modifies ton fichier OSM pour simuler de nouvelles données avec ID négatif. Pierre De : Vincent Frison À : verd...@wanadoo.fr; Discussions sur OSM en français Envoyé le : Lundi 2 février 2015 17h12 Objet : Re: [OSM-talk-fr] Base de données pour le développement Merci Philippe pour ta réponse. Je reste cependant surpris du fait que la base de test soit par défaut vide ou quasiment. Après qu'elle soit lente, instable et non durable ça c'est tout à fait normal mais je ne vois pas vraiment pourquoi il n'y aurait pas par défaut une copie des données de la vrai base.. Bon en suivant ton idée j'ai donc essayé de la remplir un peu avec JOSM. J'ai changé l'URL à http://api06.dev.openstreetmap.org/api, j'ai téléchargé une petite zone de test et fait quelques modifs mais dès que j'essaye d'uploader j'ai ce message d'erreur : Le serveur 'http://api06.dev.openstreetmap.org/api/0.6/' ne reconnaît pas un objet que vous essayez de lire, mettre à jour ou supprimer. Soit cet objet n’existe pas sur le serveur, soit vous utilisez une adresse web qui n’est pas valide pour y accéder. Veuillez vérifier l’adresse du serveur 'http://api06.dev.openstreetmap.org/api/0.6/'. En gros il peut pas faire de PUT sur une ressource qui n'existe pas.. ou alors il faudrait faire comprendre à JOSM que ce sont des nouveaux éléments à créer (et non pas des éléments existant à mettre à jour) ? Sinon mon programme devrait fonctionner de la manière suivante :1) Pour chaque immeuble de la base à importer je calcule l'osmId du building correspondant à la position géographique de l'immeuble (grâce à une base PostGIS en local contenant les données OSM de la France).2) Si un ID de building est trouvé je télécharge le way depuis l'API d'OSM et si le way ne contient pas d'informations sur la hauteur ou sur le nombre d'étages alors je les renseigne.3) Je met à jour l'élément dans la foulée, il y a donc très peu de chance d'avoir des accès concurrents puisque le délai est de quelques millisecondes. La base de données concerne environ 40 000 immeubles répartie sur toute la France mais de toute façon je comptais bien lancer un nouveau sujet pour détailler et demander des conseils techniques voir légaux. Pour l'instant mon problème est juste sur la base de données de test... ++ Vincent Le 2 février 2015 19:27, Philippe Verdy a écrit : Dans ce cas tu télécharges une zone pour tes tests depuis la base principale vers un fichier OSM, tu changes l'adresse de l'API ou tu utilises une autre session JOSM pour le faire. Et tu envoies les données de cette zone de test sur la base de test.Après tu peux faire ce que tu veux...Cette base de test ne garantie pas la conservation à long terme des données il me semble (elle n'est pas taillée pour). Elle peut être purgée sans prévenir si elle devient trop volumineuse dans sa config limitée). Elle ne garantie pas non plus de bonnes performances (temporairement elle peut être sollicitée par d'autres tests concurrents). Elle peut aussi contenir des erreurs insérées volontairement pour tester le comportement de certains logiciels. S'il y a des données qui te gène dans ta zone de test (et qui ne sont assez anciennes) tu peux les virer, mais choisis plutôt une zone vierge si tu peux. Aucune idée de l'échelle de ton test : toute une grande ville comme Paris, Lyon, Marseille, Lille ou Bordeaux ? il y a des tas de trucs spécifiques dans ces villes. Après, à toi de faire tes tests de rendu. Garde tes fichiers OSM que tu souhaites valider en test si ensuite tu comptes les envoyer sur la base principale, mais attends toi à un travail supplémentaire de fusion... et de résolutions des conflits si les données OSM que tu as importées initialement en test ont été touchées sur la base principale pendant que tu les modifiais pour tes tests. En aucun cas tu ne doit réimporter directement les données brutes extraites de la base de test vers la base principale (à cause des erreurs volontaires et autres tests concurrents qui peuvent même avoir des données arbitraires qui ne correspondent à rien dans la réalité). Donc il vaut mieux que tu crées des fichiers OSM de petite taille pour rendre gérable le travail de fusion et résolution des conflits sinon tu y passeras un temps fou et certains pourrais faire des reverts de tes modifs partielles suspendues à de nombreuses résolutions de conflits (et tu devrais alors recommencer en tenant compte des conflits générés par les reverts de tout ce que tu as partiellement envoyés mais qui ne sont plus là pour continuer). Il est possible aussi de créer ta propre base de test (c'est open-source) et tu n'y seras pas gêné par les autres. A toi de la tailler selon tes besoins. Le 2 février 2015 19:08, Vincent Frison a écrit : Bonjour à tous, Je suis un nouvel inscrit à la liste et j'aimerais contribuer ce fabuleux projet qu'est OSM :) J'
Re: [OSM-talk-fr] Base de données pour le développement
Bonsoir et bienvenue, Le 02/02/2015 23:12, Vincent Frison a écrit : La base de données concerne environ 40 000 immeubles répartie sur toute la France mais de toute façon je comptais bien lancer un nouveau sujet pour détailler et demander des conseils techniques voir légaux. Pour l'instant mon problème est juste sur la base de données de test... Ou bien demander des conseils légaux voire techniques ;) Tu as des infos sur la licence associée aux données de la base PSS ? C'est, comme pour tout apport de données d'une base externe, la première question à voir, sachant qu'elle peut à elle toute seule bloquer la suite. Je vois que ce fil : http://www.pss-archi.eu/forum/viewtopic.php?id=33791 n'a pas déchaîné les foules, et comme turman (toi ?) je n'ai rien trouvé sur le statut de cette base. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base de données pour le développement
quand tu as chargé des objets depuis OSM, ils comportent un numéro de version qui n'existe pas sur le serveur de test où ils doivent non pas être modifiés ou supprimés mais créés. Pour les mettre en création, il faut d'abord ôter leur numéro de version (directement dans le code XML), et mettre leurs ID en valeur négative (change simplement de signe), et les marquer en "modified" pour qu'ils puissent être envoyés comme s'ils venaient d'être créés. . Une petite manip à faire à coup de "grep" ou avec un éditeur supportant les recherches/substitutions d'expressions régulières (garde l'original, sauve dans un nouveau fichier OSM, tu peux facilement te planter dans la transformation et JOSM te dira que ton fichier est invalide ou t'affichera n'importe quoi). (tu peux aussi ajouter un tag "source:test=sources incomplètes : données importées depuis OpenStreetMap.org" si tu veux éviter de pister toutes les sources stockées dans les historiques des objets voire depuis quelques mois uniquement dans les changesets) Ceci fait tu as des données fraîches à mettre sur le serveur de test. Le 2 février 2015 23:12, Vincent Frison a écrit : > Merci Philippe pour ta réponse. > > Je reste cependant surpris du fait que la base de test soit par défaut > vide ou quasiment. Après qu'elle soit lente, instable et non durable ça > c'est tout à fait normal mais je ne vois pas vraiment pourquoi il n'y > aurait pas par défaut une copie des données de la vrai base.. > > Bon en suivant ton idée j'ai donc essayé de la remplir un peu avec JOSM. > J'ai changé l'URL à http://api06.dev.openstreetmap.org/api, j'ai > téléchargé une petite zone de test et fait quelques modifs mais dès que > j'essaye d'uploader j'ai ce message d'erreur : > > Le serveur 'http://api06.dev.openstreetmap.org/api/0.6/' ne reconnaît pas > un objet > que vous essayez de lire, mettre à jour ou supprimer. Soit cet objet > n’existe pas sur le serveur, soit vous utilisez une adresse web qui n’est > pas valide pour y accéder. > Veuillez vérifier l’adresse du serveur ' > http://api06.dev.openstreetmap.org/api/0.6/'. > > En gros il peut pas faire de PUT sur une ressource qui n'existe pas.. ou > alors il faudrait faire comprendre à JOSM que ce sont des nouveaux éléments > à créer (et non pas des éléments existant à mettre à jour) ? > > Sinon mon programme devrait fonctionner de la manière suivante : > 1) Pour chaque immeuble de la base à importer je calcule l'osmId du > building correspondant à la position géographique de l'immeuble (grâce à > une base PostGIS en local contenant les données OSM de la France). > 2) Si un ID de building est trouvé je télécharge le way depuis l'API d'OSM > et si le way ne contient pas d'informations sur la hauteur ou sur le nombre > d'étages alors je les renseigne. > 3) Je met à jour l'élément dans la foulée, il y a donc très peu de chance > d'avoir des accès concurrents puisque le délai est de quelques > millisecondes. > > La base de données concerne environ 40 000 immeubles répartie sur toute la > France mais de toute façon je comptais bien lancer un nouveau sujet pour > détailler et demander des conseils techniques voir légaux. Pour l'instant > mon problème est juste sur la base de données de test... > > ++ Vincent > > > Le 2 février 2015 19:27, Philippe Verdy a écrit : > > Dans ce cas tu télécharges une zone pour tes tests depuis la base >> principale vers un fichier OSM, tu changes l'adresse de l'API ou tu >> utilises une autre session JOSM pour le faire. Et tu envoies les données de >> cette zone de test sur la base de test. >> Après tu peux faire ce que tu veux... >> Cette base de test ne garantie pas la conservation à long terme des >> données il me semble (elle n'est pas taillée pour). Elle peut être purgée >> sans prévenir si elle devient trop volumineuse dans sa config limitée). >> Elle ne garantie pas non plus de bonnes performances (temporairement elle >> peut être sollicitée par d'autres tests concurrents). >> >> Elle peut aussi contenir des erreurs insérées volontairement pour tester >> le comportement de certains logiciels. >> >> S'il y a des données qui te gène dans ta zone de test (et qui ne sont >> assez anciennes) tu peux les virer, mais choisis plutôt une zone vierge si >> tu peux. >> >> Aucune idée de l'échelle de ton test : toute une grande ville comme >> Paris, Lyon, Marseille, Lille ou Bordeaux ? il y a des tas de trucs >> spécifiques dans ces villes. >> >> Après, à toi de faire tes tests de rendu. >> >> Garde tes fichiers OSM que tu souhaites valider en test si ensuite tu >> comptes les envoyer sur la base principale, mais attends toi à un travail >> supplémentaire de fusion... et de résolutions des conflits si les données >> OSM que tu as importées initialement en test ont été touchées sur la base >> principale pendant que tu les modifiais pour tes tests. >> >> En aucun cas tu ne doit réimporter directement les données brutes >> extraites de la base de test vers la base principale (à cause des erreurs >> volontaire
Re: [OSM-talk-fr] Base de données pour le développement
Note quand même qu'une fois que tu as uploadé les objets en création sur le serveur de test, ils ont un nouvel id qui n'a rien à voir avec ceux de la base originale. Ce qui veut dire que tu ne pourras pas facilement réexporter les données du serveur de test (que tu auras modifiées et complétées) par la manip inverse puisqu'il te faudra faire des fusions entre les objets importés sur la base de test, ceux que tu as modifiés ou créés dessus (avec des numéros de version différents) et ceux qui sont restés sur la base normale (et ont pu aussi être modifiés depuis)... à moins que tu gardes les IDs et versions originales dans des tags spécifiques comme "ref:osm:id=*" et "ref:osm:version=*" (pour l'import vers la base de test) ou "ref:devosm:id=*" et "ref:devosm:version=*" (pour l'import inverse), ce qui pourrait te faciliter le travail de fusion ultérieur puisque tout sera marqué par défaut en création et créera donc des doublons partout, même si la validateur de JOSM peut t'aider à dédoublonner les noeuds et chemins superposés, mais ce ne sera pas évident car il y a aussi des tas d'objets distincts dans la base OSM qui sont aussi superposés où la fursion n'a pas encore été faite...) C'est pourquoi toutes les modifs que tu voudras tester sur la base de test devraient être sauvegardées à part de l'import initial, dans les fichiers OSM que tu pourras aussi transformer de la même façon (passage en création: id négatifs, pas de version, statut "modified", tags "ref:devosm:id=*" et "ref:devosm:version=*" pour faciliter la fusion) et ne pas avoir à fusionner la totalité. Le 3 février 2015 02:06, Philippe Verdy a écrit : > quand tu as chargé des objets depuis OSM, ils comportent un numéro de > version qui n'existe pas sur le serveur de test où ils doivent non pas être > modifiés ou supprimés mais créés. > > Pour les mettre en création, il faut d'abord ôter leur numéro de version > (directement dans le code XML), et mettre leurs ID en valeur négative > (change simplement de signe), et les marquer en "modified" pour qu'ils > puissent être envoyés comme s'ils venaient d'être créés. . > > Une petite manip à faire à coup de "grep" ou avec un éditeur supportant > les recherches/substitutions d'expressions régulières (garde l'original, > sauve dans un nouveau fichier OSM, tu peux facilement te planter dans la > transformation et JOSM te dira que ton fichier est invalide ou t'affichera > n'importe quoi). > > (tu peux aussi ajouter un tag "source:test=sources incomplètes : données > importées depuis OpenStreetMap.org" si tu veux éviter de pister toutes les > sources stockées dans les historiques des objets voire depuis quelques mois > uniquement dans les changesets) > > Ceci fait tu as des données fraîches à mettre sur le serveur de test. > > Le 2 février 2015 23:12, Vincent Frison a > écrit : > > Merci Philippe pour ta réponse. >> >> Je reste cependant surpris du fait que la base de test soit par défaut >> vide ou quasiment. Après qu'elle soit lente, instable et non durable ça >> c'est tout à fait normal mais je ne vois pas vraiment pourquoi il n'y >> aurait pas par défaut une copie des données de la vrai base.. >> >> Bon en suivant ton idée j'ai donc essayé de la remplir un peu avec JOSM. >> J'ai changé l'URL à http://api06.dev.openstreetmap.org/api, j'ai >> téléchargé une petite zone de test et fait quelques modifs mais dès que >> j'essaye d'uploader j'ai ce message d'erreur : >> >> Le serveur 'http://api06.dev.openstreetmap.org/api/0.6/' ne reconnaît >> pas un objet >> que vous essayez de lire, mettre à jour ou supprimer. Soit cet objet >> n’existe pas sur le serveur, soit vous utilisez une adresse web qui n’est >> pas valide pour y accéder. >> Veuillez vérifier l’adresse du serveur ' >> http://api06.dev.openstreetmap.org/api/0.6/'. >> >> En gros il peut pas faire de PUT sur une ressource qui n'existe pas.. ou >> alors il faudrait faire comprendre à JOSM que ce sont des nouveaux éléments >> à créer (et non pas des éléments existant à mettre à jour) ? >> >> Sinon mon programme devrait fonctionner de la manière suivante : >> 1) Pour chaque immeuble de la base à importer je calcule l'osmId du >> building correspondant à la position géographique de l'immeuble (grâce à >> une base PostGIS en local contenant les données OSM de la France). >> 2) Si un ID de building est trouvé je télécharge le way depuis l'API >> d'OSM et si le way ne contient pas d'informations sur la hauteur ou sur le >> nombre d'étages alors je les renseigne. >> 3) Je met à jour l'élément dans la foulée, il y a donc très peu de chance >> d'avoir des accès concurrents puisque le délai est de quelques >> millisecondes. >> >> La base de données concerne environ 40 000 immeubles répartie sur toute >> la France mais de toute façon je comptais bien lancer un nouveau sujet pour >> détailler et demander des conseils techniques voir légaux. Pour l'instant >> mon problème est juste sur la base de données de test... >> >> ++ Vincent >> >> >> Le 2 février 2015 19:2
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Tu peux mettre la commune entre parenthèses, c'est plus lisible que les deux-points collés. Ce nom suffixé dans '"name=*" pour les relations n'est de toute façon pas celui des rues qui est dans "addr:street:*", c'est un guide visuel pour l'éditeur. Le 2 février 2015 20:20, lenny.libre a écrit : > > Le 01/02/2015 21:12, Philippe Verdy a écrit : > >> Note: le noms des deux relations (name=*) devrait être suffixé pour >> éviter l'homonymie. >> > J’ai fait une recherche et je n'ai pas trouvé de description sur la > manière de faire (séparation entre radical et suffixe et le suffixe > lui-même - name, code insee ... - ). > Est-ce : name = "Avenue des Chênes:Bordeaux" pour l'une et name = "Avenue > des Chênes:Mérignac" pour l'autre ? > >> On peut toujours indiquer le nom **non suffixé** de la rue dans le tag >> addr:street=* de la relation. >> >> Et puisque tous les membres (la voie notamment) ne sont pas dans le >> périmètre des communes, ils ne sont pas non plus dans le périmètre par >> défaut du code postal (qui n'est mentonné presque partout QUE dans la >> commune). Il faudra donc aussi compléter addr:postalcode=* dans la relation >> associatedStreet qui a des éléments à cheval de dexu communes ou sur la >> frontière communale. >> >> Ok > > > ___ > 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 : non rapprochement highway avec code FANTOIR
Le rapprochement BANO n'utilise-t-il pas de préférence le tag "addr:street:*" (plutot que "name=*") quand il est présent ? Le 2 février 2015 21:10, Vincent de Château-Thierry a écrit : > > Le 02/02/2015 20:20, lenny.libre a écrit : > >> >> Le 01/02/2015 21:12, Philippe Verdy a écrit : >> >>> Note: le noms des deux relations (name=*) devrait être suffixé pour >>> éviter l'homonymie. >>> >> J’ai fait une recherche et je n'ai pas trouvé de description sur la >> manière de faire (séparation entre radical et suffixe et le suffixe >> lui-même - name, code insee ... - ). >> Est-ce : name = "Avenue des Chênes:Bordeaux" pour l'une et name = >> "Avenue des Chênes:Mérignac" pour l'autre ? >> >>> On peut toujours indiquer le nom **non suffixé** de la rue dans le tag >>> addr:street=* de la relation. >>> >> > Si on en est là, autant laisser comme name=* de la relation le nom de > terrain (sans nom de ville accolé) et ajouter à titre indicatif un tag > addr:city à la relation, ou une note disant la même chose. Quand il existe > (ce qui n'est en rien obligatoire), le tag name des relations > associatedStreet sert dans BANO. > > 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: [OSM-talk-fr] Espaces demi m....
Ce n'est incisif pour personne, c'est une anomalie de JOSM quand même... Ca n'a rien de personnel, et JOSM souffre encore de nombreux défauts d'affichage des textes (par exemple il est incapable d'afficher les noms de plein d'écritures qui sont pourtant supportées par tous les navigateurs web sur le même OS)... Essaye d'y lire les noms écrits en birman, en lao (le khmer a été intégré), en pali, en tifinaghs... Et pourtant les moteurs de rendu (dont Mapnik sur OSM.org) les affichent aussi correctement. Aucun problème non plus pour afficher ces noms dans iD (puisque c'est le rendu de texte du navigateur web) ou dans Potlatch 2 (rendu de texte de Flash). Donc je maintiens que c'est un problème de l'appli JOSM elle-même. Le 2 février 2015 21:15, Vincent Privat a écrit : > Et quel bonheur de voir des commentaires aussi... incisifs sur le wiki, > aussi: > > https://josm.openstreetmap.de/wiki/StartupPageSource?action=diff&version=1533 > Heureusement que les contributeurs au wiki sont en général plus sympas > sinon aucun développeur de JOSM ne continuerait à participer bénévolement. > > Le 1 février 2015 20:38, Philippe Verdy a écrit : > >> Et non ce n'est PAS un fichier de config de JOSM, JOSM se contente de >> lire le HTML généré par une page wiki de JOSM. >> >> Si les fautes d'orthographe te plaisaient, mois pas. >> >> A ce sujet je ne sais pas qui a fait la traduction française de plein de >> trucs dans JOSM mais elle est bourrée de fautes (et aussi de contre-sens et >> faux-amis) ! >> Ca commence à m'agacer de les voir en permanence dans l'interface depuis >> un moement sans personne pour les corriger. >> >> Le 1 février 2015 20:32, Philippe Verdy a écrit : >> >> Quel espaces ??? Ce sont les indentations des puces de la page wiki et >>> elles y sont comem sur les autres pages. >>> Mes contribs sur cette page consistaient à corriger les "fôtes" de >>> français. >>> >>> Le 1 février 2015 19:51, Marc Sibert a écrit : >>> >>> Bonjour, Il y a un personnage maladroit qui a ajouté des espaces de m... dans les fichiers de config de JOSM. Des trucs qui sont placés avant les signes de ponctuation double, un certain "verdy_p". S'il peut faire marche arrière immédiatement, ça éviterait des (pas) jolis carrés dans mon JOSM. Merci... pour la correction (pas pour la contribution). A+ -- Marc Sibert mailto:m...@sibert.fr >>> >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Bonjour, Le 03/02/2015 02:25, Philippe Verdy a écrit : Le rapprochement BANO n'utilise-t-il pas de préférence le tag "addr:street:*" (plutot que "name=*") quand il est présent ? Du tout, non. Sur les entités associatedStreet, on a très souvent un tag name, et, d'après taginfo.fr, jamais de tag addr:street : http://taginfo.openstreetmap.fr/tags/type=associatedStreet#combinations Il y a 2 cas pour un objet portant le tag addr:housenumber, - rechercher un tag addr: street sur le même objet, - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Bonjour, Le 03/02/2015 06:37, Vincent de Château-Thierry a écrit : - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. Je croyais que le tag name d'une relation AssociatedStreet était plus cosmétique qu'autre chose. Si oui, ne faudrait-il pas utiliser en priorité le tag name des membres street de la relation ? Stéphane ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
