Re: [OSM-dev-fr] Génération de tuiles vectorielles avec OpenMapTiles

[Frédéric Rodrigo]

Le 04/11/2019 à 00:03, François de Metz a écrit :

On Wed, Oct 30, 2019 at 12:06:48PM +0100, Frédéric Rodrigo wrote:

Le 29/10/2019 à 11:16, François de Metz a écrit :

On Tue, Oct 29, 2019 at 09:24:40AM +0100, Frédéric Rodrigo wrote:

Ce sur quoi je suis en train de travailler est de plus haut niveau. Un peu
comme un tileserver-gl mais mais avec calcule à la volé. Ça sert les tuiles
vecto, les styles, et la version rasteur le tout avec du cache.

Pour l'instant je n'ai pas utilisé postile, j'attends qu'il produise le
tilejson (mais ça devrait arriver
https://github.com/Oslandia/postile/issues/2 )

Le but est de le publier, mais là c'est pas encore très sec, je peux le
communiquer sur demande.

Ca parait top !

Je résume la discussion, j'importe et met à jour les données dans le postgres, 
et je génère directement les tuiles à partir de celui ci, sans pré-génération.

Si ton projet permet de cacher et d'invalider les zones mise à jour, ca 
m'intéresse beaucoup.

François


Le projet est maintenant disponible sur github

https://github.com/makinacorpus/makina-maps

Ça devrait être possible de l'installer et de le lancer ;)


Par contre l'invalidation du cache n'est pas encore là.

Hello,

Top ! J'ai fini par prendre le temps de l'installer et de le tester et cela 
fonctionne bien. Merci !

Je vais avancer sur mon import et la mise à jour des données et reviendrai 
dessus.



Il y a maintenant le support de la mise à jour et de l'invalidation du 
cache.




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Génération de tuiles vectorielles avec OpenMapTiles

[Frédéric Rodrigo]

Le 29/10/2019 à 11:16, François de Metz a écrit :

On Tue, Oct 29, 2019 at 09:24:40AM +0100, Frédéric Rodrigo wrote:

Ce sur quoi je suis en train de travailler est de plus haut niveau. Un peu
comme un tileserver-gl mais mais avec calcule à la volé. Ça sert les tuiles
vecto, les styles, et la version rasteur le tout avec du cache.

Pour l'instant je n'ai pas utilisé postile, j'attends qu'il produise le
tilejson (mais ça devrait arriver
https://github.com/Oslandia/postile/issues/2 )

Le but est de le publier, mais là c'est pas encore très sec, je peux le
communiquer sur demande.

Ca parait top !

Je résume la discussion, j'importe et met à jour les données dans le postgres, 
et je génère directement les tuiles à partir de celui ci, sans pré-génération.

Si ton projet permet de cacher et d'invalider les zones mise à jour, ca 
m'intéresse beaucoup.

François



Le projet est maintenant disponible sur github

https://github.com/makinacorpus/makina-maps

Ça devrait être possible de l'installer et de le lancer ;)


Par contre l'invalidation du cache n'est pas encore là.



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Génération de tuiles vectorielles avec OpenMapTiles

[Frédéric Rodrigo]

Ce sur quoi je suis en train de travailler est de plus haut niveau. Un 
peu comme un tileserver-gl mais mais avec calcule à la volé. Ça sert les 
tuiles vecto, les styles, et la version rasteur le tout avec du cache.


Pour l'instant je n'ai pas utilisé postile, j'attends qu'il produise le 
tilejson (mais ça devrait arriver 
https://github.com/Oslandia/postile/issues/2 )


Le but est de le publier, mais là c'est pas encore très sec, je peux le 
communiquer sur demande.




Le 28/10/2019 à 23:01, François de Metz a écrit :

On Mon, Oct 28, 2019 at 10:46:04PM +0100, Thomas Gratier wrote:

Salut,

Regarde du côté de https://github.com/Oslandia/postile-openmaptiles qui
utilise https://github.com/Oslandia/postile
Il fait du OpenMapTiles à la volée mais je précise que je n'ai pas testé
les perfs.

OpenMapTiles a aussi un truc avec postserve 
https://github.com/openmaptiles/openmaptiles-tools#postserve-quickstart-with-docker

J'ai testé une ancienne version et j'avais des bugs de rendu. Il faudrait que 
je réessaye.

François


Cordialement

Thomas

Le lun. 28 oct. 2019 à 22:38, Frédéric Rodrigo  a
écrit :


Le 28/10/2019 à 20:55, François de Metz a écrit :

Bonjour,

J'ai bricolé cet été un visualisateur de données intérieur avec
OpenMapTiles et un peu de javascript. Le résultat est visible pour
Montparnasse [1] et toute l'ile de france.
Les tuiles sont pré-généré au zoom 17.

J'aimerais étendre la zone couverte au monde entier. Quelqu'un
aurait-il de l'expérience pour générer des tuiles OpenMapTiles à
l'échelle ? Si possible avec une mise à jour régulière pour que ce
soit également une aide a la contribution ?

[1]: https://osm-indoor.2metz.fr/#18.66/48.8409619/2.3204768


Vu tu n'as que les données indoor ta base doit quand même être
relativement petite. Il ne devrait pas trop y avoir de problème coté
base de données pour la passage à l'échelle.

Sur un OpenMapTiles standard, il faut entre 30j et 40j avec 8cpu pour
pré-générer les zooms 0 à 14. Même si tu ne veux que le 17 assez vide,
je pense que ça va être relativement long à prégénérer.

Je travaille justement en ce moment sur une autre approche, calculer les
tuiles à la voler depuis une base OpenMapTiles, donc sans
pré-génération. Je pense que dans ton cas ça pourrait bien simplifier
les choses.

Frédéric.



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Génération de tuiles vectorielles avec OpenMapTiles

[Frédéric Rodrigo]

Le 28/10/2019 à 20:55, François de Metz a écrit :

Bonjour,

J'ai bricolé cet été un visualisateur de données intérieur avec
OpenMapTiles et un peu de javascript. Le résultat est visible pour
Montparnasse [1] et toute l'ile de france.
Les tuiles sont pré-généré au zoom 17.

J'aimerais étendre la zone couverte au monde entier. Quelqu'un
aurait-il de l'expérience pour générer des tuiles OpenMapTiles à
l'échelle ? Si possible avec une mise à jour régulière pour que ce
soit également une aide a la contribution ?

[1]: https://osm-indoor.2metz.fr/#18.66/48.8409619/2.3204768



Vu tu n'as que les données indoor ta base doit quand même être 
relativement petite. Il ne devrait pas trop y avoir de problème coté 
base de données pour la passage à l'échelle.


Sur un OpenMapTiles standard, il faut entre 30j et 40j avec 8cpu pour 
pré-générer les zooms 0 à 14. Même si tu ne veux que le 17 assez vide, 
je pense que ça va être relativement long à prégénérer.


Je travaille justement en ce moment sur une autre approche, calculer les 
tuiles à la voler depuis une base OpenMapTiles, donc sans 
pré-génération. Je pense que dans ton cas ça pourrait bien simplifier 
les choses.


Frédéric.



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Intégration java OSM

[Frédéric Rodrigo]

Je pense que la question porte plutôt sur l'intégration de cartes dans 
une application Java.


https://wiki.openstreetmap.org/wiki/FR:Mapsforge
https://docs.mapbox.com/android/java/overview/



Le 27/08/2019 à 18:57, marc marc a écrit :

Bonjour,

si tu veux intégrer une carte avec les marqueurs,
umap pourrait faire l'affaire.
si tu veux gérer toi-même le fond, cela ne conviendra pas.

Cordialement,
Marc

Le 26.08.19 à 18:15, pe...@valentinbru.com a écrit :

Bonjour,

Je travaille actuellement sur la conception d’un logiciel de marketing
en java/Swing , j’ai actuellement des positions Latitude/Longitude de
croisements avec mes infos que j’aimerais afficher sur une map et je
n’ai pas trouvé d’équivalent à OpenLayers ou Leaflet pour intégrer la
map OSM dans mon application  je voulais donc savoir si vous aviez
connaissance d’une librairie ou api qui peut faire ça ?

Merci beaucoup,

*Valentin BRU*

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Demande de retour sur la version beta d'Osmose

[Frédéric Rodrigo]

Bonjour,

Suite à une série de changement nous aimerions avoir des retours sur la 
version beta d'Osmose :


http://beta.osmose.openstreetmap.fr/fr/map/

Les principaux changement sont :

- Popup
  - changement de la mise en page
  - tooltips sur les liens et boutons
  - chargement des géométries des objets OSM lors de l'ouverture de la 
popup
- Amélioration du temps de réponse des tuiles contenant les marqueurs 
(changement d'index en base et de l'affichage)

- Ajout du format d'export KML
- Modification de la fenêtre de sauvegarde de l'éditeur intégré
- Passage des signalements en résolus ou faux positifs depuis les pages 
de listes (par item, par utilisateur)


Merci d'avance.

Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Développement Osmose

[Frédéric Rodrigo]

Le 26/12/2017 à 13:04, marc marc a écrit :

Le 26/12/2017 à 10:56, Frédéric Rodrigo a écrit :

il faut changer le # en ?
http://osmose.openstreetmap.fr/fr/map/?source=14708=7170=13

Oui ça marche mal. Il faut réécrire cette partie du code (aide
bienvenue).

y a-t-il un tutoriel pour se faire la main sur le code d'osmose ?
un exemple d'une analyse ultra simple ?


Pas vraiment. Mais tu peux regarder ça :
https://fr.slideshare.net/FredericRodrigo/20130906-sotmbirminghamosmose


Là on parlait surtout d'un problème dans le frontend web (phython/js) et 
pas avec les analyses.



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Test Osmose-Mapillary

[Frédéric Rodrigo]

Salut,

Je finis ce qu'il reste à faire sur Rennes. Je pense que tout le Campus 
est à tors taggé en maxspeed=50. Mais d’après les photo il est en zone30.

J'ai corrigé là ou il avait des photo de dispo.
Adrien tu es probablement mieux placer que moi pour corriger le reste.


Frédéric.



Le 10/07/2017 à 10:38, PanierAvide a écrit :

Bonjour,

Ça a dû être un sacré chantier pour faire ce rapprochement, les 
résultats sont pertinents donc bien joué !


Je me disais que ce type de corrections se prêterai bien à un 
challenge MapRoulette, et là je vois qu'Osmose propose déjà toutes 
sortes de fichiers à l'export... On vit à une époque formidable ;-) 
Hâte que ce soit disponible à une échelle plus large.


Cordialement,

Adrien.


Le 09/07/2017 à 19:53, Julien balas a écrit :

Le 08/07/2017 à 20:11, Frédéric Rodrigo a écrit :

Salut,

J'ai obtenu de Mapillary un mini dump du résultats de la détection des
panneaux dans la région de Rennes.

C'est rapproché des données OSM comme c'est fait avec de l'OpenData.

Ça signalement donc quand l'effet d'un panneau n'est pas retrouvé dans
les données OSM.


cool, j'ai ajouté quelques stops



Comme ce n'est pas toujours simple j'ai pour l'instant limité à 
certains

types de panneau dont l'effet se traduit par un seul tag, ça essaye de
retrouver ce tag à proximité. La distance est variable en fonction du
panneau.


Mais il y a plusieurs problème:

- la localisation des panneaux est approximative


en effet, la rocade déborde jusque le long du chemin de halage ;)
https://www.mapillary.com/app/?lat=48.10593859663507=-1.7144116702545489=17=true=map%5B%5D=regulatory--maximum-speed-limit-70--g1 





- souvent dédoublé

- les panonceaux ne sont pas pris en compte

- pas différence entre un panneau d'application et un panneau 
d'approche


ca detecte parfois un peut trop aussi :)

- une vitesse de bus qui deviens une limitation
https://www.mapillary.com/app/?lat=48.1312010610244=-1.67386871309325=17=true=map%5B%5D=regulatory--maximum-speed-limit-90--g1 



- ça remonte aussi bien des problèmes dans OSM que des problèmes 
dans la

reconnaissance des panneaux (on peut marquer les faux positif dans
Mapillary ?)


Je n'ai pas trouvé, mais je connais mal mapillary.



On pourrait aussi chercher à cartographier les panneaux eux mêmes et/ou
leur effets.


http://dev.osmose.openstreetmap.fr/en/map/#item=8300=true=14=48.12522=-1.67435=Mapnik=T 



En tout cas c'est prometteur.

Est ce que dans mapillary l'icone de hauteur est générique ?
si non les hauteurs ne sont pas toujours détectées (3.1 au lieu de 2.5)
https://www.mapillary.com/app/?lat=48.12780824036=-1.683399190456=17=true=map%5B%5D=regulatory--height-limit--g1=wuf09rJKjlpb2F_78Lv6YA=0.5091192026214278=0.515137058569636=0 




ps : si le lien mapillary etait cliquable dans osmose ca serait top!

Merci de ton travail.




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Stats sur les angles des highways

[Frédéric Rodrigo]

Le 20/07/2017 à 20:06, Vincent Privat a écrit :

Hello,
On vient de nous soumettre cette idée:
https://josm.openstreetmap.de/ticket/15044

ça me semble une bonne idée mais pour trouver la valeur adéquate du 
seuil je serai curieux d'avoir les angles moyens, médians et maximum 
entre 2 nodes consécutifs qu'on peut trouver dans la base pour chaque 
type de highway.


Quelqu'un saurait faire ça ? (avec postgis ou autre)

Vincent


Il y a déjà quelque chose d'approchant dans Osmose, tu peux regarder le 
code:


https://github.com/frodrigo/osmose-backend/blob/master/analysers/analyser_osmosis_way_approximate.py



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Test Osmose-Mapillary

[Frédéric Rodrigo]

Le 10/07/2017 à 10:38, PanierAvide a écrit :

Bonjour,

Ça a dû être un sacré chantier pour faire ce rapprochement, les 
résultats sont pertinents donc bien joué !

En fait non ça a été facile. C'est le même outillage que pour l'OpenData.



Je me disais que ce type de corrections se prêterai bien à un 
challenge MapRoulette, et là je vois qu'Osmose propose déjà toutes 
sortes de fichiers à l'export... On vit à une époque formidable ;-) 
Hâte que ce soit disponible à une échelle plus large.



Moi aussi ! reste à convaincre Mapillary..


Cordialement,

Adrien.


Le 09/07/2017 à 19:53, Julien balas a écrit :

Le 08/07/2017 à 20:11, Frédéric Rodrigo a écrit :

Salut,

J'ai obtenu de Mapillary un mini dump du résultats de la détection des
panneaux dans la région de Rennes.

C'est rapproché des données OSM comme c'est fait avec de l'OpenData.

Ça signalement donc quand l'effet d'un panneau n'est pas retrouvé dans
les données OSM.


cool, j'ai ajouté quelques stops



Comme ce n'est pas toujours simple j'ai pour l'instant limité à 
certains

types de panneau dont l'effet se traduit par un seul tag, ça essaye de
retrouver ce tag à proximité. La distance est variable en fonction du
panneau.


Mais il y a plusieurs problème:

- la localisation des panneaux est approximative


en effet, la rocade déborde jusque le long du chemin de halage ;)
https://www.mapillary.com/app/?lat=48.10593859663507=-1.7144116702545489=17=true=map%5B%5D=regulatory--maximum-speed-limit-70--g1 





- souvent dédoublé

- les panonceaux ne sont pas pris en compte

- pas différence entre un panneau d'application et un panneau 
d'approche


ca detecte parfois un peut trop aussi :)

- une vitesse de bus qui deviens une limitation
https://www.mapillary.com/app/?lat=48.1312010610244=-1.67386871309325=17=true=map%5B%5D=regulatory--maximum-speed-limit-90--g1 



- ça remonte aussi bien des problèmes dans OSM que des problèmes 
dans la

reconnaissance des panneaux (on peut marquer les faux positif dans
Mapillary ?)


Je n'ai pas trouvé, mais je connais mal mapillary.



On pourrait aussi chercher à cartographier les panneaux eux mêmes et/ou
leur effets.


http://dev.osmose.openstreetmap.fr/en/map/#item=8300=true=14=48.12522=-1.67435=Mapnik=T 



En tout cas c'est prometteur.

Est ce que dans mapillary l'icone de hauteur est générique ?
si non les hauteurs ne sont pas toujours détectées (3.1 au lieu de 2.5)
https://www.mapillary.com/app/?lat=48.12780824036=-1.683399190456=17=true=map%5B%5D=regulatory--height-limit--g1=wuf09rJKjlpb2F_78Lv6YA=0.5091192026214278=0.515137058569636=0 




ps : si le lien mapillary etait cliquable dans osmose ca serait top!

Merci de ton travail.




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Test Osmose-Mapillary

[Frédéric Rodrigo]

Salut,

J'ai obtenu de Mapillary un mini dump du résultats de la détection des 
panneaux dans la région de Rennes.


C'est rapproché des données OSM comme c'est fait avec de l'OpenData.

Ça signalement donc quand l'effet d'un panneau n'est pas retrouvé dans 
les données OSM.


Comme ce n'est pas toujours simple j'ai pour l'instant limité à certains 
types de panneau dont l'effet se traduit par un seul tag, ça essaye de 
retrouver ce tag à proximité. La distance est variable en fonction du 
panneau.



Mais il y a plusieurs problème:

- la localisation des panneaux est approximative

- souvent dédoublé

- les panonceaux ne sont pas pris en compte

- pas différence entre un panneau d'application et un panneau d'approche

- ça remonte aussi bien des problèmes dans OSM que des problèmes dans la 
reconnaissance des panneaux (on peut marquer les faux positif dans 
Mapillary ?)



On pourrait aussi chercher à cartographier les panneaux eux mêmes et/ou 
leur effets.


http://dev.osmose.openstreetmap.fr/en/errors/?item=8300=true
http://dev.osmose.openstreetmap.fr/en/map/#item=8300=true=14=48.12522=-1.67435=Mapnik=T

Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Version beta du frontend d'Osmose

[Frédéric Rodrigo]

Salut,

On a changé la façon d'afficher les signalements sur le frontend 
d'Osmose. On compte maintenant utiliser les tuiles vectorielles pour ça.


Vous pouvez tester sur :

http://beta.osmose.openstreetmap.fr/

(C'est les mêmes donnés que sur l'interface normale (ce n'est pas une 
base de données de test))



N’hésitez surtout pas à faire vos retour et à signaler des bugs.

Changement notable, les popups ne s'ouvrent plus au survol, je ne suis 
pas arrivé à le coder.



Frédéric.



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Finding duplicate cycleways

[Frédéric Rodrigo]

Pourquoi chercher quelque chose d’approchant quand on peut avoir l'original.
Osmose-QA le fait déjà !

J'ai répondu sur Github.

Frédéric.


Le 26/04/2017 à 12:50, Benoit Fournier a écrit :

Bonjour les osmose-gurus,

Voici une demande du développeur de l'application mobile StreetMobile
https://github.com/westnordost/StreetComplete/issues/139#issuecomment-296753596
et cf message de talk@ ci-dessous.

Il cherche des pistes pour détecter une piste cyclable qui serait un 
doublon potentiel, parce que elle serait à la fois :

- sur une route "motorisée" highway=* définie par un tag cycleway=*
- sur un way séparé parallèle avec un tag principal highway=cycleway

A-t-on quelque chose d'approchant dans Osmose, même sur une autre 
problématique ?


Benoît




-- Forwarded message --
From: *Tobias Zwick* >
Date: 24 April 2017 at 19:27
Subject: [OSM-talk] Finding duplicate cycleways
To: OpenStreetMap talk mailing list >



Hi

I wonder, does anyone know a QA tool out there that finds duplicate
cycleways?

With duplicate, I mean cycleways that are both
- tagged as cycleway=* on a highway=* way and
- mapped as a separate way parallel to the street with highway=cycleway

I understand that there is no simple tag on the highway=* way to denote
that the cycleway is mapped as its own way, so whether a cycleway is
mapped or not cannot be determined just by looking at the tags of a road
but must be determined by analyzing the geometry of ways in relation to
each other (I guess).

Greetings
Tobias

___
talk mailing list
t...@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk 





___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Osm

[Frédéric Rodrigo]

Bonsoir,
Ta question est tellement vague qu'il n'est pas possible d'y répondre.
Frédéric.

Le 02/06/2016 à 12:38, Abed Kanbar a écrit :


Bonjour,

Comment je peux travailler sur une carte *osm* juste pour une ou 
plusieurs villes en utilisant Qgis Desktop ?


Merci d’avance pour vos réponses.



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Fwd: OSMOSE/BANO : Faux positifs ?

[Frédéric Rodrigo]

C'est bon sur le rendu bano
http://layers.openstreetmap.fr/?zoom=18=48.68445=6.21784=BFT

Les données affichéee sur osmose viennent d'un envoie de cquest depuis 
la base bano.



Le 27/02/2016 10:33, Art Penteur a écrit :

Bonsoir,

Sur la commune de Nancy, Osmose signale plein  de "name=* ou route
potentiellement manquante à proximité" alors que la rue avec le même
nom a bien l'air d'exister.
Exemple sur la Rue Louis Aragon avec la copie d'écran ci-dessous :
https://framadrop.org/r/y4dfbSViK-#Q4SU+bt2fx3XFIKBYo9Ztp3XP/JgvySO2tp2Abt8BEs=

Y'a quelque chose à faire pour corriger ça ?

Art.

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Optimization base postgis pour tuiles mapnik

[Frédéric Rodrigo]

Ça prend du temps c'est normal.
La réponse est : il faut utiliser un cache.

Ces tuiles sont très couteuse à calculer et contienne peu souvent des 
mises à jour visible.
Ce qui se pratique même est de les précalculer pour ne pas que 
l'utilisateur ai à attendre.



Le 15/01/2016 16:03, Marc Ducobu a écrit :

Bonjour,

La couverture de la DB est européenne.

Je cherche à installer un serveur de tuiles sur l'europe. Le serveur
utilisé est un EG-32 d'ovh (
  - CPU : Intel Xeon E5-1620v2 4c/8t 3,7 GHz/3,9 GHz
  - RAM : 32 Go DDR3 ECC 1600 MHz
  - Disques : 2x 4 To SATA3
(https://www.ovh.com/fr/serveurs_dedies/infra/2014-EG-32.xml)). Tout est
installé mais il y a un problème : à un niveau de zoom haut, les tuiles
mettent du temps à être générées. Et donc, lors d'un zoom, il faut pas
mal de temps pour que les tuiles soient affichées.

Du coup j'ai essayé de configurer la base postgresql afin d'optimiser
son temps de réponse.

Pour l'instant les variables que j'ai changées sont :
effective_cache_size = 24GB
wal_buffers  = 16MB # avant 4MB
random_page_cost = 3 # avant 4
fsync = off # avant on
synchronous_commit = off # avant on
maintenance_work_mem 4096 # avant 64MB
work_mem =  500MB # avant 4MB

(dans ce que j'ai lu ils parlent de modifier checkpoint_segment = à
1600. Comme celui actuel est de 3, ça me semble bcp et du coup j'hésite.)

Ces changements n'ont pas amélioré le temps de génération des tuiles.

Que pensez-vous de ces paramètres ? Aussi j'aimerai bien utiliser un
outil afin de tester la manière dont réagit la génération de tuiles en
fonction des paramètres. Avez-vous un outil / une méthode à conseiller ?

Merci bcp.

Marc

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Open Earth View - tuiles 3D

[Frédéric Rodrigo]

Petit retour rapide. J'ai juste testé la démo.
Je trouve la navigation à la sourie complètement contre intuitive.
click gauche devrait faire du drag, le zoom molette est à l'inverse de 
ce qu'il se fait habituellement.
bref pour la première démo je ne suis pas arrivé a visualiser quelque 
chose en navigant.



Le 14/01/2016 12:32, Clement IGONET a écrit :

Bonjour tout le monde,

Je travaille depuis plus d'un an sur un projet de génération de
tuiles 3D à partir des données d'OSM. Le projet se concentre surtout
sur la modélisation de bâtiments.

Le projet était en C++, mais j'ai tout refait en NodeJS pour
beaucoup plus de souplesse en dev (adoption, facilités du langage avec
modèle de données JSON, concision du code, évolutions, maintenance,
etc...).

Actuellement, les tuiles 3D générées peuvent être au formats suivants:
- GeoJSON
- X3D (JSON)
- X3D (XML)
Et à venir:
- JSON pour la lib three.js
- JSON pour la lib js babylon.js

J'ai une quantité assez importante de projet à développer autour de ça:
- viewer 3D web avec globe terrestre (x3dom, three.js, babylon.js)
- vue cubemap/skybox pour la navigation là où les camionettes google
ne vont pas (intérieur de bâtiment, chemins en montagne, etc...)
- gestion d'évènemetns temps réel dans les bâtiments (surveillance
ascenseurs, clims, incendie, intrusions, etc...)

Le projet a vocation à être libre (le moins de contraintes
d'exploitation possibles).

Certains d'entre vous serez-t-il intéressé par rejoindre le projet?

Tout type de participation serait bievenu (demandes de
fonctionnalités, communications, développement, intégration, tests,
etc...).

Présentaiton du projet: http://wiki.openstreetmap.org/wiki/Open_Earth_View
Projet nodejs: https://www.npmjs.com/package/osm2x3d
Projet entier: 
https://git.framasoft.org/pizaninja/OpenEarthView/tree/master/
Démos:
- http://www.openearthview.net/ (hébergement OVH payé par framasoft)
- http://www.openearthview.net/demo/cubemap_forest/forest.html
(attention, 10 MO à télécharger dans la scène)

Clément Igonet.

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

[Frédéric Rodrigo]

Salut,

Les requêtes actuelles sont déjà assez lourde. C'est assez difficile de 
faire des choses dans le domaine du bâti.


Tu peux déjà éviter d'utiliser une fonction, c'est joli, mais c'est lent.
Essayes d'utiliser des temps tables avec des index dessus si besoin, et 
essaye de réduire le nombre de jointures.
Essaye d'éviter d'utiliser way_nodes, tu as aussi les id des nodes dans 
ways.nodes.
De plus way_nodes ne supporte pas le mode diff tu ne peux pas faire 
touched_way_nodes.


Dans osmose la projection est un paramètre de l'analyse.


Frédéric.


Le 16/11/2015 19:46, Tyndare a écrit :


Bonjour,

J'ai voulu essayer de faire une analyse osmose pour détecter des 
bâtiments fractionnés à cause du cadastre.
Pour l'instant ce n'est pas vraiment une réussite, je ne sais pas si 
il y aurait des volontaires pour m'aider, je ne maîtrise pas du tout 
SQL ou PostGIS en fait...


Ce que j'ai voulu faire c'est détecter les situations où un bâtiment 
est collé à un autre de manière rectiligne, mais dont l'angle avec la 
section commune ne soit pas à 90°:


-+
 /
/
--+---

J'ai deux problèmes:

1. Le principe marche relativement bien dans les zones modernes (où 
les bâtiments sont à peut près carrés), mais trouves beaucoup trop de 
faux positifs dans les vielles villes.
Si quelqu'un à une idée d'heuristique pour réduire le nombre de faux 
positifs je suis preneur.



2. Ma requête SQL est beaucoup trop compliquée, et elle génère des 
tables intermédiaires de taille exponentielle...
Si une âme charitable est motivé pour jeter un œuil à mon horrible 
requête SQL et me donner quelques conseils d'optimisation:


https://github.com/tyndare/osmose-backend/commit/6dd5e773ac7e0f5480518c066ed2bd4b0c50a04e

Merci,

Tyndare.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

[Frédéric Rodrigo]

Pour l’exécuté dans le backend principal d'Osmose ça dépendent du temps 
que ça prend et de la base de données que ça utilise.
Mais rien n’empêche a n'importe quel programme de devenir un backend 
d'Osmose en envoyant directement des rapports au frontend d'Osmose.


Ce genre de grosse requête est quand un long processus d'affinage.

Le 16/11/2015 23:27, Tyndare a écrit :

Mais du coup c'est envisageable de faire ce genre d'analyse ou les
serveurs Osmose sont déjà trop chargés ?

En tout cas merci beaucoup Frédéric pour tes conseils.
En gros il faut que je réécrive tout ;-) (je dois dire que je m'y
attendais un peu)


Le 16 novembre 2015 22:33, Frédéric Rodrigo <fred.rodr...@gmail.com> a écrit :

Salut,

Les requêtes actuelles sont déjà assez lourde. C'est assez difficile de
faire des choses dans le domaine du bâti.

Tu peux déjà éviter d'utiliser une fonction, c'est joli, mais c'est lent.
Essayes d'utiliser des temps tables avec des index dessus si besoin, et
essaye de réduire le nombre de jointures.
Essaye d'éviter d'utiliser way_nodes, tu as aussi les id des nodes dans
ways.nodes.
De plus way_nodes ne supporte pas le mode diff tu ne peux pas faire
touched_way_nodes.

Dans osmose la projection est un paramètre de l'analyse.


Frédéric.



Le 16/11/2015 19:46, Tyndare a écrit :


Bonjour,

J'ai voulu essayer de faire une analyse osmose pour détecter des bâtiments
fractionnés à cause du cadastre.
Pour l'instant ce n'est pas vraiment une réussite, je ne sais pas si il y
aurait des volontaires pour m'aider, je ne maîtrise pas du tout SQL ou
PostGIS en fait...

Ce que j'ai voulu faire c'est détecter les situations où un bâtiment est
collé à un autre de manière rectiligne, mais dont l'angle avec la section
commune ne soit pas à 90°:

-+
  /
 /
--+---

J'ai deux problèmes:

1. Le principe marche relativement bien dans les zones modernes (où les
bâtiments sont à peut près carrés), mais trouves beaucoup trop de faux
positifs dans les vielles villes.
Si quelqu'un à une idée d'heuristique pour réduire le nombre de faux
positifs je suis preneur.


2. Ma requête SQL est beaucoup trop compliquée, et elle génère des tables
intermédiaires de taille exponentielle...
Si une âme charitable est motivé pour jeter un œuil à mon horrible requête
SQL et me donner quelques conseils d'optimisation:


https://github.com/tyndare/osmose-backend/commit/6dd5e773ac7e0f5480518c066ed2bd4b0c50a04e

Merci,

Tyndare.




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] requete pour trouver un way qui intersecte plusieurs communes

[Frédéric Rodrigo]

J'aimerais bien que l'analyse puisse être internationale. Filer sur un type
de hygjway c'est possible ?
Le 18 mai 2015 23:01, didier2020 didier2...@free.fr a écrit :


 aprés avoir corrigé un bon nombre de détection,
 je ne pense pas que cela soit la géométrie de l'intersection
 qui importe, mais plutôt la nature de la voie :

 J'ai remarqué que les intersections complexes sont plus liés
 aux écarts entre le tracé Bing vs tracé cadastre .

 Faire une analyse sans faux positifs grace au premier mot du name :
 upper(split_part(tag-'name',' ', 1) in ()

 Toujours a corriger
 Rue , Place, Impasse

 Mitigé :
 Avenue - Allée (dans les forets)

 Faux positifs :
 Route
 Chemin
 Chaussée

 Le lundi 18 mai 2015 à 21:54 +0200, Frédéric Rodrigo a écrit :
  Le 17/05/2015 11:08, didier2020 a écrit :
   1)
   colonne intersectioncomplexe ajoutée
   ( a prioris il y aura plus de faux positif si .t.)
   voir id=153318806 ou id=111737255
 
  Pour osmose, on prend ou on prend pas ?
 
 
 on prend tout, le critere etant ailleur.
  ___
  dev-fr mailing list
  dev-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/dev-fr



 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/dev-fr

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] requete pour trouver un way qui intersecte plusieurs communes

[Frédéric Rodrigo]

Salut,

Voilà ce que j'en ai fait, regarde un peut les résultats et si tu peux 
l'améliorer. Il y a un bug avec les voies qui reviennent dans la commune 
d'origine, à voir si c'est est acceptable.


SELECT
  id
FROM
(
SELECT
  highway.id,
  highway.linestring,
  ST_ClosestPoint(highway.linestring, ST_Intersection(admin.linestring, 
highway.linestring)) AS intersection

FROM
  relations
  JOIN relation_members ON
relation_members.relation_id = relations.id AND
relation_members.member_type = 'W'
  JOIN ways AS admin ON
admin.id = relation_members.member_id AND
ST_NPoints(admin.linestring)  1
  JOIN ways AS highway ON
-- les ways qui ne sont pas des autoroutes, qui ont un tag name et 
qui sont  a 1km

highway.tags?'highway' AND
NOT highway.tags-'highway' IN ('proposed', 'motorway', 'trunk', 
'motorway_link', 'trunk_link') AND

highway.tags?'name' AND
ST_Length(highway.linestring, false)  1000 AND
ST_NPoints(highway.linestring)  1 AND
-- avec une intersection
ST_Intersects(admin.linestring, highway.linestring)
WHERE
relations.tags?'type' AND
relations.tags-'type' = 'boundary' AND
relations.tags?'boundary' AND
relations.tags-'boundary' = 'administrative' AND
relations.tags?'admin_level' AND
relations.tags-'admin_level' = '8' AND
relations.tags?'ref:INSEE'
) AS t
WHERE
  -- la taille de l'intersection par rapport a la longueur de la voie 
est significative

  ST_Line_Locate_Point(linestring, intersection)  0.1 AND
  ST_Line_Locate_Point(linestring, intersection)  0.9
;



Le 16/05/2015 16:26, didier2020 a écrit :

c'est mieux avec la requete ...


Le samedi 16 mai 2015 à 16:25 +0200, didier2020 a écrit :

j'ai bati un truc a partir de la requete de christian
sur une base osmosis .

j'ai pas réussi a aggreger les communes - longueur du way dans la
commune.

Le samedi 16 mai 2015 à 11:42 +0200, Frédéric Rodrigo a écrit :

Le 15/05/2015 18:36, Christian Quest a écrit :

Suite à cet échange et à une demande de didier2020, j'ai sorti un CSV
des highway qui portent un nom et qui croisent plusieurs communes.
Les motorway ont été retiré, et c'est trié par nombre de communes
croisées, puis par kilométrage décroissant.
La liste des codes INSEE des communes croisées est indiquée.

C'est ici: http://osm105.openstreetmap.fr/~cquest/routes.csv

A affiner pour une future analyse osmose ?


Si vous avais une requête qui tourne sur base osmosis je prends.


___
Talk-fr mailing list
talk...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr







___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Proxy TMS - WMS cadastre

[Frédéric Rodrigo]

* est le calque de bse
** est juste le complément pour les tuiles à cheval sur 2 communes, tu 
peux t'en passer.


Le 08/03/2015 15:31, orhygine a écrit :



Le 8 mars 2015 12:27, Frédéric Rodrigo fred.rodr...@gmail.com
mailto:fred.rodr...@gmail.com a écrit :

C'était l'adresse de test. Le service est maintenant en place, voir :

https://lists.openstreetmap.__org/pipermail/talk-fr/2015-__February/075223.html

https://lists.openstreetmap.org/pipermail/talk-fr/2015-February/075223.html


Ok merci pour la réponse. Je teste donc dans JOSM en créant une couche
d'images TMS avec la configuration :

tms[20]:http://tms.cadastre.openstreetmap.fr/**/tout/{z}/{x}/{y}.png
http://tms.cadastre.openstreetmap.fr/**/tout/%7Bz%7D/%7Bx%7D/%7By%7D.png

Bien que j'observe que cela fonctionne correctement sur
http://tms.cadastre.openstreetmap.fr/ (test sur le centre de Toulouse
par exemple), je n'obtiens pas les tuiles dans JOSM.

En dézoomant suffisamment je vois des tuiles s'afficher mais jamais au
centre de la carte. Lorsque je zoome, pas de tuile.

Clic droit / Charger la tuile : ne fait rien.
Clic droit / Charger toutes les tuiles : ne fait rien.
Clic droit / Charger les tuiles avec des erreurs : ne fait rien.
Clic droit / Réinitialiser le cache : pas mieux.

Clic droit / Afficher les informations de la tuile affiche Tile
17/66061/47860 qui fonctionne correctement avec l'URL
http://tms.cadastre.openstreetmap.fr/*/tout/17/66061/47860.png dans un
navigateur.

Je suis en version JOSM latest 8119 sous ubuntu 14.10. J'utilise la
projection 3857 dans JOSM.

Quelqu'un aurait-il une idée du pb ?
Merci.


Le 07/03/2015 21:48, orhygine a écrit :

Est-ce que ce service fonctionne toujours ? Ce n'est pas le cas
actuellement sur
http://osm110.openstreetmap.__fr/~fred/cadastre.html
http://osm110.openstreetmap.fr/~fred/cadastre.html.

Le 19 février 2015 00:46, Nicolas Dumoulin
nicolas_openstreetmap.org@__dumoulin63.net
mailto:nicolas_openstreetmap@dumoulin63.net
mailto:nicolas_openstreetmap.__...@dumoulin63.net
mailto:nicolas_openstreetmap@dumoulin63.net a écrit :

 Le vendredi 13 février 2015 21:01:29 Frédéric Rodrigo a écrit :
  Je viens d'ajouter le mode joker, il faut utiliser * a
la place du
  code insee. Bien sûr ça ne prend que une seule commune à
la fois.

 Génial !
 Merci, c'est juste énorme ! :-D

 --
 Nicolas Dumoulin
http://wiki.openstreetmap.org/__wiki/User:NicolasDumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

 _
 dev-fr mailing list
dev-fr@openstreetmap.org mailto:dev-fr@openstreetmap.org
mailto:dev-fr@openstreetmap.__org
mailto:dev-fr@openstreetmap.org
https://lists.openstreetmap.__org/listinfo/dev-fr
https://lists.openstreetmap.org/listinfo/dev-fr




--
Christophe aka orhygine | http://orhyginal.free.fr |


_
dev-fr mailing list
dev-fr@openstreetmap.org mailto:dev-fr@openstreetmap.org
https://lists.openstreetmap.__org/listinfo/dev-fr
https://lists.openstreetmap.org/listinfo/dev-fr



_
dev-fr mailing list
dev-fr@openstreetmap.org mailto:dev-fr@openstreetmap.org
https://lists.openstreetmap.__org/listinfo/dev-fr
https://lists.openstreetmap.org/listinfo/dev-fr




--
Christophe aka orhygine | http://orhyginal.free.fr |


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Proxy TMS - WMS cadastre

[Frédéric Rodrigo]

Petit ajout du mode double jocker.

Comme il ne peut y avoir qu'une seule commune par tuile, j'ai ajouté la 
possibilité d'avoir une autre TMS avec le complément pour une deuxième 
commune (avec fond transparent), il suffit d'avoir un autre TMS avec 
** à la place de *


C'est le double joker qui est place sur la démo :
http://osm110.openstreetmap.fr/~fred/cadastre.html

Et si tu vous estes perfectionniste que la tuiles est à cheval sur 3 
communes, il suffit d'utiliser le triple joker *** ;)


Frédéric.

Le 15/02/2015 18:05, Christian Quest a écrit :

C'est TOP :)

Mettre ça sur cadastre.openstreetmap.fr/tms
http://cadastre.openstreetmap.fr/tms ?

Le 13 février 2015 21:01, Frédéric Rodrigo fred.rodr...@gmail.com
mailto:fred.rodr...@gmail.com a écrit :

Je viens d'ajouter le mode joker, il faut utiliser * a la place du
code insee. Bien sûr ça ne prend que une seule commune à la fois.

http://osm110.openstreetmap.__fr/~fred/cadastre.html
http://osm110.openstreetmap.fr/~fred/cadastre.html


Le 13/02/2015 08:01, didier2020 a écrit :

ca n'a pas marché du premier coup ...
je n'avais pas mis le http://osm110 et j'avais laissé les
crochets de
chaque coté du code insee

tms[20]:http://osm110.__openstreetmap.fr:4567/30085/__semi/{z}/{x}/{y}.png

http://osm110.openstreetmap.fr:4567/30085/semi/%7Bz%7D/%7Bx%7D/%7By%7D.png

- j'ai changé les parametres tout-semi ... SANS changer le nom
du tms
dans josm = avec le cache josm c'était pas tres cohérent

= il faut bien nommer les différents tms
tmsFRtout =

tms[20]:http://osm110.__openstreetmap.fr:4567/30085/__tout/{z}/{x}/{y}.png

http://osm110.openstreetmap.fr:4567/30085/tout/%7Bz%7D/%7Bx%7D/%7By%7D.png

tmsFRsemi =

tms[20]:http://osm110.__openstreetmap.fr:4567/30085/__semi/{z}/{x}/{y}.png

http://osm110.openstreetmap.fr:4567/30085/semi/%7Bz%7D/%7Bx%7D/%7By%7D.png

tmsFRtransp =

tms[20]:http://osm110.__openstreetmap.fr:4567/30085/__transp/{z}/{x}/{y}.png

http://osm110.openstreetmap.fr:4567/30085/transp/%7Bz%7D/%7Bx%7D/%7By%7D.png

- pour transp , il faut penser a  dezoomer (je comprenais pas
pourquoi
je ne voyais rien) pour voir les différentes limites

++ on voit mieux les noms de voie que sur le wms  (ils ne
sont pas
tronqués avec un gros zoom)

++ donc cool ! et encore plus cool le mode jocker ...

Le vendredi 13 février 2015 à 00:05 +0100, Frédéric Rodrigo a
écrit :

Bonjour,

J'ai mis en place un petit proxy qui faite des redirections
HTTP depuis
des tuiles vers le WMS du cadastre. Ça permet :
- une utilisation plus simple
- un mode joker de détection automatique de la commune, mais
je ne l'ai
pas encore codé ;), permet aussi de visualiser plusieurs
communes à la fois.

La démo est là :
http://osm110.openstreetmap.__fr/~fred/cadastre.html
http://osm110.openstreetmap.fr/~fred/cadastre.html
C'est utilisable en ligne et dans josm.

Il n'y a, ni stockage ni rediffusion du cadastre, c'est
juste une
redirection vers le WMS du cadastre.

On pourrait faire tourner ça proprement sur un serveur
quelque part ?

Frédéric.




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Proxy TMS - WMS cadastre

[Frédéric Rodrigo]

Bonjour,

J'ai mis en place un petit proxy qui faite des redirections HTTP depuis 
des tuiles vers le WMS du cadastre. Ça permet :

- une utilisation plus simple
- un mode joker de détection automatique de la commune, mais je ne l'ai 
pas encore codé ;), permet aussi de visualiser plusieurs communes à la fois.


La démo est là :
http://osm110.openstreetmap.fr/~fred/cadastre.html
C'est utilisable en ligne et dans josm.

Il n'y a, ni stockage ni rediffusion du cadastre, c'est juste une 
redirection vers le WMS du cadastre.


On pourrait faire tourner ça proprement sur un serveur quelque part ?

Frédéric.

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Intégration toponymes Occitan

[Frédéric Rodrigo]

Avec les ref insee c'est quand même bien mieux.

Mais je ne suis pas sûr que la qualité des données soit pour l'instant 
suffisante. Tu peux remonté les problèmes et/ou obtenir des 
éclaircissements ?


- certaines traduction qui contienne des virgules, des slashs ou des 
tirets quadratins mal utilisé je pense :

Sent Perdon – Isac : Saint-Pardoux-Isaac
c'est la traduction des noms des communes, ou des noms des villages ?
- le texte entre parenthèse doit probablement être ignoré (à confirmer ?)
- Les-Artigues-de-Lussac : Les Artigues-de-Lussac, des fois il y a des 
tirets, mais dans la plus part des cas ils n'y sont pas.
- L'article n'est pas systématiquement passé entre parenthèse, c'est 
volontaire ?

- le détrompeur est parfois présent, parfois absent :
Castèthnau dau Medòc : Castelnau-de-Médoc
Castra : Castres-Gironde
- les capitales sur les article ne sont pas toujours homogènes:
Senta Fe La Granda : Sainte-Foy-la-Grande
Sent Feliç de font Cauda : Saint-Félix-de-Foncaude


Frédéric.


Le 03/10/2014 00:28, Christophe Merlet a écrit :

Bonjour,


Lo Congrès m'a fait parvenir une mise à jour de son fichier de plus de
4500 toponymes en Occitan indexés sur le code INSEE des communes.

Y a t'il un volontaire pour scripter l'import automatique de ces
traductions sur les limites communales et les node place correspondant ?

Le fichier est téléchargeable à l'adresse
https://owncloud.redfoxcenter.org/public.php?service=filest=f644eccca351c5657e95ab24183edff4


Ce serait bien de le faire car il y a actuellement beaucoup de demande
pour une carto en occitan.


De plus, un colloque est en train d'être organisé par la DGLFLF
(Délégation générale de la langue française et des langues de France, un
département du Ministère de la culture et de la communication) pour
février 2015 sur les ressources numériques des langues de France.

Ce serait pas mal qu'OSM puisse y présenter une carto en Occitan la plus
exhaustive possible à cette occasion.



Librement,




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Intégration toponymes Occitan

[Frédéric Rodrigo]

Le 03/10/2014 14:20, Christophe Merlet a écrit :

Le 03/10/2014 13:44, Frédéric Rodrigo a écrit :

Avec les ref insee c'est quand même bien mieux.

Mais je ne suis pas sûr que la qualité des données soit pour l'instant
suffisante. Tu peux remonté les problèmes et/ou obtenir des
éclaircissements ?

- certaines traduction qui contienne des virgules, des slashs ou des
tirets quadratins mal utilisé je pense :
 Sent Perdon – Isac : Saint-Pardoux-Isaac
 c'est la traduction des noms des communes, ou des noms des villages ?
- le texte entre parenthèse doit probablement être ignoré (à confirmer ?)
- Les-Artigues-de-Lussac : Les Artigues-de-Lussac, des fois il y a des
tirets, mais dans la plus part des cas ils n'y sont pas.
- L'article n'est pas systématiquement passé entre parenthèse, c'est
volontaire ?
- le détrompeur est parfois présent, parfois absent :
 Castèthnau dau Medòc : Castelnau-de-Médoc
 Castra : Castres-Gironde
- les capitales sur les article ne sont pas toujours homogènes:
 Senta Fe La Granda : Sainte-Foy-la-Grande
 Sent Feliç de font Cauda : Saint-Félix-de-Foncaude



Je suis à la recherche d'une **solution technique** pour mettre à jour
des tags depuis un fichier CSV, pas d'un audit qualité.


Techniquement cela ne pas de problème, en tout cas pour moi. Faire un 
script et intégrer les données dans OSM est l'affaire d'une-demi heure.



Rien n’empêche d'importer les communes qui ne pose aucun problèmes, et
ça en fait des milliers, au lieu de reporter depuis plusieurs mois cet
import. Surtout que les problèmes que tu soulèves sont triviaux et se
corrigent par un simple regexp.


Je pense qu'il vaut quand même mieux corriger les données à la source et 
importer dans OSM les mêmes données que celles publiées par Lo Congrès.



La question est la même que pour la mise à jour des populations de
communes qui aurait du idéalement être fait dés la publication par
l'INSEE des chiffres officiels de 2014.


Idem. Je pense que personne ne le fait parce que l'intérêt est assez faible.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Intégration toponymes Occitan

[Frédéric Rodrigo]

Le 03/10/2014 14:41, Christophe Merlet a écrit :

Le 03/10/2014 14:30, Frédéric Rodrigo a écrit :

Le 03/10/2014 14:20, Christophe Merlet a écrit :

Le 03/10/2014 13:44, Frédéric Rodrigo a écrit :

Avec les ref insee c'est quand même bien mieux.

Mais je ne suis pas sûr que la qualité des données soit pour l'instant
suffisante. Tu peux remonté les problèmes et/ou obtenir des
éclaircissements ?

- certaines traduction qui contienne des virgules, des slashs ou des
tirets quadratins mal utilisé je pense :
  Sent Perdon – Isac : Saint-Pardoux-Isaac
  c'est la traduction des noms des communes, ou des noms des
villages ?
- le texte entre parenthèse doit probablement être ignoré (à
confirmer ?)
- Les-Artigues-de-Lussac : Les Artigues-de-Lussac, des fois il y a des
tirets, mais dans la plus part des cas ils n'y sont pas.
- L'article n'est pas systématiquement passé entre parenthèse, c'est
volontaire ?
- le détrompeur est parfois présent, parfois absent :
  Castèthnau dau Medòc : Castelnau-de-Médoc
  Castra : Castres-Gironde
- les capitales sur les article ne sont pas toujours homogènes:
  Senta Fe La Granda : Sainte-Foy-la-Grande
  Sent Feliç de font Cauda : Saint-Félix-de-Foncaude



Je suis à la recherche d'une **solution technique** pour mettre à jour
des tags depuis un fichier CSV, pas d'un audit qualité.


Techniquement cela ne pas de problème, en tout cas pour moi. Faire un
script et intégrer les données dans OSM est l'affaire d'une-demi heure.


Je n'en ai jamais douté !
Et je constate que tu ne donne toujours aucune piste pour permettre à
quelqu'un d'autre de travailler efficacement sur cet import.


1. Filtrer les données, la partie qualité qui peut prendre du temps, si 
les données ne sont pas de bonne qualité. Pour Osmose, quand les données 
sont de trop mauvaise facture, je ne fais purement et simplement rien. 
Ce n'est pas les jeux de données ouvert à intégrer à OSM qu'il manque.
2. Extraction des ??? (je ne sais tjs pas si ce sont les traductions des 
noms de communes ou de villages ou un peu des deux) de OSM avec 
overpass-api.
3. Un petit script ruby écrit sur le pouce qui édite les tags osm dépuis 
un hash chargé depuis le CSV.

4. Upload avec JOSM.


Rien n’empêche d'importer les communes qui ne pose aucun problèmes, et
ça en fait des milliers, au lieu de reporter depuis plusieurs mois cet
import. Surtout que les problèmes que tu soulèves sont triviaux et se
corrigent par un simple regexp.


Je pense qu'il vaut quand même mieux corriger les données à la source et
importer dans OSM les mêmes données que celles publiées par Lo Congrès.


Ce serait la première fois que l'on attends d'une source potentiel de
données qu'elle se mette au standard qualité d'OSM au lieu d'effectuer
nous-même ce travail. (ROUTE 500, Cadastre, FANTOIR, ...)


Dans les exemples que tu cites, le processus est vraiment à minima de un 
an pour avoir une mise à jour. Là il me semble que ça soit la cas. Il 
est toujours préférable d'améliorer la source, mais c'est souvent 
impraticable.





La question est la même que pour la mise à jour des populations de
communes qui aurait du idéalement être fait dés la publication par
l'INSEE des chiffres officiels de 2014.


Idem. Je pense que personne ne le fait parce que l'intérêt est assez
faible.


Ceux qui y ont un intérêt ne le font pas car il ne savent pas
automatiser une tâche qui nécessite plus de 72000 éditions, et ceux qui
savent automatiser la tache ne le font pas parce qu'ils n'y voit aucun
intérêt. Ce n'est pas très productif.

Et depuis quand avoir la population à jour dans OSM serait sans intérêt ?

Librement,




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Problème de projection entre Postgis et Qgis

[Frédéric Rodrigo]

Le 08/08/2014 21:08, V de Chateau-Thierry a écrit :

Avec postgis :
select st_astext(st_transform(st_setsrid(ST_MakePoint(252071,49853),
31370), 4326));
POINT(5.78258949757128 49.7510346906123)

Avec qgis :
(252071, 49853) = (5,785167517 49,75148809)



Pour ton point, j'obtiens
POINT(5.78516751996673 49.7514880757953) avec un postgis 2.1 / postgres 9.3
donc ce que tu as avec QGis.

Sinon j'ai pris un point en plein Bruxelles, et j'obtiens les mêmes coordonnées
avec mon PostGis et avec QGis 2.1 :
select st_astext(st_transform(st_geomfromtext('POINT (4.35707 
50.84541342)',4326),31370))
= POINT(149177.247235916 170556.499638186)

Tu aurais une config particulière pour Postgis ?


Je ne pense pas. C'est le postgis 1.5 de osm110.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] schema osmosis cadastre

[Frédéric Rodrigo]

Le 07/06/2014 12:43, didier2020 a écrit :

bonjour,

il y actuellement des analyses osmoses (qui utilisent le schema osmosis)
qui détectent des erreurs sur les données osm,

je me demandais comment je pourrais faire pour les données cadastre non
importées.

j'ai pensé a un truc un peu moche :
+ modification du fichier osm
id negative = id positif + changeset,user,date ... fictif

+ lancer une analyse osmose

+ lire le fichier xml d'osmose et ajouter un tag d'erreur aux ways

si vous avez une meilleure idée, je suis preneur


Je pense que tu pourrais directement réutiliser les requêtes d'Osmose 
sans utiliser Osmose, si c'est juste pour quelques analyses bien sûr.


Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Disparition de balises (seamark) - exploiter les diff

[Frédéric Rodrigo]

C'est tout simplement le tag seamark:fixme


Le 25/04/2014 14:27, THEVENON Julien a écrit :

Je vais essayer de t en faire un vite fait. c est quel tag dont tu
cherches a detecter la suppression exactement ?



*De :* THEVENON Julien julien_theve...@yahoo.fr
*À :* Discussions développeur OSM en français
dev-fr@openstreetmap.org
*Envoyé le :* Vendredi 25 avril 2014 14h23
*Objet :* Re: [OSM-dev-fr] Disparition de balises (seamark) -
exploiter les diff

Salut,

Si tu connais le C++ tu peux faire un plugin Soda qui t affiche le
numero du changeset a chaque fois qu il voit passer une suppression
d un objet comportant ce tag et tu lances Soda sur les diffs des
deux derniers mois

Julien



*De :* Bruno Cortial bruno.cort...@laposte.net
*À :* Discussions développeur OSM en français
dev-fr@openstreetmap.org
*Envoyé le :* Vendredi 25 avril 2014 14h06
*Objet :* [OSM-dev-fr] Disparition de balises (seamark) -
exploiter les diff

Bonjour,
On signale sur la liste OpenSeaMap une disparition de balises
maritimes (objets taggés en seamark*)

https://wiki.openstreetmap.org/wiki/Key:seamark:fixme#Progress


Comment exploiter les diff des 2 derniers mois pour retrouver
les changeset impliqués ?

Bruno

___
dev-fr mailing list
dev-fr@openstreetmap.org mailto:dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr


___
dev-fr mailing list
dev-fr@openstreetmap.org mailto:dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Test beta.osmose

[Frédéric Rodrigo]

Bonjour,

Une nouvelle série d'amélioration ont été apporté à Osmose dans le cadre 
du projet OpenAquiMap.


- filtre de la sélection des items par thématique
- filtre de la sélection des marqueurs avec un proposition de correction
- connexion à Osmose avec son compte OSM par l'OAuth et affichage du 
nombre d'erreurs de l'utilisateur
- utilisation de webasset pour le js/css (compression et unification des 
fichiers)
- ajout d'un éditeur de tags, permet de faire des modif sur les tag en 
ligne (comme raw editor mais sans le raw ;). permet aussi d'appliquer 
les fix en ligne. Pour l'utiliser il faut bien sûr être connecté et 
utiliser les liens edit ou fix depuis une popup. Les modifications 
ne sont envoyé sur l'API que lors que l'on utilise le lien Sauver dans 
le menu principal. L'upload peut être long.
- amélioration du comportement sur mobile et tablette, on peut aussi 
utiliser l'éditeur.


Vous l'aurez compris la grande nouveauté c'est l'éditeur. Le concept de 
l'édition différentielle je l'espère n'est pas trop perturbante.


Toutes le remontés de bug, de problèmes de compréhension ou sur le 
concept sont les biens venus.


À tester sur la beta :
http://beta.osmose.openstreetmap.fr
Interface beta, mais utilise les mêmes vrais données que la version 
normale de Osmose.


Frédéric.

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Beta Osmose Leaflet

[Frédéric Rodrigo]

Le 25/02/2014 09:08, didier2020 a écrit :

Le lundi 24 février 2014 à 22:14 +0100, Frédéric Rodrigo a écrit :
2 nouvelles remarques: - les overlays ne s'affichent pas (sauf les 2 
osmoses)

Le service layers.openstreetmap.fr était tombé, c'est revenu,

- un item 7020 apparait dans le permalink quand:
selection tous (global) ET selection rien (categorie a mapper)
or item 7020 n'existe pas dans la catégorie a mapper

Effectivement, c'est un item caché. C'est corrigé.
mon smartphone n'a pas un ecran assez grand ... je n'arrive pas a voir 
les layers osmose car la liste des overlays est plus grande en hauteur 
que la taille de mon ecran. (c'est encore pire en paysage).  Je 
confirme que c'est bon sa !

Je n'ai pas de solution pour ça.

Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Beta Osmose Leaflet

[Frédéric Rodrigo]

Super merci, c'est bien ça. Tout et rien avait été corrigé mais pas 
inverser.



Le 24/02/2014 15:33, didier2...@free.fr a écrit :

piste? : il n'y a pas de notion de parent coté menu ou coté layer ?

  // Invert item check
   _invertAllItem: function () {
 $(input[type='checkbox']).each(function () {

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Beta Osmose Leaflet

[Frédéric Rodrigo]

Normalement on a tout pris en compte, tu peux nous confirmer que c'est bon.
Le select sur mobile est également corrigé.

Frédéric.

Le 24/02/2014 12:18, didier2020 a écrit :

Le lundi 24 février 2014 à 11:36 +0100, Frédéric Rodrigo a écrit :

Le 24/02/2014 09:07, didier2020 a écrit :

+1 pour la possibilité de recherche de lieu
+1 pour le truc qui s'anime pour faire patienter
+ pour la sélection des calques, je préfère une action clic sur le
bouton layer qui ouvre et ferme plutôt que le survol ( c'est juste une
préférence)


Test sous linux/chromium (version libre de chrome):
- l'animation ne fonctionne pas et les Osmose error n'apparaissent pas

Je ne constate pas ce problème avec le dernier linux/chromium.
Tu peux confirmer que ce n'était pas juste temporaire ? On a des doutes
sur la capacité du serveur a répondre tout le temps en temps raisonnable
pour une utilisation interactive de Osmose.

autant pour moi, mon premier essai était sur debian 6.
Avec debian 7 / Chromium et Iceweasel (FF libre) fonctionnent comme sous
windows.
Avec debian 6 / Firefox 64 fonctionne comme sous windows.


Test sous seven/firefox+ie7+chrome:

- pour la sélection des erreurs (tout-rien-inverser) :
inverser agit sur les calques (pas les layers de base, mais les
autres)

On avait ce problème au début partout, mais je ne vois plus d'où ça peut
venir, et en plus spécifique à une plateforme.

cf ci-dessus, ce n'est pas spécifique a une plateforme.


Tu peux cibler un peu
plus s'il te plait ?



clic sur inverser :
- cela ajoute un # dans la barre d'adresse.
- la selection des layers secondaire s'inverse
- la selection de la gravité ne fonctionne plus correctement tant qu'on
laisse le # dans la barre d'adresse
clic sur tout ou rien n'a pas d'influence sur ces memes layers.




- l'animation pour patienter ne se voit pas si on sélectionne uniquement
le layer 'Osmose error heatmap

Ça c'est normal, elle n'est là que pour les marqueurs.


- permalink :
je clique sur permalink = ok dans la barre d'adresse
+ si je clic sur une catégorie (structurel, tags manquants ...)
= clic sur permalink ne fait rien apparaitre dans la barre d'adresse
+ si je clic sur une catégorie (structurel, tags manquants ...) ET
modification d'item
= clic sur permalink ne fait pas apparaitre la localisation
(lat,lon,zoom) dans la barre d'adresse

ok, vu.

Merci de ton retour


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Beta Osmose Leaflet

[Frédéric Rodrigo]

Bonjour,

Nous finalisons une réécriture de l'interface d'Osmose en Leaflet. 
L'aspect de l'interface reste le même. Juste quelques petites sucreries 
en plus (géolocalisation navigateur et recherche d'adresses). 
L'interface doit aussi fonctionner sur mobile.


On est preneur de tests et des remontés de problèmes :

http://beta.osmose.openstreetmap.fr/fr/map/

Pour l'instant le seul problème connu et sans solution est le select de 
la gravité qui marche mal sous osx et mobile.


Cette beta interagit avec les mêmes données que la version normale, 
c'est juste l'interface web qui change.


Merci d'avance,
Frédéric.

Note : également merci à Yohan pour ces conseils en javascript.

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[Frédéric Rodrigo]

Le 18/02/2014 10:05, Pieren a écrit :

2014-02-17 23:08 GMT+01:00 Vincent de Château-Thierry v...@laposte.net:


Les discussions ayant réaffirmé l'absence de consensus sur la manière de
modéliser les adresses, vous trouverez pour chaque commune 6 (oui six !)
lots de données.


Merci d'offrir cette liberté. C'est tout à fait dans l'esprit du projet.


Seule la modélisation avec relation bénéficie, autant que possible, de
l'ajout des codes FANTOIR.
Pour expliquer la démarche, un peu de littérature sur cette page :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses


On laisse croire sur le wiki que la relation est la seule option pour
les codes FANTOIR, ce qui est faux. Il reste celui de mettre le tag
directement sur les highway. La dernière discussion sur le sujet
parlait du cas particulier des rues appartenant à deux communes et
donc avec deux codes FANTOIR. Mais il existe aussi des solutions dans
ces cas-là, largement appliqués pour les tags name par exemple (le
code FANTOIR n'étant qu'un alias du nom de la voie).

Pieren


Bonjour,

Je vais prendre contre pied total de Pieren... La liberté c'est bien, 
mais des adresses sans relation c'est très difficilement utilisable par 
la suite dans le cas non nominal. Mon avis c'est simple : il ne faut pas 
mettre à disposition des fichiers sans la relation : c'est de 
l’incitation la débauche, à la multiplication des cas et traitements 
particuliers.


Voilà, voilà.
Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Fichier comparaison cours d'eau

[Frédéric Rodrigo]

Le 05/02/2014 23:35, sly (sylvain letuffe) a écrit :

Le mercredi 5 février 2014 10:20:03, Sylvain Maillard a écrit :

c'est quelle version de la BDCarthage qui est utilisée pour la comparaison
?


Et bien je ne me rappel plus précisément où j'ai récupéré ça, je peux juste
dire que ça a environ 2ans et il me semble, mais sans certitudes, que c'était
dispo sur le site du sandre.

Quoi qu'il en soit, la longeur des cours d'eau n'ayant pas vraiment changé en
2 ans, je suppose que la fraicheur de ma source n'est pas la priorité sur
laquelle je dois travailler, mais plutôt tenter de voir pourquoi des données
disparaissent de la copie de la base.

Si vraiment je constate trop de numéro de référence sandre qui ont changée, je
m'occuperais alors de comparer avec une source plus récente (mais ça oblige de
regarder comment elle est faite, l'importer, la vérifier, enfin bref, un peu
de boulot quoi)




Le révérenciel sandre était déjà disponible, c'est la disponibilité de 
la géométrie qui est ressente.


Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

[Frédéric Rodrigo]

Superbe !

Il faut reconstituer les relations depuis les noms de rues. En toute
logique les noms devraient corespondre exactement aux noms de rues du
fantoir.

Frédéric.




Le 16 janvier 2014 12:24, Tyndare tynd...@wanadoo.fr a écrit :


 J'ai pu récupérer les adresses de toutes les parcelles d'une commune.
 Je fait des requêtes par zone d'environ 700m de large et je temporise un
 peut entre chaque requête donc c'est très lent.
 http://37.187.60.59/cadastre-housenumber/adresses.php

 Voici par exemple le résultat pour Mulhouse:

 http://37.187.60.59/cadastre-housenumber/data/068/QP224/QP224-parcelles-adresses.osm

 Je ne sais pas trop quoi faire de ce résultat en fait.
 Est-ce que ça pourrait être utile de croiser ces données avec le fichier
 FANTOIR ?

 Je crois que je vais essayer de faire le lien avec les addr:housenumber
 que je récupère par ailleurs pour pouvoir leur assigner une rue de manière
 plus fiable.



 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/dev-fr


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Ajouter le Nicaragua dans Osmose?

[Frédéric Rodrigo]

Le 29/12/2013 18:16, Yohan Boniface a écrit :

Hello,

Je sais pas si je suis sûr la bonne liste, mais je sais qu'ici je
trouverai nos deux loulous d'Osmose :)
Des collègues d'HOT actuellement au Nicaragua me demande s'il serait
possible d'ajouter le pays à Osmose.

Merci d'avance pour eux si c'est possible :)

Yohan


Le trac c'est bien aussi.

Il faudrait créer un extract depuis
http://download.geofabrik.de/central-america-latest.osm.pbf (176 Mo)

relation : 287666
langue : espagnol
niveau de couverture : default_country_simple (ou default_country si 
bing couvre correctement tout le pays)

conduite : à droite

Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Mis jour bati

[Frédéric Rodrigo]

Le 24 décembre 2013 12:50, RÉAU Simon msr...@gmail.com a écrit :

 Cher Papa Noël


Là il risque d'être un peu débordé pour faire ça pour noël.


 Pour Noël je désirerais cette année que les gentils développeurs
 d'openstreetmap réussissent a extraire les limites de planche cadastral
 (que j'arrive a dessiner manuellement grâce à la couche section dans le
 plugin cadastre de JOSM).
 Avec ceci j'aimerais qu'ils trouvent une solution pour découper les
 fichier du bati issu du site cadastre.openstreetmap.fr car osmosis ne
 veut pas le faire car il lui manque des attributs sur les données.


Il juste ajouter une autre condition ici, avec la detection de la bonne
couleur :
https://gitorious.org/qadastre/qadastre2osm/source/0860ca763e273f2e611a15e3c70a1354b0fe43d8:osmgenerator.cpp#L121
Et créer nouveau fichier en sortie.

Pour osmosis, il faut enrichir le fichier. Tu as essayé de l'ouvrir avec
josm puis de l'enregistrer.
Ce n'est pas des trucs important qu'il manque. On doit même pouvoir s'en
sortir avec un sed.



 Si ils arrivaient a faire cela je pourrais mettre a jour le bati dans
 OpenStreetMap et millésimer chaque batiment selon la mis a jour de sa
 planche cadastral que je récupère sur le site cadastre.gouv.fr rubrique
 s'informer lorsque je visualise une planche cadastral.
 Ainsi je ne ferait le travail de mis a jour grace au plugin bati-fusion de
 jecor (https://github.com/jecor/bati-fusion) que sur les planches ayant
 reçus des mis à jour sur.
 Cela permettrais aussi de montrer la qualité des données OSM en sourcant
 parfaitement les données et leurs dates de mis à jour, et peut être un jour
 voir des extraits de bati enrichir la section OpenStreetMap du site
 data.gouv.fr

 N’oublie pas non plus d'apporter plein de cadeaux à tous ces développeurs
 qui nous font des outils formidables pour contribuer à OpenStreetMap et à
 toutes les fourmis qui enrichissent la base de données.

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Trouver des objets ne possédant pas certains tags

[Frédéric Rodrigo]

Le 05/12/2013 22:51, François Lacombe a écrit :

Bonsoir,

Je souhaite savoir si dans le modèle de données retenu par OSM il est
possible de retrouver des objets ne possédant pas certains tags.
A partir d'Overpass API par exemple ?

Dans OAPI, on peut tout a fait fixer une clause pour trouver des objets
qui possèdent un tag défini avec n'importe quelle valeur mais en
revanche le langage ne permet pas de définir le conjugué d'une telle
contrainte.
Est-ce un oubli ou une lacune profonde du modèle ?


L'objet de ma question ne trouve pas d'application concrète dans OSM.
OSM utilise comme beaucoup d'autres systèmes une modélisation EAV pour
le stockage des tags dans la base de données.
Je cherche actuellement à mettre au point une requête SQL qui retrouve
des enregistrements qui ne possèdent pas certaines clés.


Merci par avance pour vos indications.



Il faut utiliser un jointure externe (left join en sql) sur ton tag 
s'il est dans une table de jointure ou IS NULL si c'est une colonne ou 
un hstore... tu ne donnes pas le schéma que tu utilises...


Pourquoi OAPI ne le fait pas ? Sûrement parce que ça coute cher. Pour 
trouver une données indexé il faut chercher dans l'index. Pour trouver 
une absence de données, il faut regarder partout.


Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Verification du routage

[Frédéric Rodrigo]

Le 29 novembre 2013 10:19, Ab_fab gamma@gmail.com a écrit :

 Pour le cas des cours d'eau, l'approche suivante est sympa (*), mais
 nécessite de définir manuellement des points (nodes)clef en début de bassin
 versant de chaque fleuve.
 https://github.com/skaringa/rivers

 Sur ce thème des vérifications de tous ordres, est-ce qu'avoir
 régulièrement une extraction (pbf par ex.) du réseau ferré, de
 l'hydrographie serait utile et pas trop contraignante matériellement pour
 faciliter le travail de ceux qui veulent se pencher sur la question ?

 Je sais que l'on peut le faire en partant d'un extrait Geofabrik et
 filtrer soit-même, mais ça alourdit sensiblement l'opération


A mon avis il vaut mieux utiliser l'overpass pour ça.
A titre de comparaison je fait des extractions de tous les transports en
commun et c'est pas si long que ça a extraire.


 --
 (*) en plus des outils de suivi existants
 - http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html (à la
 sly)
 - http://suivi.openstreetmap.fr/cours-eau/suivi-affluents.html (à la fred)

Il faudrait le remettre en place sur osm7


 - http://marani.claude.free.fr/courdo (à la Arno / Claude)


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Import addr:housenumber depuis le cadastre

[Frédéric Rodrigo]

Le 31/10/2013 14:05, Tyndare a écrit :


Le 25 octobre 2013 14:53, Frédéric Rodrigo fred.rodr...@gmail.com
mailto:fred.rodr...@gmail.com a écrit :

Tu peux également utiliser directement les opérateur de dessin de
base du PDF, ça évite un passage en SVG. Soit directement dans le
code de Qadastre, soit en exécutant un script depuis Quadastre en
lui passant les primitives (c'est comme ça que j'avais fait)


Cela serait surement beaucoup plus efficace en terme de performance,
mais je ne suis pas très à l'aise en C++, et je me suis perdu dans la
spec du format PDF. SVG m'a parut plus simple, mais je me trompe peut être.


Il n'y a pas grand chose à faire en C++, juste appeler une cmd externe 
et écrire les données dans un fichier. Ensuite tu peux coder en python.

Je n'ai pas retrouvé mon code qui faisait ça.
Coté PDF pas besoin de la spec, c'est aussi simple que le svg pour faire ça.



Pour détecter les numéros de rue, j'ai codé en dure un path
(au sens svg) correspondant à chaque numéro (0-9 et les lettres
B,T,Q,A,B,C,D,E,F), et je fait une transformation pour les
comparer. Je filtre ensuite selon la taille pour ne garder que
les numéros de rue (et éviter les numéros de parcelles).


Quel genre de transformations et de comparaison tu fais (je n'ai pas
pris le temps de regarder le code) ?
J'avais rencontré des problèmes la dessus : détermination de
l'orientation du texte, du mal à comparer les shapes entres elles
pour déterminer le caractère. Le path variait en fonction de la
taille de la commune et de son orientation.


Je commence par comparer les commandes qui composent les paths, si ce
sont exactement les mêmes, alors je compare les coordonnées de la liste
des points qui composent les paths (par rapport au format SVG j'ai en
fait normalisé la représentation des path pour n'avoir que des
coordonnées absolue, pas de valeur relatives). Je transforme donc les
points avec pour chaque path:
  - une mise à l'échèle de telle manière que le point le plus loin du
premier se retrouve à une distance de 1.0
  - une rotation pour que le premier point et le 6ème (choix arbitraire)
se retrouvent à l'horizontal
Une fois ces transformations effectuées, je vérifie que la distance
maximale entre les points des deux paths soit  0.05
Je pense donc avoir une vérification assez fiable et ne pas pouvoir
confondre un chiffre avec un autre, le risque est plus d'en rater
certains pour des problème de précision.

J'avais aussi à l'origine un problème de variation des path selon la
taille de la commune, mais je pense que c'était en fait un problème de
précision du au format PDF, et je crois l'avoir résolu en découpant la
récupération du cadastre en plusieurs fichiers PDF de taille raisonnable
(comme le script import-bati.sh).


Tout est là ! Résoudre le problème à la base et faire simple. Chapeau.


J'espère que a court et moyen terme on pourra avoir accès aux
données d'adresses du cadastre sans avoir à les extraire depuis le
WMS. Ces informations sont dans les EDIGEO et il faut à mon avis
pousser pour avoir accès à ces données, on a commencé à la faire
département par département, il faut poursuivre


Passer par les fichier EDIGEO serait effectivement plus sûr et plus
logique, mais là on sort de mon domaine de compétence.


Oui, mais pas pour toute la France de toute façon.

Je pense qu'une fois le problème de l'extraction passé le plus important 
est de chercher à créer les relations associatedStreet, sans même tenir 
compte de OSM. Ça nous reprocherait de ce que l'on peut avoir en 
OpenData. L'intégration à OSM est, pour moi, un autre problème. (Même 
s'il est vrais que l'on pourrait se servir des infos de OSM pour créer 
la relation).



Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Import addr:housenumber depuis le cadastre

[Frédéric Rodrigo]

N'allons pas trop vite. Je sais ô combien l'extraction depuis le cadastre
WMS n'est pas facile pour y avoir passé (perdu?) des heures et des heures.
Il faut d'abord voir ce que fait effectivement l'outil.


Le 25 octobre 2013 15:16, Ab_fab gamma@gmail.com a écrit :

 Christian,

 Il y a déjà http://addr.openstreetmap.fr/ pour l'interface web qui met à
 disposition des fichiers osm rue par rue dans les agglos où les adresses
 ont été libérées.
 Avec une couleur par statut

 Pour la génération de ces fichiers .osm, je ne sais pas comment cela a été
 fait en pratique.


Pour addr.osm.fr

My actul workflow is:
- load shape file into postgis with shp2pgsql
- write sql code to fill nodes/relations table in osmosis format (like this
http://addr.openstreetmap.fr/Data/rennes.sql)
- export data with osmosis in .osm
- split .osm into one .osm by relation with a small ruby script

My 1 cent et un copie/coller à 1 cent.
Frédéric.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Correction en masse (Était : Gîtes, chambres d'hôtes)

[Frédéric Rodrigo]

Oui tu peux faire ça toi même simplement en rajoutant des entrées dans
http://wiki.openstreetmap.org/w/index.php?title=User:FrViPofm/TagwatchCleaner
quand la recherche ne concerne que un seul tag.

Frédéric.



Le 17 octobre 2013 11:11, Nicolas Dumoulin 
nicolas_openstreetmap@dumoulin63.net a écrit :

 Le jeudi 17 octobre 2013 10:33:12 Frédéric Rodrigo a écrit :
  Je ne réponds pas directement à ta question. Mais c'est un des buts
  d'Osmose : les testd de non régression. Quand tu tombe sur ce genre de
 cas,
  c'est bien de remplir que trac pour Osmose (ou de même de coder un test
 ;)
  ) :
  http://trac.openstreetmap.fr/

 Merci Frédéric.

 J'ai créé un ticket. J'ai vite-fait regarder dans les sources, mais je ne
 sais
 pas trop où ajouter ce genre de test … TagWatchFrViPofm.py ? un nouveau
 plugin
 ou analyser ?

 --
 Nicolas Dumoulin
 http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/dev-fr

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Script overpass-api

[Frédéric Rodrigo]

Bonjour,

J'ai vu la conf de l'auteur de overpass aus SotM, et il y a des astuces.
C'est contre intuitif mais tu pourais avoir un résultat plus rapide sans
mettre de bbox !
Il y a aussi pluseirs modes de sortie, normal (rien), seq sans les tags
et meta, le mode seq est normalement bien plus rapide.

Frédéric.



Le 6 septembre 2013 21:24, Etienne Trimaille
etienne.trimai...@gmail.coma écrit :

 J'apporte tout de même une solution que j'utilise pour extraire les
 landuse d'un fichier osm (ou pbf) dans un shapefile :

 ogr2ogr -s_srs EPSG:4326 -t_srs ${2} -f ESRI Shapefile
 polygons-landuse.shp file.osm -sql SELECT * FROM multipolygons WHERE
 landuse IS NOT NULL --config OSM_USE_CUSTOM_INDEXING NO --config
 OSM_CONFIG_FILE ../osmconf-polygons-landuse.ini

 Le driver osm dans gdal est très pratique.

 Le 6 septembre 2013 14:39, sly (sylvain letuffe) lis...@letuffe.org a
 écrit :
  On vendredi 6 septembre 2013, V de Chateau-Thierry wrote:
  Possible que le service auquel tu penses soit celui-ci :
  http://www.osm974.re/osm2gis/
 
  Je pensais en effet à ça, mais mon cerveau a dû mélanger des choses car
 je ne
  vois pas sur cet outil de possibilité de forcer un where
 tourism=camp_site
  ou option équivalente.
 
  Donc en effet, tant par la possibilité limité d'extraction en
 couverture que
  par cette impossibilité de choisir des tags, cela ne fait pas de cet
 outil le
  bon candidat pour le besoin exprimé.
 
  Sinon, si c'est du one-shot l'asso osm-fr dispose de 2 bases à jour
 avec du
  osm2pgsql, en offrant une bière à un des admin, y'a moyen de se faire
 servir le
  shapefile qui va bien ;-)
 
  --
  sly, DWG member since 11/2012
  Coordinateur du groupe [ga]
  http://wiki.openstreetmap.org/wiki/User:Sletuffe
 
  ___
  dev-fr mailing list
  dev-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/dev-fr

 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Question pour une requête Overpass

[Frédéric Rodrigo]

Bonjour,

Je ne vais répondre que a moitié à ta question.

Osmose n'en trouve pas :
http://osmose.openstreetmap.fr/fr/errors/?country=france_languedoc_roussillonitem=7120

Frédéric.

Le 26/07/2013 17:48, Nicolas Moyroud a écrit :

Bonjour à tous,

Après une petite comparaison entre les limites administratives du
Languedoc-Roussillon et les admin_centre il apparaît qu'il y a manque un
admin_centre quelque part. Je voudrais identifier l'élément manquant
pour l'ajouter dans OSM. Connaissez-vous un moyen de faire la requête
suivante avec l'overpass : renvoie moi la relation
boundary=administrative admin_level=8 pour laquelle il n'y a PAS de
membre admin_centre ? Je ne sais pas faire dans ce sens là. C'est
possible ?
Sinon comme solution il me reste l'import dans PostGIS et une bonne
requête spatiale, mais bon si je peux faire directement avec
l'overpass... :-)

Merci a+
Nicolas

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Des IDs a votre bon coeur COMPLET J'ESPERE.

[Frédéric Rodrigo]

Le 28/06/2013 09:37, Ista Pouss a écrit :

http://www.diaam.com:8080/idalacarte/index.jsp

Il s'agit de dire et de montrer que, dans un bounding box donnée, un
ensemble de tags donné est capable de déterminer un ensemble d'objets
géographiques, chaque objet géographique ayant son jeu de tag unique.
(si vous ne comprenez pas c'est que je m'exprime mal).

À partir de là, l'expression règle + tags uniques forment id.

Quelqu'un avait rouspété que l'id se formait de façon obsure. Pas du
tout !  À chaque id je suis capable de faire correspondre l'ID Overpass
(car j'utilise overpass).


C'est tes ID à toi qui sont obscures.


Soit l'exemple vachement intéressant des boulangeries stéphanoises :
http://www.diaam.com:8080/idalacarte/ids/stephboulange

Il se trouve que le jeu {shop=bakery, name=} forme règle valide pour
former un identificateur unique dans la bounding box stéphanoise.

Tenez vous bien, la boulangerie La baguette magique a comme id
Overpass
http://overpass.osm.rambler.ru/cgi/interpreter?data=node%2845.38591285563495%2C4.306640625%2C45.48228066163947%2C4.51263427734375%29%5B%22shop%22%3D%22bakery%22%5D%5B%22name%22%3D%22La+baguette+magique%22%5D%3Bout%3B
!

Et cet id est complètement prévisible, sans utiliser mon logiciel !


Là je ne te suis pas.


MAAAis (certains vont peut être rouspéter), pour vérifier que cet id
est bien unique, il est pratique d'utiliser mon logiciel.

Et mon logiciel donne à cette boulangerie l'id
www.diaam.com:8080/idalacarte/ids/stephboulange/i71435
http://www.diaam.com:8080/idalacarte/ids/stephboulange/i71435 qui me
semble (un peu) plus pratique.

J'utilise l'API Overpass qui me semble très bonne, mais qui se limite
vite avec la bounding box. Je ne peux examiner qu'une portion limitée du
territoire français, telle la taille d'une petite région, sinon je tombe
en timeout, ce qui m'embête bien.

Au moins, sur une ville, ça a l'air de bien marcher.


Je ne suis pas sur d'avoir compris. Pour moi ton outil fait des short 
links sur des requêtes overpass, avec un interface de création.



Egalement, je découvre que ce principe est très utile pour découvrir des
erreurs. J'ai parlé sur la liste utiilisateur de mes interrogations
concernant les points géodésiques ; j'ai l'impression que cette approche
est très complémentaire d'osmose, mais je sais pas si osmose n'est pas
capable de trouver ce genre d'erreurs, ou si c'est simplement que la
règle n'a pas été établie dans osmose ?


Ne le prend pas mal, mais encore une fois je ne te suis pas, quel genre 
d'erreur ?



Quoi qu'il en soit, j'ai trouvé plein d'autres problèmes analogues, et
j'ai l'intention d'essayer de traiter et comprendre les problèmes donnés
sur la liste utilisateur par cette approche, ce qui me permettra de
construire ce logiciel sur des cas concrets, et peut être d'aider ceux
qui les posent :-)

Attention que pour l'instant le site web est en HTML 0.5, à part pour
remplir la bounding box que j'ai mis en leaflet sinon c'est vraiment
trop chiant.


J'aime bien le concept HTML 0.5 ;)

Désolé,
Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Osmose error 500

[Frédéric Rodrigo]

Le 26 mars 2013 11:25, franck guillaouic fguillao...@gmail.com a écrit :

 Bonjour,

 Merci pour vos réponse ,
 Suite au menu vide , nous avons créer deux petits scripts afin de remplir
 les tables dynpoi_item , dynpoi_categ et dynpoi_item_last_update avec les
 enregistrements obtenus sur le poste osmose à la maison.
 nous obtenons sur le frontend l'affichage du menu superieur et du menu
 d'item remplie.

 Avez pu faire le transfère d'erreurs du back vers le front ? C'est la
 première chose à faire pour commencer à remplir des tables.

 Nous avons tentés de faire le transfère par la commande ./osmose_run.py
 mais sans succés.
 Plus en détails, nous avons modifiés l'URL_frontend dans
 /backend/modules/config.py par http://localhost/cgi-bin/update.py;
 puis mis dans notre virtualhost un directory cgi-bin.
 Mais aucun transfère réalisée.


/cgi-bin/update.py est une url mappé de l'application du frontend. C'est la
même url que /control/send-update, cgi-bin est juste là pour des raisons
historiques.
https://gitorious.org/osmose/frontend/blobs/master/control.py#line138

Le processus d’envoi de données est le suivant :
- osmose_run.py exécute une analyse et créer un fichier .xml.bz2
- il contacte le frontend pour lui donner une url de téléchargement du
xml.bz2 et lui donne le mot de passe
- le frontend télécharge le fichier et effectue sa mise à jour

Donc il ne faut pas de répertoire cgi-bin. Il faut que les fichiers
produits par le backend soient accéssible en http par le frontend.

Frédéric.
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [tech] Bornes hydrantes Lausanne

[Frédéric Rodrigo]

Salut,

Ne t’inquiète pas, j'ai vu ton commit. Il faut que je le test. Je fais ça
dans la semaine.

Frédéric.


Le 2 février 2013 09:59, yvecai yve...@gmail.com a écrit :

 Salut,

 Je reviens avec ces bornes hydrantes Lausannoises.
 J'ai lancé un merge-request ici : https://gitorious.org/osmose/**
 backend/merge_requests/4https://gitorious.org/osmose/backend/merge_requests/4

 Est-ce que Cyrille ou Frederic peuvent y jeter un coup d'oeil?

 Concernant le droit d'utiliser ces données, il ne faut pas s'attendre à
 avoir un super portail 'opendata' avec des licences en pleine page. Nous
 avons néanmoins un email du chef technique réseau Ville de Lausanne sur
 talk-fr  (http://lists.openstreetmap.**org/pipermail/talk-fr/2013-**
 January/053387.htmlhttp://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053387.html
 ).
 Le mouvement OpenData n'est pas très engagé de ce coté-ci du Jura. Mais
 c'est avec ce type d'intégration que l'on souhaiterai montrer l'exemple.
 Une analyse sur Osmose permettent de proposer un retour à l'effort engagé
 par le Service des Eaux.

 En plus, la communauté Romande étant un peu en berne ces temps-ci, on
 aimerai bien pouvoir monter une carto-partie pour aller valider ces bornes
 sur le terrain pour re-motiver les troupes.

 Yves Cainaud

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] osmose à la maison

[Frédéric Rodrigo]

Le 30 janvier 2013 13:06, Mickaël Guéret m.gue...@free.fr a écrit :

 J'ai donc un peu modifié la structure de la base de donnée, j'ai crée
 une vue dynpoi_item, qui reprend les infos nécessaires, plutôt que
 d'être obligé de lancer un cron...

Avec beaucoup de données ça va être très lent. C'est pour ça que c'est un
cron.


 Et voilà, ça fonctionne !! enfin presque, reste une erreur de base de
 donnée pour la page errors... Je regarde ça plus tard ! et ensuite je
 met tout ça noir sur blanc, promis ! (un endroit préféré ?)

Le plus important me semble être de patch osmose quand c'est possible. Le
reste peut aller dans un patch du README ;)

Pour les autres questions je laisse répondre Jocelyn qui est plus compétant
que moi là dessus.

Frédéric.
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle

[Frédéric Rodrigo]

Salut,

Sur osm7 j'ai installé un TileMill depuis les sources. Il apporte
quand même un gros confort dans le design du style.
Le mss j'ai envie de dire on s'en fout, c'est n'est pas la partie
intéressante. C'est surtout l'approche css-like qui est intéressante
(et donc cartocss).

Frédéric.

Le 21 décembre 2012 12:52, sly (sylvain letuffe) li...@letuffe.org a écrit :
 Bonjour,

 Résumé rapide : Je suis en train de mettre en oeuvre sur les serveurs de
 l'association osm-france un nouveau style de rendu sur la terre dont la cible
 est le contributeur openstreetmap pour qu'il puisse voir :
 - tout ou presque ce qu'il y a dans la base (tout objet dont les tags sont
 acceptés sur le wiki)
 - rapidement ses propre modifs
 - créé collaborativement si quelqu'un veut m'aider

 Son petit nom :
 2u : acronyme de Ugly and Usefull
 (J'aurais aimé l'appelé 4u, mais je n'ai pas trouvé les 2 u qui me manque)

 Voilà pour le background, maintenant je me pose la question de la technologie
 à utiliser.
 Le moteur de rendu sera mapnik, et la base : osm2pgsql. Plutôt que de partir
 de rien, je préfère reprendre le style existant sur osm.org (ou un autre,
 tant qu'il est déjà bien avancé)

 Je me suis donc naturellement tourné vers :
 https://github.com/gravitystorm/openstreetmap-carto

 Une reprise des styles actuels de osm.org qui sont au format xml vers le
 format CartoCSS
 La pub est alléchante :
 - quasi identique à l'actuel sur osm.org
 - joli format plus facile à écrire proche du CSS
 - moins de redondance dans le style
 - une interface graphique clic-clic pour faire ses modifs
 - un générateur simple pour passer de cartoCSS à xml (dont mapnik a toujours
 besoin)

 Que demande le peuple ? un enfant s'en servirait dirait presque la pub, idéal
 donc pour se partager le travail sans être informaticien et que de temps
 gagné !
 J'ai donc sauté dans la fosse (aux lions) de cette alléchante perspective,
 mais voilà que la réalité semble rattraper quelque peu la fiction, et mes 4
 heures à étudier la question et tester la solution dans tous les sens m'ont
 amené à douté de mon choix.

 J'en appel donc à ceux qui l'utilise, ceux qui utilisent autre chose, ceux qui
 sont restés au bon vieux format xml d'avant, vous en pensez quoi ?

 J'ai aussi sans doute du rater plein de trucs, et si vous avez un conseil, je
 suis preneur, voilà mon pessimiste résumé  :

 _gain de temps_
 * Je connais déjà pas mal le format xml et ça m'obligerais à apprendre un
 nouveau format
 * Le style osm.org à l'ancienne en fichier xml a tout de même bien évolué en
 4 ans, et les fichiers sont maintenant séparés par thème, la redondance est
 pas mal évitée par les xml entities et quelques tests m'ont montrés que
 c'était tout à fait possible de continuer à travailler directement sur eux

 _fiabilité_
 * Le style xml est ancien, éprouvé, et bien testé

 _pérennité_
 * Ça, la pub ne le dit pas, mais cartoCSS ne permet pas toute la richesse du
 format xml (il ne manque pas grand chose toutefois)
 * lorsque mapnik évolue, il faut que cartoCSS suive, sinon, on ne peut pas
 profiter des nouvelles fonctionnalités
 * Si cartoCSS est abandonné, je suis bloqué

 _facilité d'utilisation_
 * Finalement, un enfant ne s'en servirait peut-être pas, le truc qui passe de
 cartoCSS à xml est un obscure (pour moi) bidule en Node.js dont je n'ai pas
 réussi à trouver de paquet debian et bourré de dépendances
 (ma philosophie à 2 francs CFA : quand pas de paquet debian maintenu, méfiance
 accrue)
 * Le truc clic-clic qu'il est trop beau est bien gentil, mais il faut quand
 même monter une base postgresql+osm2pgsql donc pour le accès à tout le
 monde c'est pas non plus la panacée
 * Le TileMill (le truc clic-clic) ne tourne que sur Ubuntu, et pas sur toutes
 les versions, et avec un installateur louche qui va chercher des trucs et des
 bidules un peu partout qui ne sont pas des les repos de la distrib, ce qui
 amène à ne plus pouvoir, ou plus difficilement, traiter le style sur le
 serveur directement

 Bref de chez bref, ça fait, il me semble, un sacré potentiel à emmerde, pour
 finalement gagner quoi ? un peu de confort à écrire des styles.

 Le format du fichier .mml est symptomatique d'un mode de pensé, selon moi
 tordu, des développeurs hypes et modernes qui adorent toucher toutes les
 technos du moment et délaisseront le projet dans 3 ans par manque d'intérêt.

 C'est au format JSON, le but est de rendre plus lisible le même fichier en xml
 de mapnik, j'ai lu les deux [1] et [2], et je ne vois pas en quoi le json
 (technologie que j'exècre par sa volonté de supplanter xml sans rien apporter
 de probant) apporte quelque chose de vraiment incroyable, par contre, ce que
 je vois bien, c'est que ça fait un nouveau format incompatible et une
 nouvelle sur-couche qu'il faudra ré-écrire en xml si on change d'avis.

 A votre avis ? Je suis tenté aussi par MapCSS et Caskadenik qui me semblent se
 situer à mi-chemin.

 [1]
 Layer: [
 {
   geometry: polygon,
   extent: 

Re: [OSM-dev-fr] Nouvelle interface web sur beta.osmose.openstreetmap.fr

[Frédéric Rodrigo]

Le 01/12/2012 20:13, Pierre Béland a écrit :

Beau travail.

C'est très utile de pouvoir utiliser la couche Bing.

Il serait intéressant d'ajouter, tout comme dans Layers, la couche de
chemins de limites administratives.


Je ne suis pas très fan de cette couche. Ce qui à mon avis doit définir 
une way comme limite administrative est son appartenance à une relation 
de limites administrative. Pour moi les tags sur les ways sont désuets.



Je serai encore plus heureux Père Noël lorsque les couches d'erreur
Osmose couvriront le Québec.


On a commencé à y travailler mais le but est d'activer le mode diff 
d'Osmose sur le Québec. On n'a encore jamais utilisé ce mode... Là on 
travaille plutôt sur la finalisation du nouveau frontend.



J'observe aussi que lors de la sélection d'une autre langue, la carte se
repositionne à la localisation de la page de démarrage.


Je n'observe pas ce problème. Mais de toutes façon le système actuel de 
gestion des langues va changer. La gestion des langues par cookies nous 
pose des problèmes pour la gestion du cache.



Pour la fonction Erreurs par utilisateur
- Le flux RSS ne contient pas pour chaque item les hyperliens vers JOSM
et Osmose.


On va corrigé ça.


Le fichier https://gitorious.org/osmose/frontend/blobs/dev/po/fr.po ne
contient pas le nom des couches et le Permalien. Ceux-ci ne sont
présentement pas traduits.


Oui, je sais.

Merci de tes retours.
Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Nouvelle interface web sur beta.osmose.openstreetmap.fr

[Frédéric Rodrigo]

Le 02/12/2012 09:30, didier2020 a écrit :

+1 pour le choix des layers
+1 pour la couleur rouge
peut etre que si le nombre de marqueur est  a  et zoom  10/11 ne
laisser que le fond rouge ?

(on peut le faire manuellement en desactivant le calque Osmose Errors)


C'est déjà ce que ça fait, mais au zoom 5.


+ le lien depuis erreurs par utilisateur n'affiche plus toujours les
marqueurs
http://osmose.openstreetmap.fr/map/?zoom=16lat=46.341297lon=2.603234item=3031level=2

http://beta.osmose.openstreetmap.fr/map/?zoom=16lat=46.341297lon=2.603234item=3031level=2

mais cela marche pour certains
http://beta.osmose.openstreetmap.fr/map/?zoom=16lat=48.764063lon=2.679294item=1210level=1


Effectivement le lien n'active pas tout seul le bon niveau de level.


+ dans l'historique des analyseurs, il manque un '/' pour le lien
source:
dans la page
http://beta.osmose.openstreetmap.fr/control/update/160

sur le chiffre 160 en haut a gauche le lien est
http://beta.osmose.openstreetmap.fr/errors?source=160
a la place de
http://beta.osmose.openstreetmap.fr/errors/?source=160


Ok


+ l'affichage de la position fait apparaitre des caracteres nbsp a la
place d'un espace
par exemple (colonne pos)
http://beta.osmose.openstreetmap.fr/errors/?country=france_alsaceitem=1010


Ok

Merci pour ces retours
Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] osmose à la maison

[Frédéric Rodrigo]

En fait le backend appelle le frontend pour lui transmettre l'url des
résultats. Le frontend les télécharge alors. Il faut donc que le
backend expose les résultats d'analyses sur un serveur http.

Le 27 novembre 2012 13:04, Mickaël Guéret m.gue...@free.fr a écrit :
 Le jeudi 22 novembre 2012 à 20:49 +0100, Jocelyn Jaubert a écrit :
 Effectivement, il manque un schéma complet. J'ai mis un schéma à jour ici:

 https://gitorious.org/osmose/frontend/blobs/master/tools/database/schema.sql

 (ce n'est pas dispo sur la branche dev encore, même si le schéma est le
 même sur les deux branches)

 Merci !

 Bon, maintenant tout semble correctement installé... Mais j'ai un
 problème de conversation entre les deux parties du programme. Si j'ai
 bien compris, les fichiers de résultats générés sont postés sur le
 site frontend...

 J'ai rajouté dans le fichier 'osmose_config.py' une ligne dans le
 dictionnaire 'available_results_urls' selon ce que contient mon fichier
 '/etc/hostname', mais cela ne semble pas correct, j'ai des erreurs 405
 pour chaque analyse... Qu'est ce que j'ai raté ?
 Ensuite il faut configurer le backend avec l'url de mise à jour... Je ne
 sais pas trop quoi mettre...

 Mika


 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] idées pour projet tutoré autour de l'admin de SIG

[Frédéric Rodrigo]

Bonjour,

Le projet me semble intéressant. J'ajouterais à la liste l'outil de 
géocodage Nominatim.


Il me semblerait également pertinent de faire produire aux étudiants une 
image de VM vierge de donnée avec une documentation pour utiliser les 
logiciels et y charger des données.


Frédéric.

Le 14/11/2012 19:59, Lucas Nussbaum a écrit :

Bonjour,

e suis contributeur occasionnel à OpenStreetMap (login: lnussbaum) et
enseignant-chercheur. J'enseigne principalement dans le cadre de la
licence professionnelle ASRALL (Administration de systèmes, réseaux et
applications à base de logiciels libres), à Nancy. Pendant cette licence
pro, les étudiants ont à réaliser un projet tutoré auquel ils
consacrent environ 200h par groupes de 4, de fin janvier à fin mars.
C'est donc un projet très important en volume horaire et pour leur
formation.

Je suis tenté de proposer cette année un sujet de projet, pour un groupe
d'étudiant, autour de le mise en place et de l'administration d'un SIG.
Mon idée pour l'instant est:
--8
Installation et configuration d'un système d'information géographique

Objectif: installer et configurer un miroir local (partiel)
d'Openstreetmap, ainsi que plusieurs outils associés.
- postgis + osmosis pour importer et tenir à jour les données
- serveur web de carte (mapnik and co)
- API overpass pour permettre de télécharger les données
- possibilités d'extensions:
   + installation d'outils de QA pour OSM (par exemple osmose)
   + serveur de tiles custom
   + visualisation combinée de données de différentes sources (cf
 http://www.vttrack.fr/)
   + exports (WMS  co)
--8

Evidemment, pour l'instant, tout ça existe déjà. Mon expérience de ces
projets est qu'il est difficile d'obtenir des contributions non
triviales dans ce cadre. Mais voyez-vous des manières d'étendre ce
projet afin de faire des choses qui vous seraient utiles, tout en
restant atteignables ? De préférence, dans des directions plus 'admin
sys' que 'dev web', car le développement web n'est pas le coeur de cette
licence pro.

Pour l'instant, ce que je vois, c'est que les étudiants pourraient
produire une documentation complète de l'installation de tous ces softs,
soit en contribuant aux howtos existants, soit en en rédigeant des
nouveaux.

Que voyez-vous d'autre ?

Il est aussi possible que je redirige mes étudiants vers cette liste
pour y poser certaines questions auxquelles je n'aurai pas de réponse
(c'est formateur pour deux d'interagir avec une communauté). Je les
brieferai évidemment avant pour ne pas qu'ils deviennent des 'help
vampire'.

Merci,




___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Contrôle qualité des axes routiers

[Frédéric Rodrigo]

Voilà le résultat de la comparaison des données des points avec OSM :

http://osmose.openstreetmap.fr/map/?item=7110level=1,2,3

À mon avis il n'y a que du coté d'OSM ou il y a besoin de faire des 
améliorations.


Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] debutant sql : distinct et/ou jointure

[Frédéric Rodrigo]

Si tu n'as pas beaucoup de colonnes tu peux aussi le faire à la main 
avec des unions.


Le 04/09/2012 10:57, didier2020 a écrit :

merci pour le lien et pas merci pour mon neurone ;)
didier
Le mardi 04 septembre 2012 à 10:32 +0200, Vincent de Chateau-Thierry a
écrit :

Bonjour,


De : didier2020

j'ai une table avec 2 champs : localisation et valeur (les valeurs sont
connues)

je veux faire une matrice de x colonnes
ligne = localisation, colonne = somme des valeur par type de valeur
| 0 | 1 | 2 |
ici | 26 [ 32 | 1 |
laba| 1 | 5 | 0 |

je fais 3 requete puis je une jointure
ou je peux utiliser distinct (mais je vois pas comment)



Il y a peut-être à creuser avec ce module, qui fait de la transposition 
ligne/colonne :
http://www.postgresql.org/docs/9.0/static/tablefunc.html

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [Dev-fr] Détection des noeuds orphelins depuis le passage du bot

[Frédéric Rodrigo]

Le 23/07/2012 10:23, Ab_fab a écrit :

Et je n'arrive pas à trouver un moyen simple de les mettre en évidence,
car ils n'ont pas été modifiés par le bot.
L'analyse d'Osmose mise en place pour recenser les dommages du passage
du bot ne permet pas de les identifier.

Je pensais les retrouver en tant que noeuds orphelins, mais ce n'est pas
le cas non plus.
http://osmose.openstreetmap.fr/map/?zoom=15lat=48.80464lon=2.17521layers=BTFF00item=1080,7060level=1


Cette analyse ne liste les nœuds orphelins un par un, elle cherche des 
groupes importants de nœuds orphelins. Le but était surtout de détecter 
les imports ratés du cadastre.


Après il est possible de mettre un marqueur par nœud, mais ça va en 
faire drôlement beaucoup.


Une carte à la, feu, dup node serait plus intéressante à mon avis.


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Travailler sur des imports partiels

[Frédéric Rodrigo]

Le 5 juillet 2012 11:32, Philippe DAVID philippe.da...@allgoob.com a écrit :
 Donc sans les tables nominatim (placex, etc..) c'est ça ?
 Les tables nominatim ont l'air d'avoir une taille du même ordre de grandeur
 que l'import initial osm2pgsql, donc ça ferait bien 650GB grossièrement.

Pas tout à fait. L'import initial des données pour Nominatim est fait
avec le même outil osm2pgsql. Mais dans le cas de Nominatim c'est avec
l'option gazetteer, et ce n'est pas cela que l'on désigne sous le
nom de base osm2pgsql.

Une base osm2pgsql en mode gazetter est plus petite qu'une base dite
osm2pgsql. Mais je ne sais pas dire quel est le rapport entre les
deux.

Frédéric.

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Librairie Routing multi-modal

[Frédéric Rodrigo]

Le 25 mai 2012 12:56, Nicolas Dumoulin
nicolas_openstreetmap@dumoulin63.net a écrit :
 Je suis aussi en train de jouer avec OSRM depuis quelques jours.
 Je calcule toutes les distances (et temps) de comunes à communes (3 paires
 sans doublons) du Cantal en moins d'une minute sur mon portable.

Tu pense que pour des communes adjacentes il est possible de détecter
des problèmes de qualité dans les donnés pour le routage par détection
des trajets trop long ?

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Java et Osm développement

[Frédéric Rodrigo]

Bonjour,

Dans votre cas il va falloir une base de données. Mais attention elle 
peut vite prendre de la place si la zone à couvrir est étendu.
Les bâtiments dans OSM proviennent du cadastre et le découpage 
correspond  aux parcelles s'il n'a pas été corrigé avant l'import. Donc 
plusieurs bâtiments OSM pour un bâtiment dans la réalité.


Coté technique il va probablement falloir s'orienter vers une base 
sqlite. Il existe déjà plusieurs outil permettant de créer cette base : 
dont osm2sqlite, il y a aussi un patch pour osm2pgsql (à évaluer). Il y 
a sûrement d'autres outils. Mais sqlite avec OSM n'est pas la solution 
la plus rependu.


Ensuite vient le problème du fond de carte. Il y a deux solutions soit 
stocker des tiles en local, soit faire du rendu vectoriel. Un outil de 
rendu vectoriel peut également être une solution au problème des 
bâtiments s'ils sont dans la base vectorielle pour le rendu. Il y a 
plusieurs outils, mais cela risque de dépendre de l'OS cible : 
http://wiki.openstreetmap.org/wiki/Android voir en particulier 
MapsForges et MapDroyd.


Bon courage !

Frédéric.

Le 16/05/2012 19:45, jonathan coulon a écrit :

Bonjour,

Je suis entrain de développer une application immobilière s'appuyant sur
OpenStreetMap.
Auriez-vous des conseils à me donner pour l'implémentation d'une carte
OSM en java en offline.
Y-a-t-il possibilité de dessiner sur la carte osm en java (ex colorier
les bâtiments quand on clic dessus.).

Merci

COULON Jonathan
70 rue Emile Zola
59184 Sainghin en Weppes
Tél: 0603976045


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Re : Système d'information géographique

[Frédéric Rodrigo]

En survolant le sujet j'ai trouvé quelque pistes :

Du code réutilisable qui vient de JOSM :
http://wiki.openstreetmap.org/wiki/JMapViewer
Toute la catégorie java a fouiller :
http://wiki.openstreetmap.org/wiki/Category:Java
Une API par cloudmade :
http://developers.cloudmade.com/projects/show/java-lib

Frédéric.

Le 26/04/2012 20:08, JonathanMM a écrit :

On 26/04/2012 20:03, THEVENON Julien wrote:

* De :* Gilles Bassière gbassi...@gmail.com
* *Une autre piste est JOSM. C'est un éditeur pour OSM et la
fenêtre de
* *téléchargement utilise la carte tuilée pour se repérer. Là
aussi, il y a
* *peut-être du code à réutiliser.
* *http://josm.openstreetmap.de/

JOSM sait afficher la carte ?

JOSM sait afficher des tuiles bing, yahoo!, etc… sur un calque ;)

j avais dit a Yann que JOSM n etait pas adapte car il est plus dedie a
l utilisation de donnees mais je m apercois que c etait peut etre un
peu reducteur comme reponse...

Julien

JonathanMM


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Key:maxspeed:practical

[Frédéric Rodrigo]

Bonjour,

Le tag maxspeed:practical a déjà fait l'objet d'un vote et rencontré
une forte opposition. Ça me fait penser à la notion de cyclabilité qui
est elle aussi subjective et contextuelle.
C'est pourtant un info très pertinent si on veut faire du calcul
d'itinéraire de qualité.

http://taginfo.openstreetmap.org/keys/maxspeed%3Apractical#overview

Si ce tag correspond à un besoin effectif et qu'il y a des moyens réel
d'obtenir ces informations, il est possibilité des les mettre dans une
base voisine. Geofabrik à développé une solution à ce problème : le
SDS (separate data store)
http://lists.openstreetmap.org/pipermail/josm-dev/2012-March/006099.html

Je trouve toutefois dommage de séparer cette information de OSM. Tout
n'est pas déterminable (facilement) depuis la base OSM, comme
l'encombrement aux heures de pointes...

Frédéric.

Le 18 avril 2012 10:59, Mikaël Cordon mikael.cor...@gmail.com a écrit :
 un logiciel pourrait
 se baser sur d'avantages de critères objectifs comme le type de
 surface, l'inclinaison, les courbures de la route...

 +1

 Le 18 avril 2012 09:52, Pieren pier...@gmail.com a écrit :

 2012/4/18 Hendrik Oesterlin hendrikmail2...@yahoo.de:

  Des avis?
 

 C'est effectivement très subjectif. Par contre, un logiciel pourrait
 se baser sur d'avantages de critères objectifs comme le type de
 surface, l'inclinaison, les courbures de la route...
 Par ailleurs, cette question serait plus pertinente sur la liste
 principale, non ?

 Pieren

 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr




 --
 Mikaël Cordon

 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Utilisation des diffs pendant la phase de passage à ODBL

[Frédéric Rodrigo]

Le 11 avril 2012 10:49, Christian Quest cqu...@openstreetmap.fr a écrit :
 Ce genre d'analyse me semble pertinent pour osmose.

 On a beau corriger les erreurs à un moment donné, elles peuvent
 réapparaitre par suite d'une mauvaise manip d'un contributeur.
 Pour ce genre de données de référence, ça me semble utile de garantir
 au maximum leur qualité.

Tout à fait, c'est bien le but d'Osmose de coder des tests unitaires.

 Je pensais aussi à croiser avec les repères géodésiques qui
 contiennent le code INSEE de la commune où ils se trouvent. Ils
 doivent être à l'intérieur du polygone de la commune (quand celui-ci
 existe).

Comme tu l'avais déjà proposé, c'est déjà dans la todo liste d'Osmose.
Mais tu peux proposer une requête sql en deux étapes, une pour calcule
les limites de communes (dans un but de factorisation avec d'autres
analyses, mais je dois bien avoir déjà ça dans mes cartons) et l'autre
pour l'analyse elle même sur un schéma osmosis. Ou proposer un
analyseur externe sur un autre schéma.

 L'autre idée était de détecter les trous dans les limites de commune
 qui ne correspondent qu'à une seule commune et donc permette de créer
 la limite de cette commune. Là aussi, les repères géodésiques peuvent
 aider à leur détection si il y a unicité du code INSEE.

Le cas est assez rare pour ne pas nécessite un fort investissement et
il y a déjà un détecteur de trous dans osmose. On peut élargir la
taille des trous détectés si besoin.
http://osmose.openstreetmap.fr/map/?item=6060

Frédéric.

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Question noob postgis

[Frédéric Rodrigo]

On 22/02/2012 21:54, yvecai wrote:

J'ai pris la grande décision de me frotter un peu à postgis, mais j'ai
un peu de mal en sql, alors c'est l'occasion d'animer un peu cette liste.

Dans une base 'osm2pgsql', je recherche les relations qui partagent un
bout de chemin avec, disons la relation 1347356.
Je n'arrive pas à comprendre comment faire fonctionner les fonctions de
comparaison.

SELECT a.osm_id, b.osm_id
FROM planet_osm_line a, planet_osm_line b
WHERE ST_overlaps(a.way,select b.way where osm_id=-1347356);

ERREUR: erreur de syntaxe sur ou près de « select »
LIGNE 3 : WHERE ST_overlaps(a.way,select b.way where osm_id=-1347356);


Ton sql n'est pas bien structuré :

SELECT
a.osm_id,
b.osm_id
FROM
planet_osm_line AS a,
planet_osm_line AS b
WHERE
b.osm_id=-1347356 AND
ST_overlaps(a.way, b.way)
;


Ou en plus jolie :

SELECT
a.osm_id,
b.osm_id
FROM
planet_osm_line AS a
JOIN planet_osm_line AS b ON
ST_overlaps(a.way, b.way)
WHERE
b.osm_id=-1347356
;

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Import des numéros de rue (addr:housenumber) depuis le Cadastre

[Frédéric Rodrigo]

Bonjour,
J'ai également tenté de faire ça. Mais généralisé à tout le texte.
J'avais commencé par faire une approche par signature de forme sur les
composantes du chemin décrivant la forme (comme la tentative de 2010).
Mais pour les raisons précédemment évoquées c'est vite limité. Au
passage noter que qadastre fait une simplification qu'il faut
désactiver pour faire des analyses sur la forme d'origine.
J'étais donc parti sur une autre piste. Le détection des caractères
pas comparaison de critère : ratio de taille, de périmètre, nombre de
ligne droites significatives, détection d'angles, d'intérieurs... le
tout avec une détection et la correction de l'orientation du texte
pour diminuer les faux positif. Le résultat est bien indépendant de la
taille du pdf. Mais la qualité n'est toujours pas suffisante pour
donner un résultat exploitable même en augmentant la base statistique
de référence.

Je peux te donner les sources, c'est un qadastre modifié avec une
extension en ruby.

Fred

Le 3 novembre 2011 08:14, Ab_fab gamma@gmail.com a écrit :
 Il faudrait contacter en direct le principal intéressé, car il n'est plus
 actif sur la liste de diffusion.

 Le 3 novembre 2011 00:14, Tyndare tynd...@wanadoo.fr a écrit :

 Ca correspond exactement à ce que j’essayai de faire, il est
 accessible quelque part ce programme ?

 Le 2 novembre 2011 22:57, Ab_fab gamma@gmail.com a écrit :
  Bonsoir,
 
  Je ne serai pas d'une grande aide sur la question, mais j'ai ce fil de
  discussion de juillet 2010 à te proposer :
 
  http://lists.openstreetmap.org/pipermail/talk-fr/2010-July/thread.html#24030

 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr



 --
 ab_fab
 Il n'y a pas de pas perdus

 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Import des numéros de rue (addr:housenumber) depuis le Cadastre

[Frédéric Rodrigo]

Le 3 novembre 2011 12:22, Tyndare tynd...@wanadoo.fr a écrit :
 Je suis partis sur une approche plus simpliste qui doit être similaire
 à ta première tentative. Je me contente des données récupérée par
 qadastre: un Path composé d'une liste de commandes (moveto, lineto,
 curveto) et une liste de coordonnées associées.
 J'ai pris comme à priori que les numéros de rue seraient toujours
 écris avec la même police et devrais donc être composés exactement des
 même commandes dans le même ordre.

C'est un mauvais à priori. Le détail du chemin va dépendre de la
taille des caractères. Le point de départ du chemin n'est pas toujours
le même.

Il faut vraiment travailler avec plusieurs communes, c'est là que se
révèlent les problèmes.

 Ensuite pour comparer la liste des
 coordonnées associées aux commandes, j'applique une transformation
 (déplacement et rotation) pour ramener la première de la liste à (0,0)
 et la troisième  à l'horizontale (en choisissant la deuxième ça ne
 marchait pas pour le chiffre 3) et je met le tout à échelle pour que
 ça rentre dans un carré d'1 de large.
 Ca a l'air très fiable si les coordonnées sont assez précises, et je
 pense que c'est généralisable au texte (chaque mot génère un Path mais
 il faut ensuite les assembler).

 Je n'ai pas regardé la simplification faite par qadastre, c'est où le
 bouton pou la désactiver ?

C'est dans le code

 Pour les problèmes de tailles, je commence à me dire qu'il n'y a pas
 d'autre solution que de repartir sur un découpage des requêtes au
 cadastre en plusieurs pdf comme le fait le script import-bati.sh

 Le programme de Benoît ROUSSEAU avait l'air très avancé. J’essaierais
 de le contacter directement si il ne se manifeste pas.

 Ludo.


 Le 3 novembre 2011 09:49, Frédéric Rodrigo fred.rodr...@gmail.com a écrit :
 Bonjour,
 J'ai également tenté de faire ça. Mais généralisé à tout le texte.
 J'avais commencé par faire une approche par signature de forme sur les
 composantes du chemin décrivant la forme (comme la tentative de 2010).
 Mais pour les raisons précédemment évoquées c'est vite limité. Au
 passage noter que qadastre fait une simplification qu'il faut
 désactiver pour faire des analyses sur la forme d'origine.
 J'étais donc parti sur une autre piste. Le détection des caractères
 pas comparaison de critère : ratio de taille, de périmètre, nombre de
 ligne droites significatives, détection d'angles, d'intérieurs... le
 tout avec une détection et la correction de l'orientation du texte
 pour diminuer les faux positif. Le résultat est bien indépendant de la
 taille du pdf. Mais la qualité n'est toujours pas suffisante pour
 donner un résultat exploitable même en augmentant la base statistique
 de référence.

 Je peux te donner les sources, c'est un qadastre modifié avec une
 extension en ruby.

 Fred

 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Idées d'analyses pour Osmose...

[Frédéric Rodrigo]

Le 25 octobre 2011 02:14, Christian Quest christian.qu...@gmail.com a écrit :
 Voici quelques idées en vrac d'analyses pour osmose:

 Tags implicites:
 - area=no - rare, mais implicite, non ?
 - area=yes sur des surfaces implicites (exemple: amenity=parking)

Je suis d'accord, c'est enfoncer des portes ouvertes. Mais il y a déjà
beaucoup de vrais erreurs à corriger. C'est vraiment du peaufinage.

 Tags sur mauvais type d'objet:
 - highway=crossing sur un chemin et pas un node
 - waterway=canal, stream ou river sur chemin fermé

Intéressant, il doit y avoir bien d'autres cas.

 Analyse des noms:
 - name=route ou name=fixme ou name=inconnu, etc...

Ce type d'analyse peut aller dans TagWatchCleaner voir :
http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#3030

 Incohérence de tags:
 - natural=water + leisure=swimmin_pool - retirer le natural=water
 - amenity=school + name contient maternelle - amenity=kindergarten
 - amenity=kindergarten + name contient élémentaire ou primaire -
 amenity = school
 - amenity=swimming_pool ou leisure=swimming_pool sur un chemin fermé
 de grande surface (à définir/tester)
 - amenity=place_of_worship + name contient église ou synagogue ou
 mosquée mais religion non renseigné - proposer religion =

Pertinence à vérifier avec des requêtes sur une base.

 Erreurs de clé de tag / clé rare:
 - exemple: hiway et autres erreurs au lieu de highway, peut se baser
 sur des stats issues de taginfo

Intéressant, détection de tags non courant avec valeur courante (pour
d'autres tags)

 J'en ai d'autres, plus complexes sur les relations pour les adresses.

Dis toujours. Moi aussi j'en ai sur les adresses : bâtiment sans adresse ;)

Fred

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Plugin Osmose pour Josm

[Frédéric Rodrigo]

Nouvelle version de disponible. Cette fois avec une amélioration. Un 
bouton de plus pour télécharger les objets sur les quels portent l'anomalie.


http://f.rodrigo.free.fr/tmp/josm/

Fred

Le 13/10/2011 19:36, Didier Marchand a écrit :

j'ai retrouvé mon joujou !

non sans rire, dans les zones ou il y énormement d'erreur a corriger,
c'est bien mieux que le port a distance (josmzone)

merci
didier


Le jeudi 13 octobre 2011 à 18:11 +0200, Frédéric Rodrigo a écrit :

Bonjour,
J'ai effectué une syncro du plugin osmose avec JOSM/plugin OSB. Aucune
évolution sur le plugin lui même.
Comme la dernière fois il est disponible là :
http://f.rodrigo.free.fr/tmp/josm/

Fred

Le 12/09/2011 23:30, didier2...@free.fr a écrit :

bonsoir,

le plugin osmose n'est plus compatible avec la version 4399 de JOSM.
je reste sur JOSM (ver 4279) car ce plugin est vraiment tres pratique

une evolution est-elle a l'ordre du jour ?

didier


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr




___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Osmose: suggestion de nouvelle analyse sur area=yes

[Frédéric Rodrigo]

Le 11/10/2011 17:55, Christian Quest a écrit :

Le 11 octobre 2011 17:49, Frédéric Rodrigo fred.rodr...@gmail.com
mailto:fred.rodr...@gmail.com a écrit :

Bonjour,
Pour l'instant les problèmes remontés par Osmose ne le sont pas déjà
par d'autres outils, en particulier par Keep-right et OSMI.
Peut-être peut-on appliquer le validator de JOSM sur toute la France
et remonter le résultat dans osmose... il faut voir comment c'est fait.

Fred


Peut être pas tout le validator, mais certains de ses tests sont
vraiment pertinents.
Certains contributeurs n'utilisant pas JOSM ne savent pas que leur
modifs comportent des erreur (voire aussi pour certains utilisant JOSM,
mais c'est une autre histoire).


J'ai regardé comment sont fait les tests du Validator de JOSM et ce 
n'est pas utilisable pour de grandes quantités de données. Si on veut 
voir certains tests dans osmose il faut les recoder.


Je mets sont area=yes mais le chemin n'est pas fermé dans la todo list 
d'Osmose.


Fred

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Plugin Osmose pour Josm

[Frédéric Rodrigo]

Bonjour,
J'ai effectué une syncro du plugin osmose avec JOSM/plugin OSB. Aucune 
évolution sur le plugin lui même.

Comme la dernière fois il est disponible là :
http://f.rodrigo.free.fr/tmp/josm/

Fred

Le 12/09/2011 23:30, didier2...@free.fr a écrit :

bonsoir,

le plugin osmose n'est plus compatible avec la version 4399 de JOSM.
je reste sur JOSM (ver 4279) car ce plugin est vraiment tres pratique

une evolution est-elle a l'ordre du jour ?

didier


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Osmose: suggestion de nouvelle analyse sur area=yes

[Frédéric Rodrigo]

Bonjour,
Pour l'instant les problèmes remontés par Osmose ne le sont pas déjà par
d'autres outils, en particulier par Keep-right et OSMI. Peut-être peut-on
appliquer le validator de JOSM sur toute la France et remonter le résultat
dans osmose... il faut voir comment c'est fait.

Fred
 Le 11 oct. 2011 11:56, Christian Quest christian.qu...@gmail.com a
écrit :

 Le cas est simple:

 area=yes mais le chemin n'est pas fermé. C'est une erreur signalée par
 validator.

 --
 Christian


 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Détection de mailles de réseau ouvertes

[Frédéric Rodrigo]

J'ai écrit une requête sur un principe légèrement différent. Il ne 
cherche les culs de sac d'écart de niveau d'highway mais que sur les 
intersections.


CASE tags-'highway'
WHEN 'motorway' THEN 0
WHEN 'motorway_link' THEN 0
WHEN 'primary' THEN 1
WHEN 'primary_link' THEN 1
WHEN 'trunk' THEN 1
WHEN 'trunk_link' THEN 1
WHEN 'secondary' THEN 2
WHEN 'tertiary' THEN 3
WHEN 'unclassified' THEN 4
WHEN 'residential' THEN 4
ELSE 5
END AS level

Le principe est par exemple de trouver des primary (level:1) connectées 
directement et uniquement sur des level=3.


J'ai par contre un doute sur le level des trunks.

Voila un exemple d'erreur, il y a une unclassified pour relier deux 
secondary :

http://www.openstreetmap.org/browse/node/820904393

Fred

Le 16/03/2011 21:16, Vincent de Chateau-Thierry a écrit :

Le 16/03/2011 15:08, Frédéric Rodrigo a écrit :
 
  Effectivement les way sont brutalement coupé aux limites de région.
  Suivant les test ça crée de faux positifs. Il faut peut être trouver
  une solution à ça.
 

L'idéal serait d'avoir tous les objets connectés à ceux s'arrêtant à la
frontière, et tous ceux connectés à ceux qui la chevauchent. On pourrait
alors produire des analyses en restant dans l'emprise de la région, en
tolérant les ways chevauchant la limite, mais avec au moins la garantie
que tous les objets considérés sont complets.

Le 16/03/2011 18:56, Eric Marsden a écrit :


Un test similaire est implanté dans OsmInspector (vue routing), qui
identifie les discontinuités par le fait que deux noeuds appartenant à
des highway sont proches mais distincts. Très utile pour détecter et
corriger les bugs non visibles dans les rendus cartographiques mais
qui affectent le routage.

http://tools.geofabrik.de/osmi/



Oui, on reste sur la même thématique. La vue de Geofabrik permet
d'identifier des nodes à déplacer pour boucher les fuites de réseau.
Le filtre que je propose, même s'il détecte aussi les ways
géométriquement non connexes, vise plutôt à modifier les tags que la
géométrie, en reclassant des highways. Ça se complète.

vincent
  275007763
  288121371
  288125619
  290215802
  313889099
  339587652
  341873998
  389440584
  393445285
  393445295
  393445296
  415315237
  415315238
  415315270
  456262626
  461591701
  465201330
  470274638
  472456500
  485639083
  501581092
  501581135
  512506812
  535373322
  541408583
  541408594
  548395984
  559576000
  563270068
  567920816
  567920874
  568116425
  599021844
  599021857
  599133449
  599863628
  674039235
  682527371
  755810608
  755810612
  755810628
  773250635
  774473535
  796990658
  796990676
  796990787
  796990884
  796991027
  796991103
  807108406
  820904393
  823170683
  830372058
  832093389
  843099532
  848164936
  848164944
  848165034
  873908687
  880806366
  880806369
  881455476
  884729941
  885860071
  885860087
  885860115
  885860118
  892700540
  892701523
  900698333
  900698340
  916453538
  921929672
  930314554
  961432388
  981589125
  981644862
 1008125641
 1043924229
 1044724951
 1044725038
 1045612955
 1051094727
 1051660970
 1067816919
 1139668295
 1139722430
 1276843344
 1304783031
 1309066673
 1314232033
 1358272433
 1362213898
 1366573764
 1366645022
 1367771363
 1368766593
 1389360437
 1389360449
 1392894254
DROP VIEW highway_level CASCADE;
CREATE VIEW highway_level AS
SELECT
id,
nodes,
tags?'junction' AS junction,
CASE tags-'highway'
WHEN 'motorway' THEN 0
WHEN 'motorway_link' THEN 0
WHEN 'primary' THEN 1
WHEN 'primary_link' THEN 1
WHEN 'trunk' THEN 1
WHEN 'trunk_link' THEN 1
WHEN 'secondary' THEN 2
WHEN 'tertiary' THEN 3
WHEN 'unclassified' THEN 4
WHEN 'residential' THEN 4
ELSE 5
END AS level
FROM
ways
WHERE
tags?'highway'
;

DROP VIEW way_ends CASCADE;
CREATE VIEW way_ends AS
(
SELECT
id,
nodes[1] AS nid,
level
FROM
highway_level
WHERE
NOT junction
)
UNION
(
SELECT
id,
nodes[array_length(nodes,1)] AS nid,
level
FROM
highway_level
WHERE
NOT junction
)
;

DROP VIEW h CASCADE;
CREATE VIEW h AS
SELECT
way_ends.nid,
way_ends.level AS nlevel,
highway_level.level
FROM
way_ends
JOIN way_nodes ON
way_ends.nid = way_nodes.node_id
JOIN highway_level ON
way_ends.id != highway_level.id AND
way_nodes.way_id = highway_level.id
GROUP BY
way_ends.nid,
way_ends.level,
highway_level.level
;


SELECT
nothaving.nid
FROM
h AS nothaving
LEFT JOIN h AS having_ ON
having_.level = nothaving.nlevel+1 AND
having_.nid = nothaving.nid
WHERE
having_.nid IS NULL
GROUP BY
nothaving.nid
;

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] France cassée

[Frédéric Rodrigo]

Bonjour,

Modifier unilatéralement une telle relation dans le but de rentre ton
outil opérationnel, n'est très fairplay.
D'autant plus que, je n'ai pas vérifié en profondeur, mais il me
semble que maintenant la relation France soit cassé !
Les deux way (6844581 et 30837814) de la frontière entre Monaco et
l'Italie ne sont plus référencées.

Fred

Le 5 septembre 2011 09:12, Aurélien FILEZ kinj...@gmail.com a écrit :
 Oui mais je pense avoir réglé le problème ;)
 Mais en effet ça serait bien que quelqu'un confirme

 2011/9/4 yvecai yve...@gmail.com

 A priori avec l'éditeur de relation.
 Seulement, j'attendrais un peu d'avoir des retours sur la mailing-list,
 c'est anormalement calme ce week-end, rentrée oblige?
 Reste qu'il y a des pros de la relation 'France' par ici qui auront de bon
 conseils d'ici quelques jours au plus, je pense.
 As-tu jeté un oeil ici ?
 http://wiki.openstreetmap.org/wiki/France_boundary_pyramidal_construction
 Yves

 On 03. 09. 11 18:21, Aurélien FILEZ wrote:

 En téléchargeant les données avec JOSM, on remarque bien qu'il y a un
 segment dans la relation 82629 qui n'est pas collé au reste (ci joint une
 capture).
 Comment faire pour retirer ces deux ways de cette relation sans pour
 autant les supprimer ?

 2011/9/3 Aurélien FILEZ kinj...@gmail.com

 Bon j'ai investigué un peu, et il s'avère que la France n'est pas cassée.

 En revanche, il y a des ways qui sont de trop.

 En effet, la France Métropolitaire (1362232) définit dans ses relations
 les :
   France - Italie (89489)
   France (Côte Méditerranéenne) (82629)
   France - Monaco (90352)

 Concernant la côté Côte Méditerranéenne, ça entre via la way 25097915 qui
 fait le pont avec la frontière France-Italie et semble ressortir par la
 way 37811860 qui fait le pont avec France-Monaco. Le reste des ways de la
 Côté Méditerranéenne (82629) ne devrait être que des ways (uniques ou
 composées) formant des polygones fermés, pour établir des îles plus ou moins
 grandes
 Or on y retrouve des ways ouvertes, à commencer par
 la séquence 27654540 - 30837814 qui se lient entre elles mais n'aboutissent
 à rien dans le cadre de la France Métropolitaine (ni en entrée de l'une, ni
 en sortie de l'autre).
 Ne devrait-on pas les retirer de la relation 82629 puisque visiblement
 elles n'apportent rien sinon de la confusion dans la boucle générale ?
 Kin
 2011/9/3 Aurélien FILEZ kinj...@gmail.com

 Salut à tout le monde,
 Etant développeur C++ et perdu dans les différents scripts existants pour
 gérer les super-relations dont j'ai besoin, je me suis fait un petit
 programme à l'arrach' pour retrouver le polygone de notre cher pays.

 La relation 1362322 commence dans le nord avec la frontière franco-belge
 puis ça descend. Arrive la frontière avec l'Italie, jusqu'ici tout se passe
 bien, puis vient la côté méditerranéenne où le chemin commence à être plutôt
 délicat.
 La relation 82629 - France (Côte Méditerranéenne) commence par deux îles
 (deux ways fermées) puis entame le contour par la way 25097915. En suivant
 le tracé, tout va bien jusque la way 37811860 qui elle ne semble aboutir à
 rien au sein de la relation 82629.
 En effet, le premier noeud de cette way 37811860 est le noeud 245981466,
 qui prolonge la continuité de la relation via la way 42463891. En revanche
 le noeud d'arrivé (60233828) est partagé avec les ways 30837497, 37811854 et
 24874398 et aucune de ces 3 dernières ways ne participe à la relation 82629.
 Bref, pour la côte méditerranéenne, on part de la way 25097915 et arrivé à
 la way 37811860, c'est voie sans issue.
 Si je ne me suis pas trompé et que c'est bien une cassure, une fois réglé,
 moi et mon petit code C++ continueront à parcourir les bords du territoire
 en remontant ce même genre de problème ;)
 A bientôt,
 Kin


 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr


 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr



 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr



___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Connaitre les informations de lieu à partir d'un point

[Frédéric Rodrigo]

Bonjour,
Tu peux utiliser un moteur de reverse geocoding. Nominatim le fait
(données OSM) :
http://wiki.openstreetmap.org/wiki/Nominatim

My 2cents
Fred

Le 17 août 2011 09:53, damien dawa...@gmail.com a écrit :
 Bonjour
 J'ai besoin de connaitre les informations de lieu (pays / région /
 ville / (voir) rue) à partir d'un point géographique en coordonnées.
 Comment faire (pour une application java) ?
 Merci
 Damien

 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/dev-fr


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] trouver des way en doublon que j'ai crée par erreur.

[Frédéric Rodrigo]

Le 16/08/2011 22:39, Vincent de Chateau-Thierry a écrit :

Bonsoir,

Le 16/08/2011 22:07, julien balas a écrit :


Mais la je bloque un peut sur la marche a suivre.
Avec mes petites moulinette maison je n'arrive a rien.

Est ce que la methode suivante vous semble pertinente ?
- prendre le dump FR
- filtrer pour ne garder que les way ayant une REF (osmosis?)
- charger ca dans une base (osmosis aussi?)
- faire une requete postgis magique qui me donne la liste des ID a
verifier/corriger

ou alors je part des changeset(il y en avait un par region)
et par un moyen que je connais pas, je verifie chaque way.



Je commencerais par charger les données en base PostGIS, dans un schéma
Osmosis, et (en option) à opérer un filtre (osmosis aussi) pour ne
garder que les ways avec un tag highway et un tag ref. L'intérêt ici
d'Osmosis, c'est que le schéma te donne la liste ordonnée des nodes qui
forment un way.

Ensuite, une requête doit te permettre de compter, par exemple, les ways
avec une combinaison de critères tels que :
- même tag ref
- même tag highway
- même nombre de points
- même id de 1er point
- même id de dernier point
- ET même id de deuxième point (histoire d'éliminer, s'il y en a, des
configurations en boucle, connectés par les 2 extrémités).


Column|Type | Modifiers
--+-+---
 id   | bigint  | not null
 version  | integer | not null
 user_id  | integer | not null
 tstamp   | timestamp without time zone | not null
 changeset_id | bigint  | not null
 tags | hstore  |
 nodes| bigint[]|
(
 bbox | geometry|
 linestring   | geometry|
)

On peut comparer tout le tableau de points d'un seul coup. Mais la 
question est surtout de savoir si les nœuds sont aussi dupliqués ou pas.


___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Plugin Osmose pour Josm

[Frédéric Rodrigo]

Salut,
Suite à des divagations sur irc je vous annonce la naissance d'un plugin 
Osmose pour Josm. Il est issu d'un fork des sources du plugin 
OpenStreetBug. Jocelyn à mis en place une api similaire à celle 
d'OpenStreetBug coté serveur Osmose.


Tout est là, sources et jar prêt à être utilisé :
http://f.rodrigo.free.fr/tmp/josm

Pour l'installation :
http://wiki.openstreetmap.org/wiki/JOSM/Plugins#Manually

Fred

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Osmose et last-update.py

[Frédéric Rodrigo]

Le 13/07/2011 21:09, Thomas Petillon a écrit :

Ce patch s'applique à Name_Toponymie.py et permet de régler le problème
des (nombreux) noms de lieu bretons contenant « c'h », dont l'apostrophe
est détectée comme une coupure de mot, ce qui déclenche une erreur de
toponymie due à la majuscule supposément manquante au « h ». En gros il
y a plein de faux positifs.


Je viens de regarder. Je me pause par contre des questions. La page 
wikipédia sur le sujet n'est pas assez claire et contradictoire.


http://fr.wikipedia.org/wiki/C%27h

- Quel est la majuscule de c'h : C'h ou C'H' ?
- Quel est bon caractère à mettre au milieu ' ou ’ ?

Pour le patch on peut faire plus simple en remplaçant tout le trigramme 
par un caractère utf8 temporaire  tout en s'assurant qu'il n'est pas 
déjà présent dans la chaîne d'origine.


Fred

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Rendu de l'extraction du filaire cadastral

[Frédéric Rodrigo]

Le 31/03/2011 20:20, Bruno Cortial a écrit :

[transfert sur dev-fr]

Bonjour,
Moi ausi je verrai bien du road matching et pour ce faire je
souhaiterai tester sur les gpx issu de r-c2w la procédure d'import
différentiel de réseau routier qui a été utilisée pour
Brest-Métropole-Océane [1] pour voir ce que cela donnerai.

Mais mon vieux PC n'a pas été fichu de générer un gpx du filaire en un
temps raisonnable (sans doute pas assez de ram, 1.5 Gio)
Donc si une bonne âme veut bien me transmettre quelques fichiers de
communes de Loire-Atlantique...

[1] http://wiki.openstreetmap.org/wiki/BMO#Differential_import


Pas de problème, je t'envoie ça en privé.

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr