Re: [OSM-dev-fr] Partage de DEM ( était Héberger le rendu HOT?)

[Sylvain Maillard]

Dans les MNT impressionants de détails (mais il faut se méfier, on a eu des
surprises en camargue), il y a le MNT du plan rhône élaboré sur fond
publiques (http://www.planrhone.fr/front/333-252-0-BDT-Rhone) ... par
contre il n'y a pas de licence réellement claire à ce sujet !
la liste des ayants droits est clairement définie (données gratuites, mais
service de copie sur support payant), par contr eil n'est pas vraiment fait
mention de possibilités d'utilisations autres.  Etant donné que c'est un
produit gré par l'IGN, ne pas hésiter à activer les contacts pour en savoir
plus !

Sylvain



Le 28 juin 2013 20:51, Jean-Claude Repetto  a écrit :

> On 28/06/2013 19:43, sly (sylvain letuffe) wrote:
>
>>
>> Tu dis ça car tu sais qu'un tel jeu de donnée est déjà accessible ?
>> y'aurait
>> un échantillon dispo quelque part pour déjà tenter de juger de son intérêt
>> qualitatif ?
>>
>>
>>
> Tu peux en télécharger un échantillon sur le site de la métropole de Nice
> Côte d'Azur :
> http://www2.nice.fr/open_data/**data/MNT_NCA_5m_2009_ASC.zip
>
> Jean-Claude
>
>
> __**_
> 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] Partage de DEM ( était Héberger le rendu HOT?)

[Jean-Claude Repetto]

On 28/06/2013 19:43, sly (sylvain letuffe) wrote:


Tu dis ça car tu sais qu'un tel jeu de donnée est déjà accessible ? y'aurait
un échantillon dispo quelque part pour déjà tenter de juger de son intérêt
qualitatif ?




Tu peux en télécharger un échantillon sur le site de la métropole de 
Nice Côte d'Azur :

http://www2.nice.fr/open_data/data/MNT_NCA_5m_2009_ASC.zip

Jean-Claude


___
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.

[Philippe Verdy]

En quoi ton ID est meilleur ou constitue une référence stable ? Alors que
tu en es le seul auteur (même si tu utilises un algorithme, il va générer
un ID dans une base qui n'est pas réputée stable, ni utilisable à aussi
grande échelle que les IDs des instituts nationaux officiels (qui ont
démontré les employer et les maintenir depuis des années).

Le seul vrai problème des ID officiels est qu'ils omettent souvent de
mentionner leur année de référence. Mais quand ils l'indiquent, on omet
encore de mentionner cette date.

Et c'est là qu'il suffirait de compléter ces IDs avec la date (au moins
l'année) où on les a obtenus pour savoir s'ils correspondent encore à
quelquechose, et vers quel(s) autre(s) objets avec d'autres IDs ils ont
évolués  (pour peu que la source maintienne des infos sur les
transformations survenues, et qu'on puisse consulter ces historiques pour
trouver  des correspondances (de 1 vers 1 l'ID est conservé, mais de N vers
1, ou de 1 vers N, ou de N vers M c'est plus compliqué, mais on a tout de
même réduit l'espace de recherche pour se resynchroniser entre deux dates
de référence : l'indication de l'année permet de savoir où des ambiguités
sont apparues, et facilitera tout de même les rapprochements en réduisant
le nombre de vérifications à faire sur le terrain).

C'est là que:
- "ref=" peut devenir "ref:2000=", ou bien "ref=:2000" (plus
ambigu à interpréter selon les formats d' des sources) indiquées.
- "ref:=" devient aussi "ref::2000=", ou
"ref:=:2000" (même remarque)

La stabilité est ici apportée par l'année indiquée (si elle suffit à
déterminer une version). C'est ce qui permet de suivre les évolutions. Peu
importe l'année indiquée d'ailleurs tant qu'elle tombe dans la tranche de
date où l'identifiant à été constaté comme valide, mais si on veut
contrôler plus tard, on peut toujours vouloir mettre à jour cette date en
indiquant la date de dernière vérification.

Certaines bases de référence sont versionnées non pas par année mais par
numéro de version majeure (un changement de version majeure peut entraîner
parfois un changement de format de l'identifiant):
- "ref=" peut devenir "ref:v:=", ou bien
"ref=:" (plus ambigu à interpréter selon les formats d'
des sources) indiquées.
- "ref:=" devient aussi "ref::v:=", ou
"ref:=:" (même remarque)

(La remarque s'applique aussi aux tags similaires mentionnant des
identifiants, par exemple les codes ISO 3166 qui ont actuellement des tags
non préfixés par "ref:")



Le 28 juin 2013 16:49, Ista Pouss  a écrit :

> Le 28 juin 2013 16:18, Philippe Verdy  a écrit :
>
>> Je suis aussi d'avis que ces IDs générés en interne par une base privée
>> sont du même type que ceux généras par un des nombreux services de type
>> TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
>> ni même librement utilisables (et sans suivi de leur utilisation par un
>> tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
>> données modifiées de son choix dans le trafic).
>>
>>
> Oui, bien sûr, ok, mais le mien ?? Moi c'est vachement mieux :-)
>
>
>
>> Si des IDs stables doivent exister pour référencer des objets OSM, ils
>> doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
>> des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
>> identifiants INSEE par exemple, librement vérifiables).
>>
>>
> Je n'empêche personne de procéder ainsi.
>
> Il me semble, toutefois, que la création de tels identifiants, nécéssite
> de poser le même genre de questions que celles que j'essaie de proposer :
> qu'est-ce qui caractérise un objet ? Qu'est ce qui permet de le reconnaître
> ? Qu'est ce qui définit leur égalité ? Comment les hasher ?
>
> Mais enfin, on verra.
>
>
> La "stabilité" des IDs est très relative : elle n'est garantie que si ils
>> sont datés avec leur date de validité, les objets référencés pouvant à tout
>> moment changer de statut. Si un ID stable devait être utilisé, il devrait
>> au minimum inclure l'année de leur création
>> - soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
>> ref:INSEE=35238),
>> - soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
>> d'avoir une autre clé pour d'autres années après un changement de l'objet
>> référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
>> autre voisine).
>> Ensuite à charge pour les outils de recherche et de mise en relation avec
>> d'autres bases de faire les correspondances avec ces IDs stables, en tenant
>> compte de l'année s'il y a des IDs différents pour la même base de
>> référence (ici celle de l'lNSEE).
>>
>>
> Oui, enfin bon, OK. La stabilité comme tu dis des ID est effectvement un
> problème, puisque l'objet peut se modifier de toutes formes.
>
> Mais, à l'inverse, on peut dire que les risques de modifications
> permanentes rendent plus intéressantes encore l'existence d'un ID :-)
>
>
>
>>
>> Les IDs externes ne sont utiles que si la base externe est bien la source
>> de référe

Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)

[Christian Quest]

Le 28 juin 2013 19:43, sly (sylvain letuffe)  a écrit :
> On vendredi 28 juin 2013, Christian Quest wrote:
>> Vous pensez que ça vaudrait le coup de récupérer des DEM locaux ?
>
> Je dirais délicat de répondre :
> En terme de résultat final que l'on peut attendre pour l'utilisateur, ça me
> semble évident que ça serait génial. Même si ça fait un patchwork de zones
> très bien représentées et d'autres plus grossières, je pense que ça serait un
> réél plus.
>
> Mais je vois poindre un travail de titan qui consiste à uniformiser les
> formats, faire les demandes, fusionner tout çà en un tout utilisable, casse
> tête des licences, etc.
> Je dirais dur d'estimer le travail nécessaire, même si ça pourrait sans doute
> faire des heureux bien au delà d'osm !
>
>> On doit pouvoir récupérer celui de PACA et de l'Auvergne pour
>> commencer... deux coins où il y a du relief.
>
> Tu dis ça car tu sais qu'un tel jeu de donnée est déjà accessible ? y'aurait
> un échantillon dispo quelque part pour déjà tenter de juger de son intérêt
> qualitatif ?
>

Oui, accessible, et de qualité.
Si y'a encore de la place sur le disque que j'ai passé au CRIGE PACA
pour les orthos, je demande à Romain de l'ajouter...


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)

[sly (sylvain letuffe)]

On vendredi 28 juin 2013, Christian Quest wrote:
> Vous pensez que ça vaudrait le coup de récupérer des DEM locaux ?

Je dirais délicat de répondre :
En terme de résultat final que l'on peut attendre pour l'utilisateur, ça me 
semble évident que ça serait génial. Même si ça fait un patchwork de zones 
très bien représentées et d'autres plus grossières, je pense que ça serait un 
réél plus.

Mais je vois poindre un travail de titan qui consiste à uniformiser les 
formats, faire les demandes, fusionner tout çà en un tout utilisable, casse 
tête des licences, etc.
Je dirais dur d'estimer le travail nécessaire, même si ça pourrait sans doute 
faire des heureux bien au delà d'osm !

> On doit pouvoir récupérer celui de PACA et de l'Auvergne pour
> commencer... deux coins où il y a du relief.

Tu dis ça car tu sais qu'un tel jeu de donnée est déjà accessible ? y'aurait 
un échantillon dispo quelque part pour déjà tenter de juger de son intérêt 
qualitatif ?


-- 
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

Re: [OSM-dev-fr] Paratage de DEM ( était Héberger le rendu HOT?)

[Christian Quest]

Vous pensez que ça vaudrait le coup de récupérer des DEM locaux ?

On doit pouvoir récupérer celui de PACA et de l'Auvergne pour
commencer... deux coins où il y a du relief.

___
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.

[Ista Pouss]

Le 28 juin 2013 17:56, Pieren  a écrit :

> Pourquoi ajouter des relations pour compenser les déficiences
> logicielles ? Il est assez facile de reconstituer automatiquement
> l'ensemble d'une rue par son nom et la proximité des différents
> segments. Il faut juste écrire un peu de code.
>
>
Heu... il n'est pas clair que ce soit une déficience logicielle... et il
n'est pas clair qu'il soit si facile de reconstituer une rue par analyse de
proximité.

Enfin bon là c'est un autre sujet. Il me permet surtout de dire que, si la
règle de cohérence est "reconstituer les morceaux par proximité", alors le
système que j'ambitionne de réaliser vérifiera que cette règle est
cohérente, qu'elle est bien appliquée et, si oui, formera des
identificateurs de rues :-)

Cordialement.
___
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.

[Pieren]

2013/6/28 Ista Pouss :

> Oui peut être. Mais, en l'état, on me dit que les données osm sont justes,
> et que c'est le moteur de recherche qui se trompe, car il ne sait pas qu'on
> peut découper une rue en plusieurs morceaux, et que il devrait les
> rassembler.

Ne t'inquiètes pas, ils le savent parfaitement ;-) Mais, tant que tu
ne donnes pas de numéro dans la rue, peu importe la section qui sera
retournée.

> Moi j'ai plutôt tendance à penser que c'est les données osm qui devraient
> rassembler les morceaux, par exemple avec des relations, mais, sur ce plan
> là en tous cas, je ne m'avancerai pas. Moi j'essaie de comprendre ce qui
> forme logique et cohérence sur OSM.

Pourquoi ajouter des relations pour compenser les déficiences
logicielles ? Il est assez facile de reconstituer automatiquement
l'ensemble d'une rue par son nom et la proximité des différents
segments. Il faut juste écrire un peu de code.

Pieren

___
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.

[Ista Pouss]

Le 28 juin 2013 17:24, Sylvain Maillard  a
écrit :

>
> c'est pas pour ça justement qu'on a inventé le concept de "relation" ? =>
> on peut faire un seul grand objet "virtuel" composé de plusieurs segments
> "réels" ... donc chaque morceau de la rue peut avoir des attributs
> différents, mais on peut quand même avoir le traçé le la rue entière !
>


Oui peut être. Mais, en l'état, on me dit que les données osm sont justes,
et que c'est le moteur de recherche qui se trompe, car il ne sait pas qu'on
peut découper une rue en plusieurs morceaux, et que il devrait les
rassembler.

Moi j'ai plutôt tendance à penser que c'est les données osm qui devraient
rassembler les morceaux, par exemple avec des relations, mais, sur ce plan
là en tous cas, je ne m'avancerai pas. Moi j'essaie de comprendre ce qui
forme logique et cohérence sur OSM.

Pour ce cas précis des rues, une relation ou un way avec un higway et un
nom sont susceptibles de déterminer une rue, c'est tout ce qui m'intéresse
pour l'instant. Evidemment c'est insuffisant, évidemment ça peut changer ;
c'est ce qui m'intéresse aussi.

Cordialement.


-- 
Les dérives de rue :
Le projet de théâtre de Saint-Étienne emporté par le
vent

___
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.

[Sylvain Maillard]

Le 28 juin 2013 17:15, Ista Pouss  a écrit :

>
> Mouais... et il faudrait, peut être aussi, que les "contributeurs avec un
> point de vue technique" se mettent un jour à réfléchir à ce qu'est une rue
> ???
>
> Car une rue est bien autre chose qu'une série de segments chacun bornés
> par un panneau de circulation !
>

c'est pas pour ça justement qu'on a inventé le concept de "relation" ? =>
on peut faire un seul grand objet "virtuel" composé de plusieurs segments
"réels" ... donc chaque morceau de la rue peut avoir des attributs
différents, mais on peut quand même avoir le traçé le la rue entière !

Sylvain
___
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.

[Ista Pouss]

Le 28 juin 2013 17:04, Julien Balas  a écrit :

>
> Tout a fait, le moteur de recherche est perfectible.
>
> L'idée (pas encore mis en oeuvre je trouve) c'est que le site OSM est le
> site des gens qui contribue a OSM. Donc avec une vision un peut technique.
> Et que les utilisateurs finaux vont (ou iront un jour) sur des sites grand
> public qui utilise OSM mais avec une autre interface
>
> mapquest (qui est un site grand public qui utilise les données OSM)
> donne UN point de la rue, ca résoud (ou pas) le probleme de l'utilisateur.
> http://mapq.st/112eqTU
>
>
Mouais... et il faudrait, peut être aussi, que les "contributeurs avec un
point de vue technique" se mettent un jour à réfléchir à ce qu'est une rue
???

Car une rue est bien autre chose qu'une série de segments chacun bornés par
un panneau de circulation !

Enfin bon, ce que j'en dit...

Donc, en tous les cas, mon logiciel a permis de relever que le moteur de
recherche du point de vue technique ne renvoyait fort justement - puisque
c'est le niveau technique - qu'une portion d'une rue lorsqu'il se trouvait
qu'il y avait un panneau de signalisation dans cette rue.

C'est pas mal pour une version alpha, non :-) Merci de l'encouragement :-)

Cordialement.



-- 
Les dérives de rue :
Le projet de théâtre de Saint-Étienne emporté par le
vent

___
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.

[Ista Pouss]

Le 28 juin 2013 16:48, Pieren  a écrit :

> Ce nouvel objet est peut-être mauvais mais il brise l'ID (on devrait
> plutot dire l'url ou "lien court vers overpass") du premier objet qui
> lui est encore correct. Sans rien altérer à l'objet original, l'ID
> "permanent" ne l'est plus.
>
>
Oui, je prévois que ça fonctionne comme ça.

Il faudra "corriger" le nouvel objet polluant, ou modifier la règle, ou je
ne sais quoi d'autre.

... si mon système trouve des usages, évidemment.

En tous les cas je vous remercie tous pour vos questions et remarques qui
me permettent de réfléchir et de perfectionner mon système, je vous tiens
au courant !

Cordialement.


___
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.

[Julien Balas]

On 28/06/2013 16:56, Ista Pouss wrote:
Le 28 juin 2013 16:31, Julien Balas > a écrit :


Il y a visiblemen une incomprehension du modele OSM de ton coté.
Une rue de la réalité est representée par plusieurs segments OSM.
Dans ton exemple il y a 2 segments pour la rue brossard, mais il
pourrait y en avoir beaucoup +,
avec des vitesses differentes, certains morceaux en sens unique,
d'autre qui font parti d'un circuit(relation) de bus, un morceaux
de bande cyclable, des pavés, etc.
Chaque fois qu'on veut avoir des tags differents sur une portion
de route, on coupe en 2 et ca crée 1 way(segment) suplementaire


Alors il faudrait aussi l'expliquer à ceux qui ont fait le moteur de 
recherche d'OSM car eux, lorsque je demande cette rue, ils ne me 
renvoient qu'une seule portion de la rue.


Tout a fait, le moteur de recherche est perfectible.

L'idée (pas encore mis en oeuvre je trouve) c'est que le site OSM est le 
site des gens qui contribue a OSM. Donc avec une vision un peut technique.
Et que les utilisateurs finaux vont (ou iront un jour) sur des sites 
grand public qui utilise OSM mais avec une autre interface


mapquest (qui est un site grand public qui utilise les données OSM)
donne UN point de la rue, ca résoud (ou pas) le probleme de l'utilisateur.
http://mapq.st/112eqTU

--
JB

___
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.

[Ista Pouss]

Le 28 juin 2013 16:35, Pieren  a écrit :

> Une rue peut être segmentée en plusieurs ways. C'est très courant dans
> OSM. Il peut y avoir une raison légitime, comme des attributs
> spécifiques à une portion de la rue (ici, lanes=2) ou une partie en
> sens unique ou etc... Ca peut aussi être géométrique, comme lorsqu'un
> sens giratoire ajoute une certaine distance entre 2 segments. Et même
> s'il n'y a pas de raison légitime, il arrive qu'une rue soit
> sectionnée en 2,3,4,etc morceaux sans que cela soit considéré que
> "faux" dans OSM. On peut les fusionner si on veut mais c'est pas une
> erreur.
>


Le moteur de recherche d'OSM ne le comprend pas ainsi.

Mais il est possible que ce soit le moteur de recherche qui se trompe. Si
c'est le cas, alors je réfléchirai à une autre règle pour découvrir les
rues.

Cordialement.
___
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.

[Ista Pouss]

Le 28 juin 2013 16:31, Julien Balas  a écrit :

> Il y a visiblemen une incomprehension du modele OSM de ton coté.
> Une rue de la réalité est representée par plusieurs segments OSM.
> Dans ton exemple il y a 2 segments pour la rue brossard, mais il pourrait
> y en avoir beaucoup +,
> avec des vitesses differentes, certains morceaux en sens unique, d'autre
> qui font parti d'un circuit(relation) de bus, un morceaux de bande
> cyclable, des pavés, etc.
> Chaque fois qu'on veut avoir des tags differents sur une portion de route,
> on coupe en 2 et ca crée 1 way(segment) suplementaire
>
>
Alors il faudrait aussi l'expliquer à ceux qui ont fait le moteur de
recherche d'OSM car eux, lorsque je demande cette rue, ils ne me renvoient
qu'une seule portion de la rue.




>
>> Donc, je ne sais pas si ma règle est juste, mais au moins j'ai trouvé ce
>> qui me semble être une erreur dans osm :-)
>>
>>
> non, tout vas bien :)
> la rue de Lodi un peut au nord de la rue de brossard est aussi en 2
> segments, chacun en sens unique dans un sens différent.
> C'est normal, c'est la même rue, mais les deux morceaux ont un
> fonctionnement différents, donc on fait 2 segments, donc 2 way.
>
>
Là encore, le moteur de recherche se trompe, alors : il ne montre qu'une
partie de cette rue.

Lorsque que quelqu'un demande une rue, il demande la rue, pas une portion
de cette rue découpée selon les panneaux de circulation.

Cordialement.
___
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.

[Ista Pouss]

Le 28 juin 2013 16:18, Philippe Verdy  a écrit :

> Je suis aussi d'avis que ces IDs générés en interne par une base privée
> sont du même type que ceux généras par un des nombreux services de type
> TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
> ni même librement utilisables (et sans suivi de leur utilisation par un
> tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
> données modifiées de son choix dans le trafic).
>
>
Oui, bien sûr, ok, mais le mien ?? Moi c'est vachement mieux :-)



> Si des IDs stables doivent exister pour référencer des objets OSM, ils
> doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
> des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
> identifiants INSEE par exemple, librement vérifiables).
>
>
Je n'empêche personne de procéder ainsi.

Il me semble, toutefois, que la création de tels identifiants, nécéssite de
poser le même genre de questions que celles que j'essaie de proposer :
qu'est-ce qui caractérise un objet ? Qu'est ce qui permet de le reconnaître
? Qu'est ce qui définit leur égalité ? Comment les hasher ?

Mais enfin, on verra.


La "stabilité" des IDs est très relative : elle n'est garantie que si ils
> sont datés avec leur date de validité, les objets référencés pouvant à tout
> moment changer de statut. Si un ID stable devait être utilisé, il devrait
> au minimum inclure l'année de leur création
> - soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
> ref:INSEE=35238),
> - soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
> d'avoir une autre clé pour d'autres années après un changement de l'objet
> référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
> autre voisine).
> Ensuite à charge pour les outils de recherche et de mise en relation avec
> d'autres bases de faire les correspondances avec ces IDs stables, en tenant
> compte de l'année s'il y a des IDs différents pour la même base de
> référence (ici celle de l'lNSEE).
>
>
Oui, enfin bon, OK. La stabilité comme tu dis des ID est effectvement un
problème, puisque l'objet peut se modifier de toutes formes.

Mais, à l'inverse, on peut dire que les risques de modifications
permanentes rendent plus intéressantes encore l'existence d'un ID :-)



>
> Les IDs externes ne sont utiles que si la base externe est bien la source
> de référence principale et fiable de vérification des données (cette
> fiabilité pouvant être garanti par la loi quand elle oblige une entité à
> s'inscrire dans un registre officiel reconnu, dont le nombre est
> relativement limité). S'il s'agit par exemple d'un point géodésique en
> France, la base de référence française est bien connue et c'est d'elle
> qu'on tire l'identifiant externe. S'il s'agit d'un identifiant de société
> ou d'un établissement de cette société, il n'y a que les identifiants au
> RCS et SIREN+SIRET qui sont stables et fiables (mais eux aussi devrait être
> datés), mais on peut ajouter le numéro fiscal européen.
>
>
Donc... les IDs externes sont bien intéressants, si je résume bien ta
pensée ?...

Merci :-)

Cordialement.
___
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.

[Pieren]

2013/6/28 Ista Pouss :
> Je ne garantie rien, je dis seulement que la règle est susceptible de former
> cohérence, et si, plus tard, il apparait un autre objet ayant les mêmes
> caractéristiques, alors je peux au moins affirmer que cet objet est, selon
> toute probabilité, mauvais :-)

Ce nouvel objet est peut-être mauvais mais il brise l'ID (on devrait
plutot dire l'url ou "lien court vers overpass") du premier objet qui
lui est encore correct. Sans rien altérer à l'objet original, l'ID
"permanent" ne l'est plus.

Pieren

___
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.

[Ista Pouss]

Le 28 juin 2013 14:38, Pieren  a écrit :

> 2013/6/28 Ista Pouss :
>
> > 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 quoi l'ID Overpass ? Comment fais-tu pour convertir la requête
> 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
>
>
L'ID Overpass est expliqué là :
http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Les explications sont malheureusement un peu obscures (j'observe avec
plaisir qu'il n'y a pas que moi à avoir du mal à m'expliquer) car ils
mélangent (il me semble) avec des notions de template wiki, mais l'idée est
que certaines requêtes overpass renvoient un seul objet osm, et que donc la
requête peut servir d'id pour cet objet.

Cependant, au départ, on ne sait pas si la requête donnera un objet unique.
C'est à ce niveau que mon système intervient.

En toute rigueur, je ne transforme pas cet id overpass en un id à moi ou
vice versa. Je fais les opérations suivantes :

1) requête overpass selon les critères donnés.
2) vérification que chaque objet renvoyé par la requête est unique selon
les critères donnés
3) si ok, fabrication de "mon" id. L'id overpass, de toutes façons, se
fabrique de lui même si l'on peut dire.


en un numéro "magique" "71435" ou ("stephboulange/71435") ?
>
> Est-ce que, comme le suggère Frederic, c'est juste un short-link, un
> hash-map stocké sur ton serveur ou celui d'overpass ? Cela veut-il
> dire qu'une autre instance d'overpass donnera un autre chiffre ?
>

Non, tel que je comprends le fonctionnement d'overpass en tous cas, tous
les ids overpass donneront le même résultat pour toutes les instances
overpass (à part l'extrait url serveur bien sûr). Cet id est prévisible, à
partir du moment où l'on sait que s'en est un.

Mon id à moi peut se comprendre comme un hashmap, stocké sur mon ordinateur
à moi. Actuellement c'est un stupide id de base de donnée, mais on peut
imaginer n'importe quoi d'autre.



> Est-ce que ça fonctionne encore si la requête retourne plusieurs
> objets ? Comment garanties-tu l'unicité si un autre objet contenant
> les mêmes caractéristiques apparait plus-tard dans le même
> bounding-box, ça marchera encore ?
>
>
Si la requête retourne plusieurs objets, alors elle n'est plus considérée
comme un id d'objet :-) c'est aussi simple que ça :-)

Je ne garantie rien, je dis seulement que la règle est susceptible de
former cohérence, et si, plus tard, il apparait un autre objet ayant les
mêmes caractéristiques, alors je peux au moins affirmer que cet objet est,
selon toute probabilité, mauvais :-)

Cet aspect du service n'est pas encore développé, mais je compte m'y
attaquer le plus rapidement possible. Dans la situation actuelle, en
version super alpha, il n'y a aucune actualisation.

 Cordialement.


-- 
Les dérives de rue :
Le projet de théâtre de Saint-Étienne emporté par le
vent

___
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.

[Pieren]

2013/6/28 Ista Pouss :

> Donc, soit la règle est mauvaise, soit les données OSM sont mauvaises, soit
> tous les deux sont mauvais. Ici, je pense, si je puis me permettre, que les
> données OSM sont mauvaiises, car déjà il n'y a qu'une seule rue brossard à
> st etienne, et si je fais une recherche "Rue Brossard, saint etienne" (je ne
> sais pas comment faire pour vous donner le lien direct de cette recherche),
> alors j'obtiens une seule rue à st etienne (bien), mais il ne me la marque
> que sur une portion de la rue (mauvais). On voit qu'OSM n'est pas cohérent
> avec lui même : il devrait me marquer toute la rue Brossard, et non pas
> seulement une portion.

Une rue peut être segmentée en plusieurs ways. C'est très courant dans
OSM. Il peut y avoir une raison légitime, comme des attributs
spécifiques à une portion de la rue (ici, lanes=2) ou une partie en
sens unique ou etc... Ca peut aussi être géométrique, comme lorsqu'un
sens giratoire ajoute une certaine distance entre 2 segments. Et même
s'il n'y a pas de raison légitime, il arrive qu'une rue soit
sectionnée en 2,3,4,etc morceaux sans que cela soit considéré que
"faux" dans OSM. On peut les fusionner si on veut mais c'est pas une
erreur.

Pieren

___
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.

[Julien Balas]

Qu'observe-je ? Que la règle ne marche pas, car il y a des ways qui 
ont même highway et même nom, tel la rue Brossard, ici 
http://www.openstreetmap.org/browse/way/30878250 et là 
http://www.openstreetmap.org/browse/way/33630650


Donc, soit la règle est mauvaise, soit les données OSM sont mauvaises, 
soit tous les deux sont mauvais. Ici, je pense, si je puis me 
permettre, que les données OSM sont mauvaiises, car déjà il n'y a 
qu'une seule rue brossard à st etienne, et si je fais une recherche 
"Rue Brossard, saint etienne" (je ne sais pas comment faire pour vous 
donner le lien direct de cette recherche), alors j'obtiens une seule 
rue à st etienne (bien), mais il ne me la marque que sur une portion 
de la rue (mauvais). On voit qu'OSM n'est pas cohérent avec lui même : 
il devrait me marquer toute la rue Brossard, et non pas seulement une 
portion.

Il y a visiblemen une incomprehension du modele OSM de ton coté.
Une rue de la réalité est representée par plusieurs segments OSM.
Dans ton exemple il y a 2 segments pour la rue brossard, mais il 
pourrait y en avoir beaucoup +,
avec des vitesses differentes, certains morceaux en sens unique, d'autre 
qui font parti d'un circuit(relation) de bus, un morceaux de bande 
cyclable, des pavés, etc.
Chaque fois qu'on veut avoir des tags differents sur une portion de 
route, on coupe en 2 et ca crée 1 way(segment) suplementaire


Donc, je ne sais pas si ma règle est juste, mais au moins j'ai trouvé 
ce qui me semble être une erreur dans osm :-)




non, tout vas bien :)
la rue de Lodi un peut au nord de la rue de brossard est aussi en 2 
segments, chacun en sens unique dans un sens différent.
C'est normal, c'est la même rue, mais les deux morceaux ont un 
fonctionnement différents, donc on fait 2 segments, donc 2 way.


--
JB


___
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.

[Philippe Verdy]

Sinon en dehors des identifiants, on a en France aussi les codes APE qui
permettent de classer les activités (cela permettrait de dégrossir les
types de commerce par exemple, même si les APE peuvent eux aussi changer et
devraient aussi être datés). Cela permettrait aussi des vérifications sur
les autres classifications OSM génériques (comme shop=*) pour détecter des
anomalies ou des oublis dans les tags génériques.


Le 28 juin 2013 16:18, Philippe Verdy  a écrit :

> Je suis aussi d'avis que ces IDs générés en interne par une base privée
> sont du même type que ceux généras par un des nombreux services de type
> TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
> ni même librement utilisables (et sans suivi de leur utilisation par un
> tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
> données modifiées de son choix dans le trafic).
>
> Si des IDs stables doivent exister pour référencer des objets OSM, ils
> doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
> des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
> identifiants INSEE par exemple, librement vérifiables).
>
> La "stabilité" des IDs est très relative : elle n'est garantie que si ils
> sont datés avec leur date de validité, les objets référencés pouvant à tout
> moment changer de statut. Si un ID stable devait être utilisé, il devrait
> au minimum inclure l'année de leur création
> - soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
> ref:INSEE=35238),
> - soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
> d'avoir une autre clé pour d'autres années après un changement de l'objet
> référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
> autre voisine).
> Ensuite à charge pour les outils de recherche et de mise en relation avec
> d'autres bases de faire les correspondances avec ces IDs stables, en tenant
> compte de l'année s'il y a des IDs différents pour la même base de
> référence (ici celle de l'lNSEE).
>
> Combien d'IDs garder ensuite dans la base OSM ? On peut faire le ménage en
> fonction des dates indiquées justement, qui permettent de procéder à des
> vérifications ultérieures ou des remises à jour (même si cela consiste
> seulement à garder l'identifiant en ne changeant que l'année), et en
> fonction de l'universalité de ces identifiants (les identifiants INSEE sont
> assez largement universels pour être gardés à demeure pour longtemps
> partout en France, tant que l'INSEE les maintiendra; mais l'INSEE peut
> aussi décider une année de revoir son propre système de codification et ces
> dates indiquées dans des références supplémentaires historiques seront
> utiles pendant une période de transition assez longue). Ces identifiants
> sont plus universels que bien d'autres d'origine privée (mais d'usage
> limité au seul domaine de leur concepteur).
>
> Les IDs externes ne sont utiles que si la base externe est bien la source
> de référence principale et fiable de vérification des données (cette
> fiabilité pouvant être garanti par la loi quand elle oblige une entité à
> s'inscrire dans un registre officiel reconnu, dont le nombre est
> relativement limité). S'il s'agit par exemple d'un point géodésique en
> France, la base de référence française est bien connue et c'est d'elle
> qu'on tire l'identifiant externe. S'il s'agit d'un identifiant de société
> ou d'un établissement de cette société, il n'y a que les identifiants au
> RCS et SIREN+SIRET qui sont stables et fiables (mais eux aussi devrait être
> datés), mais on peut ajouter le numéro fiscal européen.
>
>
>
>
>
> Le 28 juin 2013 14:38, Pieren  a écrit :
>
> 2013/6/28 Ista Pouss :
>>
>> > 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 quoi l'ID Overpass ? Comment fais-tu pour convertir la requête
>> 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
>>
>> en un numéro "magique" "71435" ou ("stephboulange/71435") ?
>>
>> Est-ce que, comme le suggère Frederic, c'est juste un short-link, un
>> hash-map stocké sur ton serveur ou celui d'overpass ? Cela veut-il
>> dire qu'une autre instance d'overpass donnera un autre chiffre ?
>> Est-ce que ça fonctionne encore si la requête retourne plusieurs
>> objets ? Comment garanties-tu l'unicité si un autre objet contenant
>> les mêmes caractéristiques apparait plus-tard dans le même
>> bounding-box, ça marchera encore ?
>>
>> Pieren
>>
>> ___
>> dev-fr mailing list
>> dev-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/dev-fr
>>
>
>
___
dev-fr mailing list
dev-fr@openstreetmap.org

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

[Philippe Verdy]

Je suis aussi d'avis que ces IDs générés en interne par une base privée
sont du même type que ceux généras par un des nombreux services de type
TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
ni même librement utilisables (et sans suivi de leur utilisation par un
tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
données modifiées de son choix dans le trafic).

Si des IDs stables doivent exister pour référencer des objets OSM, ils
doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
identifiants INSEE par exemple, librement vérifiables).

La "stabilité" des IDs est très relative : elle n'est garantie que si ils
sont datés avec leur date de validité, les objets référencés pouvant à tout
moment changer de statut. Si un ID stable devait être utilisé, il devrait
au minimum inclure l'année de leur création
- soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
ref:INSEE=35238),
- soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
d'avoir une autre clé pour d'autres années après un changement de l'objet
référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
autre voisine).
Ensuite à charge pour les outils de recherche et de mise en relation avec
d'autres bases de faire les correspondances avec ces IDs stables, en tenant
compte de l'année s'il y a des IDs différents pour la même base de
référence (ici celle de l'lNSEE).

Combien d'IDs garder ensuite dans la base OSM ? On peut faire le ménage en
fonction des dates indiquées justement, qui permettent de procéder à des
vérifications ultérieures ou des remises à jour (même si cela consiste
seulement à garder l'identifiant en ne changeant que l'année), et en
fonction de l'universalité de ces identifiants (les identifiants INSEE sont
assez largement universels pour être gardés à demeure pour longtemps
partout en France, tant que l'INSEE les maintiendra; mais l'INSEE peut
aussi décider une année de revoir son propre système de codification et ces
dates indiquées dans des références supplémentaires historiques seront
utiles pendant une période de transition assez longue). Ces identifiants
sont plus universels que bien d'autres d'origine privée (mais d'usage
limité au seul domaine de leur concepteur).

Les IDs externes ne sont utiles que si la base externe est bien la source
de référence principale et fiable de vérification des données (cette
fiabilité pouvant être garanti par la loi quand elle oblige une entité à
s'inscrire dans un registre officiel reconnu, dont le nombre est
relativement limité). S'il s'agit par exemple d'un point géodésique en
France, la base de référence française est bien connue et c'est d'elle
qu'on tire l'identifiant externe. S'il s'agit d'un identifiant de société
ou d'un établissement de cette société, il n'y a que les identifiants au
RCS et SIREN+SIRET qui sont stables et fiables (mais eux aussi devrait être
datés), mais on peut ajouter le numéro fiscal européen.





Le 28 juin 2013 14:38, Pieren  a écrit :

> 2013/6/28 Ista Pouss :
>
> > 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 quoi l'ID Overpass ? Comment fais-tu pour convertir la requête
> 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
>
> en un numéro "magique" "71435" ou ("stephboulange/71435") ?
>
> Est-ce que, comme le suggère Frederic, c'est juste un short-link, un
> hash-map stocké sur ton serveur ou celui d'overpass ? Cela veut-il
> dire qu'une autre instance d'overpass donnera un autre chiffre ?
> Est-ce que ça fonctionne encore si la requête retourne plusieurs
> objets ? Comment garanties-tu l'unicité si un autre objet contenant
> les mêmes caractéristiques apparait plus-tard dans le même
> bounding-box, ça marchera encore ?
>
> Pieren
>
> ___
> 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.

[Ista Pouss]

Le 28 juin 2013 14:18, Frédéric Rodrigo  a écrit :

> C'est tes ID à toi qui sont obscures.
>
>
Oui ça je sais :-) À ma défense je fais de gros efforts pour expliquer :-)



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.
>
>
Et bien c'est déjà bien non ?

En plus, mon ambition est de faciliter la recherche de règles pour que
chaque élément renvoyé soit unique, selon la règle donnée. C'est à dire que
l'on recherche une organisation cohérente dans les données OSM.

Imaginons par exemple que je veuille les éléments filtrés selon les tags
tata et toto. Le logiciel vérifie qu'il n'y a pas deux éléments qui aurait
tata=xyz et toto=foo ; du coup, la règle permet de définir des ids.



>  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 ?
>
>
Sur les points géodésiques, il s'agissait de deux noeuds pour le même point
géodésique.

Un autre exemple. Soit les rues de Saint Etienne. Je voudrais créer un
identifiant unique pour chaque rue. Je postule que chaque rue est
déterminée par son tag higway, et par son nom. Peut être est-ce faux, mais
enfin admettons.

Cela se voit à cette page :
http://www.diaam.com:8080/idalacarte/creaid.jsp?nomDeRegle=stephrues2

Qu'observe-je ? Que la règle ne marche pas, car il y a des ways qui ont
même highway et même nom, tel la rue Brossard, ici
http://www.openstreetmap.org/browse/way/30878250 et là
http://www.openstreetmap.org/browse/way/33630650

Donc, soit la règle est mauvaise, soit les données OSM sont mauvaises, soit
tous les deux sont mauvais. Ici, je pense, si je puis me permettre, que les
données OSM sont mauvaiises, car déjà il n'y a qu'une seule rue brossard à
st etienne, et si je fais une recherche "Rue Brossard, saint etienne" (je
ne sais pas comment faire pour vous donner le lien direct de cette
recherche), alors j'obtiens une seule rue à st etienne (bien), mais il ne
me la marque que sur une portion de la rue (mauvais). On voit qu'OSM n'est
pas cohérent avec lui même : il devrait me marquer toute la rue Brossard,
et non pas seulement une portion.

Donc, je ne sais pas si ma règle est juste, mais au moins j'ai trouvé ce
qui me semble être une erreur dans osm :-)

Cordialement.


-- 
Les dérives de rue :
Le projet de théâtre de Saint-Étienne emporté par le
vent

___
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.

[Pieren]

2013/6/28 Ista Pouss :

> 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 quoi l'ID Overpass ? Comment fais-tu pour convertir la requête 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

en un numéro "magique" "71435" ou ("stephboulange/71435") ?

Est-ce que, comme le suggère Frederic, c'est juste un short-link, un
hash-map stocké sur ton serveur ou celui d'overpass ? Cela veut-il
dire qu'une autre instance d'overpass donnera un autre chiffre ?
Est-ce que ça fonctionne encore si la requête retourne plusieurs
objets ? Comment garanties-tu l'unicité si un autre objet contenant
les mêmes caractéristiques apparait plus-tard dans le même
bounding-box, ça marchera encore ?

Pieren

___
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
 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] Paratage de DEM ( était Héberger le rendu HOT?)

[Yohan Boniface]

On 06/27/2013 03:40 PM, sly (sylvain letuffe) wrote:

Côté calque hillshade, mon idée générale pour l'instant c'est d'utiliser
>un .vrt qui référence les tif moulinés, apparemment c'est ce qui se fait.

Je ne travail pas sur le monde mais juste sur l'europe (780°²) et j'ai opté
pour un seul et unique fichier tif (9Go)

N'ayant pas trop fait d'essais avec la solution d'un vrt et d'une grosse
arborescence, je ne saurais dire si c'est mieux ou moins bien. Si ce n'est
sans doute que ma technique ajoute une monstre opération à base de
gdal_merge.py pour produire un fichier titan.



Sur ce point, j'ai eu des précisions d'Andy Allan (Gravitystorm, 
Thunderforest): lui il utilise carrément des dalles de 1x1 (donc des 
dizaines de milliers de fichiers) dans son vrt.
Ce qui me fait dire qu'on doit pouvoir se passer de l'étape du merge dès 
lors qu'on utilise un vrt.


___
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

[Etienne Trimaille]

Gmail -> Paramètres -> Labos -> Annuler l'envoi -> activer ;-)



Le 28 juin 2013 09:16, Ista Pouss  a écrit :

> Heu... cette merde de gmail a envoyé le courrier sans que je le veuille...
> Faites comme si vous ne l'avez pas vu, je continue la rédaction, et vous
> enverrez le message complet sous peu.
>
> Désolé :-(
>
>
> Le 28 juin 2013 09:14, Ista Pouss  a écrit :
>
> Bonjour,
>>
>> Si vous avez suivi mes pensées profondes, vous savez que je milite pour
>> le développement de systèmes d'identificateurs personnels des objets
>> géographiques, que chacun pourrait créer, diffuser, échanger...
>>
>> Et bien voilà !
>> http://www.diaam.com:8080/idalacarte/index.jsp
>>
>> ... mais en version 0.0.0.0.0.0,1 Alpha.
>>
>> J'ai appelé ça "ID à la carte" - il me semble en effet que l'expression
>> "à la carte" se comprend aussi bien en anglais qu'en français, qu'elle a le
>> même sens dans les deux langues, et que, cerise sur le gateau, elle dit
>> bien ce que je veux dire, et qu'en plus elle parle de carte !
>>
>> 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).
>>
>> Soit l'exemple vachement intéressant des boulangeries stéphanoises :
>> http://www.diaam.com:8080/idalacarte/ids/stephboulange
>>
>> Le jeu {shop=bakery, name=} forme règle valide du point de vue de
>> l'identificateur unique.
>>
>> Tenez vous bien, la boulangerie "L
>>
>> --
>> Les dérives de rue :
>> Le projet de théâtre de Saint-Étienne emporté par le 
>> vent
>>  
>>
>
>
>
> --
> Les dérives de rue :
> Le projet de théâtre de Saint-Étienne emporté par le 
> vent
>  
>
> ___
> 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

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

[Ista Pouss]

Bonjour,

Si vous avez suivi mes pensées profondes, vous savez que je milite pour le
développement de systèmes d'identificateurs personnels des objets
géographiques, que chacun pourrait créer, diffuser, échanger...

Et bien voilà !
http://www.diaam.com:8080/idalacarte/index.jsp

... mais en version 0.0.0.0.0.0,1 Alpha.

J'ai appelé ça "ID à la carte" - il me semble en effet que l'expression "à
la carte" se comprend aussi bien en anglais qu'en français, qu'elle a le
même sens dans les deux langues, et que, cerise sur le gateau, elle dit
bien ce que je veux dire, et qu'en plus elle parle de carte !

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).

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 !

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 qui me semble (un
peu) plus pratique.

Voilà pour les principes... La mise en oeuvre est un peu plus hasardeuse.

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.

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 ?

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.

Cordialement.


(et encore désolé pour le double post).

-- 
Les dérives de rue :
Le projet de théâtre de Saint-Étienne emporté par le
vent

___
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

[Ista Pouss]

Heu... cette merde de gmail a envoyé le courrier sans que je le veuille...
Faites comme si vous ne l'avez pas vu, je continue la rédaction, et vous
enverrez le message complet sous peu.

Désolé :-(


Le 28 juin 2013 09:14, Ista Pouss  a écrit :

> Bonjour,
>
> Si vous avez suivi mes pensées profondes, vous savez que je milite pour le
> développement de systèmes d'identificateurs personnels des objets
> géographiques, que chacun pourrait créer, diffuser, échanger...
>
> Et bien voilà !
> http://www.diaam.com:8080/idalacarte/index.jsp
>
> ... mais en version 0.0.0.0.0.0,1 Alpha.
>
> J'ai appelé ça "ID à la carte" - il me semble en effet que l'expression "à
> la carte" se comprend aussi bien en anglais qu'en français, qu'elle a le
> même sens dans les deux langues, et que, cerise sur le gateau, elle dit
> bien ce que je veux dire, et qu'en plus elle parle de carte !
>
> 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).
>
> Soit l'exemple vachement intéressant des boulangeries stéphanoises :
> http://www.diaam.com:8080/idalacarte/ids/stephboulange
>
> Le jeu {shop=bakery, name=} forme règle valide du point de vue de
> l'identificateur unique.
>
> Tenez vous bien, la boulangerie "L
>
> --
> Les dérives de rue :
> Le projet de théâtre de Saint-Étienne emporté par le 
> vent
>  
>



-- 
Les dérives de rue :
Le projet de théâtre de Saint-Étienne emporté par le
vent

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

[OSM-dev-fr] Des IDs a votre bon coeur

[Ista Pouss]

Bonjour,

Si vous avez suivi mes pensées profondes, vous savez que je milite pour le
développement de systèmes d'identificateurs personnels des objets
géographiques, que chacun pourrait créer, diffuser, échanger...

Et bien voilà !
http://www.diaam.com:8080/idalacarte/index.jsp

... mais en version 0.0.0.0.0.0,1 Alpha.

J'ai appelé ça "ID à la carte" - il me semble en effet que l'expression "à
la carte" se comprend aussi bien en anglais qu'en français, qu'elle a le
même sens dans les deux langues, et que, cerise sur le gateau, elle dit
bien ce que je veux dire, et qu'en plus elle parle de carte !

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).

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

Le jeu {shop=bakery, name=} forme règle valide du point de vue de
l'identificateur unique.

Tenez vous bien, la boulangerie "L

-- 
Les dérives de rue :
Le projet de théâtre de Saint-Étienne emporté par le
vent

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